Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.13.0 Is Released

docs.python.org

Post reply on HN
Print view View original

101–110 of 135 posts

Re: Python 3.13.0 Is Released

#101

Post by orf »

kstrauser wrote: post #79
orf wrote: post #62

Earlier quoted context omitted.

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…

This makes sense for a desktop environment, but for a disposable testing container there is no way that building and compiling each version of Python like that is a sensible use of time/resources.

Re: Python 3.13.0 Is Released

#102

Post by kstrauser »

orf wrote: post #101
kstrauser wrote: post #79

Earlier quoted context omitted.

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…

This makes sense for a desktop environment, but for a disposable testing container there is no way that building and compiling each version of Python like that is a sensible use of time/resources.

For that kind of thing I'd always either used the tagged Python images in Docker Hub or put the build step in an early layer that didn't have to re-run each time.

One other advantage is that you know the provenance of the python executable when you build it yourself. Uv downloads a prebuilt exe from https://gregoryszorc.com/docs/python-build-standalone/main/ who is a very reputable, trusted source, but it's not the official version from python.org. If you have very strict security requirements, that may be something to consider. If you use an OS other than Linux/Mac/Windows on x86/ARM, you'll have to build your own version. If you want to use readline instead of libedit, you'll have to build your own version.

I am personally fine with those limitations. All of the OSes I regularly use are covered. I'm satisfied with the indygreg source security. The libedit version works fine for me. I like that I can have a new Python version a couple seconds after asking for uv. There are still plenty of reasons why you might want to use pyenv to build it yourself.

Re: Python 3.13.0 Is Released

#103

Post by faizshah »

mixmastamyk wrote: post #73
underdeserver wrote: post #42

Earlier quoted context omitted.

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.

I don’t think they added autocomplete support so PtPython is still better.

Re: Python 3.13.0 Is Released

#104

Post by silviogutierrez »

wdroz wrote: post #28

With the 3.13 TypeIs[0] and the 3.10 TypeGuard[1], we can achieve some of Rust's power (such as the 'if let' pattern) without runtime guarantees. This is a win for the DX, but this is not yet widely used. For example, "TypeGuard[" appears in only 8k Python files on GitHub.[2] [0] -- https://docs.python.org/3.13/library/typing.html#typing.Type... [1] -- https://docs.python.org/3.13/library/typing.html#typing.Type... […

Big fan of typing improvements in Python. Any chance you can elaborate on the "if let" pattern in Rust and how it would look in Python now? Not sure I follow how it translates.

Re: Python 3.13.0 Is Released

#105

Post by odie5533 »

kstrauser wrote: post #37
instig007 wrote: post #7

Earlier quoted context omitted.

Have a rubust CI and tests, and deploy as early as you can.

Yup. At my last gig, upgrading to a new version meant setting the Docker tag to the new one and running `make test`. If that passed, we were 99% certain it was safe for prod. The other 1% was covered by running in pre-prod for a couple days.

This is the way.

Re: Python 3.13.0 Is Released

#106

Post by odie5533 »

mixmastamyk wrote: post #78
kstrauser wrote: post #74

Earlier quoted context omitted.

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.

If you're just writing tiny scripts for yourself, sure use the system Python.

If you're doing work on a large Python app for production software, then using system Python isn't going to cut it.

Re: Python 3.13.0 Is Released

#108

Post by Doxin »

kstrauser wrote: post #24
formerly_proven wrote: post #11

Earlier quoted context omitted.

The last couple years also saw a stringent approach to deprecations: If something is marked as deprecated, it WILL be removed in a minor release sooner than later.

Yep. They’ve primarily (entirely?) involved removing ancient libraries from stdlib, usually with links to maintained 3rd party libraries. People who can’t/won’t upgrade to newer Pythons, perhaps because their old system that uses those old modules can’t run a newer one, aren’t affected. People using newer Pythons can replace those modules. There may be a person in the world panicking that they need to be on Python 3.…

I mean the stdlib is open source too, so you could always vendor deprecated stdlib modules. Most of them haven't changed in eons either so the lack of official support probably doesn't change much.

Re: Python 3.13.0 Is Released

#109

Post by riezebos »

int_19h wrote: post #66
the__alchemist wrote: post #36

Earlier quoted context omitted.

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.

The biggest problem with Python imports is that the resolution of non-relative module names always prioritizes local files, even when the import happens in stdlib. This means that, for any `foo` that is a module name in stdlib, having foo.py in your code can break arbitrary modules in stdlib. For example, this breaks: # bisect.py ... # main.py import random with: Traceback (most recent call last): File ".../foo.py",…

I agree, it's unreasonable to expect devs to know the whole standard library. The VSCode extension Pylance does give a warning when this happens. I thought linters might also check this. The one I use doesn't, maybe the issue[0] I just created will lead to it being implemented.

[0]: https://github.com/astral-sh/ruff/issues/13676

Re: Python 3.13.0 Is Released

#110

Post by dagw »

causal wrote: post #5

Any rule of thumb when it comes to adopting Python releases? Is it usually best to wait for the first patch version before using in production?

Rule 1 is wait until there are built wheels for that version of python for all the libraries that you need. In most cases that can take a month or two, depending on exactly what libraries you use and how obscure they are.
Post reply on HN