os.environ.copy()['COPY_HUH'] = "not really"

[Jeff Epler]

Under Python2.1 and earlier (back to 1.5.2):
>>> import os
>>> os.environ.copy()['COPY_HUH'] = "not really"
>>> print os.environ['COPY_HUH']
not really

Under even 2.3a0 (CVS):
>>> import os
>>> os.environ.copy()['COPY_HUH'] = "not really"
>>> os.system("echo $COPY_HUH")
not really
0

My expectation is that modifying a copy of os.environ would not actually
modify the environment either in the current session or for children
created with os.system ...

dict(os.environ) seems to be the trick on versions of Python that have
it, os.environ.data on versions that don't.

Jeff

[Gustavo Niemeyer]

> Under Python2.1 and earlier (back to 1.5.2):
> >>> import os
> >>> os.environ.copy()['COPY_HUH'] = "not really"
> >>> print os.environ['COPY_HUH']
> not really
>
> Under even 2.3a0 (CVS):
> >>> import os
> >>> os.environ.copy()['COPY_HUH'] = "not really"
> >>> os.system("echo $COPY_HUH")
> not really
> 0

Here's the problem:

>>> print os.environ.__class__
os._Environ
>>> copy = os.environ.copy()
>>> print copy.__class__
os._Environ

It's not a real dictionary, but an os._Environ class. Copying it
creates instances of the same class, and that class' behavior is
to insert the item in the environment. I belive this should be
avoided in this case, returning a true dictionary from copy(). I'll
send a patch to SourceForge, if you haven't done so yet.

--
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

[Jeff Epler]

On Tue, Apr 30, 2002 at 06:42:31PM -0300, Gustavo Niemeyer wrote:
> >>> copy = os.environ.copy()
> >>> print copy.__class__
> os._Environ
>
> It's not a real dictionary, but an os._Environ class. Copying it
> creates instances of the same class, and that class' behavior is
> to insert the item in the environment. I belive this should be
> avoided in this case, returning a true dictionary from copy(). I'll
> send a patch to SourceForge, if you haven't done so yet.

I was tempted to send a patch to SF, but I was worried that there was
some "good" reason for this feature. Maybe it's just an accident
waiting to be fixed after all. If you have a patch prepared, by all
means submit it.

Jeff

[Terry Reedy]

"Jeff Epler" <jep...@unpythonic.net> wrote in message
news:mailman.1020257642...@python.org...

I would normally expect a 'copy' to be a copy.
Perhaps os._Environ should have a .dict() method (if is does not now)
to do the conversion.

[Alex Martelli]

Terry Reedy wrote:
...

> Perhaps os._Environ should have a .dict() method (if is does not now)
> to do the conversion.

dict(os.environ) seems a better solution to me. It's a general way to
make a dictionary from any generic mapping, after all.

Alex

[Terry Reedy]

"Alex Martelli" <al...@aleax.it> wrote in message
news:eCTz8.85568$vF6.2...@news2.tin.it...

I thought of this and would agree if dict knows how to handle an
os._Environ object, but I don't know if it does and am not prepared to
test at the moment.

TJR

[Steve Holden]

"Terry Reedy" <tjr...@udel.edu> wrote in message
news:0AUz8.25621$Lj.19...@bin4.nnrp.aus1.giganews.com...

Looks like that's the way to go, then:

>>> type(os.environ)
<type 'instance'>
>>> e = dict(os.environ)
>>> e["TEMP"]
'C:\\DOCUME~1\\SHOLDEN\\LOCALS~1\\Temp'
>>>

regards
Steve
--

Steve Holden: http://www.holdenweb.com/ ; Python Web Programming:
http://pydish.holdenweb.com/pwp/

[Alex Martelli]

Terry Reedy wrote:
...

>> dict(os.environ) seems a better solution to me. It's a general way
> to
>> make a dictionary from any generic mapping, after all.
>
> I thought of this and would agree if dict knows how to handle an
> os._Environ object, but I don't know if it does and am not prepared to
> test at the moment.

_any_ generic mapping:

>>> class fake:
... def keys(self): return range(4)
... def __getitem__(self, indx): return indx
...
>>> dict(fake())
{0: 0, 1: 1, 2: 2, 3: 3}
>>>

i.e., anything with a .keys() argument-less method returning a list of
hashables, and a __getitem__ that returns a value for each item of
that list -- one could hardly ask less of "a mapping":-).

Alex

[Gustavo Niemeyer]

> I was tempted to send a patch to SF, but I was worried that there was
> some "good" reason for this feature. Maybe it's just an accident
> waiting to be fixed after all. If you have a patch prepared, by all
> means submit it.

I've done so immediately after replying your message and checking if
you haven't done so before. The patch was already accepted, and you can
review it at:

http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550804&group_id=5470

Thanks!