3 ms·
iirc this is one of the things earmarked for a hypothetical Python 4, making -P the default. It's also one of the many relatively well-known (security) issues i
by formerly_proven 3y ago
iirc this is one of the things earmarked for a hypothetical Python 4, making -P the default. It's also one of the many relatively well-known (security) issues in Python that don't get addressed for a surprising amount of time. Others in the same vein would be stuff like stderr being block-buffered when not using a TTY, no randomized hashes for the longest time, loading DLLs preferably from the working directory, std* using 7-bit ASCII in a number of circumstances and many more.
- TeMPOraL 3y ago> loading DLLs preferably from the working directory That is a feature, though, isn't it?
- formerly_proven 3y agoNo, the problem was that python[.exe] would load pythonXY.dll etc. from the working directory instead of the installation. Edit: I also recall issues with wheels where .so's in unexpected locations would take preference over the .so files shipped by the wheel. I believe most of that should be fixed nowadays with auditwheel and hardcoded rpaths.
- jonnycomputer 3y ago-P?
- throwawaymobule 3y agohttps://docs.python.org/3/using/cmdline.html?highlight=q#cmdoption-P https://docs.python.org/3/using/cmdline.html?highlight=q#cmd... had to look myself. apparantly, it's like setting PYTHONSAFEPATH which prevents 'unsafe' paths from getting added to sys.path. new in 3.11
- jonnycomputer 3y agoNew in 3.11; ah; that's why I didn't see the option in my default python.
- patrec 3y ago> stderr being block-buffered As opposed to line buffered, I assume? That sounds annoying, but why is it a security problem? > no randomized hashes I'm not up to date, but I think last I looked, I had the impression that randomized hashes didn't seem like they would fundamentally prevent collision attacks, just require more sophistication. Is that not the case?