[Python-Dev] Re: decorators and 2.4
jbone at place.org
Tue Jun 29 03:04:13 EDT 2004
On Jun 28, 2004, at 9:05 PM, Phillip J. Eby wrote:
> At 04:29 PM 6/28/04 -0500, Jeff Bone wrote:
>> If you allow conditional evaluation or parameterization of decorators
>> w/o some consideration about their impact on static type analysis ---
>> as in the nightmare scenario I offered previously --- AND if you
>> believe that adding some optional static typing and type analysis to
>> Python in the future is at least possibly desirable, then it leads
>> one to consider whether additional constraints *might* be in order.
> No, it doesn't.
Yes, it does --- as the examples offered indicate.
> You can already make weird decorators that disassemble the bytecode of
> the function and create a new function object, for example. PEP 318
> does nothing to change that fact.
True, but irrelevant unless you happen to be strategically myopic and
slightly programming-language illiterate. Tell me, Phil --- what is
your damage here? I believe we both want the same outcome. So why are
you getting so aggressive (or defensive, I can't tell which) about the
route to the particular, and shared, outcome? As surely as I'm
convinced about the need for and worthiness of certain considerations
about static type-checking and the future of this language, I'm willing
to grant that you're equally concerned about something else, even
though I don't yet know what. Why can't we have the discussion on that
factual basis instead of bogus third-hand references to the
questionable intent (though somewhat clear, but still questionable
relative to desiderata) of a spec you didn't write?
The only legit explanation I can think of is that *you know how to
implement the PEP as you understand it now, but fail to understand the
longer-term implications of said interpretation of PEP /
implementation." Take the time to connect w/ me or others on these
concerns; I think you will find them not entirely out of sync. I may
not have posted here much over the years, but I'm sure both I and
countless others have put in the time to get the hearing for our
concerns w/o being swatted down w/ an inconclusive spec like and
ignorant school-marm swatting an overly-inquisitive 2nd-grader.
> Thus, attempting to define restrictions for them is moot,
No, it's not -- as demonstrated previously.
> as far as anybody attempting to create program analysis tools -- they
> already have to deal with this dynamism today, and restricting PEP 318
> simply won't help.
What a completely BS response.
Yet --- true, but only if one accepts a particular and rather
simple-minded and overly-literal interpretation of the ***GOALS*** of
PEP 318, driven by hackers that are inclined to hack certain changes
into THE (and that in itself is an indictment) implementation of the
language --- changes that that are very lightly implied by the PEP into
the interpreter, rather than considering the longer-term goals and
objectives of both the PEP and the language. And THAT IS MY POINT.
More information about the Python-Dev