Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Python

Interviews: Guido van Rossum Answers Your Questions 169

Last week you had a chance to ask Guido van Rossum, Python's BDFL (Benevolent Dictator For Life), about all things Python and his move to Dropbox. Guido wasted no time answering your questions and you'll find his responses below.
From Google to Dropbox
by nurhussein

Hi, What prompted the move from Google to Dropbox? What did you do at Google, and what are you going to do at Dropbox?

Guido: After seven years at Google I was just ready for some change in environment, and then the Dropbox offer came along. At a high level, my job hasn't changed much: I still

- spend 50% of my time on whatever I want to do for Python in my BDFL role
- am a regular engineer in the organization (not a manager or even TL)
- do a lot of code reviews, architecture and design work
- handle a lot of email
- do a lot of actual coding for my job, in Python

The specifics differ of course. I really did only two things at Google: the first two years I worked on one of the first online code review tools Mondrian, which itself was never open-sourced but begat Rietveld, which did, and is used amongst others, by the Python, Go and Chromium communities. After that I joined Google App Engine where I did a lot of different things, almost all of them in Python. My last big project there was a new Python database API, NDB.

I've been at Dropbox for 7 months and my main project has been the design of the Dropbox Datastore API . It's ironic but not my fault that this also uses the "datastore" moniker -- there's little overlap between Dropbox Datastores and the Google App Engine Datastore.

What's even more ironic is that even though I did much of the design, and wrote two prototypes in Python, the SDKs we released last month only support Java, Objective-C and JavaScript. But I am working on a fix, this interview is just slowing me down. :-)



Why did Python avoid some common "OO" idioms?
by i_ate_god

Interfaces, abstract classes, private members, etc... Why did python avoid all this?

Guido: I can think of two reasons: (a) you don't really need them, and (b) they are hard to do if you have no compile-time type checking. Python started out as a skunkworks project (not endorsed or encouraged by management but not actively prevented), and I wanted results quickly. This led me to remove features that weren't actually needed or urgent; it also led me to do all type checking at run time, which gave me natural constraints on what features Python could support. I also had no religious OO ax to grind -- I just wanted an easy language, and it became OO more or less by accident.

In modern Python there are rough equivalents for all of these, but they don't necessarily work all that well, or they cause a lot of execution overhead, so they are often avoided, but they have their uses and their fans.



functional programming
by ebno-10db

Some people claim that Python is, at least partly, a functional language. You disagree, as do I. Simply having a few map and filter type functions does not make for a functional language. As I understand it those functions were added to the libraries by a homesick Lisper, and that several times you've been tempted to eliminate them. In general it seems you're not a fan of functional programming, at least for Python.

Question: do you feel that the functional programming approach is not very useful in general, or simply that it's not appropriate for Python? It would be nice to hear your reasons either way.


Guido: I'm not a fan of religiously taking some idea to the extreme, and I try to be pragmatic in my design choices (but not *too* pragmatic, see the start of this sentence :-). I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added builtin sum() at the same time we demoted reduce() from a builtin to something in functools (which is a dumping ground for stuff I don't really care about :-).

If I think of functional programming, I mostly think of languages that have incredibly powerful compilers, like Haskell. For such a compiler, the functional paradigm is useful because it opens up a vast array of possible transformations, including parallelization. But Python's compiler has no idea what your code means, and that's useful too. So, mostly I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers).

I also don't think that the current crop of functional languages is ready for mainstream. Admittedly I don't know much about the field besides Haskell, but any language *less* popular than Haskell surely has very little practical value, and I haven't heard of functional languages *more* popular than Haskell. As for Haskell, I think it's a great proving ground for all sorts of ideas about compiler technology, but I think its "purity" will always remain in the way of adoption. Having to come to grips with Monads just isn't worth it for most people.

(A similar comment applies to Scala. It may be the best you can do trying to combine functional and OO paradigms in one language, but the result isn't all that easy to use unless you're really smart.)



Multi-line lambdas
by NeverWorker1

