On Sun, Aug 19, 2018 at 06:18:56PM +0300, Kirill Balunov wrote: [...] > > > e) It leaves a room for a future changes (In fact, in some situations I > > > would like to have this possibility).
[Chris] > > Related to (e) is that there is room for other implementations to > > permit changes to locals(), and furthermore, a fully-compliant Python > > implementation may use an actual dictionary for locals, and simply > > return that. (That CPython doesn't is an implementation detail for the > > sake of performance.) Requiring that it be a proxy would impose > > unnecessary cost on the implementation, without benefiting any > > compliant use. I would like to see CPython locals() return a mapping object which raises a warning when you mutate it. * Currently, assignments to locals() simply do the wrong thing (modify the dict but fail to modify the local namespace) silently; such errors should never pass silently. * It should be a warning, not an error, since there are use-cases for modifying the local dict without caring about the namespace; in those cases we can simply silence the warning or ignore it. * Introducing a warning makes it clear that this is not a de facto language standard, but a mere implementation detail subject to change if somebody comes up with a better optimization for locals. - Other implementations should be permitted to use local namespaces which are read/write (that's a Quality Of Implementation issue). - Given that uses of locals() inside a function are already restricted and presumably uncommon, the extra cost of a warning is unlikely to be meaningful. [Kirill] > 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. Not in this case. If CPython intended this to be the language behaviour, it should specify that limitation instead of merely giving a doc warning that changes "may not" affect the local variables. In fact, the warning in the docs is too strong. Modifying locals() inside a class or module scope is allowed, and works fine. It is only functions which is problematic. > Therefore, all the others, to be compliant, try to replicate > all subtleties and features of the basic implementation - CPython. Implementations are expected to obey the documented behaviour (unless given special dispensation to break the rules, which I think has happened once or twice with MicroPython). For behaviour which isn't dpcumented, it is true that implementations *often* try to copy CPython, but that's not mandatory and there are exceptions. PyPy is probably the alternate implementation which tries the hardest to duplicate CPython, but even PyPy has differences: http://doc.pypy.org/en/latest/cpython_differences.html including a few things which the PyPy developers believe is a bug in CPython. This list of differences between Jython and CPython is terribly out of date, but I haven't found anything more recent: http://www.jython.org/archive/21/docs/differences.html > And even > more so, I do not believe that anyone will rely or use such a feature. Users of CPython frequently rely on CPython implementation details. Why do you think Jython and IronPython users will be different? -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
