As a non Python dev this seems like very surprising behavior for a system library to be modified by just having a file with a specific name in the same folder.

▲

MereInterest 2 days ago | parent | next [-]

It's an awful problem, and a pretty big gotcha for the ecosystem. For example, I worked on a tool that used `tool_name/random.py` for analysis of RNG usage. However, any command run within that directory would shadow the builtin `import random`. As a result, I couldn't run the `black` formatter from within that directory, because it would accidentally import the local `random.py`.

The solution is to update the python flags to include `-I`, so that python will run in an isolated mode.

<rant>

This is relates to my frustration with how PEP-668 was implemented. Python has long had a problem with accidental overwriting of system libraries. If you `sudo python -mpip install foo`, then that can interact very poorly with your distro's `sudo apt-get install python-foo`, since pip would add/remove files that were expected to be managed solely through `apt-get`.

But in adding a warning to prevent this, they also applied the same warning to `~/.local/pythonX.Y/site-packages`, which is where traditionally a user would install additional packages with `python -mpip --local foo`. The argument is that since this is part of the import path of `/usr/bin/python`, it belongs to the system's python installation, so installation to the user's site-packages should also be blocked. This is a sleight of hand that changes the goal of PEP-668 from "avoid conflicts in file ownership" to "ensure an isolated python environment for system tools".

If I were to accept their argument that /usr/bin/python's imports should only be affected by distro-managed installations, then I should also be prevented from making any `*.py` files anywhere. After all, if those were in the working directory, they would be imported. This is clearly ridiculous, and so I don't buy the argument that breaking user-level site-packages is justified in order to have an isolated system-level python.

The correct solution would be for distro-managed programs to use `#!/usr/bin/python -I` as their shebang instead of `#!/usr/bin/python`, so they would actually get an isolated environment. Instead, PEP-668 needlessly broke user-level site-packages, and didn't even solve the problem that it set out to do.

</rant>

▲

rcxdude 2 days ago | parent | prev | next [-]

You would get a similar thing in C and C++ with a system header in a library directory (maybe some compilers would warn on such a thing?). Most languages don't privilege their standard libraries in a way that would prevent this.

▲

mostlylurks 2 days ago | parent [-]

Privileging the standard library would be a pretty bad way of fixing the issue. It wouldn't prevent the same issue from affecting non-standard libraries, which are also subject to the same issue.

The correct way to avoid this issue would be to require local code to be imported in a distinct manner from installed libraries, with an explicitly defined relative path, which is how it works in the javascript ecosystem. If you want to import local code, you just `import foo from './foo';` (for a module in the same folder, `import foo from '../foo';` for module from parent folder, etc.), and if you want to import an installed library, `import foo from 'foo';`.

	▲	rcxdude 2 days ago \| parent [-]
		Yeah, I wasn't recommending it as a mitigation per se. python /does/ have relative imports but they're not required. C and C++ notionally have a similar thing with "include.h" vs <include.h> but the behavior is complex and not really designed for avoiding confusion about where the header is coming from.

▲

DangitBobby 2 days ago | parent | prev | next [-]

Yeah my takeaway after reading the article was this seems more like a demonstrated vulnerability in Python than in Claude Code.

▲

ATMLOTTOBEER 2 days ago | parent | prev [-]

Yeah my first impression here is just “wow python is bad”