241–250 of 390 posts
I'm a researcher and have used exclusively Python 2.7 and NumPy for many years. Originally I ported my codebase from Matlab to NumPy because I wanted to go open source. But it's a very nice thing in science if your code runs perfectly for many years. You don't want to do rewrites. So I feel like I should have stayed with Matlab. Now that I'm soon forced to do another rewrite, I think I'll just switch to a different l…
Earlier quoted context omitted.
>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…
Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. 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…
Earlier quoted context omitted.
Huh? I'm starting projects in Python 2 because I know for once that the language won't move out from under me. I love it.
How do you plan on getting on when packages from PyPi stop supporting Python 2 at all? When Django, flask, numpy, requests, pandas, and more just don't even install ? Will you just use ancient versions?
Scheme that I wrote in the 1980s still runs (and is running today in commercial systems). I have so little patience at this point for this "higher version = better" nonsense.
I'm a researcher and have used exclusively Python 2.7 and NumPy for many years. Originally I ported my codebase from Matlab to NumPy because I wanted to go open source. But it's a very nice thing in science if your code runs perfectly for many years. You don't want to do rewrites. So I feel like I should have stayed with Matlab. Now that I'm soon forced to do another rewrite, I think I'll just switch to a different l…
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.
>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…
Perl is a weird language language for you to cite when we're talking about languages that do major transitions well. Perl 6 was created because Perl 5 was an evolutionary dead end, took 15 years, has no adoption, and Perl 5 usage shrunk tremendously in the meantime. Not saying this glibly as I love Perl and I hope Perl 6 sees some adoption, but come on now. Also remember that Perl 5 itself was nearly a complete rewri…
Earlier quoted context omitted.
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…
Frankly, I still haven't seen a single reason to switch to Python3 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 be…
That’s about the same time python 2 support drops in general. Sounds strange to support packages after the underlying python has moved on. Kudos to the numpy team for writing the most awesome python module under the sun, and for providing great support!
Huh? I'm starting projects in Python 2 because I know for once that the language won't move out from under me. I love it.
Earlier quoted context omitted.
That's a really poor reason to kill an old version. To be clear, I FEEL YOUR PAIN. However, new isn't legit just because it's new. As a non-Python pro, I cannot say why one version over another. However, arguing that the old one is bad just because it is inconvenient isn't valid. As someone who struggles with versions of Python on my Mac and on production servers (and with code that runs on 2.7 and 3.6+), as far as I…
*I can feel the pain of devs that have to deal with Python 2 and 3. To me the beginning of the ugly Python 3.0 announcement was too off putting, it stopped my interest in Python and I went back to PHP, Java and later also NodeJS, Go. In comparison PHP and Java always successfully transitioned to new versions, keeping it backward-compatible and do baby steps instead of a big incompatible cut. PHP canceled the ill fate…
What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of bo…
Nonsense. Use six, use tox for testing in both, easy peasy. They're not that different. Plenty of libraries do it. No reason scripts can't too. Plenty do. Specify a "/usr/bin/env python3" shebang if you want to use any cool features like f-strings
tox apparently depends on virtualenv; this is reasonable if your software is primarily Python, but absurd if your package merely uses Python for one-off scripts. macOS doesn't even install pip by default.
I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities.