That’s wild, do we typically see such gains in dot releases? I don’t remember the last time this happened. Great news.
There was a heap of features added between 3.5 and 3.11, for example. Enough to make it a completely different language.
251–260 of 460 posts
That’s wild, do we typically see such gains in dot releases? I don’t remember the last time this happened. Great news.
There was a heap of features added between 3.5 and 3.11, for example. Enough to make it a completely different language.
Earlier quoted context omitted.
One of the biggest contributors in Python's (lack of) speed is dynamic typing. While a jump is a jump and an assignment is an assignment, an addition is more like "hmm... what is a left operand... is it double? what is a right operand? wow, it's also a double! okay, cpu add eax, ebx".
Also "what is equals?". That's why people will do: def fooer(i: str, strings: list[str]): push = str.append for s in strings: push(i, s) Apparently this helps the interpreter understand that `append` is not getting overwritten in the global scope elsewhere.
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?
Earlier quoted context omitted.
I suspect that the amount of people and especially companies willing to spend time and money optimizing Python are fairly low. Think about it: if you have some Python application that's having performance issues you can either dig into a foreign codebase to see if you can find something to optimize (with no guarantee of result) and if you do get something done you'll have to get the patch upstream. And all that "only…
> you can either dig into a foreign codebase ... > Or you could rewrite your application Programmers love to save an hour in the library by spending a week in the lab
Earlier quoted context omitted.
Python being interpreted is the main reason why it’s slow, but not the excuse to not compare it to similar and faster programming languages.
One of the biggest contributors in Python's (lack of) speed is dynamic typing. While a jump is a jump and an assignment is an assignment, an addition is more like "hmm... what is a left operand... is it double? what is a right operand? wow, it's also a double! okay, cpu add eax, ebx".
There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part.…
I use a beautiful hack in the Cosmopolitan Libc codebase (x86 only) where we rewrite NOPs into function calls at runtime for all locking operations as soon as clone() is called. https://github.com/jart/cosmopolitan/blob/5df3e4e7a898d223ce... The big ugly macro that makes it work is here https://github.com/jart/cosmopolitan/blob/master/libc/intrin... An example of how it's used is here. https://github.com/jart/cosmopo…
Personally, cosmo is one of those projects that inspires me to crack out C again, even though I was never understood the CPU's inner workings very well, and your work in general speaks to the pure joy that programming can be as an act of creation.
Thanks for all your contributions to the community, and thanks for being you!
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.
This is the first time I ever heard someone complain about Python's error messages in the 10+ years I've been using it. Even people who just learned it, pick up reading tracebacks after about a day of practice. The only problem I ever see is if a library swallows too much, and gives a generic error, but that's not something the language can fix. I really hope they don't change things too much.
Traceback (most recent call last):
File "calculation.py", line 54, in
result = (x / y / z) * (a / b / c)
~~~~~~^~~
ZeroDivisionError: division by zero
In this new version it's now obvious which variable is causing the 'division by zero' error.https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...
Earlier quoted context omitted.
I worked on Python almost exclusively for maybe five years. Then I tried go. Each time I wrote a go program, I am giddy with excitement at how fast my first attempt is, scaling so smoothly with the number of cores. I also wrote a lot of fairly performant C in the 90s, so I know what computers can do in a second. I still use Python for cases when dev time is more important than execution time (which is rarer now that…
You should try Nim, it's Python like but compiled so it's as far as C. These days if I want to script something (and don't need Python specific libraries like pandas) I use Nim.
Earlier quoted context omitted.
I love asyncio! It's a very well put together library. It provides great interfaces to manage event loops, io, and some basic networking. It gives you a lot of freedom to design asynchronous systems as you see fit. However, batteries are not included. For example, it provides no HTTP client/server. It doesn't interop with any synchronous IO tools in the standard library either, making asyncio a very insular environme…
It depends how you see it https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...