Namespaces for the Python Package Index [LWN.net]

Namespaces for the Python Package Index

Posted May 4, 2023 7:43 UTC (Thu) by lunaryorn (guest, #111088)
In reply to: Namespaces for the Python Package Index by NYKevin
Parent article: Namespaces for the Python Package Index

I once heard the theory that typosquatting is largely not a problem in the Java ecosystem because these reverse DNS group names make artifact names so long that on one actually types them out; people copy them from elsewhere (e.g. search.maven.com, Github, etc) which makes it much harder to trick people into copying wrong artifact names. And there are probably way to many potential typos to attempt typosquatting on Maven Central.

I actually really like the Java naming system; I think it's one of the few things Java really got right from the start. I believe it helps to manage trust because you can selectively delegate trust along the namespace hierarchy. It also supports routing in proxy repositories: You can summarily accept certain root namespaces into your proxy repository, require manual verification for others (e.g. the whole io.github hierarchy), and make sure that your own "com.example.your-company.internal" packages never get resolved from a public repository.

It also moves load off maintainers in a central repository: Sonatype can afford a comparatively strict and cumbersome application process, because they only check group names once, whereas moderation on PyPi or crates.io has no chance but to check each and every package.

All this is somewhat impossible to do with flat packaging as in Rust or Python. Sure these names are harder to type out, but that's what tooling exists for, in my opinion.

to post comments

Namespaces for the Python Package Index

Posted May 4, 2023 7:52 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (4 responses)

The whole point of Python is to move away from the Java style of doing things (i.e. big enterprisey hierarchical structures). If you want Java, then use Java.

Namespaces for the Python Package Index

Posted May 4, 2023 9:56 UTC (Thu) by SLi (subscriber, #53131) [Link]

That sounds a bit like the purpose is to do it differently only because Java does it this way. As I said, I don't understand the upsides and downsides of the Java system, but I'm sure "Java does it this way, so this can't be good" is not a good justification.

Namespaces for the Python Package Index

Posted May 4, 2023 13:53 UTC (Thu) by lunaryorn (guest, #111088) [Link]

I have a déjà vu. Didn't they say the same (or, for the more "elite" part of the community, rather "If you want Haskell, then use Haskell") about PEP 484 and the whole typing thing? And look where we are today… ;)

Namespaces for the Python Package Index

Posted May 4, 2023 17:26 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

Didn't Python have UCS-2 or UTF-16 as its internal encoding for the longest time? That's a lesson Java should have taught anyone to avoid…

Namespaces for the Python Package Index

Posted May 5, 2023 2:25 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

No, it was even dumber than that. Python had "narrow" and "wide" builds, which used UCS-2 and UCS-4 respectively (i.e. the language was not aware of surrogate pairs and treated them as two characters). To a first approximation, the Windows builds were narrow and the Linux builds were (mostly) wide (and I have no idea what they did for macOS).

This was all cleaned up in Python 3. Now, strings are sequences of abstract code points, and the encoding is an internal implementation detail. If you want to use "bytes encoded in UTF-8" instead, you can easily do that, but it's just not what the language does by default.

Namespaces for the Python Package Index

Posted May 4, 2023 8:45 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Domain names can and do contain the - character. How do you include that in a Java namespace?

Namespaces for the Python Package Index

Posted May 4, 2023 8:58 UTC (Thu) by lunaryorn (guest, #111088) [Link]

The established convention would be to use an underscore instead.