A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-April/044257.html below:

[Python-Dev] PEP 318 - check for consensus

[Python-Dev] PEP 318 - check for consensusFred L. Drake, Jr. fdrake at acm.org
Wed Apr 14 14:00:05 EDT 2004
On Wednesday 14 April 2004 12:46 pm, Phillip J. Eby wrote:
 > Actually, those are not the obvious keywords.  The function's name is an
 > attribute of the function, so it's redundant.  For that matter, a
 > function's globals are available as 'func_globals'.  It's the enclosing
 > *local* scope that the function was defined in that's needed.  For a
 > function defined at module level, the globals and locals are the same, but
 > for functions defined in a class body, you need the class locals.  So,
 > 'locals' would be a more obvious keyword.

Locals would certainly be nice to have.  What should be done about the case 
of:

    def func():
        [decorator]
        def f(): pass
        return f

I think the decorator would want some way of determining that the locals can't 
be modified so an appropriate error can be raised, if it's interested in 
modifying the namespace directly.  This could be done by returning a dict 
proxy that denies writes; we have one of those already.

I don't know that there are many examples where we want write access to the 
locals in practice; the most interesting case for me is the set of property 
decorators that have been discussed, and read access is sufficient for those.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4