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).
Python 2.8?
41–50 of 74 posts
Re: Python 2.8?
#42Earlier 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.
Re: Python 2.8?
#43The 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…
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?
#44Earlier 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…
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?
#45The 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…
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?
#46Earlier 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.
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?
#47Back 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…
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?
#48Earlier 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?
Because you're importing big legacy python2 libraries.
Re: Python 2.8?
#49Back 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…
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?
#50Earlier 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…