On Fri, Oct 5, 2012 at 5:29 PM, Devin Jeanpierre <jeanpierr...@gmail.com> wrote: > On Wed, Oct 3, 2012 at 11:34 AM, Steven D'Aprano <st...@pearwood.info> wrote: >> I find myself unable to choose between 2) and 4), which suggests that >> the status quo wins and we keep the current behaviour. > > What is the benefit of having a dict that represents a namespace, but > whose mutations don't mutate said namespace? Compare with option 2, > where the dict is mutable, and whose mutations mutate the namespace it > represents. That behavior is altogether significantly less surprising. > > I've never understood why locals() returned a mutable dictionary > either, except that Python has no immutable dictionary type.
There's no benefit, it's just a historical artefact imposed by backwards compatibility constraints. We should have taken the opportunity to fix it in Python 3.0 (just as we dropped support for "from x import *" at function scope) but I don't believe anyone suggested it at the time. The problem is that, while updating it to return types.MappingProxyType instead would produce more obvious error messages for those that don't know you can't use it to update local variables inside a function (even though it works at module and class scopes), such a change would *break* existing code which knows the dictionary doesn't get written back, and just uses it for its own purposes (e.g passing it to exec). As for *why* changes don't get written back, it's because the compiler is allowed to assume it knows about every variable name that exists in the local scope (by design), and that doesn't fit with writable locals() for functions. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
