So, first off - unless you've lived under a rock for the last 24 hours, you should know Python 3000 final is hot off the bit presses. This marks a huge milestone for the language, and major props are deserved to all of the python-core people who have spent so much time working on it. Python 3000 marks an interesting point in the evolution of the language - we all know it is meant to clean up some of the warts of the python 2.x series. It's designed and implemented knowing full well it breaks backwards compatibility - but I would argue it doesn't fall in the black and white camp of revolution vs. evolution. In my mind, Python 3 actually falls right in the middle. Yes, it is revolutionary in the aspect that it breaks compatibility with 2, but it is not so significant a series of breakages that it falls outside of the evolutionary camp.
For example, changes to fundamentals - like whitespace, dropping tuples, switching to pure functional programming - that in my mind counts as revolutionary. Python 3 counts as more of an evolutionary jump - the changes are meant to clean things up - removing the prehensile tail and single eyebrow, so to speak.
It's still a jump though - that why the core team has been repeating the mantra "use it for porting/prototyping but not day to day production use". I can't stress this enough - Python 3 is slower that 2.x, and library maintainers are going to lag significantly behind. Sure - download it, experiment with it, and keep it in your mind, but don't deploy with it - right now.
Actual widespread adoption of it is going to happen after 3.1/3.2 at very least, and the 2.6 and so on releases will continue to thrive. Adoption of 3 will be a long time in coming, and will ultimately be driven by the OS maintainers. I can easily see, over the next few years, python2 and python3 co-existing on operating systems and then one day, python2 just goes away.
All in all, it's a great series of changes, and a lot of people put a lot of work and time into it. Python development - core development is pragmatic, reasoned and always thoughtful about the changes that go into the language and libraries. The amount of time that is required to be this way is amazing.
So, I spent a few days in november at PyWorks in Atlanta - I got to do my talk on threading/multiprocessing (slides here). I think it went OK, but provided my multiprocessing talk is accepted for PyCon, I know what I will do differently.
I got generally positive feedback on the talk, so that was a bonus.
Also, recently I got a chance to fix a handful of multiprocessing doc issues - I expanded some examples, fixed some other doc errors/etc. Doc changes go live quickly, so you can see them shortly after I update them.
I am always looking for:
- Bug reports on multiprocessing
- Usability issues
- Examples that would help make things easier to understand
- Doc suggestions
Everything is fair game. I openly admit that not everything is as clear as it should be, and the package has some rough edges I want to whittle down, but finding random statements on popular sites like:
"except that the multiprocessing library is half-baked. it's been the bane of my existence recently."
and not having bug reports, emails or any other information to help me make it better drives me up a wall.
Since 2.6 was released, I haven't had enough time to give it a lot of the TLC it needs - real work, and being a dad trump my open source time. Even my other projects are in the cooler until a less busy time is achieved.
So please - send me you suggestions, send me your criticisms, hell, send me hate mail if you really feel the need to vent, but don't do nothing. Right now, I'm the primary maintainer, but Christian Heimes has also been doing a lot of heavy lifting, as well as others. It's really a team effort (especially as Richard, the original author has been MIA for some time).
Lastly, I fixed my hosting issues - apparently my host disabled my account without telling me that it was being disabled. Hooray.