Guido van Rossum wrote:
>> well, I find the proposed magic behaviour of "case" at least as confusing...
>
> It's not magic if it can be explained. "def goes over all the cases
> and evaluates them in the surrounding scope and freezes the meaning of
> the cases that way as long as the function object survives" is not
> magic.
well, people find "def goes over all default values and evaluates them
in the surrounding scope (etc)" pretty confusing, and the default values
are all part of the function header. here you're doing the same thing
for some expressions *inside* the function body, but not all. it might
be easy to explain, but I don't think it's easy to internalize.
> I'm still confused how this wrapper would be used at run time.
> (Because at compile time we *don't* generally know whether a
> particular value contains a const wrapper or not.)
oh, it would require the compiler to check for const-ness on globals
when the function object is created, which would work for simple names,
and require some yet-to-be-determined-handwaving-hackery for anything
else...
>>>>> - local dispatch tables, and other generated-but-static data structures
>> def foo(value):
>> table = const {
>> 1: "one",
>> 2: "two",
>> 3: fie.fum,
>> }
>>
>> (maybe "static" would be a better keyword?)
>
> At least it resembles the corresponding C keyword better than 'const'.
>
> 'static' tells me something useful (at least if I know C/C++/Java).
>
> And I have some idea on how to implement it (not so different from the
> def-time switch freezing).
>
> However it should be
>
> static table = {...}
I'm not sure it should, actually -- the primary form is more flexible,
and it better matches how things work: it's the expression that's
special, not the variable.
and things like
radian = degree * static (math.pi / 180)
would be pretty nice, for those of us who likes our Python fast.
> But I don't see how this would require the const-wrapper.
it wouldn't.
> And I still think that this is not as nice as def-time freezing
> switches; static or const causes clumsy syntax when importing
> constants from another module since you have to repeat the const-ness
> for each imported constant in each importing module.
well, the point is that you only have to spell it out if you actually
care about things being constant/static/evaluated once/early, and when
you do, it's always obvious for the reader what you're doing.
</F>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
