Making Python 3 more attractive

Posted Apr 15, 2015 18:46 UTC (Wed) by njs (subscriber, #40338)
In reply to: Making Python 3 more attractive by spanezz
Parent article: Making Python 3 more attractive

> Maybe not: https://docs.python.org/dev/whatsnew/3.5.html#deprecated

So, uh, what on that list are you bothered by? It looks like a tiny list of tiny obscure cleanups to me.

Making Python 3 more attractive

Posted Apr 16, 2015 8:44 UTC (Thu) by spanezz (guest, #56653) [Link] (1 responses)

I am bothered by the idea that if I code against the official documentation in the current Python 3.x, some bits of my code can end up triggering deprecation warnings in 3.x+1 and stopping to work in 3.x+2. That means that every software that I release that uses Python 3.x will need a code review when 3.x+1 comes out, and that is work.

I do not see "Obscure" as an objective definition: what is obscure for you may be everyday work for me. A change on something that is obscure for me may not affect the code that I wrote, but can still break some module written by someone else that is part of my dependency chain.

There are ways of addressing this: one would be to mark some stdlib features as "stable" in the documentation, and make a guarantee that they will not be broken in any new 3.x release. Another would be to consider everything released in a 3.x release as stable, and make a commitment not to break it regardless of how obscure it is, scheduling API-breaking cleanups for 4.0. Both things would make me happier.

I suffered greatly back in the days when at every new 2.x release I started getting bug reports of DeprecationWarnings on something of other, and I feel a great sense of relief now that I can release 2.7 code that does not rot that easily. I really do not like the idea of going back: http://www.enricozini.org/2015/python-api-stability/

Making Python 3 more attractive

Posted Apr 16, 2015 20:14 UTC (Thu) by iabervon (subscriber, #722) [Link]

That's more of a function of the policy against creating 2.8 than the policy for 3.x, though. The 2.x EOL was supposed to encourage people to move to 3.x, but it actually has the opposite effect for people who were happy with 2.4, didn't like switching to 2.5, 2.6, and 2.7, and are now happy not to have to switch to 2.8.

On the other hand, if they said that 3.4.x would be maintained for at least as long as 2.7.x (under the same policy), that might tempt people, although making similar promises about more and more versions would be a big maintenance burden.

Making Python 3 more attractive

Posted Apr 16, 2015 11:15 UTC (Thu) by federico3 (guest, #101963) [Link]

Many people write code that is going to be used for years rather than weeks.

Writing a library that can run natively under Python 2.7, 3.3 and 3.4 is painful and requires an amount of hacks. Not to mention Python 2.6.

Then, it has to run reliably when deployed with the latest version of every dependency and older ones, maybe up to 2 years ago or more - and your code will break in every possible way.