Namespaces for the Python Package Index [LWN.net]

Namespaces for the Python Package Index

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

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 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.