At 01:16 PM 6/21/2006 -0700, Guido van Rossum wrote:
>On 6/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > >But that's not the discerning rule in my mind; the rule is, how to
> > >define "at function definition time".
> >
> > Waaaaa! (i.e., my head hurts again :)
>
>Um, wasn't this your proposal (to freeze the case expressions at
>function definition time)?
Actually, I proposed that either that *or* first use could work, and in
subsequent discussion I sided with first use.
Greg didn't quote the rest of my original post or any of the subsequent
discussion in the post you picked up on, so that probably gave you the
impression I was still in favor of function definition time, when I had
already begun leaning towards "first use" as easier to define.
>Yeah, but if you have names for your constants it would be a shame if
>you couldn't use them because they happen to be defined in the same
>scope.
Maybe the real answer is to have a "const" declaration, not necessarily the
way that Fredrik suggested, but a way to pre-declare constants e.g.:
const FOO = 27
And then require case expressions to be either literals or constants. The
constants need not be computable at compile time, just runtime. If a
constant is defined using a foldable expression (e.g. FOO = 27 + 43), then
the compiler can always optimize it down to a code level
constant. Otherwise, it can just put constants into cells that the
functions use as part of their closure. (For that matter, the switch
statement jump tables, if any, can be put in a cell too.)
>I don't like "first use" because it seems to invite tricks.
Okay, then I think we need a way to declare a global as being constant. It
seems like all the big problems with switch/case basically amount to us
trying to wiggle around the need to explicitly declare constants.
_______________________________________________
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
