[flagged]
If you're making claims about defamation and libel, at least be specific.
Python 3.13.0 Is Released
71–80 of 135 posts
Re: Python 3.13.0 Is Released
#72Earlier quoted context omitted.
No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching. Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.
> It’s doing hash table lookups per variable access. That hasn't been true for many variable accesses for a very long time. LOAD_FAST, LOAD_CONST, and (sometimes) LOAD_DEREF provide references to variables via pointer offset + chasing, often with caches in front to reduce struct instantiations as well. No hashing is performed. Those access mechanisms account for the vast majority (in my experience; feel free to check…
Thanks for the correction and technical detail. I’m not saying this is bad, it’s just the nature of this kind of dynamic language. Productivity over performance.
Re: Python 3.13.0 Is Released
#73Python versions 3.11, 3.12 and now 3.13 have contained far fewer additions to the language than earlier 3.x versions. Instead the newest releases have been focusing on implementation improvements - and in 3.13, the new REPL, experimental JIT & GIL-free options all sound great! The language itself is (more than) complex enough already - I hope this focus on implementation quality continues.
For those interested in the REPL improvements: " Python now uses a new interactive shell by default, based on code from the PyPy project. When the user starts the REPL from an interactive terminal, the following new features are now supported: Multiline editing with history preservation. Direct support for REPL-specific commands like help, exit, and quit, without the need to call them as functions. Prompts and traceb…
I hope it doesn’t break ptpython, and/or is worse than it. I’ve been using it for quite a while.
Re: Python 3.13.0 Is Released
#74Earlier quoted context omitted.
The magic command in other settings would be pyenv. It lets you have as many different Python versions installed as you wish. Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it.
> Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it. Why not?
It's unlikely that the OS's version of Python, and the Python packages available through the OS, are going to be the ones you'd install of your own volition. And on your workstation, it's likely you'll have multiple projects with different requirements.
You almost always want to develop in a virtualenv so you can install the exact versions of things you need without conflicting with the ones the OS itself requires. If you're abstracting out the site-packages directory anyway, why not take one more step and abstract out Python, too? Things like pyenv and uv make that trivially easy.
For instance, this creates a new project using Python 3.13.
$ uv init -p python3.13 foo
$ cd foo
$ uv sync
$ .venv/bin/python --version
Python 3.13.0rc2
You can get 95% of the same functionality by installing pyenv and using it to install the various versions you might want. It's also an excellent tool. Python's own built-in venv module (https://docs.python.org/3/library/venv.html) makes it easy to create virtualenvs anytime you want to use them. I like using uv to combine that and more into one single tool, but that's just my preference. There are many tools that support this workflow and I highly recommend you find one you like and use it. (But not pipenv. Don't pick that one.)
Re: Python 3.13.0 Is Released
#75Earlier quoted context omitted.
It definitely does, but don't you think that it could be worth it if it makes multithreading usable for CPU-heavy tasks?
No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching. Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.
> No. Python is orders of magnitude slower than even C# or Java.
That sounds like a fantastic reason to make it run faster on the multi-core CPUs we're commonly running it on today.
Re: Python 3.13.0 Is Released
#76Good to get advanced notice, if I read all the way down, that they will silently completely change the behavior of multiprocessing in 3.14 (only on Unix/Linux, in case other people wonder what’s going on), which is going to break a bunch of programs I work with. I really like using Python, but I can’t keep using it when they just keep breaking things like this. Most people don’t read all the release notes.
Unfortunately, they learned the wrong lesson from the 2->3 transition. Break things constantly instead of all at once. :p
Still, this one doesn’t seem too bad. Add method=FORK now and forget about it.
Re: Python 3.13.0 Is Released
#77Python versions 3.11, 3.12 and now 3.13 have contained far fewer additions to the language than earlier 3.x versions. Instead the newest releases have been focusing on implementation improvements - and in 3.13, the new REPL, experimental JIT & GIL-free options all sound great! The language itself is (more than) complex enough already - I hope this focus on implementation quality continues.
I've love to see a revamp of the import system. It is a continuous source of pain points when I write Python. Circular imports all over unless I structure my program explicitly with this in mind. Using python path hacks with `sys` etc to go up a directory too.
There was an attempt to make imports lazy: https://peps.python.org/pep-0690/
It was ultimately rejected due to issues with how it would need to change the dict object.
IMO all the rejection reasons could be overcome with a more focused approach and implementation, but I don't know if there is anyone wishing to give it another go.
Re: Python 3.13.0 Is Released
#78Earlier quoted context omitted.
> Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it. Why not?
It's unlikely that the OS's version of Python, and the Python packages available through the OS, are going to be the ones you'd install of your own volition. And on your workstation, it's likely you'll have multiple projects with different requirements. You almost always want to develop in a virtualenv so you can install the exact versions of things you need without conflicting with the ones the OS itself requires. I…
This is the conventional wisdom these days, and a real thing, but unless you are admin challenged, running your local scripts with the system Python is fine. Been doing it two decades plus now.
Yes, make a venv for each work project.
Re: Python 3.13.0 Is Released
#79Earlier quoted context omitted.
Hmm.. I think this is a misunderstanding. What I meant is: While I am already inside a container running Debian, can I ... 1: ./myscript.py 2: some_magic_command 3: ./myscript.py So 1 runs it under 3.11 (which came with Debian) and 2 runs it under 3.13. I don't need to preserve 3.11. some_magic_command can wrack havoc in the container as much as it wants. As soon as I exit it, it will be gone anyhow. The in a sense,…
Ignore the talk below about pyenv, it’s not even slightly suitable for this task. You want precompiled Python binaries. Use “uv” for this, rather than hacking it together with pyenv.
Use either one. `pyenv install 3.x` is slower than `uv python install 3x`, but that's not the most common operation I use either of those tools for. Uv is also comparatively brand new, and while I like and use it, I'm sure plenty of shops aren't racing to switch to it.
If you already have pyenv, use it. If you don't have pyenv or uv, install uv and use that. Either one is a huge upgrade over using the default Python from your OS.
Re: Python 3.13.0 Is Released
#80Earlier quoted context omitted.
No. Python is orders of magnitude slower than even C# or Java. It’s doing hash table lookups per variable access. I would write a separate program to do the number crunching. Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.
> No. Python is orders of magnitude slower than even C# or Java. That sounds like a fantastic reason to make it run faster on the multi-core CPUs we're commonly running it on today.
The cost to write and debug multithreaded code is high and not limited to the area you use it. And for all that you get a 2-8x speed up.
So if you care about performance why are you writing that part in python?
> multi-core CPUs we're commonly running it on today.
If you spawn processes to do work you get multi core for free. Think of the whole system, not just your program.