Merge pull request #3 from epage/prior

Document Python prior art

text/0000-packages-as-optional-namespaces.md

@@ -195,6 +195,10 @@ This proposal is basically the same as https://internals.rust-lang.org/t/pre-rfc
 
 Namespacing has been discussed in https://internals.rust-lang.org/t/namespacing-on-crates-io/8571 , https://internals.rust-lang.org/t/pre-rfc-domains-as-namespaces/8688, https://internals.rust-lang.org/t/pre-rfc-user-namespaces-on-crates-io/12851 , https://internals.rust-lang.org/t/pre-rfc-hyper-minimalist-namespaces-on-crates-io/13041 , https://internals.rust-lang.org/t/blog-post-no-namespaces-in-rust-is-a-feature/13040/4 , https://internals.rust-lang.org/t/crates-io-package-policies/1041/37, https://internals.rust-lang.org/t/crates-io-squatting/8031, and many others.
 
+Python has a similar coupling of top-level namespaces and modules with the filesystem.  Users coming from other packaging systems, like Perl, wanted to be able to split up a package under a common namespace.  A hook to support this was added in Python 2.3 (see [PEP 402](https://peps.python.org/pep-0402/#the-problem).  In [PEP 420](https://peps.python.org/pep-0420/) they formalized a convention for packages to opt-in to sharing a namespace.  Differences:
+- Python does not have a coupling between package names and top-level namespaces so there is no need for extending the package name format or ability to extend their registry for permissions support.
+- In Python, nothing can be in the namespace package while this RFC allows the namespace package to also provide an API.
+
 # Unresolved questions
 
  - How exactly should the Cargo.toml `lib.name` key work in this world, and how does that integrate with `--extern` and `-L` and sysroots?