# Handling modules on PyPI that are now in the standard library?

**URL:** <https://discuss.python.org/t/handling-modules-on-pypi-that-are-now-in-the-standard-library/27071>\
**Category:** Core Development\
**Created:** [May 25, 2023, 4:54am UTC](https://discuss.python.org/t/handling-modules-on-pypi-that-are-now-in-the-standard-library/27071 "2023-05-25T04:54:13Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\
**Post date:** [June 14, 2023, 5:56am UTC](https://discuss.python.org/t/handling-modules-on-pypi-that-are-now-in-the-standard-library/27071/21 "2023-06-14T05:56:27Z")

</div>

> [@mwichmann](#):
>
> Any thought of just deleting some of these old and at the time well-meaning backports?

Yeah, for _really_ old (\<2.6) backports like `multiprocessing`, `hashlib`, etc., that see ≈\<100,000 monthly downloads, the calculus above changes and yanking all releases (like @gpshead did) is probably the way to go (and is strictly superior to deleting, as discussed above), as the breakage is less, the benefit is more, and it’s the easiest option to implement (just click a button). (Newer or more widely used backports will need more thought, though, per the analysis above.)

---

<div class="post-metadata">

**Author:** ![ppentchev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ppentchev/32/11028_2.png) [@ppentchev](https://discuss.python.org/u/ppentchev)\
**Post date:** [June 15, 2023, 9:50am UTC](https://discuss.python.org/t/handling-modules-on-pypi-that-are-now-in-the-standard-library/27071/22 "2023-06-15T09:50:14Z")

</div>

> [@Jelle](#):
>
> > [@ppentchev](#):
> >
> > will expect to be able to import the “tomli” module and examine its interface even if mypy itself is being run with Python 3.11
> 
> I don’t think that’s true; mypy (1) never imports your code, it’s purely static and (2) understands the `sys.version_info` check, so it checking in 3.11+ mode it won’t care about the `else` branch.
> 
> Perhaps you have mypy’s `python_version` setting set to a lower version of Python, so mypy will type check your code for that version.

Right. Um. Yeah. So it seems that I had, indeed, misunderstood the intent of specifying the Python version to mypy. I thought it was more like “…but bear in mind that this version of Python might also need to run that code, so do complain if I use newer features”, and now that I think about it, this kind of contradicts the _other_ thing I thought mypy should do: “…but please also use the newer features of the currently-running version” 🙂

So yeah, thanks for pointing this out. In the past two weeks since you wrote that I have already started dropping the python\_version option from the mypy invocations in some of my projects, so, yeah. Thanks, and sorry for the noise. It seems that this is indeed not a valid concern WRT the actual topic.

G’luck,  
Peter

[Previous page](https://discuss.python.org/t/handling-modules-on-pypi-that-are-now-in-the-standard-library/27071.md?page=1)