# PEP 755: Implicit namespace policy for PyPI

**URL:** <https://discuss.python.org/t/pep-755-implicit-namespace-policy-for-pypi/63191>\
**Category:** Packaging\
**Created:** [September 7, 2024, 4:37pm UTC](https://discuss.python.org/t/pep-755-implicit-namespace-policy-for-pypi/63191 "2024-09-07T16:37:02Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![takluyver](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/takluyver/32/513_2.png) [@takluyver](https://discuss.python.org/u/takluyver)\
**Post date:** [September 9, 2024, 5:21pm UTC](https://discuss.python.org/t/pep-755-implicit-namespace-policy-for-pypi/63191/15 "2024-09-09T17:21:30Z")

</div>

> [@steve.dower](#):
>
> Perhaps prefixes should be linked to defensible trademarks, rather than being arbitrarily selected by whoever requests it?

What if we went one step further and based prefixes on reversed domain names? So `com.google.*` could belong to Google, `org.jupyter.*` to Jupyter, and so on.

Obviously this would be more of a shift in our conventions than registering `google-*` or `jupyter-*`, but on the plus side:

- It’s a pattern already familiar in many other ecosystems (Java packages, apps on Android, Mac & many modern Linux apps), so we’re not starting from scratch.
- Domain names are exclusive, whereas trademarks can overlap.
- This could allow for automated or semi-automated registration of a prefix, based on setting up a particular DNS entry or static file on the domain you own, potentially reducing the load on PyPI admins, who everyone agrees are overloaded.
- These are already valid package names, so it shouldn’t need major changes in tooling.
- But they’re not commonly used, so the issue of pre-existing packages conflicting with a restricted namespace is smaller (albeit not totally gone).

---

_[View the full topic](https://discuss.python.org/t/pep-755-implicit-namespace-policy-for-pypi/63191)._