Python-Dev June 2004

python-dev@python.org

123 participants
187 discussions

by Chermside, Michael

Jeff Bone writes: > IMHO, making decorators functions is a bad idea. Decorators are > metadata about the function to which they refer. Bob Ippolito responds: > Uh, the WHOLE POINT we want this is to have side-effects. If it > doesn't make the function act in a different way, it might as well live > in the doc string or something. > > The most wanted use cases are all function transformations, not the > setting attributes on function objects. And back to Jeff: > Declarative vs. imperative. Design-time *definitional* modification of > behavior vs. runtime. I don't really think you want side-effects in > the literal sense. E.g. "classmethod" isn't a side-effect, it's a > definitional thing. If you really want side-effecting operations on > functions, you've already got that given higher-order / first-class > functions. Just one more opinion here, but I'm with Bob on this one. Sure, many of the uses I envision are "declarative" in the sense that they just associate metadata with the function. But many other uses I envision would alter the function's behavior. Yes, of COURSE it can all be achieved by applying higher-order operations to Python's first-class functions -- in my mind, that's what decorators ARE... a cleaner syntax allowing easier use of higher order functions. -- 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.

17 years, 3 months

decorators and 2.4

by Anthony Baxter

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.

17 years, 3 months

What can we do about dealing with the Demo directory?

by Brett Cannon

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

17 years, 3 months

Re: [Python-Dev] Compiling the Python sources with a C++ compiler (aCC)

by Paul Sheer

> 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

17 years, 3 months

RE: [Python-Dev] Proposal: thread.get_dict

by Chermside, Michael

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.

17 years, 3 months

Re: [Python-checkins] python/dist/src/Doc/api exceptions.tex, 1.18, 1.19

by Fred L. Drake, Jr.

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>

17 years, 3 months

RE: [Python-Dev] Re: decorators and 2.4

by Chermside, Michael

> 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.

17 years, 3 months

RE: [Python-Dev] Re: decorators and 2.4

by Chermside, Michael

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.

17 years, 3 months

Re: [Python-Dev] Re-raise in absence of an "active" exception

by Anders J. Munch

"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

17 years, 3 months

RE: [Python-Dev] Allowing u.encode() to return non-strings

by Chermside, Michael

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.

17 years, 3 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev June 2004