python

But is there even an official docker image for deploying applications using 3.13t and 3.14t? Looking at https://hub.docker.com/_/python/ and https://github.com/docker-library/python/issues/947 , it seems to have been ignored. Without one, it's all useless. Almost no one wants to compile Python from source.

> You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee. Well, if all you need is the server to run Docker/Podman, SSH and some other limited amount of packages, it shouldn't be too bad. Of course, there are also horror stories of Alpine resulting in way worse performance in select use cases: https://github.com/docker-library/python/issues/509 and there's the fact that Alpine might be popular inside of containers, but way less so outside. Also, because of the short EOL cycle, I personally ditched Debian on servers (and Alpine in containers) myself for Ubuntu everywhere: https://blog.

For what it's worth, Python 3.10 will add -fno-semantic-interposition when built with --with-optimizations by default. However, the slow down only affects Pythons built with --enabled-shared anyway. The issue is discussed here [0]. I also attempted to backport the fix to the official Python Docker image [1], but wasn't able to get much traction. I wish this would land since everyone using these images would get an instant speedup. [0]: https://bugs.python.org/issue38980 [1]: https://github.com/docker-library/python/issues/501

Those images pull from python.org sources, see: https://github.com/docker-library/python/blob/master/3.8/bus...

I did an analysis with the official Docker Python image [0] with the --enable-optimizations flag. Although not the point of the results [1], they show a decent speed up when using Debian vs Alpine as well. [0] https://github.com/docker-library/python/issues/160 [1] https://gist.github.com/blopker/9fff37e67f14143d2757f9f2172c...

Seems like someone is indeed compiling: https://github.com/docker-library/python/blob/65b5603fdf177c...

I use zsh daily but type `xonsh` any time I do something in the shell that would normally require a google. “Uh ok so I have this JSON file. When I pipe this to `jq` I forget: to pivot an array of objects to an object keyed by array[x].id is it like `to_entries` then chain it to `map`? Uhh let’s look at the docs...” However in Python I can write that function at the speed of thought. It may be a couple more lines of code but I’m also 100% confident in the output. Like I understand some people can legitimately program in bash [0]. But I just can’t bring myself to practice. Why would anyone inflict this language on themselves? [0] https://github.com/docker-library/python/blob/master/update....

Also, I wonder how many obscure bugs were introduced by using more aggressive compiler flags? The image has "lto" in the name, and at https://github.com/docker-library/python/issues/160 I see this comment: > In the future the Python developers may decide to turn on further optimizations based on this argument, for example link-time optimizations (LTO), though they haven't worked out all the bugs for that one yet. (Thanks mastax for finding the issue!)

I think these optimizations are upstream, but they're not in the canonical 'python' docker image: https://github.com/docker-library/python/issues/160

From looking at what I think is the Dockerfile for that image (https://github.com/docker-library/python/blob/b1512ead24c6b1...), that image is complex; it's downloading & building Python in it and adding & removing a dev toolchain, in a few different layers. I'm not surprised that I got something a lot smaller from just running `apk add python3.6`, although as a result they are not comparing apples to apples; their minideb example does pretty much exactly the equivalent (i.e. downloading the distro-provided package, not compiling it within their image).