Making Python 3 more attractive
1–10 of 172 posts
Re: Making Python 3 more attractive
#2[deleted]
Re: Making Python 3 more attractive
#3People are always going to whine about any change. The Python community should have been more adamant about dropping 2.x updates. Spreading out the pain doesn't make it easier...more code is still being written in 2.x. Ugh, I think I said this 5 years ago. Imagine the tens of millions of new 2.x code that's been written in the last 5 years. Oh well, good luck.
Re: Making Python 3 more attractive
#4> The Unicode support that comes with Python 3 is "kind of like eating your vegetables", he said. It is good for you, but it doesn't really excite developers
Saddly I agree with that. There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) or a large carrot ("Oh look 3x performance improvement!").
Something like a carrot was presented during Pycon and that was gradual types (optional types). These reduce some cases covered by unit tests, make code more readable for new developers, help with IDE support, and of course assist with general static checkers. According to Guido 3.5 should start having a partial support for it.
But in general I would have liked either one of these instead (some are contradictory, arbitrary hard, or downright impossible):
* At least 2-3x performance improvement
* No GIL
* Merge greenlet library in the core (to make eventlet or gevent work)
* Some kind of an ahead of time compiler that bundles just the needed interpreter library parts into an executable
* Firefox and Chrome agree to add browser suport for it
* Mobile support (native Android support or Apple ditches Swift and uses Python instead).
Re: Making Python 3 more attractive
#5Python developers would almost all upgrade in a single minute for 30%+ better performance.
It's interesting that performance wasn't a topic at this rump session as reported; I moved over to Go about a year ago, and while I miss Python's expressivity at least once a week, I'm just not willing to slow down all my programs by 5x.
On the other hand, if Python could double in speed, I'd likely try to rework it into our workflows. Well, maybe. I really dig Go.
Re: Making Python 3 more attractive
#6Python should institute "migration" notices on all of the 2.x documentation, making it clear that the intent of the community should be to move to Python 3. I know they plan to support Python 2 for a while longer, but no reason they can't make the statement that everyone should be using the latest versions available.
Re: Making Python 3 more attractive
#7I don't think any of the things proposed will really drive conversion from Py2 to Py3. I don't think developers need to be excited about it, it just needs to be plausible. Python 3 has some significant momentum now (these talks seem overly negative about it). Developers are waiting for the signal from the enterprise Linux distributions that Py3 is "truly stable", i.e., they're waiting for it to be made the default Python. Once this happens, any remaining holdouts, which, again, are not that many of the actual libraries that people regularly use (cf. https://python3wos.appspot.com ), will stop their moaning and finally catch up.
I think if someone hasn't moved to Python 3 yet, no iterative change is really going to get them to do it. It's OK if old software is resistant to breaking changes; this is about building a good ecosystem for the software to come. If it was about making things easy for people who've already written their software, Python 3 would not have been released in the first place.
Honestly I don't really see why anyone cares about whether Mercurial is Py2 or Py3, since it's not a library and isn't holding up new development. Mercurial can use the Py2 interpreter to its heart's content and it shouldn't have any effect on the prosperity of Py3.
The Python community needs to get serious about pushing adoption of Py3 by the distros, and then we can put this navel gazing to rest and move on with Py3 finally realized as the standard.
Re: Making Python 3 more attractive
#8People are always going to whine about any change. The Python community should have been more adamant about dropping 2.x updates. Spreading out the pain doesn't make it easier...more code is still being written in 2.x. Ugh, I think I said this 5 years ago. Imagine the tens of millions of new 2.x code that's been written in the last 5 years. Oh well, good luck.
It's challenging. On the one hand, you don't want to break what is working (Python 2.x), so you'd like to support it so that community can continue to be productive. On the other hand, you don't want your braintrust split across two different versions, and you don't want the confusion that comes from having two major versions.
For example, the (Epic) Learning Python 5th Edition by Mark Lutz, had to be written for two simultaneous audiences, 2.7 and 3.3. There are all these disclaimers noting where things are different between the two versions, and there is a lot of cognitive overload trying to read a book can't assume you are on Python3.
In the best case world - people would treat this like a y2k situation, and realize that if they didn't get with the program, and migrate over to Python3, they'll end up like Perl, with some other newcomer that isn't so bipolar charging forward and winning mindshare.
Unfortunately, their are a lot of Python2 people who are happy with Python2, and we're in the situation we have today.
Re: Making Python 3 more attractive
#9If the Perl6 rewrite is validated by it having a larger user base than Python 3 in 5 years' time, part of me that has died will be reborn. Unlikely, though.
Re: Making Python 3 more attractive
#10> The Unicode support that comes with Python 3 is "kind of like eating your vegetables", he said. It is good for you, but it doesn't really excite developers Saddly I agree with that. There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) or a large carrot ("Oh look 3x performance improvement!"). Something like a carrot was presented during Pycon and that was gradual types (o…
Firefox added Python support in the past and there was no uptake. Brendan Eich has a hnews comment on it.
I think 2x-3x perf improvement /is/ possible. I mean we have the example of javascript that went from terrible perf to almost native parity. Of course Mozilla & Google each dedicated an entire team to get there.
We already have the example of PyPy too which /today/ averages a >5x (http://speed.pypy.org/) speed up with CPython!