[issue8603] Create a bytes version of os.environ and getenvb()

STINNER Victor report at bugs.python.org
Thu Jul 29 19:11:46 CEST 2010


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 29 juillet 2010 03:08:27, Ezio Melotti a écrit :
> A quick search[0] also shows that environ.data is used by several projects.

_Environ is a wrapper on data: call putenv() when a value is changed and 
unputenv() when a value is removed. Since os.environb, it does also convert 
key and value types. So .data should not be used directly.

It looks like a common usage of .data is to get get to "a real dict" (and not 
"an user dict"). I think that os.environ.data or os.environ.data.copy() can be 
replaced by dict(os.environ) is that case.

> Changing it from str to bytes will most likely break these programs,

I'm not sure of that. It looks (in the search result) that os.environ.data is 
just stored and passed to a function, but not used as a dictionary to get a 
value (well, I'm not sure because it's hard to say with just 3 lines of the 
program). In that case, it doesn't matter if the dictionary contains byte or 
unicode strings.

Eg. zope2instance:

  old_env = os.environ.data.copy()
  ...
  os.environ.data = old_env

It does still work with bytes.

> so I'm not sure it's a good idea

Yes, it's not a good idea to use .data :-) This attribute should be protected, 
not public (even if it is not documented).

> IMHO os.environ.data should contain str, whereas os.environb.data
> bytes.

data is shared between os.environ and os.environb, because data is the 
solution to synchronize both dictionaries.

> If they must share the same data I would prefer them to be both
> str.

No, data should use the native type: bytes on UNIX and BSD, str on Windows.

--

If you still consider that the change on .data as a bug, I think that the fix 
is to remove .data (mark it as protected: environ.data => environ._data).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________


More information about the Python-bugs-list mailing list