Talk 8: Python 3000
Python 3000 is the funny name for what will eventually be Python 3.0. This is planning for the way future, things that will happen much later. The next version 2.5 is coming out (hopefully) in early August.
Seems to be a big redesign. Without redesigning the entire language, he wants to fix early on design bugs that have persisted, get rid of deprecated division, and will allow some incompatible changes. Seems a bunch like how radical Perl 6 is going to be. Looking at what's best going forward.
The process is that Guido is the main driver, but is leveraging the community. Wants to avoid being the next Perl 6. (Hah!) Trying to answer questions early - when is the goal to release, continue 2.x and 3.x simultaneously?, how incompatible can it be?, do we backport features from 3.x to 2.x? Things like that.
Regarding incompatibility ... new keywords are allowed, all strings are Unicode, don't use <> as alias for !=, but not things like changing precedence, or changing the meaning of the else clause on for/while.
Mechanical translation of 2.x to 3.x will not be very possible. Some things will be pretty easy, but can't be 100% certain. The most likely approach is the creator of some pychecker that will do 80% of the work, and augment 2.x with warnings about features that will be deprecated come 3.x.
Some things that Python 3000 will not have. No programmable syntax or macros, no adding syntax for parallel iteration, no changing hash, keys to attributes, and no changing iterating over a dict to yield key-value pairs. They also should not change the look and feel of the language too much, make gratuitous and confusing changes, or add radical new features. (Can always do that later.)
For upcoming features, read PEP 3100, from this page. Also you can follow the mailing list, and he has a blog, but the URL went away too fast for me to copy.
Basic cleanup of Python 3000 will include killing classic classes, like string exceptions, or exceptions that don't derive from the root of the exception heirarchy. Division of integer by integer will return a float, remove the last few semantic differences between int and long, and by default use absolute import. Kill ancient library modules, clean stdlib up a bunch. Kill off sys.exc_type, dict.has_key(), file.xreadlines(), apply(), input(), buffer(), coerce().
Some minor changes... exec is a function again, kill `x` in favor of repr(x), change exception syntax slightly to yield a name for the exception, kill off "raise E, arg" in favor of "raise E(arg)". Also changing list generator expression from "list(f(x) for x in S)" to "[f(x) for x in S]".
Apparently lambda lives. He doesn't like it and wants it to die, but figured they should try for a better version. They've tried for a year and come up with nothing, so, it's just going to live.
Strings are getting a revamp. Instead of having str and unicode, there will now be bytes and str. The former doesn't have things like bytes.upper() and such, they're just a string of bytes. The new str class is like the old unicode one, it always supports text.
Now print is becoming a function, too. More information is in the PEP 3100 linked to above. Lots of discussion about this but he feels it's a barrier to the evolution of the language to have it as the old builtin that it was?
The talk has now run overtime by a bit, so he's wrapping it up. Interesting stuff. Oh, and they're having a Sprint which is a way to get things done... see linky.
Comments
Aww, man, I love the <> operator!
Hey, Junior, thanks a lot of posting these detailed reports from OSCON. It's almost as good, in some ways even better, as being there. Now I just hope someone from the 6a contingent makes as detailed a report from the beer fest that's apparently happening in conjunction with the convention.
сайт про взлом, про хакеров, статьи для хакеров
проститутки, индивидуалки, интим услуги