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. jb CTO, Deepfile