Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 2.8?

lwn.net

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Python 2.8?

#61

Post by MattConfluence »

didibus wrote: post #14
daveguy wrote: post #7

I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any…

> Giving people more time to transition is going to benefit some projects.

Python 3 was released in December 2008. Python 2.7 was released in July 2010, and was given 5 years of support which was then extended to 10.

Those people who have not transitioned yet have not done so because of lack of time. They might have valid reasons for delaying, but time is not one.

Re: Python 2.8?

#62

Post by dagw »

copx wrote: post #8
douche wrote: post #3

The 2.X => 3.X transition really appears to have been bungled here, which is a shame. I really liked Python before I got deeply into the .Net world, but it has become less than enticing with this fragmentation. Meanwhile other languages seem to have taken up the vanguard position, which leaves Python in kind of an awkward position, between the new hotness and the tried-and-true enterprisey ecosystems

>The 2.X => 3.X transition really appears to have been bungled here, which is a shame. Obviously, the question is what went wrong. Personally I think the dev team gave users too much time to switch. The Python devs should have only given users one or two years to upgrade. Making it clear that all support for Python 2 would end after that period. Another mistake was that when originally released Python 3 did not offer…

Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile.

Not only that, they effectively took away a lot of vital shiny old things like numpy and django. It was something like 3 years between python 3.0 and the first stable releases of numpy and django with python support. That was 3 years where python 3 was effectively useless to a large number of python developers, and you can lose a lot of momentum in 3 years. Had the core python team gotten together with the teams for numpy, scipy, django and a couple of other big name libraries and coordinated the release of python 3 with versions of all those libraries that would work with python 3, then I imagine things might have gone a lot smoother.

Re: Python 2.8?

#63

Post by dekhn »

naftaliharris wrote: post #37
didibus wrote: post #14

Earlier quoted context omitted.

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any…

(I'm the primary author of this interpreter). > Backporting features will be hard It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for exampl…

Thanks for working on this. I like some of the stuff in Python 3, but I don't see any compelling reason to switch to it; I'd much rather see the vast majority of features in 3 moved back to a 2 series interpreter. That most of the features can be moved back is, in itself, an important statement on whether 3 was necessary at all.

Re: Python 2.8?

#64

Post by dekhn »

Cyph0n wrote: post #18
ram_rar wrote: post #13

I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. With golang getting a lot of traction and compiler tools like grumpy (python -> Go), I would rather invest time to transition into golang as apposed to transition to 3.X.

Transitioning from Python to Go isn't as easy as you make it out to be. Good luck finding solid alternatives to the likes of Numpy, scikit-learn, Pandas, SQLAlchemy, BeautifulSoup, Flask etc. Oh, and not to mention the community surrounding these and other popular Python libraries.

Agreed, my main reason for not switching to Go fulltime is numpy and scipy. I was recently pointed at https://github.com/gonum which has a subset of the functionality of numpy and scipy.

Re: Python 2.8?

#65

Post by unixhero »

viraptor wrote: post #19
unixhero wrote: post #16

Earlier quoted context omitted.

The problem is some of the massive python modules that cannot be ported from 2.7 to 3 .x

Which ones specifically? Many massive ones that held out for a long time are either done or in the process of porting. (twisted, openstack, almost all web frameworks, etc.) PS. https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* librarie…

Yes I was thinking about twisted

Re: Python 2.8?

#66

Post by TylerE »

MattConfluence wrote: post #61
didibus wrote: post #14

Earlier quoted context omitted.

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any…

> Giving people more time to transition is going to benefit some projects. Python 3 was released in December 2008. Python 2.7 was released in July 2010, and was given 5 years of support which was then extended to 10. Those people who have not transitioned yet have not done so because of lack of time. They might have valid reasons for delaying, but time is not one.

I disagree. When your dev team is totally busy working on features that customers are actually paying for, there is less than no business case for porting to Py3.

Re: Python 2.8?

#67

Post by saurik »

ProblemFactory wrote: post #49
placebo wrote: post #38

Back when python 3 was introduced and after learning of breaking backward compatibility my first thought was, "good luck with that"... Wanting to create something better is not surprising. What was surprising (to me at least) is not seeing that people don't like change unless they see a really dramatic benefit to what they already have, and clearly see that the advantages to making that change far outweigh the discom…

> So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. Well, it's been over 8 years. And we've just reached the point where nearly all libraries are available in Python3, and Python3 is recommended for starting new projects. Python3 was also a very unconventional backwards incompatible change. 90% of the incompatibility came from "you must correctly and carefully…

The fact that you could choose to be that careful with Unicode in Python 2.7, though, is important to not forget: if the only change was that now you had to be, then code could have easily migrated and worked on both. This was the story of Ruby 1.9, which was, compared to Python 3, a cakewalk.

The reality here is that you are just wrong in both understanding and premise :/.

First, all these minor changes are actually extremely serious, as they made it hard to impossible to have cose which ran on both; as someone who was nowhere near an expert in Ruby, it was still easy to write code which straddled the boundary between 1.8 and 1.9. Ruby 1.9 really could be seen as a set of "warnings" on 1.8.

Second, the most serious change in Python 3 was not Unicode, it was actually the way it handled generators and iterators and lists in various contexts: this was a set of changes which broke lots of code in subtle ways and which could not be handled using your argument of search and replace (and which contributed to the awkwardness of having code running on both 2 and 3 at the same time).

Re: Python 2.8?

#68

Post by cthalupa »

daveguy wrote: post #34
rcthompson wrote: post #33

Earlier quoted context omitted.

How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.

Sane is py2. Default is bytes not some Unicode string. If you want Unicode use u"". If you want what is usually needed in algorithms (aka bytes ) use "".

If you think py2 is the sane one, then you must work on a project where everything is written and communicated in bone standard roman characters.

For the vast majority of the actual planet, this simply isn't the case.

Re: Python 2.8?

#69

Post by rcthompson »

daveguy wrote: post #34
rcthompson wrote: post #33

Earlier quoted context omitted.

How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.

Sane is py2. Default is bytes not some Unicode string. If you want Unicode use u"". If you want what is usually needed in algorithms (aka bytes ) use "".

So you admit that byte strings and Unicode strings are different data types, yet you claim that Python 2 is the sane one for choosing to both using exactly the same class?

Re: Python 2.8?

#70

Post by hueving »

sametmax wrote: post #52
hueving wrote: post #47

Earlier quoted context omitted.

Yes, the biggest hindrance to python3 is the fact that python2 is a good language. It's very rare to come across a case where you can tell someone, "if you were using python3, this would be so much easier/more performant." Most of the migrations I have seen have been because of a stick rather than a carrot (e.g. this library we depend on is dropping py2 support). It's definitely the case that the move has only been a…

Well, another issue is that there are carrots, but they are tough to sell. I have been using Python 3 for 2 years now in production, and I would never want to go back to Python 2. Benefits include: - less boilerplate. Automatic super(), no object inheritance, yield from, generalized unpacking, keyword only args, less itertools import, no need for __future__, f-srings, etc. Basically my code is shorter and faster to w…

Good points, but error handling and less boilerplate are mostly moot once the code is already written, which is what makes them not great carrots for switching projects.
Post reply on HN