This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients gregory.p.smith, gvanrossum, iritkatriel
Date 2021-09-02.20:42:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1630615368.05.0.365023083164.issue44091@roundup.psfhosted.org>
In-reply-to
Content
FWIW I don't remember the context that led me to just file the issue this year.  The most serious frequent instances of this I remember happening were all many years ago when a less capable software distribution mechanism was in use.

A scenario where I would imagine it today aside from things like what Irit mentioned with the developer workflow:

People using an OS distro's Python interpreter (and even OS distro supplied Python packages instead of pip in a virtualenv) in order to run their own potentially long running code.

The OS distro does not know about their running processes as they haven't created OS packages with startup/restart/shutdown and dependency relationships expressed.  So the OS updating Python packages does not trigger a restart of their software after updating a dependency out from underneath it.

I know this happens, but I don't know how often it actually bites anyone.  And there are workarounds if deemed serious (tie in with the OS package management).

I personally wouldn't prioritize work on this issue unless it fits in naturally with other work going on to plumb the information through.  Or without an ability to demonstrate a compelling frequently encountered user-confusion scenario.  It's a "nice to have" more than a "need".
History
Date User Action Args
2021-09-02 20:42:48gregory.p.smithsetrecipients: + gregory.p.smith, gvanrossum, iritkatriel
2021-09-02 20:42:48gregory.p.smithsetmessageid: <1630615368.05.0.365023083164.issue44091@roundup.psfhosted.org>
2021-09-02 20:42:48gregory.p.smithlinkissue44091 messages
2021-09-02 20:42:47gregory.p.smithcreate