2018-02-27 2:57 GMT+03:00 Terry Reedy <tjre...@udel.edu>: > The point of point 3 is that terminology and details would likely be > different if Python were freshly designed more or less as it is today, and > some things only make more or less sense in historical context. Learn what > you need to know to write code that works. >
Thank you, I'm fairly familiar with the scope and namespace concepts in Python 3, and they are also very well described in the "Execution model" https://docs.python.org/3/reference/executionmodel.html#execution-model, for this special thanks to the person who wrote it ;-) I started using Python with СPython 3.5 and I'm not familiar with the Python 2 features. But since Python 2 got into our discussion, I still have a question: a. Is this restriction for locals desirable in the implementation of CPython in Python 3? b. Or is it the result of temporary fixes for Python 2? Personally, I find the convenient functionality to update the local symbol table inside a function, similar to `globals`. Of course, I do not have the full picture and the difficulties with the flaws in implementing such functionality in CPython3. On the other hand, I understand that this additional dynamism as a whole may not be beneficial, and that local and global variables are determined at function compilation time. At this point, I only know one way to achieve this: `exec ('% s =% s'% (var_name, var_val))`, which I find clumsy enough. Funny, contradictory thoughts in my head :) Calling surrounding function local names collectively 'nonlocals' is the > result of months of bikeshedding. > Yes `nonlocals` is a cool fix in Python3. 2018-02-27 3:25 GMT+03:00 Steven D'Aprano <steve+comp.lang.python@pearwo od.info>: > Mostly because locals() predates MappingProxyType by many years, and also > because that restriction doesn't apply to other implementations of Python > such as Jython and IronPython. > > In CPython, the dict returned by locals() is a copy of the local > namespace, so modifying the dict doesn't modify the real local variables. > > (Well, sometimes it does, but not always. The story in Python 2 is really > complex.) Yes, I understand all the more the documentation specifies *New in version 3.3: class.MappingProxyType.* I'm not saying that this should be a standard for the Python language, especially in the context of what I wrote above. But the Python documentation already contains links to the features of the CPython implementation, (`id` for example). If the answer to the previous question is "Yes, such a restriction is desirable in CPython because, because, because ... and thereafter it is not planned to be changed." Then I do not see why it can not be made more explicit by changing `dict` to` types.MappingProxyType`. With the following change in the documentation: "Note The contents of this dictionary should be perceived as read-only mapping and should not be modified; The returned mapping type is implementation-dependent: changes may not affect the values of local variables used by the interpreter or the returned object may not support item assignment. CPython implementation detail: The returned object is `types.MappingProxyType` a read-only proxy of the current local symbol table." p.s.: Steven, this question was somewhat inspired by yours "Is there are good DRY fix for this painful design pattern?" With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
