On 6/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > So the constant would be evaluated at function definition time? I find
> > that rather confusing.
>
> 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.
> >> (except for the default argument thing; see above). the result is a
> >> kind of semi-constant objects that would be useful, but perhaps not
> >> constant enough...)
> >
> > I fail to see the usefulness of this wrapper. The wrapper isn't
> > completely transparent o some code that uses type checks may need to
> > be modified. The wrapper doesn't get removed by a simple assignment;
> > after
> >
> > const a = 1
> > b = a
> >
> > how do we prevent b from being treated as a constant?
>
> we cannot -- this approaches assigns (a small amount of) const-ness to
> objects, not names.
OK, so neither a nor b is really a constant; it's just that they have
a value that is a constant wrapper.
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.)
> >> it might be too much C# exposure, but I think I prefer the "explicit
> >> when using" approach...
> >
> > It may be not enough C# exposure, but I don't know exactly which
> > approach you are referring to.
>
> the original one: if you want to treat an expression as a constant, you
> have to be explicit. examples:
>
> >>> a "constant" (or perhaps better, "const") primary would also be useful
> >>> in several other cases, including:
> >>>
> >>> - as a replacement for default-argument object binding
>
> this is used when you want to pass an *object* into an inner function,
> rather than a name:
>
> def foo(value, bar=fie.fum):
> if value == bar:
> ...
>
> can be written
>
> def foo(value):
> if value == const bar:
> ...
>
> >>> - 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 = {...}
But I don't see how this would require the const-wrapper.
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.
> >>> - explicit (but still anonymous) constant/expression "folding"
>
> def foo(value):
> if value < const (math.pi / 2):
> ...
>
> and so on. to implement this, the runtime simply evaluates the "const"
> expressions together with the default value expressions, and assigns the
> result to some func_xxx attribute. everything else works as usual.
Yup, got it. This is clearly implementable and has clear semantics.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
