On 05/13/2013 10:01 PM, Glenn Linderman wrote: > On 5/13/2013 7:36 PM, Ethan Furman wrote: >> On 05/10/2013 10:15 PM, Glenn Linderman wrote: >>> >>> So it is quite possible to marry the two, as Ethan helped me figure out using an earlier NamedInt class: >>> >>> class NIE( IntET, Enum ): >>> x = ('NIE.x', 1) >>> y = ('NIE.y', 2) >>> z = ('NIE.z', 4) >>> >>> and then expressions involving members of NIE (and even associated integers) will be tracked... see demo1.py. >>> >>> But the last few lines of demo1 demonstrate that NIE doesn't like, somehow, remember that its values, deep down under >>> the covers, are really int. And doesn't even like them when they are wrapped into IntET objects. This may or may not >>> be a bug in the current Enum implementation. >> >> [demo1.py excerpt] >> print( repr( NIE1( 1 ) + NIE1(2))) >> print( repr( NIE1( IntET('NIE1.x', 1 )) + NIE1(2))) >> >> >>> So the questions are: >>> 1) Is there a bug in ref435 Enum that makes demo1 report errors instead of those lines working? >> >> Nope. > > Well, if it isn't a bug, it will be interesting to read the documentation that explains the behavior, when the > documentation is written: > > The "obvious" documentation would be that Enum names values of any type, particularly the first type in the > multiple-inheritance list. The values assigned to the enumeration members are used as parameters to the constructor of > that first type, but the value of the enumeration member itself is an item of the type, created by the constructor. > > The __call__ syntax [ EnumDerivation( value ) ] looks up enumeration members by value. > > The obvious documentation would stop there. > > The one piece of "marriage" that is interesting is to avoid specifying the name twice, and it seems your code > > I'd expect NIE1.x.value to be IntET('x', 1) but I'll have to look more carefully at what you've done, when I have > some time next week. You may have made some "simplifying assumptions", and things _should_ be as simple as possible, but > no simpler... especially not if it leads to unexpected results. > > This will take more thought than I have time for tonight, also. Right now, I think I want the value for NIE.x to be > IntET('NIE.x', 1 ). And your code isn't achieving that at present, but maybe I just need to tweak __new__ and then > can... and maybe it cures the discrepancy in expectations mentioned earlier too... Thank you for being persistent. You are correct, the value should be an IntET (at least, with a custom __new__ ;). I'll look into it. -- ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4