What's going on here is that Python has added support for another kind of polymorphism known as "single dispatch".
This allows you to write a function with several implementations, each associated with one or more types of input arguments. The "dispatcher" (called 'singledispatch' and implemented as a Python function decorator) figures out which implementation to choose based on the type of the argument. It also maintains a registry of types -> function implementations.
This is not technically "multimethods" -- which can also be implemented as a decorator, as GvR did in 2005[1] -- but it's related[2].
Also, the other interesting thing about this change is that the library is already on Bitbucket[3] and PyPI[4] and has been tested to work as a backport with Python 2.6+. So you can start using this today, even if you're not on 3.x!
Interesting, but I have a hard time accepting this. If I accept a type of iterable I would either check isinstance and do separate methods or check isinstance and convert to a single type and operate on it. On the other hand, I also try to minimize accepting multiple types of iterable. I don't do that very often except in the case of list and tuple. Since these two types are very very similar in nature I call a separate method in my code to handle the two types. That's okay, just a few extra lines.
I don't really understand the benefit of mm and dispatch. This sounds useful for building routes in webapp. But for library, it sounds like we are bringing back C++'s single interface, multiple types... I don't even remember what that is called.
This is quite useful to hide away casting from one type to another or to "build" objects - say you have an object represented by a JSON or XML structure, now you can have functions that accept either/or.
Is this method overloading or am I missing something?
Huh? But that's not single dispatch? Single dispatch is deciding what function to call based on the type of your object, not on the type of arguments. That's called double dispatch.
Single dispatch is pretty standard polymorphism, C++ can do that.
The thing I'm looking forward to in Python 3.4 is that you should be able to follow the wise advice about how to handle text in the modern era:
"Text is always Unicode. Read it in as UTF-8. Write it out as UTF-8. Everything in between just works."
This was not true up through 3.2, because Unicode in Python <= 3.2 was an abstraction that leaked some very unfortunate implementation details. There was the chance that you were on a "narrow build" of Python, where Unicode characters in memory were fixed to be two bytes long, so you couldn't perform most operations on characters outside the Basic Multilingual Plane. You could kind of fake it sometimes, but it meant you had to be thinking about "okay, how is this text really represented in memory" all the time, and explicitly coding around the fact that two different installations of Python with the same version number have different behavior.
Python 3.3 switched to a flexible string representation that eliminated the need for narrow and wide builds. However, operations in this representation weren't tested well enough for non-BMP characters, so running something like text.lower() on arbitrary text could now give you a SystemError (http://bugs.python.org/issue18183).
With that bug fixed in Python 3.4, that removes the last thing I know of standing in the way of Unicode just working.
I love how there's a thorough "what's new" document for a still-in-progress release, and terms like "provisional API" are linked to a glossary that tells you exactly what they mean. While Python is not the most interesting language to me anymore, it still sets the standard in clear, comprehensive, newbie-friendly documentation.
I think newbies are far from the people most likely to be looking at version-to-version changelogs in any language.
This is great for those maintaining substantial codebases in the language, though.
The thorough specification process gives lots of warning for the introduction of changes (so you can almost update on release day if you were really so inclined and prepared).
Edit: Though on a re-read, clear, comprehensive newbie friendly documentation is something that (somewhat unrelatedly) Python does have. My bad.
Even I was amazed at the neat documentation of the changes that are made for this release.
There is some unknown familiarity in that page layout that my brain naturally knows what to click and read through.
Kudos to team who did this work.
I like the implementation of the "Enum" class, especially the way they allow for enums with variant behavior and "abstract Enums" (something I could have used in Java recently).
But, ever since I found out about algebraic data types from other languages, I keep wanting those. There's not quite a good way to do those in Python. (I've used both "tuple subclass" and "__slots__," but both of those have their own little quirks.)
Python 3.4 is one of the most feature-packed releases I recall. Besides the obvious new perks like enums and asyncio, note some hidden gems like PEP 442:
"
This PEP removes the current limitations and quirks of object finalization. With it, objects with __del__() methods, as well as generators with finally clauses, can be finalized when they are part of a reference cycle.
"
This has been a notorious limitation in Python forever, and in 3.4 it's finally solved.
I am not into the Python internals but I would suspect the widely critiqued Python 3 step was just that: a shift that did not bring that much by itself but rearranged the inners enough to allow unlocking a lot of new doors in the future.
Finally, a statistics module!
Actually though, simple methods for measures of center and spread have been on my Python wishlist since, like, forever. The mean() function is going to be especially useful. So excited!
This seems to me to be a watershed release. 3.4 is the point where we should move en masse to Python 3 for software development. At the same time, we should conciously abandon the default distro installed Python. Leave that for sysadmin tasks and sysadmin scripting, but for actual applications, install Python 3.4 in a virtualenv and use that going forward. By now you should only occasionally run into non-ported libraries and the details of how to port them are well enough known that you should be able to do the job yourself if you run into one that is important to you.
I have quite a few projects based on django, and these are still 2.7. There are still too many dependencies that are not python3 ready yet.
On the bright side since django 1.5 has been released with python 3 support, many related projects have moved to python3. Still not completely there yet, but moving forward.
Shameless plug: I've been testing little badges to tell which requirements are python 3 ready or not on requires.io (https://requires.io). Should be in production later today or tomorrow.
We started up new development a couple of weeks ago, With it was the choice of language, runtime and so on.
Python3 ended up being the target for server-side bits. Thanks to the fact that Pyramid now is Python3 capable.
We are still finding Python3 issues. Deploying Python3 on RHEL was a bit of a pain, most solved by RH Software Collections providing a python3.3 build, and the functioning state of virtualenv+pip.
Not being able to use mod_wsgi with python3 was a bit of a pain, ( fastcgi wrapper, to the rescue ) but solved.
I recently started moving my existing open source apps to Python 3, now that Django, NumPy and Matplotlib all support it. For new apps I write Python 3 from scratch. Perhaps I'm not getting advantage of all the new stuff, but one app is into serial I/O and I had to rewrite entirely the code dealing with strings, because I read bytes from the serial device.
Debian Jessie will default to Python 3 only I heard. I am starting to only install python3-* packages.
Can someone help me understand how to think about the transition from 2.7.x to 3.x?
I have recently switched my work to Python and just started development on what will become a series of web projects all done in Python + Django. Yes, when it comes to Python I am a noob.
Looking at it with fresh eyes it seems that the most useful ecosystem is solidly rooted in the 2.7.x branch. Books and online courses promote the idea of using 2.7.x. My kid enrolled in the MIT intro to CS edX course and they use 2.7.5. Codecademy, same thing.
From the perspective of developing a number of non-trivial web-based products, how should I view the 2.7.x and 3.x ecosystems? Do you see a timeline to a transition? How should one prepare for it (or not)? What should one avoid?
At the moment it seems safe to pretty much ignore 3.x. I kind of hate that because I have this intense desire to always work with the the latest stable release of any software I use. Here things are different due to the surrounding ecosystem of libraries and tools. I'd certainly appreciate any and all help in understanding this a bit better.
If you don't have any legacy baggage, you should celebrate your freedom to do what hockey great Wayne Gretszky said was his secret to success: Don't skate to where the puck is, skate to where it will be. The value of Python 2 knowledge is like the value of knowledge of how to write HTML/CSS for old versions of IE: a declining asset. If you don't have to deliver production software for today's user base, rejoice, and focus on learning how to target tomorrow's user base. Python 3 + Django 15 already let you do that. Those external libraries that don't work with Python 3 will either be upgraded or replaced. There is probably a lot you can learn about Python 3 and the latest Django while that takes place.
And, regarding kids, I'm teaching mine Python 3 only (no time wasted on Py 2) and the latest HTML5/CSS3 (no time wasted learning workarounds for obsolete browsers). I think they're better off focusing entirely on preparing for the future, not spending part of their time preparing for the past.
It is strange that they claim to have implemented SHA-3 in hashlib.
The details of the padding and capacity are still under discussion, so no final standard has been published yet.
I'm interested in seeing how robust this custom allocator feature will be. I doubt it will be more efficient than C/C++ but it makes the language that much more useful.
As to statistics module, wouldn't it be more useful to have median functions with default percentile parameter (defaulting to 0.5) ?
I mean, it's common use case and seems like natural thing to have.
[+] [-] pixelmonkey|12 years ago|reply
http://www.python.org/dev/peps/pep-0443/
What's going on here is that Python has added support for another kind of polymorphism known as "single dispatch".
This allows you to write a function with several implementations, each associated with one or more types of input arguments. The "dispatcher" (called 'singledispatch' and implemented as a Python function decorator) figures out which implementation to choose based on the type of the argument. It also maintains a registry of types -> function implementations.
This is not technically "multimethods" -- which can also be implemented as a decorator, as GvR did in 2005[1] -- but it's related[2].
Also, the other interesting thing about this change is that the library is already on Bitbucket[3] and PyPI[4] and has been tested to work as a backport with Python 2.6+. So you can start using this today, even if you're not on 3.x!
[1] http://www.artima.com/weblogs/viewpost.jsp?thread=101605
[2] http://en.wikipedia.org/wiki/Dynamic_dispatch
[3] https://bitbucket.org/ambv/singledispatch
[4] https://pypi.python.org/pypi/singledispatch
[+] [-] yeukhon|12 years ago|reply
I don't really understand the benefit of mm and dispatch. This sounds useful for building routes in webapp. But for library, it sounds like we are bringing back C++'s single interface, multiple types... I don't even remember what that is called.
[+] [-] voltagex_|12 years ago|reply
Is this method overloading or am I missing something?
[+] [-] Pxtl|12 years ago|reply
[+] [-] revelation|12 years ago|reply
Single dispatch is pretty standard polymorphism, C++ can do that.
[+] [-] rspeer|12 years ago|reply
"Text is always Unicode. Read it in as UTF-8. Write it out as UTF-8. Everything in between just works."
This was not true up through 3.2, because Unicode in Python <= 3.2 was an abstraction that leaked some very unfortunate implementation details. There was the chance that you were on a "narrow build" of Python, where Unicode characters in memory were fixed to be two bytes long, so you couldn't perform most operations on characters outside the Basic Multilingual Plane. You could kind of fake it sometimes, but it meant you had to be thinking about "okay, how is this text really represented in memory" all the time, and explicitly coding around the fact that two different installations of Python with the same version number have different behavior.
Python 3.3 switched to a flexible string representation that eliminated the need for narrow and wide builds. However, operations in this representation weren't tested well enough for non-BMP characters, so running something like text.lower() on arbitrary text could now give you a SystemError (http://bugs.python.org/issue18183).
With that bug fixed in Python 3.4, that removes the last thing I know of standing in the way of Unicode just working.
[+] [-] mineo|12 years ago|reply
[0] http://nedbatchelder.com/text/unipain.html [1] http://nedbatchelder.com/text/unipain/unipain.html#35
[+] [-] graue|12 years ago|reply
[+] [-] tekacs|12 years ago|reply
This is great for those maintaining substantial codebases in the language, though.
The thorough specification process gives lots of warning for the introduction of changes (so you can almost update on release day if you were really so inclined and prepared).
Edit: Though on a re-read, clear, comprehensive newbie friendly documentation is something that (somewhat unrelatedly) Python does have. My bad.
[+] [-] scapamalt|12 years ago|reply
[+] [-] ot|12 years ago|reply
[1] http://www.python.org/dev/peps/pep-3156/
[+] [-] lockes5hadow|12 years ago|reply
[+] [-] arocks|12 years ago|reply
Thanks! Now I don't have to do this on every box anymore for using Python.
[+] [-] digisign|12 years ago|reply
After finding bpython this is a bit underwhelming. Perhaps they should just include it by default.
[+] [-] dmishe|12 years ago|reply
[+] [-] yeukhon|12 years ago|reply
[+] [-] LeafStorm|12 years ago|reply
But, ever since I found out about algebraic data types from other languages, I keep wanting those. There's not quite a good way to do those in Python. (I've used both "tuple subclass" and "__slots__," but both of those have their own little quirks.)
[+] [-] shoo|12 years ago|reply
[+] [-] eliben|12 years ago|reply
" This PEP removes the current limitations and quirks of object finalization. With it, objects with __del__() methods, as well as generators with finally clauses, can be finalized when they are part of a reference cycle. "
This has been a notorious limitation in Python forever, and in 3.4 it's finally solved.
[+] [-] gbog|12 years ago|reply
[+] [-] joliv|12 years ago|reply
[+] [-] panzi|12 years ago|reply
[+] [-] takluyver|12 years ago|reply
[+] [-] nemothekid|12 years ago|reply
Is there anyone else who is still procrastinating moving their workflow to Python3?
[+] [-] memracom|12 years ago|reply
[+] [-] Xixi|12 years ago|reply
On the bright side since django 1.5 has been released with python 3 support, many related projects have moved to python3. Still not completely there yet, but moving forward.
Shameless plug: I've been testing little badges to tell which requirements are python 3 ready or not on requires.io (https://requires.io). Should be in production later today or tomorrow.
[+] [-] bobmoretti|12 years ago|reply
Are there any major libraries that have not yet been ported to Python 3? I'd be interested to hear about others' experiences making the plunge.
[+] [-] Spidler|12 years ago|reply
Python3 ended up being the target for server-side bits. Thanks to the fact that Pyramid now is Python3 capable.
We are still finding Python3 issues. Deploying Python3 on RHEL was a bit of a pain, most solved by RH Software Collections providing a python3.3 build, and the functioning state of virtualenv+pip.
Not being able to use mod_wsgi with python3 was a bit of a pain, ( fastcgi wrapper, to the rescue ) but solved.
[+] [-] r0muald|12 years ago|reply
Debian Jessie will default to Python 3 only I heard. I am starting to only install python3-* packages.
[+] [-] digisign|12 years ago|reply
[+] [-] voltagex_|12 years ago|reply
[+] [-] robomartin|12 years ago|reply
I have recently switched my work to Python and just started development on what will become a series of web projects all done in Python + Django. Yes, when it comes to Python I am a noob.
Looking at it with fresh eyes it seems that the most useful ecosystem is solidly rooted in the 2.7.x branch. Books and online courses promote the idea of using 2.7.x. My kid enrolled in the MIT intro to CS edX course and they use 2.7.5. Codecademy, same thing.
From the perspective of developing a number of non-trivial web-based products, how should I view the 2.7.x and 3.x ecosystems? Do you see a timeline to a transition? How should one prepare for it (or not)? What should one avoid?
At the moment it seems safe to pretty much ignore 3.x. I kind of hate that because I have this intense desire to always work with the the latest stable release of any software I use. Here things are different due to the surrounding ecosystem of libraries and tools. I'd certainly appreciate any and all help in understanding this a bit better.
[+] [-] SiVal|12 years ago|reply
And, regarding kids, I'm teaching mine Python 3 only (no time wasted on Py 2) and the latest HTML5/CSS3 (no time wasted learning workarounds for obsolete browsers). I think they're better off focusing entirely on preparing for the future, not spending part of their time preparing for the past.
[+] [-] Siecje|12 years ago|reply
OS/2
[+] [-] tveita|12 years ago|reply
[+] [-] ridhoq|12 years ago|reply
[+] [-] thearn4|12 years ago|reply
[+] [-] bluecalm|12 years ago|reply
[+] [-] bluecalm|12 years ago|reply
[+] [-] chrismorgan|12 years ago|reply
[+] [-] lightcatcher|12 years ago|reply
[+] [-] lockes5hadow|12 years ago|reply
[+] [-] danbmil99|12 years ago|reply