TODO: A zero dependency #python app can be installed with
- git clone
- or download zip,
executed with python -m
But you can't search #pypi for these apps.
These apps have minimal supply chain risk
Are still "installable" in locked down environments
I got people on my team that still can't get uv, pip or pipx to work with Artifactory. (Why don't they just use pipenv, or setuptools or poetry or ...)
But they're more or less unfindable.
I want default #python extras so bad...
- put fast things like orjson, rtoml, google-re2 and so on in extras: 99% of your users will have a bad experience out of box
- move them to direct dependency? now you can't upgrade or try out 3.15 and *some day* your users will not be able to carry on because the orjson or rtoml guy died or google-re2 staff were laid off and there aren't wheels anymore.
Sandboxing #python? Easy.
I set my computer in the cat box and no one has touched it.
Fine, for the priv of using the #python hashtag, peeps are working on sandboxing python without docker/VMs.
Pyodide, pyscript, micropython-wasm, (I think?) are all WASM strategies.
I am messing around with hermetic-seal, which is like .NET Code Access Security, which is fundamentally flawed for protecting against malice, but works for some very narrowly defined threat models & uses ordinary python.
I maintain a fork of this abandoned #python library with some users. It is 2 functions.
The installation instructions should push people towards vendorizing it.
I should check to see what is new since I last looked at vendy for facilitating vendorizing.
Survey on improving the #pypi sidebar today.
I told them I think "verified / Trusted Publisher" means, "the build server used a short lived password"
(thinking more, if metadata is signed but nothing else is, what a weird place to stop. Like, ooh, I trust this metadata, so I trust the unsigned #python wheel?)
We don't know who publishes ANYTHING to pypi.org it is all anonymous. "That build server" isn't exactly what people mean by identity. Sure, it narrows it down.
I fork packages and I don't want to look like I taking credit away from the original author, so I leave their names there. But the UI now makes it look like my published package is somehow *them*. That trust should not extend to my package. People should only trust it if they trust me. Ditto for the 150 contributors who didn't publish the package. (I mean, except if we skip blaming the publisher and blame the person who snuck in a malicious commit)
Don't get me wrong, I'm happy they're thinking about this & and doing the survey.
#tkinter in #python is a "batteries maybe included" - it is inconsistent enough that I'm about to create a "where's my tkinter" website for helping people know which python have tkinter and which don't and what to do about it.
Wow, this is so much more complicated. There are several distro channels of python, many use `python-build-standalone` - the one you download an .exe/.msi from python.org? That depends on what check box you ticked and what the defaults were. Docker is hit or miss if tkinter is included.
It is still got a way to go but here is a tool for making the missing #pypi user profile.
But Matt, where do you put the signature or rel=me? In a package!
Pypi is pretty meager for profile info, but you can publish a #python package with a whole website in it.
This is what the static site works like, with light debranding. I left pypi in the name because there are a lot of packages with `pypi-` in the name.
It is yet another "publish a cryptographic signature on two sites to prove you own it"
Pet peeve. You never know if your installed #python has #tkinter included or not. It seems to be completely random.
3.12.0, nope. 3.13.0, nope. 3.14.4 yes!
Man, the length that people go to break things on windows.
#uv prohibits scripts with name of python3.
Most techniques to create a #python3 alias don't work, so I made the library python3-alias - which can be built with `python -m build` but `uv sync` refuses.
Use cases is a Makefile you don't own has `python3 blah blah` and you can't change it to `py blah blah` or run windows store installs.
If you got a working alternative, I'm curious otherwise, this is more behavior like `sh` library that if you even import it on windows it shits bricks, because, hey if there is even one linux or mac library in the venv you should fdisk the users computer because f*k 'em
I'm trying to think of a better option, but I'm thinking of a few cases where module-does-not-exit is the responsibility of the calling code. But another way to look at it, python has an assumption of being somewhat cross plat and if you do, then all the linux only library should be treated like `[extras]` and if import gets modulenotfound, then you keep going until you attempt to do a thing with the library.
Looks like there aren't any issue #python issue/bug trackers that are
- easy to install (eliminates trac, roundup)
- can be found in #pypi (is just bad SEO?)
- isn't actually mostly a github clone (Kallithea)
- isn't actually help desk software (call center & tickets to fix printers I guess.)
Really? I'm torn between wanting to write trac-init, roundup-init and just writing what should be yet-another-issue-tracker.
youtube #python conference happening online right now, live
I'm actually sick and I still can't call in sick to watch to whole thing.
I can't decorate my #python functions they way I want to. I want them to have jolly hats
```python
```
# Invalid hat
# 🎩 = lambda _ : _
# valid hat
_Δ_= lambda _ : _
@_Δ_
def hello(): print("hello")
hello()
```
```
@_ Mastodon doesn't seem to be happy with the notation either
#csharp like #python doesn't have private functions, only functions that are callable with a clunky syntax (in c#'s case, reflection, in python you have to use Hungarian notation)
So if this is what people really want, then I propose anti-sugar for all the functions you don't want your users to call and that you want to keep to yourself. Antisugar functions will be declared in cobol syntax to make sure no one can call them without a morning of typing.
IDEA: a #python package, but it acts as my #pypi profile page.
This idea isn't all that novel, (package-as-resume) but this time I want to make it easy for people to copy & useful on installation. And of course it is ironic to install a package a way to get info about a user as a trust building exercise. I guess if I got it to run in pyscript that would be a good exercise.
Do you wish you could remove certain libraries from the #python standard library? Sort of like CAS in .NET?
Well I got you covered.
Not a replacement for docker. Works like pytest-socket.
Anyhow, looking forward to examples of exploits, which I imagine would be un-monkeypatching or just using other libraries.
Still I think this would be a nice way to seal apps you distribute against highjacked 3rd party libraries that weren't specifically targetting this defense.
And why is this called `hermetic-seal?` ? Well after searching for a perfect name I picked `hermetic`, which is 404 on pypi, free to take? Nope, if you register trusted publisher for that name #pypi says it is **taken**!
# Find your non 3.14 #python, run in folder parent to all your repos
```
from pathlib import Path;import subprocess
g=0;b=[]
for p in Path().cwd().iterdir():
v=p/'.venv'
if v.exists():
e=v/'Scripts/python.exe'if(v/'Scripts/python.exe').exists()else v/'bin/python'
if e.exists():
r=subprocess.run([e,'--version'],capture_output=1,text=1)
if'3.14'in r.stdout:g+=1
else:b.append((p.name,r.stdout.strip()))
else:b.append((p.name,'no py'))
if b:[print('bad:',*b)]
print(f'{g} good')
```
#rtoml, pydantic, Maturin, pyO3 are all fighting me. #python #Python314
This worked for pydantic
"pydantic>=2.12.0; python_version >= '3.14'",
This didn't work for rtoml
"maturin>=1.9.6; python_version >= '3.14'",
The effort to rewrite everything in #python was underway already and no one told me!
cmdix supports this long list of gnu/linux/bash cli commands, but the readme give it no SEO visibility on pypi!
https://github.com/jaraco/cmdix/blob/main/pyproject.toml#L81
Am I taking crazy pills? I count 3+ drop in replacements for `random` on pypi.* But the #python standard library `secrets` is not a drop in replacement for `random` except for a subset of function signatures. i.e. you can't generally write `import secrets as random`
Do I need to publish a drop in replacement for `random` that has all the signatures and repoints everything to SystemRandom?
* these events might be statistically independent
My use case is to get Bandit to shut up everytime I `import random`
Also, I should publish the xkcd-random library, for when pseudorandom is just to unpredictable.
And another near drop-in replacement
https://pypi.org/project/quantum-random/
and another
https://pypi.org/project/pycrypto/
What's faster:
- source code for a 10,000 key dict in a .py file
- same as json in a comment in the .py, read it using `__file__` and parsing out the json and loading with orjson
orjson! or heck any format really. Anything can turn a dict on the file system into a dict in memory faster than python itself.
dict in source are slooooooow. I should benchmark that across #python versions.
#pypi #python package maintainers are under attack.
https://www.theregister.com/2025/09/24/pypi_phishing_attacks/
Forget rewriting all the CLI commands in rust, let's rewrite them in #python
- partially done from a quick search of pypi
- would make bandit happy (bandit hates subprocess)
- screaming, blazing, lightspeed fast*
* compared to *pure *bash
Oh wait, hold on. This is cheating. This is not how you rewrite sudo in python.
```
def run_as_sudo(sudo_user, cmd_str, shell=False, timeout=None):
sudo_args = ["sudo", "-u", sudo_user]
r = run_cmd(sudo_args + cmd_str.split(), shell=shell, timeout=timeout)
return r
```
https://github.com/wesinator/python-sudo/blob/master/sudo/sudo.py#L6
Do you ever synchronize your `__version__` variable with your pyproject.toml, config.ini?
I wrote this #python build tool a while back and have been using it everywhere.
For a time, the python community was on the cusp of a folksonomy standardization for metadata as dunder strings. It went nowhere and now pretty much only `__version__` is still ubiquitous. Had it gone to standard, it would probably look like the `__about__.py` files many projects have.
#python and #pypi supply chain mitigation for *apps*
What we (and npm and cargo and so on) need is pipx, except it runs that app in a docker container.
So I wrote a little script to generate a docker file, transferred the credentials for a secure python proxy to it, build and run the docker file.
The docker part was hard, but 10% of users, 1% of the time would be able to do it, but that wasn't the worst.
The private credential repo proxy was the hardest to configure. pip and uv really don't want to use anything other than pypi directly. Better to make sure no one uses a corporate proxy than to just trust pypi.org
malicious typo squats? in the news daily.
MITM? That is just life man, every organization is running a MITM against all the staff too see what they're up to. pip and uv have the wrong threat model. UX tricks to drive proxy use to 0 isn't improving security.
Features this needs
- auto discover if user has docker or podman
- auto discover credentials in context (machinewide pip.conf and translate to unix and move into the container)
- use local website or tkinter to handle user prompts because if only the 1% of 1% of users comfortable with cli use this, then it is pretty thin security. Heck even pipx has pretty low adoption.
And by proxy I mean like these, not HTTP proxies which don't have pypi security features
Artifactory
AWS CodeArtifact
Google Cloud Artifact Registry
GitHub Packages
GitLab Packages
Sonatype Nexus
Cloudsmith
Buildkite Package Registries
It's alive! Why bother with a .whl, or .zip or .pex or .pyz when you have `.sh` right there.
Shove your app into `python -c "..."`and stick that in a `.sh` file
Works now for
- single #python file
- module of many files
I guess uv integration is next.
Also useful for things like gitlab pipelines that don't let you reference python files in certain cases.
Today's idea,
#python -c "..." can and should act like a packaging format.
Question is, has it already been done. Doesn't look like it.
Use case? Yaml build scripts with restrictions on referencing .py files (looking at you gitlab) or R/O file systems.
Implementation, custom import loaders and probably zipping up the string to make it more compact.
Claude couldn't do it. There are like 4 layers of escaping and it got confused. Fine, I'll write code by hand.
I got an #python app and I wish it would install myapp[all] by default and myapp[core] if specified, e.g. on a build server. The options look bad.
- Split package into 2, mypackage-core and mypackage.
- project.optional-dependencies has `[all]` and `[core]` and `dependencies` is empty, eg default installation is broken.
- Default to installing dependencies, make people add `[all]` for what should be the default experience.
Roughly [all] is for desktop use
[core] would be for the same app on CI
IDEA: if you can put one serialized data structured into #python comments, why not any of them? xml in comments, json in comments, toml in comments. Where else can you put your zero-runtime-cost cat photos? That's right, in triple quoted annotations.
```python
def income_tax(income:"""
What does a baby computer call his father?
""", rate:"""well?""")->"""
Data
""":
return income*rate
```
We got unlimited power and we're not using it.
Is there enough reuse opportunities for a `catdog_typing` library?
A catdog being a union of types where the developer needs more control over the duck type interface, e.g. `str | list[str]` - by duck typing, iteration does what you probably don't want. So ideally these pairs get wrapped and the duck type interface is replaced with something sensible.
`str | Path | 'filelike'` seem like another common catdog.
Your life been on hold since 2005 when #PEP350 was rejected? Do you look at your #python code and think, "I should use the comments as a database or issue tracker"?
#PEP350 has an implementation now. Micah Elliott doesn't seem to be online here to tell him. Oh well.
Still work to do, but the perfect is the enemy of the published.
Please try it out. If you have a code base with old school `# TODO` comments, it will do something, but more features are enabled with full PEP350 tags or using the `@Todo()` decorator.
@Todo Two yanks. I think I need to update my build script to pipx install the wheel run the app from outside of the regular venv and see if it works.
https://pypi.org/project/pycodetags/#history
Because twice it didn't.
IDEA: I could support `str | list[str]` without incorrect iteration semantics by creating a whole new type that wraps both, delegates calls to str or list as appropriate and doesn't allow iteration into chars in str.
And mypy will hate it. `str | list[str]` is just messed up man.
Given how common `str | list[str]` show up, I think #python allowing str to be iterable was a mistake.
Just finished that #python packaging survey. What I'd like is a front runner package reputation scanner that will refuse to install a package that has <1000 downloads, was published <1 week ago, has problematic CVEs. I don't like the idea of installing all the packages and then, days later, on a build server, checking to see if they're malicious.
Coding Kata: You are Ebenezer Scrooge the morning of what could be Christmas. It is too cold to open the window to shout at passer-bys. Write a #python script to get the date, check the obituaries for Tiny Tim and use stripe to transfer a proper salary to your office staff.
When `python3` doesn't exist, are maintainers planning to send everyone a mac?
https://docs.python.org/3/library/venv.html#venv.EnvBuilder.setup_python
So to get a python3 alias on Windows without buying a mac, I wrote a library. I don't have a Mac handy, but this will *not* work on Unix, creating the cli command conflicts with the pre-existing python3 symlink.
Works on windows, in particular, works when running `shell python3 ...` inside of Makefile.
I couldn't figure out how to make an entrypoint conditional on the operating system or existence of python3 alias. As far as I can tell, it is now hard to package a setup.py so that setup.py custom code runs at install-time. (good for security!)
```toml
[tool.poetry.scripts]
python3 = 'python3.__main__:run'
```
Some Star Wars inspired syntax for #python
```python
do:
httpx.get('https://httpbin.org/get')
not:
print("Can't do it")
```