161–170 of 460 posts
One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.
When is that coming? Yes the error messages are confusing in a big list comprehension.
Earlier quoted context omitted.
> 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.) And that's even assuming that the code would have existed at all in another language. The thing about interpreted GC languages is that the iterative loop of creation is much more agile, easier to start with and easier to prototype in than a compiled, strictly typed language.
I think this is the best explanation for its popularity. Sure, it runs slow, but it's very fast to write. The latter is usually more important in the world of business, for better or worse.
Earlier quoted context omitted.
This is probably the wrong comparison to make: Python is two orders of magnitude slower than compiled GC languages, but it's in the same order of magnitude as most other interpreted GC languages. (It actually changes a whole lot, because there's a whole lot of code already out there written in Python. 25% faster is still 25% faster, even if the code would have been 100x faster to begin with in another language.)
Python is compiled to a VM (that is CPython). The semantics and implementation of the VM haven't prioritized performance as much as some other systems. Here we're seeing improvements in the implementation. But the semantics will be the hard part, as those semantics limit the performance. For instance "a + b" is (I believe) compiled into bytecodes that pretty much follow the expression. But the implementation of "add"…
Earlier quoted context omitted.
There are a lot of dynamically typed languages that are significantly faster than python. Late binding issues can be effectively worked around.
Do you have an example of a dynamically typed language where, say, addition of two lists of doubles would be significantly faster than in Python?
I wish there was something like llvm for scripting languages. Imagine if python, php, javascript, dart or ruby would not interpret the code themself, but compile to an interpretable common language, where you could just plug in the fastest interpreter there is for the job.
This is called the JVM and everyone has spent the last twenty years getting really upset about it.
Could you expand on this?
Earlier quoted context omitted.
Yup. Sad but true. I just wanted c++ style multithreading with unsafe shared memory but it's too late. I was impressed by the recent fork that addresses this in a very sophisticated way, but realistically gil cpython will keep finding speed ups to stave off the transition.
wondering how that interacts with c/c++ extensions that presumes the existance of the GIL
Earlier quoted context omitted.
> JavaScript has proven that any language can be made fast given enough money and brains, Yeah but commercial Smalltalk proved that a long time before JS did. (Heck, back when it was maintained, the fastest Ruby implementation was built on top of a commercial Smalltalk system, which makes sense given they have a reasonably similar model.) The hard part is that “enough money“ is...not a given, especially for noncommer…
Yes, I’m aware of the Smalltalk miracle. Google wasn’t alone in optimizing JS, it actually came late, Safari and Firefox were already competing and improving their runtime speeds, though V8 did doubled down on the bet of a fast JS machine. The question is why there isn’t enough money, given that there obviously is a lot of interest from big players.
I'd argue that there wasn't actually much interest until recently, and that's because it is only recently that interest in the CPython ecosystem has intersected with interest in speed that has money behind it, because of the sudden broad relevance to commercial business of the Python scientific stack for data science.
Both Unladen Swallow and IronPython were driven by interest in Python as a scripting language in contexts detached from, or at least not necessarily attached to, the existing CPython ecosystem.
Earlier quoted context omitted.
> You should probably read the full context around that quote, I'm sick and tired of everyone repeating it mindlessly: I'm confused. What do you think the context changes? At least as I read it, both the short form and full context convey the same idea.
That quote has been thrown around every time in order to justify writing inefficient code and never optimizing it. Python is 10-1000x slower than C, but sure, let's keep using it because premature optimization is the root of all evil, as Knuth said. People really love to ignore the "premature" word in that quote. Instead, what he meant is that you should profile what part of the code is slow and focus on it first. Kn…
As was said, profile, find user-impacting bottlenecks, and then optimize.
Earlier quoted context omitted.
> You should probably read the full context around that quote, I'm sick and tired of everyone repeating it mindlessly: I'm confused. What do you think the context changes? At least as I read it, both the short form and full context convey the same idea.
That quote has been thrown around every time in order to justify writing inefficient code and never optimizing it. Python is 10-1000x slower than C, but sure, let's keep using it because premature optimization is the root of all evil, as Knuth said. People really love to ignore the "premature" word in that quote. Instead, what he meant is that you should profile what part of the code is slow and focus on it first. Kn…
Earlier quoted context omitted.
"Premature optimization is the root of all evil." -- Donald Knuth
python isn't premature. python is more than 30 years old now, python 3 was released more than 10 years go.