[Python-ideas] Enums

[Spectral One]

> Subject:
> Re: [Python-ideas] Enums
> From:
> Greg Ewing <greg.ewing at canterbury.ac.nz>
> Date:
> 8/19/2011 7:31 PM
>
> To:
> python-ideas at python.org
>
>
> Spectral One wrote:
>
>> def Box:
>>     def SetMake( new_make:enum(pcmake)=ibm ):
> >
>> b.SetMake(apple) #Works fine
>
> How do you propose to implement this?
>
> Currently, function arguments are evaluated without any
> knowledge of the function to which they are going to be
> passed. To what extent would you change that, and how?
>
> -- 
> Greg

Hmm, is setting a flag to switch twixt normal and another namespace 
really all that tricky?

It would probably help to know how Python handles namespaces already, 
but I don't. In fact, I don't know Python well enough to do much more 
than speculate on how it's implemented. I was just figuring that the 
syntax and API are the harder parts to do well, anyhow, so I suggested 
in that mode.

That NO evaluation is done before entry is a bit of a surprise. 
Obviously, the number of arguments is stored and checked, since 
TypeError is raised on argument number mismatches.


There are obviously various ways to accomplish this, but the idea was, I 
confess, unconstrained by implementation details I don't know. Some 
possibilities that pop to mind:

Such things could be held in a list, much like object properties or 
classes, which is available to be interrogated by the parser. When 
checking the argument list, it could also check lists for associated enums.

If functions are complete objects, you could embed the information in 
the object for each specified argument in some standard way. 
'function.__enums__()' maybe

It seems that the function, on call, would need to know to check these 
things or not, but that's something that could be handled behind the 
scenes with a block to test that's simply conditionally skipped or added 
as needed. That would still require that the values be processed 
differently while being interpreted, unless some global rule was 
instituted to get around it. (Late-parsing arguments might work, or 
making sure that the names of variables are passed as strings to the 
function, so the function can ignore incorrectly-parsed identifiers. Of 
course THAT would require a tone more processing, or would preclude 
multiple values, so I really don't like it.)

Actually, if our hearts aren't set on passing the enum names as 
identifiers, we could pass them as strings that are parsed on the other 
side. (rules for combining them would be part of the standard enum 
object definition.) This wouldn't look as neat to me, but it would move 
the namespace issue completely inside the recipient function. A function 
could fake it or actually use the the enum functions based on string 
parsing.
def Box:
     def SetMake( new_make=enum(pcmake)["ibm"] )
...
b.SetMake("apple")

Beyond that, it's mostly just a matter of determining proper behavior 
for an enum object type and the events it should raise, etc. (An 
extended dictionary class which stashes {key:(key,value)} could work as 
a basis.)

-Nate