One of the most common complaints about Python is the limitations of its lambdas, namely being one line only without the ability to do assignments. Obviously, Python's whitespace treatment is a major part of that (and, IIRC, I've read comments from you to that effect). I've spent quite a bit of time thinking about possible syntax for a multi-line lambda, and the best I've come up with is trying to shoehorn some unused (or little used) symbol into a C-style curly brace, but that's messy at best. Is there a better way, and do you see this functionality ever being added?

Guido: Really? I almost never hear that complaint except from people who submit questions to Slashdot interviews. :-)

There is indeed a better way, and that is using the 'def' keyword to define a regular function in a local scope. The defined function object becomes a local variable that has exactly the same semantics as a lambda except that it is bound to a local variable, and it doesn't have any of the syntactic constraints. For example, there is *no* semantic difference between

def make_adder(n):
__def adder(x):
____return x + n
__return adder

and this equivalent using lambda:

def make_adder(n):
__return lambda x: x + n

(except that when you introspect the lambda asking for its name, it will say '' instead of 'adder').

Andrew Koenig once pointed out to me that there's one pattern where lambdas are really much more convenient, and that is if you have a long list or dict (perhaps some kind of switching definition) containing lots of lambdas, since if you wanted to do that without lambda you'd end up first having to define lots of little functions, giving them all names, and then referencing them all by name from inside the list or dict. But in that pattern the lambdas are usually simple enough to be lambdas, and if you have a few exceptions, using 'def' before starting the list or dict is a fine compromise.



PyPy
by Btrot69

Do you see PyPy as the future? Or do you remain unconvinced, and -- if so -- why ?

Guido: I'm still unconvinced, for two reasons: (a) they don't support Python 3 (well) yet, and (b) there are lots of extension modules (both third party and in the standard library) that they don't support well. But I hope they'll fix those issues. I think it's competition from projects like PyPy, Jython and IronPython that keeps the CPython project honest and on its toes.



Python in the browser ?
by Btrot69

Over the years, there have been several attempts to create a sandboxed version of python that will safely run in a web browser.Mostly this was because of problems with Javascript. Now that Javascript works -- and we have nice things like CoffeeScript -- is it time to give up on python in the browser ?

Guido: I gave up on it in 1995, so yes. And please don't try to compile Python to JavaScript. The semantics are so different that you end up writing most of a Python runtime in JavaScript, which slows things down too much. (CoffeScript's strength is that it is designed to map cleanly to JavaScript, and the two are now co-evolving to make the mapping even cleaner.)



Python 3
by MetalliQaZ

How do you feel about the current state of the migration to Python 3 (Py3k)? From a user perspective it seems that the conversion of popular libraries has lagged far behind, which has impeded the transition. In my professional capacity, nearly every single system I use lacks an installed 3.x interpreter. In fact, 2.7 is a rarity. I'd like to get your thoughts.

Guido: Curious where you work. I agree that Python 3 migration will still take a long time, but if your systems don't come with Python 2.7 they must be pretty ancient! When I left Google they were about done with the internal transition to Python 2.7 (having successfully migrated from 2.4 to 2.6 over the past few years) and here at Dropbox both the client and the server are using Python 2.7. Both companies are already thinking about Python 3 too.

Back to Python 3 migration, I am actually pretty optimistic. Lots of popular libraries have a working port or are working on one. (The Python Software Foundation also occasionally funds projects to port libraries that are widely used but don't have enough of a community to do a port.) It will take a long time, but I see a lot of progress, and in a few years I expect most new code will be written in Python 3. Totally eradicating Python 2 usage will probably take much longer, but then again, Windows XP isn't quite dead yet either. :-)



Key question for any language designer
by dkleinsc

Have the prospects of Python in any way improved since you grew a beard? To what degree does language success correlate to beard length?

Guido: It is absolutely essential. Just look at Perl's fate -- Larry Wall is just too clean-shaven. :-)
This discussion has been archived. No new comments can be posted.

Interviews: Guido van Rossum Answers Your Questions

