iscinumpy.dev
Should You Use Upper Bound Version Constraints? -
Bound version constraints (upper caps) are starting to show up in the Python
ecosystem. This is causing real world problems with
libraries following this recommendation, and is likely to continue to get
worse; this practice does not scale to large numbers
of libraries or large numbers of users. In this discussion I would like to
explain why always providing an upper limit causes far more harm than good
even for true SemVer libraries, why libraries that pin upper limits require
more frequent updates rather than less, and why it is not scalable. After
reading this, hopefully you will always consider every cap you add, you will
know the (few) places where pinning an upper limit is reasonable, and will
possibly even avoid using libraries that pin upper limits needlessly until the
author updates them to remove these pins.
If this 10,000 word behemoth is a bit long for you, then skip around using the
table of contents, or see the TL;DR section at the end, or read
version numbers by Bernát Gábor, which is shorter but is a
fantastic read with good examples and cute dog pictures. Or
Hynek’s Semantic Versioning Will Not Save You
Be sure to check at least
the JavaScript project analysis before you
leave!
Also be warned, I pick on Poetry quite a bit. The rising popularity of
Poetry is likely due to the simplicity of having one tool vs. many for
packaging, but it happens to also have a special dependency solver, a new upper
bound syntax, and a strong recommendation to always limit upper
versions - in direct opposition to members of the
Python core developer team and PyPA developers. Not
all libraries with excessive version capping are Poetry projects (like
TensorFlow), but many, many of them are. To be clear, Poetry doesn’t force
version pinning on you, but it does push you really, really hard to always
version cap, and it’s targeting new Python users that don’t know any better yet
than to accept bad recommendations. And these affect the whole ecosystem,
including users who do not use poetry, but want to depend on libraries that do!
I do really like other aspects of Poetry, and would like to
eventually help it build binary packages with Scikit-build
(CMake) via a plugin, and it has some great developers. If I don’t pick on
Poetry enough for you, don’t worry, I have a
follow-up post that picks on it in much more detail.
Also, check out pdm, which gives many of the benefits of Poetry while
following PEP standards. Also pixi, which works with the Conda ecosystem.
If you come across something that can’t be solved, try using
--exclude-newer <DATE> in uv and pdm. This limits the solve by
ignoring packages newer than some date.
![Diagram showing an example usage of Literal.
Instead of the signature:
def get_temperature(city: str, unit: str) -> int: ...
Use the following signature:
from typing import Literal
def get_temperature(
city: str,
unit: Literal["celsius"] | Literal["fahrenheit"],
) -> float:
...
print(get_temperature("Lisbon", "celsius")) # 18.0
print(get_temperature("Lisbon", "fahrenheit")) # 64.4](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:4642ovs4svxe3k3echdm4rks/bafkreif7pnqacw2i3azrwrevolzrhntvy6x7nv3wxanpowpsb5whzi656u)
