Making Python 3 more attractive

Posted Apr 15, 2015 12:48 UTC (Wed) by spanezz (guest, #56653)
Parent article: Making Python 3 more attractive

I do not understand the obsession with the GIL, as if the only thing in which python can compete was performance. Python is an interpreted language. Calling "foo.bar += 1" triggers a jungle of dictionary lookups, by design: performance was traded for flexibility.

Something compelling in python3.4 is asyncio and coroutine-based asynchronous programming: they allow to do what node.js is doing, but avoiding the callback hell. I see Tornado as the node.js alternative that works and is actually pleasant to use, and 3.4 brings so much more to it.

Something compelling in python 2.7, however, is stability. I can write code in 2.7 and I am certain that I won't need to change it until 2020. Can the same thing be said for 3.4? Maybe not: https://docs.python.org/dev/whatsnew/3.5.html#deprecated

So, the way I see it, what we have now is already very cool indeed. So: first, /tell everyone about it/, and second, pretty please, /stop breaking it/.

Making Python 3 more attractive

Posted Apr 15, 2015 15:22 UTC (Wed) by jtaylor (subscriber, #91739) [Link]

removing the GIL would be nice, but I doubt it would really help python3 adoption.
There are almost no existing programs that would profit significantly from it because they don't use threads in the first place because the currently existing GIL makes that pointless on cpu bound tasks.

If people think performance is the way to get people to use python3, one should look at improving serial performance.
Maybe via JIT or maybe just by applying some of the stuff the astoptimizer package does into the core interpreter. There was also once a variant of cpython using wider bytecode which claimed to improve performance by some decent (but not amazing) amount, I wonder what happened with that.

Making Python 3 more attractive

Posted Apr 15, 2015 17:06 UTC (Wed) by kjp (guest, #39639) [Link]

Totally Agree. If you want something fast, threaded, and safe, make a rust extension for python. (It's amazing how safe rust is). Just make sure you don't panic back into python. I can not believe they are still talking about breaking more stuff, after the 3.0 debacle. *shakes head*.

"await/yield from" and the static type annotation checking (not sure if either are done) is the only thing I've seen interesting about 3.x. We have 50K LOC in python and it's a bitch to change - python has to be able to handle "success" better (where success is your codebase goes from prototype to much, much, larger and interonnected).

Making Python 3 more attractive

Posted Apr 15, 2015 18:46 UTC (Wed) by njs (subscriber, #40338) [Link] (3 responses)

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