<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">вс, 19 авг. 2018 г. в 17:51, Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Aug 20, 2018 at 12:43 AM, Kirill Balunov<br>
<<a href="mailto:kirillbalunov@gmail.com" target="_blank">kirillbalunov@gmail.com</a>> wrote:<br>
><br>[...]<br>
> I have the same feeling and already have asked the same question before<br>
> <a href="https://mail.python.org/pipermail/python-list/2018-February/731241.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/python-list/2018-February/731241.html</a>. The<br>
> main take away was that it is the CPython implementation detail and that<br>
> `MappingProxy` type was introduced only in 3.3. I still do not find these<br>
> arguments convincing. On the other hand with the current status quo -<br>
> `locals` returns `dict` inside a function, we have only advantages:<br>
><br>
> a) `locals` always returns a dict and is consistent in all places. (To be<br>
> consistent is always good.)<br>
><br>
> b) This type of question occurs every 6 months (there is always a topic to<br>
> talk about at ML).<br>
><br>
> c) When someone encounters this behavior first time, he thinks that he found<br>
> a bug <- There was no error but nothing happened (gives an opportunity to<br>
> study the internal details of the CPython implementation, the average level<br>
> increases. Everyone also tries to find a way, something like "I believe,<br>
> there must be a way, because Python is so dynamic" which theoretically<br>
> allows you to make even more new discoveries.).<br>
><br>
> d) This is considered by some as a way not to leak the CPython<br>
> implementation details. (Here I have no comments, let it be on the<br>
> conscience of others.)<br>
><br>
> e) It leaves a room for a future changes (In fact, in some situations I<br>
> would like to have this possibility).<br>
<br>
Related to (e) is that there is room for other implementations to<br>
permit changes to locals(), and furthermore, a fully-compliant Python<br>
implementation may use an actual dictionary for locals, and simply<br>
return that. (That CPython doesn't is an implementation detail for the<br>
sake of performance.) Requiring that it be a proxy would impose<br>
unnecessary cost on the implementation, without benefiting any<br>
compliant use.<br>
<br>
ChrisA<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a></blockquote><div><br></div><div>Let me disagree with you. While CPython is only one of the implementations of the Python language, it is the most common one and defacto is considered as a standard. Therefore, all the others, to be compliant, try to replicate all subtleties and features of the basic implementation - CPython. And even more so, I do not believe that anyone will rely or use such a feature.</div><div><br></div><div>I'm not saying that this change should be a part of the Python language specification. I just said that this is already implied by the implementation of CPython3 and if you make it more clear with `MappingProxy` type it will be a net win in my eyes.</div><div><br></div><div>With kind regards,</div><div>-gdg</div></div></div>