[issue17546] Document the circumstances where the locals() dict get updated

2016-12-02 Thread Martin Panter

Martin Panter added the comment:

Some minor tweaks to my earlier patch:
* list comprehension → comprehension
* time it is called → time of the call

--
versions: +Python 3.6, Python 3.7 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file45735/locals_doc.04.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-07-21 Thread Ethan Furman

Changes by Ethan Furman :


--
nosy:  -ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-06-29 Thread Martin Panter

Martin Panter added the comment:

I quickly scanned through the email thread from Issue 17960. I guess it makes 
sense to specify that locals() can be used to directly get a class’s namespace. 
Probably doesn’t hurt to say locals() is equivalent to globals() at module 
level, although this seems like a fairly redundant feature.

Here is locals_doc.03.patch, which uses my wording for function namespaces, and 
also adds more for class and global namespaces, as suggested by Nick.

--
Added file: http://bugs.python.org/file39833/locals_doc.03.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-06-29 Thread Nick Coghlan

Nick Coghlan added the comment:

I mostly like Martin's suggested wording, but would also note that I filed 
issue 17960 to tighten up the requirements for when we expect assigning to 
locals() to work.

To save folks reading the whole referenced email, I think it would be worth 
defining that modifying the namespace returned by locals() will affect the 
runtime namespace at module and class scope and when using exec, but will have 
no effect at function scope (as locals() returns a copy of the namespace in 
that case).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-06-28 Thread Martin Panter

Martin Panter added the comment:

Here is another attempt with different words:

'''
.. note::
   The dictionary returned by :func:`locals` is an accurate snapshot of the 
local namespace at the time it is called.  If the namespace changes after the 
call, the dictionary may become out of date, but it may also automatically 
update at any time.  The contents of the dictionary should not be modified by 
the user; it is undefined whether such changes affect the namespace or not.
'''

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-01-15 Thread R. David Murray

R. David Murray added the comment:

Yeah, the question of thread-safety in regards to what we are talking about 
here also occurred to me.  That is, the wording makes one wonder if locals is 
thread safe or not.  I don't see your suggested wording as making it clearer, 
though.

The problem is that it *is* underspecified.

So I think the correct description of the current under-specification is that 
locals() returns a copy of the current locals namespace.  If you modify the 
thing returned by locals it may or may not update the local namespace.  If you 
modify the local namespace (by doing x = y or its equivalents) the change may 
or may not be reflected in the object that was returned by locals().

Now, how do we boil that down?  Or do we just say it more or less that way?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-01-15 Thread Martin Panter

Martin Panter added the comment:

What about instead of

'''
Whether changes to one are reflected in the other after the call returns is 
undefined; additionally, the dictionary may change unpredictably after the 
call, and how it does is implementation-specific.
'''

substitue this wording:

'''
Whether changes to one are reflected in the other after the call returns, and 
when such updates occur, is undefined and implementation-specific.
'''

The old wording seems under-specified. It would allow a function call, garbage 
collection, etc, to clobber the dictionary, say overwriting with another 
function’s locals(), before you get a chance to work with the dictionary.

--
nosy: +vadmium

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-01-15 Thread R. David Murray

R. David Murray added the comment:

Your formulation is more concise, thank you.

I suggest dropping the word 'additionally'.  Also, "how it does" would be 
better phrased as "how it changes", I think.  (It really should be "whether and 
how it changes", but in deference to Anatoly's 'advanced English' comment I'm 
willing to let that imprecision slide).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2015-01-14 Thread Ethan Furman

Ethan Furman added the comment:

Combined the second and last lines, discarded duplication.

--
nosy: +ethan.furman
versions: +Python 3.5
Added file: http://bugs.python.org/file37711/issue17546.stoneleaf.01.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2013-05-02 Thread Ezio Melotti

Changes by Ezio Melotti :


--
nosy: +ncoghlan
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2013-03-31 Thread Florent Xicluna

Changes by Florent Xicluna :


--
nosy: +flox

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2013-03-30 Thread anatoly techtonik

anatoly techtonik added the comment:

> ... cannot be relied upon to either happen or not happen...

IMHO this phrase is from Advanced English course.

> The original included the caution against modifying it, and I think it is
valid because of the inconsistent behavior.
> Perhaps it could be weakened to "it is not a good idea to modify"?

Ambiguity already adds fear and uncertainty. Just explaining the
consequences would be good style for the technical doc.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17546] Document the circumstances where the locals() dict get updated

2013-03-30 Thread R. David Murray

R. David Murray added the comment:

Hmm.  Perhaps the last sentence could be "... because changes to the local dict 
propagating to the local namespace cannot be relied upon to either happen or 
not happen".  That would make it less redundant, since it would essentially be 
referencing the previous statement in the specific case of the consequences of 
modification.

The original included the caution against modifying it, and I think it is valid 
because of the inconsistent behavior.  Perhaps it could be weakened to "it is 
not a good idea to modify"?

--
title: Document the circumstances where the locals() dict gets  updated -> 
Document the circumstances where the locals() dict get updated

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com