Weekly Edition
Return to the Development page
| |||||||||||||||||||
|
| |||||||||||||||||||
Python 3.0 released
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On behalf of the Python development team and the Python community, I
am happy to announce the release of Python 3.0 final.
Python 3.0 (a.k.a. "Python 3000" or "Py3k") represents a major
milestone in Python's history, and was nearly three years in the
making. This is a new version of the language that is incompatible
with the 2.x line of releases, while remaining true to BDFL Guido van
Rossum's vision. Some things you will notice include:
* Fixes to many old language warts
* Removal of long deprecated features and redundant syntax
* Improvements in, and a reorganization of, the standard library
* Changes to the details of how built-in objects like strings and
dicts work
* ...and many more new features
While these changes were made without concern for backward
compatibility, Python 3.0 still remains very much "Pythonic".
We are confident that Python 3.0 is of the same high quality as our
previous releases, such as the recently announced Python 2.6. We will
continue to support and develop both Python 3 and Python 2 for the
foreseeable future, and you can safely choose either version (or both)
to use in your projects. Which you choose depends on your own needs
and the availability of third-party packages that you depend on. Some
other things to consider:
* Python 3 has a single Unicode string type; there are no more 8-bit
strings
* The C API has changed considerably in Python 3.0 and third-party
extension modules you rely on may not yet be ported
* Tools are available in both Python 2.6 and 3.0 to help you migrate
your code
* Python 2.6 is backward compatible with earlier Python 2.x releases
We encourage you to participate in Python 3.0's development process by
joining its mailing list:
http://mail.python.org/mailman/listinfo/python-3000
If you find things in Python 3.0 that are broken or incorrect, please
submit bug reports at:
http://bugs.python.org/
For more information, links to documentation, and downloadable
distributions, see the Python 3.0 website:
http://www.python.org/download/releases/3.0/
Enjoy,
- -Barry
Barry Warsaw
barry@python.org
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSTc3pXEjvBPtnXfVAQI69wP/dPHh8IL3GxziEV9QzlveKG+KyZb2X16x
fxJnTCiXAbiAhT5C+m43OEnbF1PJgMDKtcZ5b7aQb4TQ0mJxISTQh0RfLCpArmlo
tdTbzCLnh13KzB+3sUHCx+MeQNXERoWDV8hLz+4Ae71UsuUGynhtyP7ZJMJDue8j
so2gv3fOMSs=
=vkiy
-----END PGP SIGNATURE-----
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations.html
(Log in to post comments)
Pythron Posted Dec 4, 2008 3:08 UTC (Thu) by ncm (subscriber, #165) [Link]
If it's incompatible, it's a different language, and needs a different name. I feel obliged to call this one "Pythron".
Pythron Posted Dec 4, 2008 4:17 UTC (Thu) by kev009 (subscriber, #43906) [Link]
Wishful thinking. Python 3 is hardly a new language. C, C++, FORTRAN, ADA, etc over the years which were subjected to much worse change between versions and manufactures. Python 3 is an evolutionary upgrade and contains helpful tools to switch over by means of Python 2.6 and the migration scripts. I doubt Perl 6 will handle evolution this smoothly :P.
Pythron Posted Dec 5, 2008 16:45 UTC (Fri) by elanthis (subscriber, #6227) [Link]
C++ hasn't had a significant compatibility-breaking change in about 15-20 years. Even the changes being introduced in C++0x have been carefully selected to all but ensure that existing software won't stop compiling, even if that meant that the new syntax and keywords are a little less than optimal in some cases. (It's true that a lot of C++ code kept breaking with each g++ release, but that's because g++ kept dropping support for broken code that it used to accept; totally g++'s fault and the fault of people who can't seem to comprehend C++, which is _not_ as hard as some detractors claim it is.)
Python, on the other hand, breaks applications with every single point release. On top of that, it breaks the embedding API with almost every single point release. It's a constantly moving target.
Pythron Posted Dec 11, 2008 16:30 UTC (Thu) by rriggs (subscriber, #11598) [Link] (It's true that a lot of C++ code kept breaking with each g++ release, but that's because g++ kept dropping support for broken code that it used to accept; totally g++'s fault and the fault of people who can't seem to comprehend C++, which is _not_ as hard as some detractors claim it is.)Bullpucky! From Scott Meyers, hardly a C++ detractor: "… C++ developers could really use a larger tool set, but the barrier to entry for truly powerful tools is the ability to parse C++ source code, and that’s a barrier very few have been able to breach. "C++ is nearly impossible to parse, primarily because it continues to rely on the C preprocessor. I develop in Python and in C++. C++ certainly has its uses. But crappy syntax and a standard library that can't hold a candle to most other modern languages are its two biggest faults.
Pythron Posted Dec 11, 2008 23:42 UTC (Thu) by nix (subscriber, #2304) [Link] C++ is nearly impossible to parse, primarily because it continues to rely on the C preprocessor.I've written a C++ parser, and, believe me, the C preprocessor can be almost completely ignored: it doesn't make anything harder. It is *not* the problem. The rampant context-sensitivity is the problem. A trivial example that everyone knows: is A foo (b); a declaration of a variable 'foo' of type 'A', and its initialization via a single-argument constructor, passing the variable 'b', or a declaration of a function 'foo' taking a single parameter of type 'b' and returning an 'A'? To answer that you have to know if 'b' is a type or not at that point in the program *at parsing time*.
Pythron Posted Dec 4, 2008 4:25 UTC (Thu) by allesfresser (subscriber, #216) [Link]
I would judge the level of incompatibility as "mostly harmless." :) If you feel the absolute compulsion for a new name, perhaps "Python as it should have been all along" would be a good choice... I heartily applaud the decisions made in this major revision... it'll make my life easier.
Pythron Posted Dec 4, 2008 4:48 UTC (Thu) by ncm (subscriber, #165) [Link]
I suppose you could change the name of the auld language, instead. May I propose "Pychthon"? (Fhtaghn!)
Pythron Posted Dec 4, 2008 12:09 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]
It would be a WASTE to change it to anything but Pynchon.
Python 3.0 released Posted Dec 4, 2008 4:45 UTC (Thu) by qg6te2 (subscriber, #52587) [Link] Fedora rawhide is in the process of converting from python 2.5 to 2.6. Given the bleeding edge nature of Fedora, one wonders why a switch directly to 3.0 is not being made. Certainly makes more sense in the long term.
Python 3.0 released Posted Dec 4, 2008 5:40 UTC (Thu) by danielthaler (subscriber, #24764) [Link]
I expect a number of upstream projects need to switch first. It doesn't make sense to ship a version that isn't usable by packages that depend on python.
Python 3.0 released Posted Dec 4, 2008 6:10 UTC (Thu) by shredwheat (subscriber, #4188) [Link]
It makes good sense for Fedora to be first moving to 2.6. Remember that 2.6 was released only a few months ago, and was developed parallel to 3.0.
Python2.6 makes an excellent transition point for moving to 3.0. It already contains the non-invasive new features, and has warnings and options to prepare for the move to 3.0.
Python 3.0 released Posted Dec 4, 2008 20:48 UTC (Thu) by iabervon (subscriber, #722) [Link]
The idea with 2.6, as I understand it, is to be the ideal Python 2.x-compatible version for moving code to 3.0 from. So it makes sense for Fedora to have "python" be 2.6, to identify problems, but still have programs work, while having "python3.0" be 3.0 (now that it's released). There's a fine line between "bleeding edge" and "not expected to work".
Python 3.0 released Posted Dec 5, 2008 18:58 UTC (Fri) by nevyn (subscriber, #33129) [Link] It's very likely that Fedora will never have a release with two different python versions again, so the probability of an official /usr/bin/python3.0 is pretty close to zero. Also I think anyone who expects python-3.0 to be in distributions "soon" needs to share the drugs around more. Yes, it's better then the perl-5 to perl-6 transition, but that isn't saying much and it broke way too much stuff gratuitously (I first assumed removing {}.has_key() was an April fools joke).
Python 3.0 released Posted Dec 5, 2008 20:52 UTC (Fri) by iabervon (subscriber, #722) [Link]
I wouldn't be surprised if Fedora ended up wanting to include software that uses new features of Python 3.0 (in the upstream project) to an extent that Fedora can't reasonably port it to Python 2.x (even with the possibility of doing a lot of "from __future__ import ..." everywhere) at the same time that they want to include software that will require extensive updating that Fedora can't reasonably do to work with Python 3.0. (FWIW, my Ubuntu box currently has python2.4, python2.5 and python (=2.5); my Gentoo box currently has python2.4, python2.5, python2 (=2.5), and python (=2.5).)
I haven't used Fedora, but I'd be surprised if it were possible to have a wide variety of Python software any time soon without having at least 2 (if not more) versions of python.
Python 3.0 released Posted Dec 5, 2008 22:16 UTC (Fri) by nevyn (subscriber, #33129) [Link]
It's true that Fedora hasn't had much pressure to move to a new version of Python when it didn't want to before. However there are multiple precedents now of Fedora dropping packages after a move to a new version (because they depended on an older version). The biggest victim being Zope.
So I find it very believable that Fedora will just keep saying "either your package works with 2.* or we don't ship it" for anything which comes along that "requires py3k". More likely is that upstreams will use 2.* as the baseline for a significant amount of time to come, much like people didn't all move to Apache-httpd-2.* instantly.
Python 3.0 released Posted Dec 5, 2008 22:27 UTC (Fri) by dlang (subscriber, #313) [Link]
however there is defiantly going to be some project that is going to move to python 3.0 immediately.
you are assuming that one of the goals of the project is to be included into Fedora so Fedora can lay down requirements (like "don't use Python 3")
other systems will use Python 3 and programmers will write things in Python 3.
if Fedora wants to include these things they will need to include Python 3 or re-write them
there is another thread this week in the LWN comments where people are advocating that the distros should not modify any packages and should just ship the upstream packages unmodified. this is an example of how it's not going to be possible.
Python 3.0 released Posted Dec 5, 2008 23:28 UTC (Fri) by jspaleta (subscriber, #50639) [Link]
The real problem is what this means for upstream developers. If the language incompatibilities are mostly cosmetic then downstream distributors will be able to hold a transitional patchset together without the upstream developers having to branch, upstream can just make the move to py3k and the cosmetic changes can be generated to make a py2.x variant. But for codebases which have to make deep changes, or make heavy use of additional python based projects, they will most likely have to branch and coordinate porting into py3k with the other python module projects.
Either way its going to be painful..and messy.
-jef
Python 3.0 released Posted Dec 6, 2008 0:23 UTC (Sat) by iabervon (subscriber, #722) [Link]
In a lot of situations, it's trivial to have some software use python2 and other software use python3. An apache transition is a lot more difficult, because you can't really have half your site served with one apache and the other half served with a different version (on one IP and all on port 80 without a ton of annoying redirection).
Python 3.0 released Posted Dec 8, 2008 18:16 UTC (Mon) by nevyn (subscriber, #33129) [Link]
Actually "in a lot of situations" it's trivial to run two different Apache-httpd's ... the problem is all the other situations where it's a giant PITA.
The same is true of python, yes it's possible to run two versions in some situations ... but due to all the other situations Fedora has said "there will be only one". AIUI Debian ship multiple versions of python, but only one version of some (all?) modules ... which doesn't seem that useful. It'll be interesting to see how Debian manage the py3k transition.
Python 3.0 released Posted Dec 14, 2008 6:08 UTC (Sun) by njs (subscriber, #40338) [Link]
In Debian, in almost all cases, there is a single package for each library, but at install-time that package detects which versions of python are installed and automatically sets up the library to work with all of them (including running multiple byte-compiles, etc.). This system is called "python-support".
Python 3.0 released Posted Dec 4, 2008 5:39 UTC (Thu) by kbob (subscriber, #1770) [Link]
Python 3 was originally called Python 3000. However, it released in 2008, 992 years early.
Is software hard to schedule or what?
Python 3.0 released Posted Dec 4, 2008 6:42 UTC (Thu) by macson_g (subscriber, #12717) [Link]
3000 is clearly an octal number, which translates to 1536. And 1536 is a year when The Inquisition was implemented in Portugal.
Remember: No one ever expects The Portugal Inquisition :)
Python 3.0 released Posted Dec 4, 2008 13:36 UTC (Thu) by jimbo (subscriber, #6689) [Link] KBob wrote:-> Remember: No one ever expects The Portugal Inquisition :) Sorry, Your Eminience, but that's the Portuguese Inquisition...
Python 3.0 released Posted Dec 4, 2008 13:52 UTC (Thu) by tarjei (subscriber, #29357) [Link] I'm quite sure the original joke referred to the Spanish inquisition.
Python 3.0 released Posted Dec 4, 2008 16:07 UTC (Thu) by felixfix (subscriber, #242) [Link]
Yes, that's why the grammar was corrected to match.
Python 3.0 released Posted Dec 5, 2008 0:34 UTC (Fri) by nix (subscriber, #2304) [Link]
jimbo wrote:
>KBob wrote:- >> Remember: No one ever expects The Portugal Inquisition :) >Sorry, Your Eminience, but that's the Portuguese Inquisition...
That should be 'Eminence' :)
Python 3.0 released Posted Dec 5, 2008 3:46 UTC (Fri) by sbergman27 (subscriber, #10767) [Link]
"""
That should be 'Eminence' :) """
No. I'm sure it's Eminience. As in "of or pertaining to the planet Eminiar VII". I therefore suggest the name "Vendikar" for this new Python release. Hey, it's computer related. :-)
Python 3.0 released Posted Dec 5, 2008 2:42 UTC (Fri) by nlucas (subscriber, #33793) [Link]
To me it's clearly a base-26 number, where each digit corresponds to an alphabet letter.
Then, 3000 => daaa.
Everybody knows "daaa" is the Portuguese phonetic equivalent of the English "D'oh!" [1].
[1] http://en.wikipedia.org/wiki/D%27oh!
Python 3.0 released Posted Dec 4, 2008 8:40 UTC (Thu) by sbergman27 (subscriber, #10767) [Link]
from __future__ import python
Which should be no surprise to anyone, these days:
Python 3.0 released Posted Dec 4, 2008 9:38 UTC (Thu) by alexl (subscriber, #19068) [Link]
That strip needs to be upgraded for Python 3.0. "print" changed from a statement to a function.
Python predicted the economic crisis Posted Dec 5, 2008 0:26 UTC (Fri) by nix (subscriber, #2304) [Link]
I knew it was coming years ago when I asked my Python oracle:
>>> from __future__ import money
Then I *knew* we were in trouble.
Python predicted the economic crisis Posted Dec 5, 2008 0:59 UTC (Fri) by sbergman27 (subscriber, #10767) [Link]
Verify that it's working right by importing something you know is there.
Try "from __future__ import viagra_spam"
Python 3.0 by Christmas. Posted Dec 5, 2008 0:38 UTC (Fri) by dw (subscriber, #12017) [Link]
I can't help but suspect a little in-joke pushing this out in time for Christmas, when the Perl 6 folk have been promising that for years now. :P
Python 3.0 released Posted Dec 5, 2008 2:46 UTC (Fri) by brouhaha (subscriber, #1698) [Link] And in 2014 or so, there will finally be a release of Zope that runs on Python 3.0, but by then the current Python release will be 4.3.Sigh.
Python 3.0 released Posted Dec 5, 2008 3:35 UTC (Fri) by sbergman27 (subscriber, #10767) [Link]
The buzz in the general community suggests that "top of the food chain" applications, e.g. Django, will likely take their time and support Python 3.x in about a year. I suspect that the 3.x series will be around for some time, similar to the 2.6.x Linux kernel. The change in major version number represented changing some design decisions made up to 20 years ago. It's hard to imagine anything at this point that would warrant a 4.x series, barring someone abducting Guido and hijacking the project. ;-)
As for Zope... well it hasn't been the most agile fish in the pond, has it. At DJangoCon this year, Mark Ramm's presentation was basically a "Reefer Madness" style propaganda exhibition attempting to scare the Django devs into thinking that Django could become "like Zope". Being the very archetype of what a Python project shouldn't want to become is probably not what the original Zope devs set out to accomplish.
Python 3.0 released Posted Dec 5, 2008 6:07 UTC (Fri) by elanthis (subscriber, #6227) [Link]
So... where does Guido live? >:)
(No, really, I have a beneficial purpose in mind! I want to kidnap Larry, Guido, Yukihiro, and Bjarne, to create the world's first true object-oriented systems language with a pleasant syntax and Perl regexp support! It'll be the most wonderful thing evar@~~!)
Python 3.0 released Posted Dec 5, 2008 12:01 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]
I suspect I'm not alone in working on something like that in my spare time. What I have in mind is a statically typed, garbage collected language with a C/C++/D/Java-like basic syntax, but with two major twists to make it much more pleasant to work with:
* Something very much akin to Pythons duck typing, but still using static typing. You might think of it as implicit interfaces - if a class has all the methods of another class and the same method signatures, it can be used as if it was of the same type in e.g. as a parameter in a function call.
* Lisp-like macros, i.e. function calls that are executed at compile time, and whose input and output are nodes in the parse tree. This allows you to extend the language wiuth things like Pythons 'with'-statement and built in regexp support. The plan is to use this to use this syntax for regexp matching:
r"[a-zA-Z.]+@[a-zA-Z.]+" == someString
(notice the 'r'-prefix) create a regexp object overloads the '==' operator top perform a regex match on a string.
New system programming language Posted Dec 5, 2008 21:55 UTC (Fri) by ncm (subscriber, #165) [Link] ... garbage-collected ...FAIL
New system programming language Posted Dec 6, 2008 1:03 UTC (Sat) by liljencrantz (subscriber, #28458) [Link]
1995 called. They want their unjustified preconceptions back. Unless you're writing a kernel or a gaming engine, garbage collection makes a huge amount of sense.
New system programming language Posted Dec 6, 2008 6:14 UTC (Sat) by njs (subscriber, #40338) [Link]
Going back to malloc/free is clearly insane. Garbage collection is handy, and works well for lots of purposes. But, gc isn't perfect: my job as a programmer is to understand and control the computer's operation; garbage collection makes memory management opaque and nondeterministic. (The usual place this bites you is when trying to optimize for memory usage - it's still possible with gc, and tools can help, but it's harder and the result more fragile.)
So there's room to explore more structured systems for memory management, that let you precisely define object lifetime when possible/convenient, or fall back on gc in a controlled way. Well-written modern C++ -- with its stack allocation and multiple flavors of smart pointers -- often looks something like this, but too many people still just use new/delete and "real gc" isn't one of the available flavors. But C++ is the only game in town for this kind of thing, because everyone else just bakes gc into their runtime as The Way Memory Works. It'd be wonderful to have a better language than C++ with a better memory management system than pure gc.
New system programming language Posted Dec 6, 2008 10:38 UTC (Sat) by liljencrantz (subscriber, #28458) [Link]
That I can agree with. The op expressed the opinion that a langauge that includes garbage collection are instafail, which I belive to be a silly argument that has been disproven time and time again in the last 10 years. But it's not a silver bullet, no. And there are definitely situations where the coder could do a lot better than even the best automatic collectors with very little effort.
New system programming language Posted Dec 6, 2008 18:18 UTC (Sat) by drag (subscriber, #31333) [Link]
There are module writing languages for python.. I am aware mainly of cython/pyrex. (pyrex being more serious, cython more open to add-ons)
http://en.wikipedia.org/wiki/Pyrex_(programming_language)
The old story for python performance is:
This way you get the app rapidly prototyped and written and identify areas were performance and optimization work is actually necessary rather then trying to guess ahead of time.
I don't know particularly how successful this approach is, but it's what is mentioned in the literature and seems to make sense to me.
This way you get to use GC and then also do the manual memory stuff were it matters. Have your cake and eat it, too.
New system programming language Posted Dec 7, 2008 0:24 UTC (Sun) by njs (subscriber, #40338) [Link]
Pyrex/Cython are indeed *fantastic*. But they don't really create the kind of system I'm talking about here, because 1) they're usually used to define little self-contained computational cores and simple wrappers around foreign code, so their interaction with overall memory management is minimal (except that they let you temporarily avoid the constant heap allocations that tend to bottleneck pure Python code), 2) they don't provide any tools beyond malloc/free anyway.
Python 3.0 released Posted Dec 6, 2008 18:29 UTC (Sat) by nix (subscriber, #2304) [Link]
Useful Lisp-like macros without a Lisp-like syntax is going to be very
painful to design. I wish you luck, but without much hope.
Python 3.0 released Posted Dec 7, 2008 10:12 UTC (Sun) by liljencrantz (subscriber, #28458) [Link]
Thank you for the wellwishes. :)
But yes, the simple structure of Lisp obviously makes it much easier both to implement a macro system and to use it for creating new code. Just the simple little addition of static typing makes writing macros significantly harder.
On the other hand, people have been doing some impressive things by using C++ templates for metaprogramming, and that is a significantly more anemic and archaic interface than what I have planned.
My plan is that regular projects will very rarely contain custom macros, they should mostly be used for extending the language to provide features like enums, python-style with-statements, etc..
please don't use Python-3 Posted Dec 5, 2008 14:01 UTC (Fri) by zooko (subscriber, #2589) [Link]
Ugh, I personally intend to cling to Python-2 for as long as I can. I haven't heard of any features in Python-3 that I actually care about. Maybe there are some in there, but glancing at the first few paragraphs of "What's New in Python 3" has never showed me anything that I care about.
I have a lot of code in various packages written in Python-2, and I'm secretly hoping that nobody gets around to upgrading to Python-3 for a few years so I can just ignore Python-3 and keep hacking.
The main feature that Python lacks that I want is more programmatic, automated sharing of modules, through tools such as setuptools and services such as http://pypi.python.org . The incompatibility of Python-3 makes this problem worse, not better.
Also, there's a really cool feature that I'm interested in that works in Python-2 but is fundamentally incompatible with Python-3: capability-based restricted Python:
http://lackingrhoticity.blogspot.com/2008/08/introducing-...
Perhaps this post will come back to haunt me...
please don't use Python-3 Posted Dec 5, 2008 19:56 UTC (Fri) by edlenz (guest, #12021) [Link]
This feature is intersting...
a=[1,2,3]
works with any object with .__str__ mehtod.
please don't use Python-3 Posted Dec 5, 2008 22:11 UTC (Fri) by nevyn (subscriber, #33129) [Link]
That's not a feature, just different syntax (I agree it's better, but it's also different):
a = [1,2,3]
please don't use Python-3 Posted Dec 6, 2008 0:39 UTC (Sat) by pcharlan (subscriber, #29128) [Link]
> I haven't heard of any features in Python-3 that I actually care about.
I am relatively new to Python, but how someone could have designed a language with closures that lacks nested lexical scoping ("nonlocal" in Python3.0) is baffling to me.
I'm in the "I wish Python were Scheme" camp, and so also miss tail-call optimization, but I'm used to languages not seeing the beauty in that. But nested lexical scopes are so basic that their omission from Pythons previous to 3.0 was just weird.
please don't use Python-3 Posted Dec 6, 2008 5:01 UTC (Sat) by sbergman27 (subscriber, #10767) [Link]
I'm not certain if I am understanding you clearly. Nested functions have always been able to refer to variables in the immediately enclosing function. They just haven't been able to rebind them. Here is the relevant PEP for nonlocal, for reference:
please don't use Python-3 Posted Dec 6, 2008 6:28 UTC (Sat) by njs (subscriber, #40338) [Link]
>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.
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.
Python 3.0 released Posted Dec 5, 2008 23:31 UTC (Fri) by muwlgr (guest, #35359) [Link]
There are voices about speed regression in Python 3.0
http://mooseyard.com/Jens/2008/12/python-30-whats-the-point/
Python 3.0 released Posted Dec 6, 2008 5:28 UTC (Sat) by sbergman27 (subscriber, #10767) [Link]
Well, the speed regressions are mild and expected, and will be addressed "after 3.0 is released", which means "starting now", I guess. The post you've linked to is a bit misleading. Sure, the new ruby interpreter is expected to be faster, the post claiming "3 times" as fast. But Python is already 5 or 6 times faster than Ruby since Ruby 1.8 is a purely interpreted, whereas Python has always be a VM. The post implies that Python 2.6 and Ruby 1.8 both have comparable speed, which is not the case at all.
Actually, what the poster is missing is that 3.0 is not a whiz-bang, shiny, gotta-upgrade-now sort of release and was never supposed to be. Use it for green field projects, and if desired, continue on with 2.6 and 2.7, and possibly 2.8 and 2.9 for your existing code.
|
|||||||||||||||||||