Search
72 results for “brettcannon”
-
In your specific example, assuming the project is using https://semver.org/, I would reevaluate - thinking I got it wrong since I know you are so much more experienced than me.
However, my main reason for making it show easier, including for the --version, is that there are a lot of x.y.z projects that isn't #SemVer.
https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers list quite a few.
What if pyproject.toml had something like:
[project]
name = "demo"
version-scheme = "SemVer 2.0.0"
version = "0.1.0" -
Generally I find SemVer as the best versioning scheme. One of the few exceptions is for OS's, where #CalVer makes more sense.
What would be a great improvement, especially for #SemVer, is if it would show better that a project is using it. Both in the repo and like here when doing "--version" in the CLI. Icing on the cake would be if release date also shows:
> python -V
Python 3.13.7 SemVer 2025-08-14 -
Generally I find SemVer as the best versioning scheme. One of the few exceptions is for OS's, where #CalVer makes more sense.
What would be a great improvement, especially for #SemVer, is if it would show better that a project is using it. Both in the repo and like here when doing "--version" in the CLI. Icing on the cake would be if release date also shows:
> python -V
Python 3.13.7 SemVer 2025-08-14 -
Generally I find SemVer as the best versioning scheme. One of the few exceptions is for OS's, where #CalVer makes more sense.
What would be a great improvement, especially for #SemVer, is if it would show better that a project is using it. Both in the repo and like here when doing "--version" in the CLI. Icing on the cake would be if release date also shows:
> python -V
Python 3.13.7 SemVer 2025-08-14 -
Generally I find SemVer as the best versioning scheme. One of the few exceptions is for OS's, where #CalVer makes more sense.
What would be a great improvement, especially for #SemVer, is if it would show better that a project is using it. Both in the repo and like here when doing "--version" in the CLI. Icing on the cake would be if release date also shows:
> python -V
Python 3.13.7 SemVer 2025-08-14 -
Generally I find SemVer as the best versioning scheme. One of the few exceptions is for OS's, where #CalVer makes more sense.
What would be a great improvement, especially for #SemVer, is if it would show better that a project is using it. Both in the repo and like here when doing "--version" in the CLI. Icing on the cake would be if release date also shows:
> python -V
Python 3.13.7 SemVer 2025-08-14 -
I have no tips, but I have seen prices for Europe calling and data, so low it redoubles the diuble anger at the north American billionaires ripping us off.
80% of American and Canadian phone and data pricing is theft to make tax avoiding billionaires.
End billionairism.
-
I have no tips, but I have seen prices for Europe calling and data, so low it redoubles the diuble anger at the north American billionaires ripping us off.
80% of American and Canadian phone and data pricing is theft to make tax avoiding billionaires.
End billionairism.
-
I have no tips, but I have seen prices for Europe calling and data, so low it redoubles the diuble anger at the north American billionaires ripping us off.
80% of American and Canadian phone and data pricing is theft to make tax avoiding billionaires.
End billionairism.
-
I have no tips, but I have seen prices for Europe calling and data, so low it redoubles the diuble anger at the north American billionaires ripping us off.
80% of American and Canadian phone and data pricing is theft to make tax avoiding billionaires.
End billionairism.
-
@brettcannon your name came up at the #ShitPostWG office hours today.
We were talking about the patchcheck.py script from cpython and I ended up in a CSV-shaped rabbit hole that led me to revision r61528: https://gist.github.com/bmispelon/d9afaf915d864d270fc872495a76e169
Fun times!
-
@brettcannon what's a "file viewer"? I use `less`. #NotHelping #LinuxOnTheDesktop
If I were using desktop GUI things more than a terminal and browser on Linux: Before settling on a distro's Gnome based default, also give KDE a try.
In my more moons ago than I can count past experience it was always more polished and helpful in that regard. (but my command line based user habits didn't need it)
-
@brettcannon Thinking if #NoGIL is sorted first, making JIT happen later is probably much easier than the other order.
-
@ThePSF @brettcannon @mariatta
I heard #GuidoVanRossum, shortly after starting his second term as the #Python #BDFL, has hinted at going for a THIRD term. He indicated "there are ways" of accomplishing it.It could be worse. He could threaten to take over #Greenland by force or impose `import tariffs`.
-
@ThePSF @brettcannon @mariatta
I heard #GuidoVanRossum, shortly after starting his second term as the #Python #BDFL, has hinted at going for a THIRD term. He indicated "there are ways" of accomplishing it.It could be worse. He could threaten to take over #Greenland by force or impose `import tariffs`.
-
@ThePSF @brettcannon @mariatta
I heard #GuidoVanRossum, shortly after starting his second term as the #Python #BDFL, has hinted at going for a THIRD term. He indicated "there are ways" of accomplishing it.It could be worse. He could threaten to take over #Greenland by force or impose `import tariffs`.
-
@ThePSF @brettcannon @mariatta
I heard #GuidoVanRossum, shortly after starting his second term as the #Python #BDFL, has hinted at going for a THIRD term. He indicated "there are ways" of accomplishing it.It could be worse. He could threaten to take over #Greenland by force or impose `import tariffs`.
-
@ThePSF @brettcannon @mariatta
I heard #GuidoVanRossum, shortly after starting his second term as the #Python #BDFL, has hinted at going for a THIRD term. He indicated "there are ways" of accomplishing it.It could be worse. He could threaten to take over #Greenland by force or impose `import tariffs`.
-
🔒📂 @brettcannon has just posted his new proposal to standardise lock files in Python:
"Two years since PEP 665 was rejected and three years since I started working towards some lock file solution, I present my next (and last regardless of outcome) attempt at coming up with a lock file standard."
https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593?u=hugovk
-
🔒📂 @brettcannon has just posted his new proposal to standardise lock files in Python:
"Two years since PEP 665 was rejected and three years since I started working towards some lock file solution, I present my next (and last regardless of outcome) attempt at coming up with a lock file standard."
https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593?u=hugovk
-
🔒📂 @brettcannon has just posted his new proposal to standardise lock files in Python:
"Two years since PEP 665 was rejected and three years since I started working towards some lock file solution, I present my next (and last regardless of outcome) attempt at coming up with a lock file standard."
https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593?u=hugovk
-
🔒📂 @brettcannon has just posted his new proposal to standardise lock files in Python:
"Two years since PEP 665 was rejected and three years since I started working towards some lock file solution, I present my next (and last regardless of outcome) attempt at coming up with a lock file standard."
https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593?u=hugovk
-
🔒📂 @brettcannon has just posted his new proposal to standardise lock files in Python:
"Two years since PEP 665 was rejected and three years since I started working towards some lock file solution, I present my next (and last regardless of outcome) attempt at coming up with a lock file standard."
https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593?u=hugovk
-
@fohrloop @brettcannon @venthur @fcodvpt Oh interesting. That could be, but I do seem to remember that flit will omit any Python files other than a single top-level directory or Python file whose name matches the package name. Or something like that. Maybe that causes it to exclude tests and docs.
Every build backend has its own rules about what files it includes in an sdist, and it wouldn't surprise me if flit is one of the most conservative in that sense. Of course, that probably does mean that if you ever want to get your package included in a Linux distro or some other context where tests and/or documentation are important, you need to use something other than flit.
-
@fohrloop @brettcannon @venthur @fcodvpt FWIW it's not actually guaranteed that sdists have tests and docs included. I mean, ultimately an sdist is just a .tar.gz archive that follows a few standards, but I don't think those standards govern what goes in the repo, except for the PKG-INFO file which needs to contain some metadata. (Technically I don't think an sdist even needs to contain the package's own source code! You could make a valid sdist with almost nothing in it - useless, but valid.)
However, the way most build tools are configured, they'll put everything in the sdist by default, so it's common to have tests+docs in there, and a certain subset of consumers have come to rely on that.
-
@fohrloop @brettcannon @venthur @fcodvpt One thing I've heard is that packagers for downstream repositories (e.g. Linux distribution package managers) prefer or even insist on sdists because they need the test code and/or documentation. There can be other tools that are trying to do things other than installing your package that can't work with a wheel, they need an sdist.
BTW you can use `python -m build` to build a project and get both the sdist and wheel "for free".
And yeah, dynamic versioning is great. I've had so many problems with hard-coding the version number in a file; IMO it's so much easier to just determine it from the tag. So this is the "killer feature" that makes me choose hatch (or setuptools back in the day before hatch supported it) over other backends.
-
-
Last month in Wasm - Python
#python #wasm #componentmodelBrett Cannon (@brettcannon) from Microsoft has added a build script for building Python for WASI.
https://github.com/python/cpython/blob/main/Tools/wasm/wasi.py
https://github.com/python/cpython/blob/main/Tools/wasm/README.md#wasi-wasm32-wasiJoel Dice from Fermyon and Peter Huene (@peterhuene) from Fastly have updated Componentize-Py from Wasmtime 13 up to 15 and are planning to be ready for Wasmtime 16 on release.
https://github.com/bytecodealliance/componentize-py/pull/43
https://github.com/bytecodealliance/componentize-py/pull/44 -
PEP 751 is accepted, congratulations to @brettcannon and everyone else involved 🙂 🎉
https://discuss.python.org/t/pep-751-one-last-time/77293/150
-
🐍🔐 Python lockfiles are back!
Read @brettcannon's new PEP 751 – "A file format to list Python dependencies for installation reproducibility":
https://peps.python.org/pep-0751/
Discuss it: