On Fri, Jul 29, 2011 at 2:40 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
ISTM a NamedValue could be either a copy of the original value or a wrapper around the original. Examples of the former include Nick's recipe and Barry's flufl.enum asint branch. Examples of the latter include the flufl.enum trunk.
The copy version requires making the copy, which is less convenient if the value's type needs more than the instance to make a copy. The wrapper version probably wouldn't work well as a drop-in replacement for the original value.
A weakref.proxy style API can actually be a fairly effective dropin replacement for a type. However, it's a high overhead and quite complicated solution.
So if a NamedValue were to make it into the stdlib, which would it be?
Arguments can be made in both directions. The main benefit of inheritance is that things behave correctly by default, and the only behavioural differences are those we add. Proxying can definitely work, but it's actually hard to do such that special method invocations work properly without giving false positives on hasattr() and ABC isinstance() checks.
Does NamedValue add much value if not coupled with grouping?
Yeah, it provides the oft-cited debugging benefits of having the name of the value appearing in the representation. That's invaluable for cases where you don't actually control the display operation (e.g logging messages in library code). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia