[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