Live data from Hacker News

Python 3.11

docs.python.org

61–70 of 156 posts

Re: Python 3.11

#61
post #55

Earlier quoted context omitted.

While I also quirked an eyebrow at the exact version, is 3 better at package management & environments?

It's still a mess, honestly. They tried to standardize on venv but since it doesn't deal well with Python libraries that depend on non-Python components, conda is still better for many purposes.

Can you give a specific example?

I've had nothing but pain with conda in mixed linux/mac/win environment at work, and actively worked to get it deprecated. We're on plain venvs now, with the occasional setup.py

Curious if I missed some useful case for it.

- very slow dependency resolvers

- using conda in docker is annoying

- the worst thing: inconsistencies in downloading binaries and other resources between win/mac/linux when installing packages

- conda insisting on messing with bashrc to run their 'activate' crap

- beware the fool who runs 'sudo conda whatever' on a multiuser system

Re: Python 3.11

#62
post #29

Earlier quoted context omitted.

1. Python has a low barrier to entry and is a popular first language, so most users don't realise how bad it is. 2. Python was originally popular with old-school sysadmins, Debian types, and a lot of its package management is based around that philosophy of carefully hand-tended servers shared by multiple users.

> a lot of its package management is based around that philosophy of carefully hand-tended servers shared by multiple users. Is it? I'd love for apt to support virtual environments or `apt install --user` like pip does, let alone populating venvs with requirements.txt.

The pile of debootstrap chroot stuff that you get told to use works pretty similarly to virtualenv. It's pretty clunky and bolted-on, but so is the Python version.

Re: Python 3.11

#63

Earlier quoted context omitted.

Care to elaborate on what is bad? How bad are they compared to other languages? (Assuming you are always accepting some tradeoffs when moving from one eco system to another)

It's painfully archaic compared to languages that have all this sorted out. Pip is a recipe for disaster, indicated by the huge amount of churn in the Python packaging sphere. It's constantly the worst part of my day whenever I pick a Python project up. Conflicting dependencies, non-deterministic installs, etc. I used to cope with this crap fest until I tried Elixir and experienced the beauty of modern package manage…

Package management is pretty fubar for in every language I've tried but python is one of the worst

Re: Python 3.11

#64
post #29

Earlier quoted context omitted.

1. Python has a low barrier to entry and is a popular first language, so most users don't realise how bad it is. 2. Python was originally popular with old-school sysadmins, Debian types, and a lot of its package management is based around that philosophy of carefully hand-tended servers shared by multiple users.

> a lot of its package management is based around that philosophy of carefully hand-tended servers shared by multiple users. Is it? I'd love for apt to support virtual environments or `apt install --user` like pip does, let alone populating venvs with requirements.txt.

(s)`chroot` and `debootstrap` existed long before docker did for this purpose.

Re: Python 3.11

#65
post #21
post #6

just spent about 4 hrs getting Python 2 and pip setup on my Mac. Any time I have the misfortune of needing to use python I get cold sweats at the thought of the environment stuff. Why is this still such a massive problem?

i sympathize. the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS. not only that, they aren't removing the default 2.7 that they ship. macOS Big Sur ships Python 2.7. ha. ha. ha. none of the proposed "virtual environments" solutions are going to rescue you when you operate globally at the OS-level and not in a sandbox. been there.

1. macOS ships a /usr/bin/python3 that is up-to-date at the time of the feature freeze of a major macOS release, e.g. macOS 11 ships Python 3.8.2 from February 2020.

2. /usr/bin/python being a symlink for python2.7 is entirely consistent with PEP 394 recommendations, especially the version before June 2019: https://raw.githubusercontent.com/python/peps/214736457f6d61...

  * Unix-like software distributions (including systems like Mac OS X and
    Cygwin) should install the ``python2`` command into the default path
    whenever a version of the Python 2 interpreter is installed, and the same
    for ``python3`` and the Python 3 interpreter.
  * When  invoked, ``python2`` should run some version of the Python 2
    interpreter, and ``python3`` should run some version of the Python 3
    interpreter.
  * If the ``python`` command is installed, it should invoke the same version of
    Python as the ``python2`` command (however, note that some distributions
    have already chosen to have ``python`` implement the ``python3``
    command; see the `Rationale`_ and `Migration Notes`_ below).
The 2019 update https://github.com/python/peps/commit/ae932bd6fd2c493d7d64ce... allowed more flexibility, but the old handling is still entirely okay.

Re: Python 3.11

#66
post #60

Earlier quoted context omitted.

Care to elaborate on what is bad? How bad are they compared to other languages? (Assuming you are always accepting some tradeoffs when moving from one eco system to another)

Off the top of my head: - What you get when you import a library depends on state that's scattered all over the system: system-managed packages, pip-managed system-global packages, pip-managed per-user packages, which virtualenv is currently active, which directory you're currently in, which directory the program you're running is in, whatever it is that conda does.... - There's no concept of reproducible builds or d…

> - There's only one global repository. If you want to build some libraries and reuse them the same way you'd use a normal library dependency, you have to publish them to the global PyPi. I think there might be an expensive service that works around this, but there's no repository program that you can just spin up on your own servers.

You can setup proxy such as Nexus, which allows hosting your own librarires: https://help.sonatype.com/repomanager3/formats/pypi-reposito...

Re: Python 3.11

#67
post #2

According to PEP-619[1], Python 3.10 release expected tomorrow, so no wonder work started on 3.11... [1]: https://www.python.org/dev/peps/pep-0619/

Development on a new branch begins at the time of beta 1 of the previous branch, which is the feature freeze point. ("Development on a new branch" is metaphorical, there's no new git branch created at that point, just the master branch.)

Re: Python 3.11

#68
post #6

just spent about 4 hrs getting Python 2 and pip setup on my Mac. Any time I have the misfortune of needing to use python I get cold sweats at the thought of the environment stuff. Why is this still such a massive problem?

Please enough of this. Trying spending 2 minutes googling it. Hint: pyenv

virtualenv, pyenv, venv.. I'm sure they all work well, but for a newbie, the sheer choice is a killer, especially when they all work almost same, but not quite.

Now compare that with cargo or npm and the canonical way makes newbie upbringing SL much easier.

Re: Python 3.11

#70
post #42

Earlier quoted context omitted.

4 hours? Yeesh. Here's how to do it in 5-10 minutes. Use pyenv to install any python version and pyenv-virtualenv to manage virutal environments. https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv-virtualenv

For me, pyenv on Mac is about 15 minute compile time with a bunch of environment variables required to make sure tkinter works properly.

The compile time depends largely on dependencies. If you have OpenSSL, zlib, and whatnot pre-installed (either via Homebrew or self-compiled and specified with environment variables), the compile time is close to 5 minutes. If you don’t, by default pyenv (actually python-build) compiles all those from scratch, and can easily spend north of 20 minutes (mostly for OpenSSL).
Post reply on HN