[Python-ideas] Syntax for easy binding __name__, __module__, __qualname__ to arbitrary objects
MRAB
python at mrabarnett.plus.com
Thu May 9 16:57:58 CEST 2013
On 09/05/2013 15:08, Nick Coghlan wrote:
>
> On 9 May 2013 21:53, "Piotr Duda" <duda.piotr at gmail.com
> <mailto:duda.piotr at gmail.com>> wrote:
> >
> > 2013/5/9 Paul Moore <p.f.moore at gmail.com <mailto:p.f.moore at gmail.com>>:
> > > On 9 May 2013 11:29, Piotr Duda <duda.piotr at gmail.com
> <mailto:duda.piotr at gmail.com>> wrote:
> > >>
> > >>
> > >> To solve these problems I propose to add simple syntax that assigns
> > >> these attributes to arbitrary object:
> > >> def name = expression
> > >> other possible forms may be:
> > >> def name from expression
> > >> class name = expression
> > >> class name from expression
> > >> name := expression # new operator
>
> One more possible colour for the bikeshed:
>
> name def= expression
>
Considering that attributes of 'name' are also being set, how about:
name .= expression
> > >>
> > >>
> > >> which would be equivalent for:
> > >> _tmp = expression
> > >> _tmp.__name__ = 'name'
> > >> _tmp.__qualname__ = ... # corresponding qualname
> > >> _tmp.__module__ = __name__
> > >> # apply decorators if present
> > >> name = _tmp
> > >
> > >
> > > Just for clarification, if you used this syntax with an expression
> > > which returned an object which *didn't* allow attributes to be set,
> > > I assume it would simply fail at runtime with an AttributeError? For
> > > example,
> > >
> > > def x = 12
> >
> > Yes, it fails, I thought about ignoring exceptions on attribute
> > assignment, but then the syntax wouldn't provide any guarantees and in
> > those cases it will be equivalent of simple assignment.
> >
> > >
> > > This isn't a point against the syntax, I just think it's worth being
> > > explicit that this is what would happen.
> > >
> > > Overall, I'm somewhat indifferent. The use case seems fairly
> > > specialised to me, and yet the syntax "def name = value" seems like
> > > it's worth reserving for something a bit more generally useful.
> > >
> > > Maybe the def name=value syntax should implement a protocol, that
> > > objects like enum and namedtuple subclasses can hook into (in the same
> > > way that the context manager and iterator protocols work, or indeed the
> > > whole class definition mechanism).
> >
> > This may be good idea.
>
> An intriguing idea, indeed. I can't promise I'll approve of the end
> result, but I think a PEP proposing a name binding protocol that passes
> in the module name, the "location" within the module (when inside a
> function or class) and the target name could be worth reading.
>
> Directly setting __module__, __name__ and __qualname__ may be a
> reasonable default behaviour.
>
> The new syntax is essentially competing with the current
> implicit-but-fragile stack introspection and the explicit-but-cumbersome
> passing of the target name.
>
> Even if the ultimate verdict ends being "not worth the hassle", we would
> at least have a common reference point when this discussion next comes
> up (it seems to be every couple of years or so).
>
More information about the Python-ideas
mailing list