LWN.net Logo

please don't use Python-3

please don't use Python-3

Posted Dec 6, 2008 6:28 UTC (Sat) by njs (subscriber, #40338)
In reply to: please don't use Python-3 by sbergman27
Parent article: Python 3.0 released

>Nested functions have always been able to refer to variables in the immediately enclosing function.

Not true -- see __future__.nested_scopes.

Until 2.1, Python didn't even have the concept of doing recursive lookup through a stack of applicable scopes. Every piece of code had access to exactly 3 scopes: "local", "global", and "builtin", checked in that order.

I think Python tends to confuse programming language enthusiasts, because the actual language core is incredibly simple and stupid (though it's become somewhat less so over time). Another example: the first time I tried learning Python, I gave up in disgust when the tutorial mentioned that lambdas were syntactically limited to a single expression (wtf?). The trick is to realize that the actual Python core is basically a hacky, simplest-thing-that-could-possibly-work language runtime, with the best human factors design in the world stuck on top.

It's a little disconcerting to try and do something Clever, squint at the details of some bit of the runtime, and discover them melting away into a bunch of local conventions and baling wire instead of some beautiful principled thing like you'd find in Haskell. But it's a great insight that the beauty and consistency of a *language* is not the same as the beauty and consistency of its internals.


(Log in to post comments)

please don't use Python-3

Posted Dec 6, 2008 13:45 UTC (Sat) by zooko (subscriber, #2589) [Link]

Nicely put, NJS.

By the way, I suspect that the reason Python's human-factors are so good is because its immediate, strong ancestor ABC was subjected to iterated user testing. Imagine! A tool intended for use by users actually being *tested* on users and then changed in response to what is observed.

If I were the emperor of the programming languages research universe, I would summarily reject all papers that didn't come with studies on real humans, which would be all of them.

please don't use Python-3

Posted Dec 6, 2008 15:56 UTC (Sat) by sbergman27 (subscriber, #10767) [Link]

I'm not certain exactly what you are saying is not true. If you are saying that functions could not access variables in their enclosing function until 3.0 then you are incorrect, as this has worked for as long as I have been using Python, which goes back to about 2.2. I know, because I've been using it.

If you are saying that my use of the word "always" was not entirely accurate, which is what I think you are saying, then I would agree, and further add that the support for this was introduced in 2.0, back in Oct 2000 and turned on by default in 2.1, released Apr 2001. So all this occurred 8 years ago, back when Python was about half its present age. In this case, you can take "always" to mean "versions as far back as I can imagine any significant number of people might be running today".

Ignoring the loaded and essentially meaningless terms "stupid" and "hacky", I can agree with "simple". But you seem to see the simple core and the human factors to be distinct entities. I would be more inclined to say that the simplicity is integral to the "human factors". If you are looking for C++ in Python, you're out of luck. Not here. Don't want it.

As to Haskell... it's like Jane Mansfield: "beautiful" and "dead". (Though its features will influence, and have influenced, other languages, including Python, for years to come.)

I'll take "practical" and "useful", please.

I would be curious as to whether you have any comments on Ruby.

please don't use Python-3

Posted Dec 7, 2008 0:18 UTC (Sun) by njs (subscriber, #40338) [Link]

I think you read more hostility into my comment than was intended (and understandably, because I have a bad habit of using words like "stupid" as technical rather than pejorative terms). I was indeed referring to the pre-2.2 changes in scope handling (though it was actually 2.1/2.2 where it was added/turned on -- python -c 'import __future__; print __future__.nested_scopes' -- unless there was another round of scope tweaks that I'm forgetting about).

And I think -- again, remember I'm talking about how a language designer/aficionado sees and gets confused by Python -- the simple core *is* somewhat distinct from the human factors; it would be entirely possible to put Python's syntax etc. on top of a Lisp or Smalltalk, and you would have more consistent internals without any harm to the language's essential spirit[1]. But my central point was -- this is where experts get confused -- it turns out not to really matter much either way.

Ruby is also an interesting example, being a Smalltalk itself -- but I don't know much about it, because the perception of a culture of monkeypatching has scared me away, another example of the importance of "cultural"/non-technical/human factors in language use.

[1] A good example of this would be the evolution of R from S (the statistics programming languages, where S has a kludgy core and R is a Scheme... but users don't really notice the difference).

please don't use Python-3

Posted Dec 7, 2008 1:04 UTC (Sun) by sbergman27 (subscriber, #10767) [Link]

Yes, I did read some hostility in it. But I wasn't sure. I went back and reviewed your posts in the Perl thread and decided you seemed pretty even-handed.

You are correct about 2.1/2.2. I was correctly remembering what I had read in the Wikipedia article on Python:

http://en.wikipedia.org/wiki/Python_(programming_language)

which says, referring to 2.0:

"The release included a change to the language specification to support nested scopes, like other statically scoped languages.[13] (The feature was turned off by default, and not required, until Python 2.2.)"

But a review of the original "What's new in Python 2.0" and "What's new in Python 2.1" documents shows that to be inaccurate.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds