131–140 of 341 posts
If this is an issue for you, I would highly recommend that you have a look at virtual environments via tools like virtualenv and conda. That way you'll be able to run all the versions you like.
Earlier quoted context omitted.
What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding. I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python…
The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.
People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded
Earlier quoted context omitted.
Doesn't OSX come with python2 by default?
It does, what can break is what `python` points to.
In other words, `brew install python` now complies with PEP 394[4].
$ brew install python
…
==> Caveats
Python has been installed as
/usr/local/bin/python3
Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
`python3`, `python3-config`, `pip3` etc., respectively, have been installed into
/usr/local/opt/python/libexec/bin
…
$ ls -l /usr/local/bin/python{,2,3}
lrwxr-xr-x 1 osteele staff 38 Mar 22 11:23 /usr/local/bin/python -> ../Cellar/python@2/2.7.14_3/bin/python
lrwxr-xr-x 1 osteele staff 39 Mar 22 11:23 /usr/local/bin/python2 -> ../Cellar/python@2/2.7.14_3/bin/python2
lrwxr-xr-x 1 osteele staff 34 Mar 31 12:27 /usr/local/bin/python3 -> ../Cellar/python/3.6.5/bin/python3
[2] https://github.com/Homebrew/homebrew-core/issues/24812
This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.
> Although it still took way too long, if you consider Python 3.0 was released about 10 years ago Somehow, it was the plan[0]. I feel like I wrote about that extensively already way too many times[1]. [0]: (2016) https://news.ycombinator.com/item?id=11502844 [1]: (2012) https://news.ycombinator.com/item?id=4569440
Earlier quoted context omitted.
Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions? I'm being facetious about that; but you know that security risks can be reasoned and mitigated with different means (sometimes less costly) than simply upgrading software.
s/security/bug I don't think that centos 6 is bug free yet it EOL in 2010 too. Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox. My client won't upgrade. They pay support, expensive support, to keep their old version. In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't…
Earlier quoted context omitted.
What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding. I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python…
The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.
If you really think something like that is happening (big if - I’ve gone through so many py3 flames...), the only answer is: because people love the language SO DAMN MUCH that they will overlook its warts. And the next logical step would be to find out how an independent research project, staffed mostly by volunteers and without a marketing budget of any sort (and not running in every browser nor shipping preinstalled on the most popular operating system), ended up with this sort of mindshare.
There might be some good lessons there.
Earlier quoted context omitted.
I saw it used a lot and it caused hours of rewrites to get libraries python3 ready. It's one of those things where I wonder why they didn't just depreciate it for another few iterations, allowing scripts to be changed over time.
The 2to3 tool will rewrite it automatically. It's not something that requires manual intervention.
Any code with a lot of assumptions about text encoding or integer division is going to be terribly broken after 2to3. It very much does require manual intervention unless you're doing very simple scripts.
Earlier quoted context omitted.
Uhhhh... sort of? I mean, I could go through all of the needless "why the hell did they make this partner incompatible also" stuff like, like removing u'' support (thai was added later), or all of the ludicrous breakage in the underlying APIs (like filesystem calls that made assumptions about character encoding that make no sense for the underlying Unix model and literally caused files to just disappear from iteratio…
Half of the problem you mention are either: - if you tried to support Python - if you tried to support Python But nobody used 3.0, 1 or 2. And supporting 2.6 is like supporting ruby 1.7 and 1.8 and 1.9. Which nobody did. And it's easy to rewrite libs when really the language started to be used in 2004. Or maybe not, given that "gem install" still regularly crashes on anything other than the top 20 packages, so it's s…
Earlier quoted context omitted.
s/security/bug I don't think that centos 6 is bug free yet it EOL in 2010 too. Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox. My client won't upgrade. They pay support, expensive support, to keep their old version. In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't…
Sometimes I wonder if the opensource movement, with its perennial “update anxiety”, is actually busy generating an industry of legacy maintenance. In a way, it’s a natural extension of the original “development is free but you pay for support” idea, but I don’t think anyone openly elaborated it into a long-term revenue-generating strategy. It looks like a slam-dunk, to be honest, with the only caveat being that work…
Android breaks the API regularly by changing the permission game.
The PSF has limited resources (3 million of dollar of budget) to exists (this includes running pypi and organising pyconf), but I think it's track record is quite good, even comparing to commercial products.