Comments Filter:
  • by EricTheGreen ( 223110 ) on Monday August 26, 2013 @11:15AM (#44677433) Homepage

    but any language *less* popular than Haskell surely has very little practical value, and I haven't heard of functional languages *more* popular than Haskell.

    There is this language called Lisp. Might have heard of it before.

    Erlang, also.

    I understand the kiddies are feeling the Clojure love these days as well (although I suppose that just ends up categorized as a Lisp subset)

    C'mon Guido, you're smarter than this...

    • If Lisp was going to take over the world, or even just be used in as much as 10% of the software created in any given year, it would have done it already. That, I think, is the entire reason why Clojure ( and before Clojure, Scheme and Racket, https://en.wikipedia.org/wiki/Racket_(programming_language) [wikipedia.org], and since Clojure, Hy http://docs.hylang.org/en/latest/ [hylang.org] ) have been created - attempts to tweak the Lisp formula into something more palatable for the mainstream without losing any of the core features that make the language useful.

      I wish Lisp and Clojure were more prevalent. Most of my work experience is with Java, and now that I've become comfortable with Lisp and Clojure in my spare time I'm chafing at the tools I have to use for work. There just aren't that many jobs around, at least outside Silicon Valley, that use either language. So I'm trying to do useful Clojure stuff in my spare time in order to have a portfolio I can show off for a Clojure shop.

      But to your point, I think Guido is safe to dismiss Lisp - it's a spectacular functional language, it's one of the most well known functional languages, and at least in original and Common Lisp form it just can't get traction in the mainstream.
      • by HiThere ( 15173 )

        Lisp doesn't work well without a good IDE...and I don't count EMACS.

        Racket would be ok. It has a decent IDE. But it doesn't do multi-processing, even though it has the appropriate language features.

        I don't know Clojure well enough. The last time I tried it (over a year ago) the install instructions produced an only-partially-working result. This is probably NetBeans fault rather than Clojure, but I didn't follow this up. I never got as far as checking how it did on parallel processing.

        Most Scheme's and

        • Maybe I was lucky, the first time I tried Clojure was within the past year and the installation worked flawlessly. My biggest problem with the language is that some error messages from simple mistakes (mis-aligned parenthesis, etc..) are obtuse - I consider that an obstacle to adoption of the language. I've acquired the patience to work past errors like that, even though they drive me bonkers for the first few weeks I'm learning a new language. But that kind of thing can and will make the difference bet
          • by HiThere ( 15173 )

            D's basic language, and standard library, are excellent and solid. But they don't cover enough. This is probably inevitable, but it *IS* a real problem. The obvious way to solve it is to wrap C libraries with D code, and include them. This, however, takes the time and effort of skilled people.

            E.g.: Sqlite3 wrappers are currently included, but they are so thin that calling them wrappers is almost a misnomer. There have been several attempts to wrap Sqlite3 in the past, but they've all been completed, u

        • by Anonymous Brave Guy ( 457657 ) on Monday August 26, 2013 @03:39PM (#44680049)

          If you're going to depend on a set of public libraries instead of an included set, they you had better verify them for quality. This is why Python's "batteries included" stance is so good. You can depend on the basic libraries.

          Ironically, that's actually one of my biggest concerns about using Python. IME, the included batteries aren't very good, once you get past the first few parts of the library reference that everyone uses all the time. A lot of the later parts -- things like file and directory manipulation, data formats and compression tools, process control, networking, even some of the date/time functionality -- have elements that are horribly slow, platform-dependent, or simply too bug-ridden to trust in production.

          It's unfortunate that package management in Python is such a mess, mostly for historical reasons. There's quite a bit of good stuff on PyPI these days, and if we were starting over, I think we'd do better to limit the standard library to a much smaller set of essential foundations, and to promote the best libraries from outside sources via the standardised package repository and tools.

          • by HiThere ( 15173 )

            OK. I've never encountered that problem. Did you inform them of your problem? Ask about it on the list?

            • Assuming you're talking about the standard library rather than package management, unfortunately it's not just one problem. I'd estimate that I've found 20-25 significant library issues over the past few years of using Python on various projects.

              Most of these issues aren't really bugs in the sense that the output is objectively wrong, though. It's more things like OS differences not quite being abstracted away completely so that sometimes running another process needs slightly different presentation of argu

      • Even though I have mixed feelings about the Lisp family of languages, I wish they would become more popular. I've never been convinced that it's the One True Approach, but for some things they're great.

        Unfortunately, much of the Lisp(s) community is the biggest enemy of the broader adoption of Lisp(s). Part of the problem is that one has to refer to Lisp(s) in the plural. Common Lisp is clearly the most powerful variant, but it's byzantine in its (unnecessary) complexity and redundant features, as well as

        • I'm a Clojure fan, sorry. :) Clojure offers many things, but I think the three most important features it adds to the standard Lisp strengths are:
          1. Variables are immutable by default, though there are mechanisms for traditional mutable variables you have one extra step to use them. That makes it easier to reason about your code, without forcing every variable to be immutable like Haskell.
          2. It's interoperable with Java, so aside from the relatively small Clojure standard library your extended "standa
          • I agree points 2 and 3 are important. As for point 1, I didn't say that Clojure was a bad language (I don't even know it), just that it was YALV. Even if it's superior to other Lisp(s), it's still another step in the balkanization that has helped keep Lisp(s) in a niche.

            Having many standards is the same as having no standard, and often even a mediocre standard is better than no standard at all.

            • Right. But nobody in the Lisp community has the authority to fix the situation - and as you noted, the community is full of people who are opposed to any such fix, so the chances of someone entering the community to fix it is small.

              So the best possible solution, weak though it may be, is to create something new that just borrows strengths from Lisp but is intentionally different. Clojure is that kind of attempt at a fresh start, and it breaks some Lisp syntax (using square brackets in some cases) and in
    • FWIW Lisp isn't a functional programming language; it has functional parts, but it's a multi-paradigmatic language that includes object oriented programming. So yeah, it can be used like that, but modern Lisp is much, much more.

      Incidentally, currently my favorite part of Lisp that I wish was in other languages is the way the variable binding allows for easy dependency injection, even in places where it wasn't originally designed that way. It makes unit testing a lot easier.
    • by Anonymous Coward

      Guido, you're smarter than this...

      No, he isn't.
      If he was, Python would not rely on whitespace for scoping.

      • Actually, if other language designers were smarter, other languages would use indenting for blocks.* Eliminating redundancy is a general aim in computing. Languages that use curly brackets or other delimiters for blocks are unreadable unless they also use indenting. And once you have the redundancy of both delimiters AND whitespace you have the danger that the two may not be in agreement. Which is compounded by the one that the compiler relies on (delimiters) not being the same as the one that stands out

        • Actually, if other language designers were smarter, other languages would use indenting for blocks.* Eliminating redundancy is a general aim in computing. Languages that use curly brackets or other delimiters for blocks are unreadable unless they also use indenting. And once you have the redundancy of both delimiters AND whitespace you have the danger that the two may not be in agreement. Which is compounded by the one that the compiler relies on (delimiters) not being the same as the one that stands out most to the human (indenting.)

          Using indents for blocks has a drawback in that standard text editors aren't good at matching the indent level when cutting and pasting. But that simply means that only Python aware editors should be used for python code. Not difficult when most programmers use IDEs.

          * (Which is what you actually mean. Scope relies on more than whitespace.)

          You have almost achieved enlightment, grasshopper, but you have yet to catch that fly with your chopsticks...

          Q: Why is (for example) C reliant on human intervention for both curly-bracing and indentation? A: Because coders have a fetish for "human-readable" source code that can be used in a "dumb" text editor.

          Now, you state that the solution to the Python copy-and-paste problem is a "Python-aware" editor... so why shouldn't the solution to the braces/indentation redundancy in C, Java etc. be a C-/Java-awar

          • The "redundancy" is because we want human-readable source code, as you state.

            But it's not really redundant, because it (should) just be ADDITIONAL information.

            BTW, I like and use Python, but would pay money for a way I could turn off intent == scope *in a way that would work in every Python interpreter I'm likely to find*. (i.e. not a hack I have to add on and build my own interpreter)

            Copy-paste is one example that often wrecks code. Also, simply wanting to turn off a conditional check to debug something

            • by mrvan ( 973822 )

              +1, I'm a big python fan, but I think the whitespace is a mistake, for a number of reasons:

              1) a snippet of whitespace-blocked code has an absolute indentation level; while a piece of curly bracket style code has relative levels. This makes copy paste and refactoring clumsy. A 'python aware editor' does not really solve this since there is not 'end of block' mark except for the indentation

              2) the python whitespace system is redundant in itself by requiring both a colon and a increase-indent token as a block s

          • You have almost achieved enlightment, grasshopper

            Yeah. That tactic only really works when you are addressing someone with a higher UID than you.

            "Fetish" is a strange choice of word for humans being more efficient at maintaining easy to read code than hard to read code. And indenting blocks is near the top of the list of most significant aids for readability.

            so why shouldn't the solution to the braces/indentation redundancy in C, Java etc. be a C-/Java-aware editor?

            It might be a help. But the fact it hasn't become a common feature in IDEs raises some question marks. (Note to others, there are plenty of IDEs that indent after a curly brace. But few if any that alw

    • Lips is a multi paradigm language, you hardly can call it functional. (Hint: is Lisp more popular than Haskel anyway?)
      Erlang certainly is far less used than Haskel, so his point is very valid.

  • by buchner.johannes ( 1139593 ) on Monday August 26, 2013 @11:22AM (#44677487) Homepage Journal

    He did answer one question once and for all. The smiley closes the bracket.
    https://xkcd.com/541/ [xkcd.com] All hail the BDFL

  • "Guido wasted not time answering your questions and you'll find his responses below."

    Just like editor wasted not time editing/checking the summary before posting.

    Zep--

    • "Wasted not" is synonymous with "did not waste". It sounds pretentiously archaic, but it is correct. On the other hand, borking up the whitespace in a Python code sample? That ain't OK at all.

      • On the other hand, borking up the whitespace in a Python code sample? That ain't OK at all.

        Which is borked with respect to the whitespace, the example or Python? Obviously both and I submit that the latter enables the former which is why it's a horrible language "feature." [ Flame me if you want Python fans, but you know in your hearts I'm right. :-) ] [ And, *that*, Randall (https://xkcd.com/541/) is how you terminate a parenthetical with an emoticon :-) ]

        • Both, of course.

          My point was that removing indents is never OK, with any language, since it makes the code unreadable. In this case, it also made the code uncompilable, but that's just a secondary offense.

        • Flamebait, but I'll bite.

          The thing that got me interested in Python at the very beginning was its use of whitespace. So no, in my heart, I don't think you are right (I was a big fan of Occam). For me, it is clearly the way a programming language should be designed. I understand that it doesn't suit others; but, interestingly, that feature is one of the key (and overlooked) reasons why Python has become so prevalent.

          There is clearly a (sufficiently) large subset of the programming community that strongly

          • There is clearly a (sufficiently) large subset of the programming community that strongly prefer whitespace scoping. And for those people, what are the other mainstream choices? Personally, I don't know of any (although, I'm sure that there are a few). And new language designers are less likely to follow Python's lead because of outspoken critics, like you.

            Default to whitespace == scope, fine. But give a #define or option to turn it off/go back to {} or BEGIN/END or whatever instead...

            • The Zen of Python

              by Tim Peters

              Beautiful is better than ugly.
              Explicit is better than implicit.
              Simple is better than complex.
              Complex is better than complicated.
              Flat is better than nested.
              Sparse is better than dense.
              Readability counts.
              Special cases aren't special enough to break the rules.
              Although practicality beats purity.
              Errors should never pass silently.
              Unless explicitly silenced.
              In the face of ambiguity, refuse the temptation to guess.
              There should be one-- and preferably only one --obvious wa

      • borking up the whitespace in a Python code sample? That ain't OK at all.

        It may have to do with a sloppy HTML conversion by Slashdot or something, but it is ironic.

        P.S. I'm actually a fan of the Python/Haskell whitespace approach.

  • whitespace (Score:3, Interesting)

    by photonic ( 584757 ) on Monday August 26, 2013 @11:34AM (#44677561)
    I know about all the religious arguments pro or against whitespace as syntax. Personally, I am a happy user of python and I actually like the forced indentation, YMMV. But please slashdot, why do you screw up the indentation when the inventor of a whitespace-as-syntax-language gives a code example? This will be too easy for anyone arguing against the use whitespace of syntax.
    • Re:whitespace (Score:5, Insightful)

      by Anonymous Coward on Monday August 26, 2013 @11:59AM (#44677811)

      What do you mean, too easy? That's exactly what's wrong with making indentation part of the syntax. It's too easy to break. It's only fitting that code given by the head honcho of Python falls victim to reformatting. It is literally his own fault.

      • Re:whitespace (Score:4, Insightful)

        by Anonymous Coward on Monday August 26, 2013 @12:10PM (#44677925)

        I have found that everyone who complains about The Python Whitespace Thing are people who have convinced themselves that they are special little snowflakes and therefore any attempt to limit their creative output on whitespace use must be some kind of crime against humanity. Any time I get code in a free-whitespace language from someone like that, I need to run it through a code formatter before it's readable.

        You are not special. Your unique ideas about how to indent code are not special, so fucking indent your code according to the standard. The fact that Python mandates proper indentation is a feature, not a bug. The fact that C lets you throw the whole program on one line is a bug, not a feature.

        • Re:whitespace (Score:5, Insightful)

          by Anonymous Coward on Monday August 26, 2013 @12:47PM (#44678317)

          You can run my code through a code formatter if you don't like my choice of coding convention. You can not fix the broken code from the story by running it through a code formatter, because the inadvertent reformatting destroyed its meaning.

          • You can run my code through a code formatter if you don't like my choice of coding convention.

            Sure you can, as long as you promise to convert it back again perfectly before you commit, so anyone looking at the diffs later doesn't have to wade through 657 whitespace-related changes to spot the one line where you changes some behaviour.

            Languages with syntactic whitespace are vulnerable to misrepresentation, but in practice 99% of that misrepresentation happens under exactly one condition: the code is being presented on a web page by someone who either doesn't know basic HTML or uses a crappy CMS that

            • Run diff -w
            • Sure you can, as long as you promise to convert it back again perfectly before you commit, so anyone looking at the diffs later doesn't have to wade through 657 whitespace-related changes to spot the one line where you changes some behaviour.

              I agree with you, but...

              diff --ignore-space-change

        • by rwa2 ( 4391 ) *

          ... also, they're probably butthurt from their python tweaks not compiling because they don't know how to configure their editor to replace tabs with [248] spaces

        • I have found that everyone who complains about The Python Whitespace Thing are people who have convinced themselves that they are special little snowflakes and therefore any attempt to limit their creative output on whitespace use must be some kind of crime against humanity.

          I'm not special, and I don't use whitespace creatively. I can't STAND it when code isn't indented properly. And yet I still think Python's whitespace is awful, and it is what makes Python a toy language. For one thing, I had having to visually see my whitespace, yet if you don't, you might accidentally mix tabs and spaces and Python gets unhappy.

      • Re:whitespace (Score:5, Insightful)

        by countach74 ( 2484150 ) on Monday August 26, 2013 @12:14PM (#44677985)
        I do a fair bit of programming in Python and curly-bracket languages (C, C++, JavaScript, PHP, etc.) and interestingly, a forgotten/misplaced curly bracket in any of those various curly-bracket languages seem to break my code vastly more often than indentation issues do. Your code should *always* be indented. Python whitespace should already be there in all of your code (minus an occasional tweak here and there). Why complain about having to write {} less frequently?
        • Because your code is more fragile to misrendering or mistransmission by Slashdot, and MS Exchange, and yahoogroups, and google groups, and ...

          The answer to your question was in your parent post, did you not see it?
          • As others have stated, use a proper means of code sharing. It's pretty terrible reading any language when all indentation white space is stripped from it. This is not a problem unique to Python (or other languages with significant white space). Just because the code in question can pass a syntax check does not mean that it is not easily misrendered or mistransmitted.
            • by AuMatar ( 183847 )

              A website is a proper means of code sharing. If your language has issues with it, your language is broken and unusable. There is no excuse for not supporting the most popular method of idea exchange in the last 20 years.

              • The fault here is the misuse of HTML, not the language with significant whitespace. After all, any other language would also lose it's indentation in such a situation, which is still not an acceptable representation of the code, regardless of whether it will compile. Code put on web pages are normally snippets used for learning from, not compiling from, and therefore loss of readability is the major problem, and affects all languages.

                Note that Slashdot is also horrendously broken in many other formatting re

        • by AuMatar ( 183847 )

          Funny- I've lost weeks of my life tracking down python indentation errors, and I've only used it sporadically. I've used C and C like languages for almost 2 decades and I've lost maybe 2-3 days of my life total on missing }. It almost never happens, and never happens with a good IDE. Whereas spacing issues happen whenever you copy paste from a website.

          Guido made 1 major mistake. It actually wasn't using whitespacing- it was in not forcing a specific amount of whitespace. If the language had enforced

          • by tuffy ( 10202 )
            Or you could've saved weeks of your life by running the pep8 tool [python.org] on your code, which will tell you all the lines that aren't indented by a multiple of 4, or which lines have tab characters in them, or any number of other formatting problems that aren't recommended by the style guide.
            • by AuMatar ( 183847 )

              If you have to follow a style guide to get compiling code, your language is broken. If you have to know of the existence of a one off tool to get compiling code, your language is broken. The fact that tool even needs to exist is proof of my point.

          • Funny- I've lost weeks of my life tracking down python indentation errors, and I've only used it sporadically.

            What's your problem? Are you perhaps trying to use a text editor that doesn't understand python for editing python code?

            Whereas spacing issues happen whenever you copy paste from a website.

            No it doesn't. Look at stack overflow for example. Any code there will copy'n'paste to a text editor with the indents intact. Any properly written website will be the same. And any website that specializes in coding should work properly in this respect. It's scandalous that slashdot still doesn't.

            Note Slashdot breaks HTML code even worse than it does Python. (In both cases unless you make

            • by AuMatar ( 183847 )

              It doesn't matter how nicely the website renders it- if it was written with an indent of 3 spaces and you dump it into code with an indent of 4 or tabs, you're going to have problems.

              • It doesn't matter how nicely the website renders it- if it was written with an indent of 3 spaces and you dump it into code with an indent of 4 or tabs, you're going to have problems.

                Yes. I did a supplementary post to the effect that I agree with this part. And personally I believe the one true indent should have been tabs, such that everyone can have the indent size they want in their text editor, without having to reformat the source. But any single standard for what an indent is would be better than the "anything goes" we have.

          • Guido made 1 major mistake. It actually wasn't using whitespacing- it was in not forcing a specific amount of whitespace. If the language had enforced that every indent must be exactly 4 spaces, it wouldn't be an issue. The fact that 4 spaces or 3 spaces or a tab all work is what causes it to break horribly

            That part I agree with.

        • by 31eq ( 29480 )

          This is a Python article! Of course somebody has to complain about whitespace! When did you ever know a Python article to not start an argument about whitespace?

          • Indeed. It's a bit like the same as people starting iPhone articles with a complaint about the supposed patenting of rounded corners.

        • I do a fair bit of programming in Python and curly-bracket languages (C, C++, JavaScript, PHP, etc.) and interestingly, a forgotten/misplaced curly bracket in any of those various curly-bracket languages seem to break my code vastly more often than indentation issues do.

          How often does that really happen? Because it's been a long time since I've had a problem with curly brackets. Or with indentation, for that matter. Is either one worth worrying about? Arguing about the topic is silly.

          There are multiple solutions to the problem of 'block delineation,' and both of these work fine.

        • Re:whitespace (Score:4, Interesting)

          by Half-pint HAL ( 718102 ) on Monday August 26, 2013 @06:36PM (#44681583)

          I do a fair bit of programming in Python and curly-bracket languages (C, C++, JavaScript, PHP, etc.) and interestingly, a forgotten/misplaced curly bracket in any of those various curly-bracket languages seem to break my code vastly more often than indentation issues do.

          Yes, but there's a rather huge difference: when you forget to close a block in C, your compiler completely flakes out as your {s and }s don't match. Your procedures don't close -- syntax error and fall over. However, if I forget to close a block in Python, this results not in a syntax error, but a logical error that the interpreter is not aware of. The block will be closed, even if only when I define my next class or procedure.

          So you've got to weigh up frequency-of-occurrence against cost-of-incident....

        • by Teckla ( 630646 )

          I do a fair bit of programming in Python and curly-bracket languages (C, C++, JavaScript, PHP, etc.) and interestingly, a forgotten/misplaced curly bracket in any of those various curly-bracket languages seem to break my code vastly more often than indentation issues do.

          Your IDE/editor should have an auto-format feature: use it. If your IDE/editor doesn't have that feature, use better tools. This will result in code formatted correctly for virtually no effort (a key press or two).

    • by Dadoo ( 899435 )

      Yeah, I don't really have a problem with whitespace as syntax, either.

      What I don't get is that there aren't more people complaining about the syntax for functions like range(), where the lower limit is inclusive, but the upper limit is exclusive. Can anyone explain to me how that makes sense?

      • It winds up making code like this very clean

        >>> x = 'This is a string'
        >>> p = 4
        >>> a, b = x[:p], x[p:]
        >>> a
        'This'
        >>> b
        ' is a string'

  • by MetalliQaZ ( 539913 ) on Monday August 26, 2013 @12:14PM (#44677979)

    I asked the Python 3 question and to answer Guido's question of me; I work at a large conglomerate that does a lot of defense contracting. In my area we deal with aerospace applications and so our linux systems are not Internet-facing. They are real-time systems that run simulations and data-acquisition. As you might expect, they only get upgraded when they really need it. We had a PDP-11 down in the lab until 2010.

    I'm not sure why I mentioned my workplace other to demonstrate how distant Py3k can seem to be. My main concern was the apparent lack of 3.x support in the big libraries out there. PIL is a great example. Also PyPy. It seems to me that there are many users that will only upgrade when the 3rd party libraries require it.

    • by Anonymous Coward

      You can use Pillow to replace PIL on python 3. Works on python 2 as well.

    • Re: (Score:3, Informative)

      by EvanED ( 569694 )

      Just to add my input, in the CS department at my university, the Linux that is currently in use is RHEL, the latest version of which (RHEL6) ships with 2.6.6.

      Now that said, we also have several other Python installations available from nonstandard locations, and a [i]python[/i] shell alias for me runs 2.7.3 and [i]python3[/i] runs 3.2. (Huh, 3.3 is available. I should update that.)

      Also, the Python project that I use that it'd be nice to see support Python 3 is SCons, and there's some talk of that going on a

    • by codealot ( 140672 ) on Monday August 26, 2013 @02:04PM (#44679111)

      I was a little surprised by GvR's answer to this. RHEL 6 ships with Python 2.6, last I checked, and we don't normally deviate from Red Hat packages without good reason. Getting the masses off pre-2.7 versions of Python will also entail releasing newer OS distributions and retiring older ones, both of which happen slowly.

      Not everyone can keep up with the latest/greatest versions out there, especially when they have hundreds of servers and big legacy applications to support.

  • Interesting interview. Surely there were more important topics but if nothing else this interview was useful in that it taught me it's okay to use the parenthesis at the end of a smiley to serve double duty as the end of a parenthetical statement (kind of like this one :-). At least when your smiley is left in plain text, that is.

"The following is not for the weak of heart or Fundamentalists." -- Dave Barry

Working...