There has recently been some discussion about Python 3, and the percieved slow rate of adoption, and as a part of that discussion there have been frequent calls for a Python 2.8. But nobobody agrees with anyone else about anything in that discussin, so I thought I would dissect the issue a bit to clarify.
Essentially there are two different views of Python 2.8. It’s common to hear people asking for a Python 2.8 to help transition to Python 3. Let’s call that a “transitional Python 2.8″. The other group that wants a Python 2.8 want it because they want all the new goodie features of Python 3.x, like
yield from, without having to actually upgrade their existing code to Python 3. I’ll call that the “featuristic Python 2.8″.
The Featuristic Python 2.8
Python 3 is in active development, and do have new features added to it. Python 2 is in bugfix mode. Why is that? Well, it’s simply because the core developers aren’t interested in adding features to Python 2. In their opinion Python 3 is so much better and nicer that thay no longer want to maintain or add features to Python 2. In fact, Python 3 exists because there were features the core developers wanted that could not be added to Python in a fully backwards compatible way.
Therefore, from the core developers point of view, if we add the features they want to Python 2, you get Python 3. You ask for a Python 2 with the goodies from Python 3? OK, here, it’s called Python 3. So the core developers are not interested in creating a Python 2.8 that includes just some of the benefits of Python 3. That’s just a lot of work, but for them it creates no benefit. A Featuristic Python 2.8 is essentially just a crippled Python 3.4.
And that features are added to the latest version and earlier versions are in bug fix mode is after all the standard mode of development. To ease transition, both Python 2.6 and 2.7 has been released, but this can’t continue for ever, for obvious reasons.
Does that mean a Python 2.8 can not happen? No, it can. If the Python core developers decide that Python 3 was a dead end, then obviously a Python 2.8 will happen. But that is a big if, and it certainly isn’t going to happen anytime soon. The other way it can happen if somebody forks Python 2, and makes a Python 2.8. It will have to be released under another name, though, but should “Psnakes 2.8″ become a big success, this may also change the core developers minds.
But asking the core developers to make a Python 2.8 and release it is currently not a constructive path forward. They are not interested in doing it. And being upset and rude isn’t gonna help either. This is open source we are talking about, and people working on their free time. You can demand that they do something they don’t want to, and call them names if they don’t. It’s not constructive.
So, if you want “Psnakes 2.8″ what should you do? Well, stop complaining and do it. I’m sorry, but that’s how it is in open source. If nobody wants to do the job, it’s not going to get done.
The Transitional Python 2.8
The other major type of Python 2.8 being discussed is a Python 2.8 that helps smooth the transition to Python 3. Mainly this would be done by making it easier to write code that runs both on Python 2.8 and Python 3 (mainly Python 3.5, probably). Could that happen? Well, I think it will be much easier to convince the core devs to release this kind of Python 2.8, if the need is there. The question then is if the need really is there. What features can you add to a Python 2.8 so that it is still backwards compatible, makes it easier to write code that runs on both Python 2.8 and Python 3, but can not be added in a separate library?
Well, *that* is an interesting discussion, and I have asked this to many people over the last year(s). And usually nobody has any suggestions. The only suggestions I have recieved so far is:
1. Include the standard library reorganisation, so that libraries are available under both the new and old names.
2. More deprecation warnings.
six helps with the standard library reorganisation, so that doesn’t really require a Python 2.8. More deprecation warnings to require a Python 2.8, but I’m not sure how helpful that would be. After all, the best path to supporting Python 3 (at least in my experience) includes runninge
2to3 on the code, so having deprecation warnings for anything that is handled by
2to3 is probably not very important.
I can think of more things, but I’m not telling, because I want people who have tried to port to tell me what features they actually want.
So in my opinion, the potential for a Transitional Python 2.8 isn’t that large either, simply because it’s not really needed. Upgrading to Python 3 *can* be a lot of work. But I’m not sure a Python 2.8 would make it significantly easier. But I’m willing to be convinced otherwise.
For the holiday season I’ve decided to have a 25% sale on my book on porting to Python 3!
You can get the PDF version at Gumroad and you get a 25% discount with the code “py3yule”.
The paperback is available from Createspace and you get the 25% discount with the code “MP4JLMLC”.
Excellent presents for any Python programmer!
The second edition of Porting to Python 3 is now available as paperback as well as PDF!
Porting to Python 3 is the most complete source available to help you with making your Python code run on Python 3.
It’s available as paperback from many channels:
- Directly from Createspace
- Amazon: .com, .co.uk, .de, .es, .fr, .it
- On other Amazons (but via resellers)
- If you want to more than ten, contact me: firstname.lastname@example.org
It’s also available as PDF! When you buy the PDF you get three PDF’s, adapted for screen/print, tablets and phones.
The book gets right to the point, without a lot of fluff and filler – Doug Hellmann
A concise, well-organised and complete reference – Richard Jones
Update: After another bug report I realized I didn’t have a check that there are distributions uploaded to the Cheeseshop. This despite being a pet peeve of mine that people don’t upload distributions to the Cheeseshop. So I released 1.4, with an additional check for this.
Pyroma rhymes with aroma, and is a product aimed at giving a rating of how well a Python project complies with the best practices of the Python packaging ecosystem, primarily PyPI, pip, Distribute etc, as well as a list of issues that could be improved.
The aim of this is both to help people make a project that is nice and usable, but also to improve the quality of Python third-party software, making it easier and more enjoyable to use the vast array of available modules for Python.
Pyroma 1.3.1 fixes a small bug and improves the integration with zest.releaser for a smoother release experience.
It supports Python 2.5, 2.6, 2.7, 3.1, 3.2 and 3.3, as well as Jython and PyPy.
Version 1.0 adds a couple of bug fixes, mainly related to giving better error messages when deducing the time zone fails.
I’ve gone through my modules on the CheeseShop and made sure the information about them is up to date. Most importantly, I’ve marked the following modules as “Development Status :: 7 – Inactive“:
- calcore: This is a module that Martijn Faassen and me write that has the Python core of a calendaring system. It was pretty nice, but only ever used by Nuxeo.
- collective.portlet.quote: Shows random quotes in a portlets, chosen from quotes in a folder. I developed this for project at Jarn.
- megrok.genshi: Genshi template support for Grok. Mostly it was used as use case for making Grok support other templates. I don’t think nobody ever used it, though.
- p4a.calendar: This module, originally by Rocky Burt (I think) once contained views for p4a.plonecalendar, but the project since a long time uses dateable.chronos instead.
I don’t think anyone is actually using these packages any more, but if you do, please tell me and you can take over maintenance.
svg.path is a collection of objects that implement the different path commands in SVG, and a parser for SVG path definitions. It supports Python 2.6 to 3.3.
It’s main use is to parse an SVG path specification and then you can extract points on that path. You can also easily manipulate the path, but 1.0 doesn’t contain support to render paths back to SVG specs. I hope to get time for this in the future, contributions are welcome.
svg.path 1.0 fixes a bug when handling path specifications that use no spaces and have negative numbers.
svg.path is put into an svg.namespace to allow for other modules using the same principles that can handle other parts of the SVG spec. I currently have no need for anything than the path bit of the specifications, but other modules are welcome there as well. Please contact me to make sure the API follows the same principles so that the modules are easily inoperable.
collective.blog.*, or just blog.star for short, is a suite of blogging modules for Plone. It is primarily designed for integrators. Most people who use Plone for blogging also uses Plone as a customized content management system, and they have specific requirements and their own skin, custom content types and other integrations. It turned out that other Plone blogging products make a lot of assumption about how you are to use it, what you want from a blog, and how your site is set up. The blog.star modules are modular, make few assumptions and reuse already existing technology as far as possible.
blog.star 1.2’s main feature is that it now supports Plone 4.3. This has in some cases required quite big changes. For example, collective.blog.feeds will under Plone 4.3 rely on Plone 4.3’s built-in Syndication functionality. collective.blog.view also has quite substantial changes.
Language support is also vastly improved, but many of the latest features has created new strings which remain untranslated, help with updating translations and adding new translations are appreciated.
It’s been far too long since I released a new version of blog.star, which is entirely because of lack of time. If somebody is interested in taking over maintenance, email me.