411–420 of 463 posts
Earlier quoted context omitted.
Still slower than OCaml, Haskell, Java or .NET.
Mmm, "faster than node.js" isn't a great benchmark out in the wide world. Although node.js being as fast as it is remains an astonishing thing.
Earlier quoted context omitted.
We try to use Python 3 at work but have to run Python 2 as well because there are still packages that weren't upgraded and it's too much working re-writing them all for no direct benefit. We also have third party vendors that only support Python 3 in experimental versions, and there not even recent versions (Bloomberg is a great example). I really like Python3 features, but the pain of using them drives me towards us…
Do you do data science?
Earlier quoted context omitted.
> As if individual developers are the reason behind the bulk of the downloads. I wonder how many downloads Travis alone counts for? Travis runs/tests user projects, so there's nothing about it that's especially partial to Python 2 over Python 3. > Your hate of Python 3 in every discussion about it is frankly baffling. Or, you know, my pragmatic assessment of its popularity. That you'd even use the word "hate" (when i…
> even if its mostly tame updates over what 2.7 offers > The situation is not unlike the perennial "next year is when Linux dominates the desktop", which has been every year since 1999. Your bias is showing, as it does in every comment section on this site regarding Python 3, as you make comment after comment about how inferior Python 3 is and how nobody is using it at all because your sample of 2 companies shows thi…
From what I've seen of his posts, he's only talking about the reality of the situation.. not "how it should be".
Go look at the stats on PyPi and other metrics. Python3 failed, there is a cutoff time for adoption. It's no different than the first 24 hours of a missing person report. You don't get eternity to see if something is going to pan out or not. We're past that point for Python3. It may survive as it's own (smaller) thing, but Python2 isn't going to die either and that's more assured than Python3's fate.
And coldtea is right, but we're not going to do your research for you. What I'm saying needed to be said to you, but you need to find better ways to contribute than just rebutting everyone who has something to say about Python3. Talking about how he hates "something else" and using Python3 as a vent is just ridiculous.
Earlier quoted context omitted.
Those can be built into Grumpy if anyone cares to do so. You don't need Python3 for that stuff. Someone, one developer, recently released a Python 2.8 that backported almost every new Python3 feature. I'm hoping it becomes a permanent fork of Python2 that uses the Go runtime. That would really be great and exactly what they've got now.
If you backport every new Python3 feature to Python2, it becomes Python3, by definition.
Earlier quoted context omitted.
Mmm, "faster than node.js" isn't a great benchmark out in the wide world. Although node.js being as fast as it is remains an astonishing thing.
Who cares about the speed of the interpreter? The interpreter's job is to orchestrate high-performance components written in some high-performance language. If your interpreter is dominating execution time, you should move some of your logic to native code.
Earlier quoted context omitted.
It seems like the 2.7 community is happy enough without the new features -- just need the bugfixes and continued backwards compatibility to keep that segment happy. From a new features perspective, the other reply's Placeholder is fascinating. (I haven't looked into it thoroughly yet.)
It is certainly interesting if it truly materializes. But it looks like the plan is to mostly backport stuff from py3- so py3 is still the future, with Placeholder getting some of those features eventually. And that is great from a legacy codebase perspective.
Earlier quoted context omitted.
Who cares about the speed of the interpreter? The interpreter's job is to orchestrate high-performance components written in some high-performance language. If your interpreter is dominating execution time, you should move some of your logic to native code.
Better not use an interpreter in first place, rather a language with REPL that allows compilation straight to native code.
Earlier quoted context omitted.
Better not use an interpreter in first place, rather a language with REPL that allows compilation straight to native code.
Why? Native code is costly: machine code generally has a much bigger footprint than interpreter bytecode. In some cases, interpreted code can be faster due to cache effects and reduced IO load making it faster to be smaller.
The fact that Google has started this project to migrate away from Python to an AOT compiled language, shows where the performance wins are.
I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…
> His stubborn view on functional mechanisms Reference, for a non-Python dev who hasn't kept up with it?
Also, map and reduce were removed from the standard global namespace and into the functools module.