So here's the state of play with decorators and 2.4.
Guido is undecided on the syntax - he writes "I'm seriously
considering doing it Java-style", but adds that he is totally
swamped for the next two weeks. He finishes with:
"Feel free to suggest this as a project for an adventurous
python-dev'er though."
So, who's feeling adventurous? I'm convinced that this should go
into 2.4 if possible, and I don't think there's any _technical_
risks (as far as implementation goes), the only problem is the
syntax (and yes, that's a technical problem too, but you know
what I mean).
Channelling Guido, via his EP keynote
(http://www.python.org/doc/essays/ppt/euro2004/euro2004.ppt)
I'm assuming that "Java-style" is something like:
@staticmethod
def blah(args):
body
@funcattrs(vegetable="blah", author="GvR")
def blah2(args):
body
It's not clear to me how you'd specify multiple decorators this
way, perhaps Guido can give more details...
So, let the floodgates open. Remember, we _can_ change this any
time up until 2.4b1, if there's a decision that the chosen form
sucks. :-)
--
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
While reading through the "Extending/Embedding Python" tutorial (no
snickering; I need to implement a type from scratch for my thesis and I
figured I might as well read the tutorial for once), I noticed a mention
of Demo/embed/demo.c . Having heard the comments about how outdated the
Demo directory was(I think the last thread was by AMK), I decided to
poke around.
Some of it is fairly old. The README, for instance, mentions a Contrib
directory for stuff. And the classes/Date.py file mentions the creation
of a generator... using __getitem__ (took me a second to realize that I
was not going nuts in not noticing a 'yield' statement).
Maintenance of the directory has come up before and has seems to die
every time (which I don't blame anyone for; I myself never stepped
forward to help). But if it is going just site there, perhaps we should
consider getting rid of it? Cool snippets of code can be grabbed from
all over the Net (take the Cookbook, for instance), and so having it
with the code is not as important as I am sure it was when the directory
was created.
Or at least we could prune it down. I can see usage from
Demo/newmetaclasses/ since metaclasses can be hard to grasp without
example code. But couldn't we remove the Demo/metaclasses/ directory
for instance?
I am partially doing this so as to see if people care enough to bother
putting an announcement in the python-dev Summary (maybe even
python-announce) to try to get the community as a whole to help update
the files. Maybe everyone on this list could adopt one module and bring
it up to date or something. Just seems like something should happen
with it, and if it is just going to sit we could at least prune it.
-Brett
> Neil Hodgson:
> I think it is unlikely that such a large patch and resulting C++
> compatibility policy will be accepted.
> Paul Svensson:
>
> The Pythin sorces are written in C; that they fail to compile
> when usung a compiler for a different language is a feature, not a bug.
>
of course :-)
however, most of the changes are good coding practice in any case.
the rest are outright inconsistencies in the python source
and ought to be fixed -
for instance, the macros 'PyMODINIT_FUNC' and 'staticforward'
are *not* used with consistency
in all, the patch is merely one-liner style changes, and
nothing more. The patch is not large.
on a philosophical note, one could have said that the Python
sources were POSIX, and: "the fact that they fail to compile
when using a different OS is a feature not a bug."
yet today Python compiles on a wide range of OS's
-paul
Armin Rigo writes:
> I am pretty sure that some extension modules would badly
> crash if arbitrary
> Python code would be allowed to temper with the data that
> they store there.
We're all consenting adults here. Tampering with the private
data of an extension module is a well-known way to crash
Python.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
On Tuesday 29 June 2004 09:52 am, akuchling(a)users.sourceforge.net wrote:
> [Bug #948970] Add PyExc_* symbols to index.
> (I ran this through texcheck, but don't have LaTeX installed on this
> machine and therefore haven't verified that the changes are accepted by
> LaTeX.)
Thanks; this works just fine.
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
> Sorry, yes, you're correct. I apologize to Phil and the list. It's
> just rather frustrating to get beat all to hell (and told
> patronizingly
> to "read" a freakin' PEP I've read, repeatedly, before even speaking
> up) for no apparent reason just for raising what IMHO are rather
> legitimate concerns.
>
> My bad, I'll go back to lurk and if this particular feature turns out
> to be the giant hairball it appears to be I won't say anything.
Hey... don't be afraid to speak up -- it's a good idea to challenge
ideas around here. It's just that in this case most of the people
who are speaking up don't seem to be swayed by your points. But
that doesn't mean it isn't useful. For example, when Gareth said
that you were trying to "define [declarative] at a rather high level
of abstraction", I finally began to understand (I hope) what you
were trying to convey with the term. Interesting... I had always
thought of "declarative" and "imperative" as having a very clear
boundary, but in fact, they can be looked at from a "higher level".
So if nothing else, you've educated me a bit. It's just that you
haven't convinced me that restricting decorators is wise, and once
folks (on either side) descend to ad hominem attacks it's time to
drop the subject.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
Jeff Bone writes:
> I would say that all such uses --- when the "outer" function doesn't
> impact state or type of the wrapped function, except perhaps to extend
> it (w/, e.g., exceptions, such as potentially in pre- and post-) ---
> can more of less be thought of as "declarative."
Since one of my examples specifically included modifying the parameter
list of the decorated function, I'm a little puzzled by what you
mean by "doesn't impact state or type of the wrapped function". But
what IS clear to me is that your definition of "declarative" and
mine are different. Okay... I can live with that.
After careful reading of your responses to me and to Phillip, I have
concluded (rightly or wrongly) that the real core we are arguing about
here is whether or not decorators should be restricted in ways that
would help with static type analysis of Python code. But although I
happen to be a static-typing fan (a scary thing to admit in THIS
newsgroup), I do NOT believe that static typing (in general) is
possible in Python (StarKiller notwithstanding). I don't think we're
risking breaking something here that isn't already very, VERY broken.
The fact that it is ALREADY possible to achieve the same ends by
rebinding the function after declaring it proves as much.
So, unless you can give me an argument I understand OTHER than static
type analysis, I'm going to go ahead and conclude that I just
disagree with you here and that we've likely learned as much from
each other as we are likely to for the moment.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
"Martin v. Löwis" [mailto:martin@v.loewis.de] wrote:
>
> I'm actually surprised that the exception is cleared when the
> function that has the exception handler completes. Where does that
> happen? The current exception is in the thread state, not in the
> frame, after all.
eval_frame calls set_exc_info and reset_exc_info to do a save/restore
to the frame object.
Effectively there's a stack of exceptions, but since it's bound to
frames interesting cases like this occur:
try:
point_A
except:
try:
point_B
except:
pass
raise
==> NameError: name 'point_B' is not defined
(Refugees from C++ might expect the 'point_A' exception instead.)
Method extraction brings the frame object into play for a different
result:
def b():
try:
point_B
except:
pass
try:
point_A
except:
b()
raise
==> NameError: name 'point_A' is not defined
- Anders
Tim Peters writes:
> A Unicode string is, at least in theory, a sequence of Unicode
> characters, the latter defined in excruciating detail by the Unicode
> Consortium. There's no conventional sense in which a Unicode string
> is an encoding of something other than exactly itself, but you could
> certainly make one up.
I, for one, have always preferred to interpret a string as it's
rot-13 equivalent.
"import this; this.s" -lly yours,
Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
I wrote:
> > We're all consenting adults here. Tampering with the private
> > data of an extension module is a well-known way to crash
> > Python.
Armin replies:
> Is it? I am not aware of any such example in the standard
> library. I am sure
> that it would be considered as a bug. The only (internal and
> expected) ways
> to crash the Python interpreter from Python are currently to
> abuse new.code()
> or gc.getreferents(). If an extension module allows this
> kind of tampering
> from Python code I'd consider it poorly written.
As I had always understood it, we go to great lengths to ensure
that Python itself and the standard library are as robust as
possible and nearly impossible to crash. However, extension
authors, by definition, are writing *extensions* and are not
under the supervision of the Python development team. It is, of
course, trivial to write an extension which will (intentionally)
crash Python, and just as easy to (unintentionally) write one
with a flaw which allows crashes. Thus, I have always understood
that as soon as you use an extension, Python no longer offers
any guaranties.
Of course, the author of the EXTENSION may offer such a guarantee.
Depending on who it is, and how widely-used and well-tested the
extension is, you may choose to trust such a guarantee. But I've
always thought that was separate from Python's promise of "no
crashes".
As for handling this particular issue, I agree with your suggestion:
> I'd advocate using fresh instances of
> 'object' as keys instead of strings, which is even safer.
Good advice for extension authors AND for pure-python writers
whenever they don't want their values tramped on. Of course,
one can still call keys() on the dictionary to obtain the key
if one is *trying* to break (or monkeypatch) the extension,
but that's where I think the "consenting adults" rule applies.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
