Python-Dev June 2004

python-dev@python.org

123 participants
186 discussions

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.

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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.

16 years, 1 month

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>

16 years, 1 month

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.

16 years, 1 month

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.

16 years, 1 month

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

16 years, 1 month

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.

16 years, 1 month

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

by Chermside, Michael

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.

16 years, 1 month

Jump to page:

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