gh-75223: Reject undotted extensions in mimetypes.add_type()

[OddBloke]

Extensions that don't start with a dot will never be found by
methods/functions that act on the registry, so we should stop users from
mistakenly adding them.

https://bugs.python.org/issue31040

• Issue: mimetypes.add_type should complain when you give it an undotted ext #75223

[OddBloke]

I've opened this now to get feedback on whether this is an appropriate change to make. Does it need a warning first, before it becomes the default behaviour?

(At a minimum, I would expect to need to add to documentation.)

[JulienPalard]

As said in https://bugs.python.org/issue31040, please use startswith instead of find.

There is one case where it works without a dot:

>>> mimetypes.add_type('empty', '')
>>> mimetypes.guess_type('')
('empty', None)

And someone may have used it to distinguish between emptyness and type not found. What I propose:

Emit a warning in case the ext is empty, else ValueError in case the type does not start with a dot, to ensure we're not breaking any code.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[OddBloke]

I have made the requested changes; please review again.

[bedevere-bot]

Thanks for making the requested changes!

@JulienPalard: please review the changes made to this pull request.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

Dismissing my review, I've updated the PR

[encukou]

IMO, this is a backwards-incompatible change and should be deprecated with a warning, and documented. (For example, if add_type is fed from a data file, this PR can change a relatively harmless data-entry error into a hard failure. Or someone could use types_map directly.)

[hugovk]

Thanks, please see #128638 to deprecate it first, and I've marked this as a draft until it's ready for merge.

[StanFromIreland]

Thanks, please see #128638 to deprecate it first, and I've marked this as a draft until it's ready for merge.

It was deprecated and scheduled for 3.16, so it's time!

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #32618039 | 📁 Comparing c491311 against main (7241f27)

  🔍 Preview build  

3 files changed

± library/mimetypes.html
± whatsnew/3.16.html
± whatsnew/changelog.html

[StanFromIreland]

This should have the same "Valid extensions start with a '.' or are empty." note IMO, but it wasn't updated before?