<p dir="ltr"><br>
On 9 May 2013 21:53, "Piotr Duda" <<a href="mailto:duda.piotr@gmail.com">duda.piotr@gmail.com</a>> wrote:<br>
><br>
> 2013/5/9 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>>:<br>
> > On 9 May 2013 11:29, Piotr Duda <<a href="mailto:duda.piotr@gmail.com">duda.piotr@gmail.com</a>> wrote:<br>
> >><br>
> >><br>
> >> To solve these problems I propose to add simple syntax that assigns<br>
> >> these attributes to arbitrary object:<br>
> >> def name = expression<br>
> >> other possible forms may be:<br>
> >> def name from expression<br>
> >> class name = expression<br>
> >> class name from expression<br>
> >> name := expression # new operator</p>
<p dir="ltr">One more possible colour for the bikeshed:</p>
<p dir="ltr">name def= expression</p>
<p dir="ltr">> >><br>
> >><br>
> >> which would be equivalent for:<br>
> >> _tmp = expression<br>
> >> _tmp.__name__ = 'name'<br>
> >> _tmp.__qualname__ = ... # corresponding qualname<br>
> >> _tmp.__module__ = __name__<br>
> >> # apply decorators if present<br>
> >> name = _tmp<br>
> ><br>
> ><br>
> > Just for clarification, if you used this syntax with an expression which<br>
> > returned an object which *didn't* allow attributes to be set, I assume it<br>
> > would simply fail at runtime with an AttributeError? For example,<br>
> ><br>
> > def x = 12<br>
><br>
> Yes, it fails, I thought about ignoring exceptions on attribute<br>
> assignment, but then the syntax wouldn't provide any guarantees and in<br>
> those cases it will be equivalent of simple assignment.<br>
><br>
> ><br>
> > This isn't a point against the syntax, I just think it's worth being<br>
> > explicit that this is what would happen.<br>
> ><br>
> > Overall, I'm somewhat indifferent. The use case seems fairly specialised to<br>
> > me, and yet the syntax "def name = value" seems like it's worth reserving<br>
> > for something a bit more generally useful.<br>
> ><br>
> > Maybe the def name=value syntax should implement a protocol, that objects<br>
> > like enum and namedtuple subclasses can hook into (in the same way that the<br>
> > context manager and iterator protocols work, or indeed the whole class<br>
> > definition mechanism).<br>
><br>
> This may be good idea.</p>
<p dir="ltr">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.</p>

<p dir="ltr">Directly setting __module__, __name__ and __qualname__ may be a reasonable default behaviour.</p>
<p dir="ltr">The new syntax is essentially competing with the current implicit-but-fragile stack introspection and the explicit-but-cumbersome passing of the target name.</p>
<p dir="ltr">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).</p>
<p dir="ltr">Cheers,<br>
Nick.<br>
><br>
><br>
> --<br>
> $B0G$K1#$l$?9u$$NO(B<br>
> $B<e$$?4$rA`$k(B<br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-ideas">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</p>