On Thu, Jul 28, 2011 at 12:21 PM, Guido van Rossum <guido@python.org> wrote:
I wish I could write
red = Enum(1)
and it made the following true:
assert red == 1 assert isinstance(red, int) # a subclass assert str(red) == 'red'
But we'd first need a non-hacky way for Enum() to know that it is being assigned to something named 'red'. I have a few other use cases for that as well, e.g. a Property class for App Engine that doesn't require a metaclass to patch up the value.
Yeah, a similar discussion came up in the context of defining namedtuple instances a while back (I don't recall if you were part of that conversation or not - IIRC, the thread started off on the topic of assignment decorators and ended up wandering down this road at some point) Most proposed solutions relied on some form of abuse of the def statement to define arbitrary objects that knew their own name. For example: def red from namedvalue(1) # Rather unnatural phrasing def red as namedvalue(1) # Phrasing is natural, but the name is on the wrong side of the 'as' def red = namedvalue(1) # Simple assignment may not suggest enough magic def as red = namedvalue(1) # Syntax soup! as red def namedvalue(1) # Just throw keywords at the screen and see if anything sticks red def= namedvalue(1) # An alternative inspired by augmented assignment def red << namedvalue(1) # Arbitrary but suggestive A protocol would then be defined to make that work (regardless of the specific syntax). Either the actual call would be transformed into "namedvalue('red', 1)" (which has the virtue of working with existing objects like collections.namedtuple, but prevents provision of useful default behaviour) or else there would be a new protocol like "obj.__named__(name)", with a fallback to something like the NamedValue recipe if __named__ wasn't defined (which has the virtue of working with arbitrary objects as in "def red as 1", but requires adapter classes to work with existing APIs like namedtuple). The bikeshed was painted many different colours before the thread finally wound down without achieving any kind of resolution. I suspect this may end up being another PEP 308, where the only way it will ever happen is if *you* find a syntax you like (or are at least willing to tolerate in order to gain the functionality). Adding an int-specific Enum class eliminates a lot of the use cases for a "named object" feature, which is the main reason I'm trying to hold out for the more general functionality - I still have hope that we'll strike on a syntax for named assignments that is clear enough and clean enough that none of the core devs actively oppose it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia