Live data from Hacker News

Python 2.8?

lwn.net

41–50 of 74 posts

Re: Python 2.8?

#41
post #40
post #18

Earlier quoted context omitted.

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.

Numpy / scipy and scikit-learn are the only things that are holding me back. Apart from that, I think its just a matter of time golang will have similar libraries in its ecosystem. Afaik, for regular CRUD apps golang can pretty much replace whole of python with better performance (in terms of concurrency).

Those toolkits often rely on generics/duck typing, and tend towards very simple REPL style exploration.

Re: Python 2.8?

#42
post #39

Earlier quoted context omitted.

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. Just to bring up a small counterpoint: I don't think anyone really expected the early 3.x releases to be used in production. They were, as I recall, intended primarily as proof-of-concept releases to let people start looking at what porting would involve, and to get fee…

> I don't think anyone really expected the early 3.x releases to be used in production. I see this as a huge red flag. Its ok, to break/experiment things until you reach 1.0. After that, the core development team must factor in the consequences of breaking backwards compatibility.

I think you're reading it wrong there; this is not a statement of "3.0 came out and then they kept breaking compatibility all the time until 3.3", it's a statement of "3.0 declared what the changes were so people could play with the new APIs, and then 3.1, 3.2 and 3.3 spent time on performance and making porting easier so that people could actually port to and deploy on later 3.x releases".

Re: Python 2.8?

#43

The amount of trolling in that thread is incredible. I don't understand why an average Joe needs to contradict Guido on trademark matters.

Because some people are hateful by nature and see Guido as Satan incarnate for "hating Python 2". And no, I'm not exaggerating, you just need to look at the comments: https://github.com/naftaliharris/placeholder/issues/47#issue... I read through that thread the other day and it breaks my heart to know that there are people who think like that. Honestly. On various occasions I've reasoned (and not reasoned) with the m…

Treat your FOSS maintainers with some human decency.

The same could be said about politicians, too......although they are easy to ridicule. It makes it hard to get good leaders when no sane person would choose to endure all the abuse a political candidate gets.

Re: Python 2.8?

#44
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…

The ultimate goal is to build an interpreter that can run both Python 2 and 3 code.

That is a great goal, I fully support you.

so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there

Even if the interpreter has to decide, "this file is python2, it will do it one way.....that file is python3, it will do it another way" that is good enough. As long as you can call functions and such between the two files.

Re: Python 2.8?

#45

The amount of trolling in that thread is incredible. I don't understand why an average Joe needs to contradict Guido on trademark matters.

Because some people are hateful by nature and see Guido as Satan incarnate for "hating Python 2". And no, I'm not exaggerating, you just need to look at the comments: https://github.com/naftaliharris/placeholder/issues/47#issue... I read through that thread the other day and it breaks my heart to know that there are people who think like that. Honestly. On various occasions I've reasoned (and not reasoned) with the m…

I don't use Python, but there are some super cringy naming suggestions in that thread.

This is the kind of thing where you are appealing to a legacy user base and there's no reason to get smirky about it. Something like Twothon, Bithon (not good for obv reasons), Zweithon, and so forth would much better communicate the intent of the project IMO.

Re: Python 2.8?

#46
post #35
post #8

Earlier quoted context omitted.

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

Exactly. For language devs. It's always good to learn from mistakes from the past. PHP 6 failed, then PHP stayed with 5.x and moved directly from v5 to v7 - that worked out fine. The Python 2 to 3 is an important lesson as well. Ruby (afaik 1 to 2), dotNet 1 to 2 and 4 to dotNetCore 1, Swift 1 to 2 to 3, ... are several more cases that were rocky for developers.

AFAIR the messy release for ruby was 1.8 -> 1.9 (the new VM, changes to encodings, OS-level threading etc) but both that change and 1.9->2.0 worked out _much_ better than python 2->3.

As I understand it, Matz considers the upgrade strategy until now quite successful, mostly because at the same time breaking changes occurred people got things they wanted (e.g. faster VM) which encouraged them to upgrade.

Hence the "ruby 3 will be 3 times faster than ruby 2" idea, that's the carrot that should contrast people's will to not update.

Re: Python 2.8?

#47
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…

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 as successful as it has because of the (relatively) unified effort of popular open source library authors to switch common dependencies.

Re: Python 2.8?

#48
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 agree. What exactly is the point of backporting features, when the main reason people give for wanting to use Python 2 is for legacy applications? What 8-year-old codebase is going to be updated to use `async`? And if you're starting a new project, why not write it in Python 3, which has first-party support?

>And if you're starting a new project, why not write it in Python 3, which has first-party support?

Because you're importing big legacy python2 libraries.

Re: Python 2.8?

#49
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 handle unicode vs bytes". All other backwards incompatible changes were trivial in comparison, almost fixable by search and replace.

And "careful handling of unicode vs bytes" was something that you already could do in Python2, and should do in Python2, but weren't forced to. If you did, then upgrade to Python3 was easy. If not, then you had a massive testing and refactoring problem on your hands.

I would not even see it as a language change, but would compare it to C and C++ compilers turning -Wall -Werror on as mandatory flags in the latest release. It would be sort of "good for the ecosystem" in the long term, but would also be a lot of effort for people with legacy codebases.

Re: Python 2.8?

#50
post #35

Earlier quoted context omitted.

Exactly. For language devs. It's always good to learn from mistakes from the past. PHP 6 failed, then PHP stayed with 5.x and moved directly from v5 to v7 - that worked out fine. The Python 2 to 3 is an important lesson as well. Ruby (afaik 1 to 2), dotNet 1 to 2 and 4 to dotNetCore 1, Swift 1 to 2 to 3, ... are several more cases that were rocky for developers.

AFAIR the messy release for ruby was 1.8 -> 1.9 (the new VM, changes to encodings, OS-level threading etc) but both that change and 1.9->2.0 worked out _much_ better than python 2->3. As I understand it, Matz considers the upgrade strategy until now quite successful, mostly because at the same time breaking changes occurred people got things they wanted (e.g. faster VM) which encouraged them to upgrade. Hence the "ru…

I suspect that Ruby also benefited from having a comparatively young community. There are folks that used Ruby before Rails, but the majority of Rubyists only started in 2006 or later, so they are used to the faster replacement rate of modern Open Source and didn't have so many legacy codebases to worry about.
Post reply on HN