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 lemburg
Recipients brett.cannon, chris.jerdonek, eric.araujo, eric.snow, jaraco, jayyin11043, lemburg, ncoghlan, ncohen, python-dev, serhiy.storchaka
Date 2022-03-26.14:34:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <2b24983c-c1f8-2e95-1e98-f087d444889b@egenix.com>
In-reply-to <1648281579.87.0.803346112327.issue32642@roundup.psfhosted.org>
Content
On 26.03.2022 08:59, Nick Coghlan wrote:
> 
> The import system is already complex, so I think the hesitation about allowing arbitrary Path-like objects is warranted. (For example: are importlib's caching semantics really valid for *arbitrary* path-like objects? An object can be path-like without being immutable)
> 
> Coercion on input (as Noam suggests) would have a much lower risk of unwanted side effects, as any dynamic behaviour would be resolved at insertion time.

This is not only about the import system. Lots of Python code out there
manipulates sys.path or reads sys.path for various reasons and does not
expect Path objects as list members, since only strings and bytes
are allowed:

https://docs.python.org/3/library/sys.html#sys.path

Conversion to strings sounds like a good way to get the best out of
both worlds.

I'm just curious on how this would work. You'd like have to create a
list subclass for use with sys.path which applies the conversion
whenever a non-string member gets added. Or perhaps add helper methods
to Path objects to safely add their value to sys.path.
History
Date User Action Args
2022-03-26 14:34:00lemburgsetrecipients: + lemburg, brett.cannon, jaraco, ncoghlan, eric.araujo, chris.jerdonek, python-dev, eric.snow, serhiy.storchaka, jayyin11043, ncohen
2022-03-26 14:34:00lemburglinkissue32642 messages
2022-03-26 14:34:00lemburgcreate