Skip to content

The potential for a Python 2.8.

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.

Tools like 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.

25% holiday discounts on Porting to Python 3!

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!

Paperback of Porting to Python 3 available for sale!

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:

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

Pyroma 1.3.1 released

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.

tzlocal 1.0 released

tzlocal is a module that tries to deduce what your local time zone is from your operating systems configuration, and returns a pytz timezone object.

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.

My defunct modules

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 1.0 released

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.

blog.star 1.2 released

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.

p4a.plonecalendar 2.1 released

p4a.plonecalendar is a calendar for Plone. Mainly it is a set of calendaring views whose main feature is that can be used without Javascript.

Version 2.1’s main feature is that it adds Plone 4.3 support.

Development workflow and architecture

Back in the stone-age, when I started programming, the main development paradigms was “bottom-up” or “top-down”. Essentially, if you created the overall structure of the program first, and then started filling out details, or did you implement low-level functions first and then composited them together.

I never did any of those, I tended to do “start-finish”, I start with the first thing that needed to happen in the program and go from there. It was hard to get it into a “workflow” of things to do that resulted in anything else. So I shunted the whole idea of “bottom-up” or “top-down” to the side, and apparently so did everyone else because people stopped talking about it. I also think that many frameworks enforce their own workflow on things, so it’s therefore become less relevant because if this.

The last few years I have however found myself doing a lot of bottom-up development, and that’s because my tool kit now includes test-driven-development (TDD)

My workflow currently looks more or less like this: I fiddle around, test things, look at what others have done and use it if I like it. If I don’t like it I do a bit of rough “start-finish” development until I start getting the “feel” for what I’m doing and a rough idea of what I need.

Then I start a new module, and use TDD (more or less). And since I use TDD, and need something that is easy to test, and that results in a bottom-up modular approach where classes tend to be very independent of each other and their environment, simply because that makes them easy to test. It wouldn’t be possible, at least for me, to do this unless I had a clear idea of what I want, which means trying it out first. But in the end, once I start the module and the tests, even though I usually end up copying in what I already had, this quickly tend to get thrown out.

But the end result is that TDD makes me a better programmer, and makes me write code that is clearer and more modular and can be refactored more easily. And this is because TDD more or less forced me to write bottom-up. So maybe that paradigm was less irrelevant than I thought.

Follow

Get every new post delivered to your Inbox.

Join 1,339 other followers