Activity

1. moefear85

   added

   type-featureA feature request or enhancementA feature request or enhancement

   on Apr 21, 2023
2. arhadthedev

   added

   topic-pathlib

   and removed

   topic-pathlib

   on Apr 21, 2023
3. ronaldoussoren commented on Apr 21, 2023

   

   ronaldoussoren

   on Apr 21, 2023

   Contributor

   More actions

   In fact, any object with a reasonable string representation, should automatically be converted to a string for anything that expects a string, that's the pythonic "batteries included" mentality.

   The "batteries included" concept refers to having a fairly rich standard library, not about features like this. "refuse the temptation to guess" applies here, especially for automatic conversion of objects to strings. What's a "reasonable" string representation when in practice all objects have a string presentation through the __str__ and __repr__ methods? In general Python tends to not automaticly convert between types unless there's a good reason to do so (e.g. 1 + "3" raises an exception and does no silently convert the string "3" to an integer).

   BTW, I don't think #102425 applies here, the os.environ values are strings some of which happen to look like paths (or integers).
4. moefear85 commented on Apr 21, 2023

   

   moefear85

   on Apr 21, 2023

   Last edited by moefear85

   Author

   More actions

   The "batteries included" concept refers to having a fairly rich standard library

   exactly. Isn't CPython basically an implementation of exactly that?

   just because an object has an str or repr method doesn't mean it conceptually lends itself to a textual representation, even though it has a linguistic word to reference it as a concept. But a path innately does have one, since all such paths are textual, there was never such a thing as an acoustic or abstract path.

   Anyways, it's not just my opinion. Someone filed this as a bug where os.environ is maintained (forgot the link), and there was a heated discussion. I think if it is to be implemented, then rather here. I also believe the ultimate decider whether something should be implemented, is whether it is practical and simplifies the workload downstream. Whether anyone feels like picking it up is a separate issue. I'm fine with modifying my copy of the source. unsubscribing.
5. ericvsmith commented on Apr 22, 2023

   

   ericvsmith

   on Apr 22, 2023

   Member

   More actions

   I agree we should not be automatically calling str or repr. It is better to be explicit in how you want the string representation of an object to appear in the environment.

   If you really want to pursue this, I suggest discussing it on https://discuss.python.org/c/ideas/6
6. eryksun commented on Apr 22, 2023

   

   eryksun

   on Apr 22, 2023

   Last edited by eryksun

   Contributor

   More actions

   For comparison, the items of the args list in subprocess.Popen can be str, bytes, or any path-like object (i.e. an object that implements __fspath__()). Moreover, on POSIX both the keys and values of the env mapping of subprocess.Popen can be str, bytes, or any path-like object. (On Windows, the keys and values can only be str strings.) For example, on Linux:

   >>> environ = os.environ.copy()
   >>> environ[pathlib.Path('SPAM')] = pathlib.Path('EGGS')
   >>> subprocess.call('echo $SPAM', env=environ, shell=True)
   EGGS

   I know the env behavior is an unintended consequence from encoding with os.fsencode(), but maybe it should actually be supported by subprocess.Popen and os.environ on all platforms. On POSIX, the function used by os.environ to encode keys and values would be os.fsencode(), and the function used to decode keys and values would be os.fsdecode(). On Windows, the key and value encode functions would use os.fsdecode(). Subscripts and iteration would still always return str strings for os.environ and bytes for os.environb.
7. iritkatriel

   closed this as not plannedon Nov 29, 2023