[Python-ideas] PEP 3155 - Qualified name for classes and functions

Ron Adam ron3200 at gmail.com
Sat Nov 5 19:01:58 CET 2011


On Sat, 2011-11-05 at 11:04 -0600, Eric Snow wrote:
> On Sat, Nov 5, 2011 at 10:32 AM, Éric Araujo <merwok at netwok.org> wrote:
> > Hi,
> >
> >> I would like to propose the following PEP for discussion and, if
> >> possible, acceptance. I think the proposal shouldn't be too
> >> controversial (I find it quite simple and straightforward myself :-)).
> >> [snip PEP]
> >
> > +1.
> >
> > For nested functions, I too think that 'f.<locals>.g' has too many dots;
> > I like '<local in f>.g' or '<f locals>.g'.
> 
> I like it too but don't think it's too many dots.
> 
> The function from which the locals came _could_ be rolled into the
> brackets.  However, in the context of some object (like the class X to
> which f belongs), 'X.f.<locals of f>.g' makes more sense in that case
> than 'X.<locals of f>.g', since the locals is related to f and not X.
> But, then the f is sort of redundant, so you go back to
> 'X.f.<locals>.g', and '<locals>' is still sort of unambiguous.
> 
> The disconnect is that <locals> is an externally anonymous namespace
> resulting from a call, rather than bound to any external namespace
> (like an object).  Perhaps it would be appropriate to use
> 'X.f().<locals>.g' to make that clear.

I think if you consider locals in f as an implementation detail of f's
name space rather than a sub item of f, it's not as confusing.  It's
better to think of locals as being part of f, rather than in f.  That is
why <f locals> makes more sense than f.<locals>.  For example locals is
in f's frame object, so if you follow that reasoning you get.
f.<frame>.<locals>,  but I don't think we need all that.

Hmmm...  I think it actually should be spelled...

      f.<local g>

Following a pattern of...

      x                 object x
      x.f               f in object x
      x.f.<local g>     local g in f in x

That's both clear and concise.

Cheers,
   Ron

















More information about the Python-ideas mailing list