Message 294261 - Python tracker

➜

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	osantana
Recipients	JelleZijlstra, osantana
Date	2017-05-23.16:29:06
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1495556946.68.0.583378356733.issue30441@psf.upfronthosting.co.za>
In-reply-to

Content
I agree with Jelle about the fix's implementation. But I disagree of suggestion to implement lock at the application side. I disagree because some external libraries may want to access os.environ in a concurrent fashion without lock acquiring. That's the case reported in my previous comment: urllib/requests.py (https://github.com/python/cpython/blob/master/Lib/urllib/request.py#L2468) iterates over os.environ with no lock control. How could I handle this issue in this case? Would it be a good idea implement the lock mechanism in current os._Environ (https://github.com/python/cpython/blob/master/Lib/os.py#L666) mapping class?

I agree with Jelle about the fix's implementation. But I disagree of suggestion to implement lock at the application side.

I disagree because some external libraries may want to access os.environ in a concurrent fashion without lock acquiring. That's the case reported in my previous comment: urllib/requests.py (https://github.com/python/cpython/blob/master/Lib/urllib/request.py#L2468) iterates over os.environ with no lock control.

How could I handle this issue in this case? Would it be a good idea  implement the lock mechanism in current os._Environ (https://github.com/python/cpython/blob/master/Lib/os.py#L666) mapping class?

History
Date	User	Action	Args
2017-05-23 16:29:06	osantana	set	recipients: + osantana, JelleZijlstra
2017-05-23 16:29:06	osantana	set	messageid: <1495556946.68.0.583378356733.issue30441@psf.upfronthosting.co.za>
2017-05-23 16:29:06	osantana	link	issue30441 messages
2017-05-23 16:29:06	osantana	create