161–170 of 390 posts
Earlier quoted context omitted.
I think you've just proved OP's point...you have to change the code.
You have to change the code a lot more to port it to an entirely different language.
One of my teammates just upgraded our django framework from 1.4 to 1.8 and it took him almost an entire week to do.
Earlier quoted context omitted.
Look at the statement from the numpy group: The NumPy project has supported both Python 2 and Python 3 in parallel since 2010, and has found that supporting Python 2 is an increasing burden on our limited resources; That's a real team saying that they just can't support 2 major versions of the language any longer.
That is like the biggest fake argument ever. There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. The are plenty of people ready to step up to continue Py2 support (Even I would be glad to help). This is a pure political decision based on ideology.
Aside from what others have said, NumFOCUS is woefully underfunded. If you're interested in seeing continued development of NumPy and other amazing scientific Python packages, you should think about contributing!
(Not a NumFOCUS person although I occasionally volunteer with them and definitely donate on a recurring basis.)
Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…
Not having a story for interoperability between 3 and 2 was incredibly shortsighted. The migration path from Objective-C to Swift is an example of how to do this sort of transition right; Python got it wrong. Widespread adoption of Python 3 would've happened years earlier if you could start a new project in Python 3 and not have to worry about libraries you want to use not supporting it yet.
For some tasks, there are literally 5 mutually incompatible syntaxes to understand (Obj C, Swift 1234). Even though the UI can sometimes autoconvert for you, it doesn't help at at when you're looking at someone else's code.
Swift is a great example of what not to do.
Earlier quoted context omitted.
why on earth is it a good thing that people are trying to kill off Python2? Because the community is fragmented and that weakens language adoption, productivity, and enjoyment. The 2-3 schism in Python has been a pain to deal with for years. I use Python casually here and there, but I'm so sick of trying to do something quickly in Python and finding out that I'm on a machine that only has 2 but the module I need is o…
>For the good of any computer language, old versions need to eventually die off. I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to. Compare to perl: I can run old perl scripts…
Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc). And while no single issue alone would justify Python 3.x, the combination of all of these issues as well as some other semantic problems justified the need for Python 3.
Of course, that being said, Python 3 also had some issues that it took several versions to iron out.
Earlier quoted context omitted.
why on earth is it a good thing that people are trying to kill off Python2? Because the community is fragmented and that weakens language adoption, productivity, and enjoyment. The 2-3 schism in Python has been a pain to deal with for years. I use Python casually here and there, but I'm so sick of trying to do something quickly in Python and finding out that I'm on a machine that only has 2 but the module I need is o…
>For the good of any computer language, old versions need to eventually die off. I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to. Compare to perl: I can run old perl scripts…
Earlier quoted context omitted.
That's a very melodramatic comment for someone who clearly hasn't been keeping track of the 3.x changelogs – which pretty much all contain at least one compelling update to the language. Modern Python is v3. Legacy support drop-off is the same with any project.
I was going for "humor" more than "melodrama," but maybe I failed at both... The actual breaking changes between 2.x and early 3.x struck me as cosmetic and pointless. To compare: Perl went one way by breaking everything to essentially make a new language, and failed to get people to switch; C++ bent over backwards to maintain compatibility, and failed to fundamentally evolve the language. Python basically failed in…
It wasn't really a big deal. There was some pain and it became essential to have multiple versions of Ruby installed. But I haven't heard of anyone insisting on new code written for Ruby 1.8.
So languages can break backwards compatibility once in a while, and it doesn't always have to be the shitstorm it was for Python.
Early 3.x was bad, and that probably gave critical mass to the backlash. But there's no reason to care anymore about what early 3.x was like. Modern 3.x is a way better language.
Earlier quoted context omitted.
Yeah, I was pretty much sold on Python 3 when I stopped having to use the `codecs` module to read my files and when it would strictly enforce the separation between `bytes` and `str`, rather than having to manually track what sort of sequence I was dealing with.
Yes, yes. My Python life is mostly about impelemnting odd protocols with Twisted. Will probably get serious about asyncio soon, but I have a lot of historical Twisted to deal with ATM. I've noticed that the "Who cares about Python 3" types are not the people working on the kinds of problems I am. So my conclussion is that for many kinds of problems the benefits of Python 2 are kind of meh, so people stay in their com…
Earlier quoted context omitted.
There’s really not anything major in 3 that’s not easily available via back ports in 2.7. Or else why do you think people aren’t bothering to pay the price to switch? This is also the reason maintainers are bringing out sticks. They realize the carrots just aren’t that tasty.
Getting rid of the GIL is a big change. In py2.7 CPU-heavy threads are useless -- they lock up the process and starve other threads. py2.7 threads are only good for I/O heavy work. You can use multiprocessing in py2.7 but with a lot of caveats if you want to share state and file descriptors. IMO the GIL removal is the one thing "that's not easily available via back ports in 2.7".
Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…
Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…
This typically means one of two things:
1. You've never really looked at the features added in the Python 3.x release series, or
2. You develop abandonware which plans never to upgrade any part of its platform ever, for any reason, and so no conceivable new feature would be sufficient to convince you to do an upgrade.
At this point (1) is untenable because of how many people have written about the useful things available in 3.x, and (2) is disingenuous (but there are still plenty of people who use "don't see a reason to upgrade" as an excuse for "I always planned to abandon this").
Just in case you're one of the people in (1), here you go:
https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p...
Earlier quoted context omitted.
Those are internal tools at best so it won't matter that much for migration.
That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.