[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