Name clash with `multipart` package.

[tomchristie]

I don't especially mind that both multipart and python-multipart exist on PyPI, but it's a bit awkward that they both also install as multipart.

I've already managed to bump my head on this, and couldn't understand why the signature for multipart.MultipartParser wasn't as expected having had both packages installed at some point.

Although I much prefer the plain multipart name I wonder if it's worth considering something like multipartparser?

Alternatively we don't worry about it for now, and consider something later if it's an issue. Not sure.

[tiangolo]

I would like to second this. It's quite hard to detect when it happens, it took 3 of us for a whole day (or more) to finally discover we had both packages installed. I was about to call a server exorcist 😂

Of course, it was a bug in our code to have both installed, but the fact that sometimes one is used and some times the other for the same multipart makes it especially difficult to debug.

Would you consider changing the import name as @tomchristie suggests? 🙏

[Kludex]

I'm not fixing this.

My intention is to maintain this package till we merge the code to Starlette.

[tomchristie]

@Kludex Appreciate a concise & clear response. 🌟

[henryiii]

FWIW, I'd recommend renaming the import to python_multipart. It's not a good idea to name your import to something that you don't own on PyPI. If someone has the PyPI package multipart, it's quite reasonable for them to name the import multipart. You don't own the PyPI name, so I think you should use the name you do own.

Note that the official CPython docs recommend multipart (the Python package) as the replacement for the removed-in-3.13 cgi module, so more packages are going to start requiring that one.

[Kludex]

Why does CPython recommends that?

[henryiii]

It's here: https://docs.python.org/3.12/library/cgi.html