On 09/05/2013 15:08, Nick Coghlan wrote:
On 9 May 2013 21:53, "Piotr Duda" <duda.piotr@gmail.com <mailto:duda.piotr@gmail.com>> wrote:
2013/5/9 Paul Moore <p.f.moore@gmail.com <mailto:p.f.moore@gmail.com>>:
On 9 May 2013 11:29, Piotr Duda <duda.piotr@gmail.com
<mailto:duda.piotr@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).