Mailman 3 May 2005 - Python-Dev

Re: [Python-Dev] PEP 343 - Abstract Block Redux
by Robert Brewer May 15, 2005

May 15, 2005

Guido van Rossum wrote: > I've written up the specs for my "PEP 340 redux" proposal as a > separate PEP, PEP 343. > > http://python.org/peps/pep-0343.html > > Those who have been following the thread "Merging PEP 310 and PEP > 340-redux?" will recognize my proposal in that thread, which received > mostly positive responses there. > > Please review and ask for clarifications of anything that's unclear. There's a typo in the code snippets at the moment. The translation of the above statement is: abc = EXPR exc = () # Or (None, None, None) ? try: try: VAR = abc.__enter__() BLOCK except: exc = sys.exc_info() raise finally: abc.__exit__(exc) I think you meant "abc.__exit__(*exc)". Assuming that, then "exc = (None, None, None)" makes the most sense. If exc_info() is going to be passed as a single arg, then I'd rather have the default "exc = ()", so I can simply check "if exc:" in the __exit__ method. Robert Brewer System Architect Amor Ministries fumanchu(a)amor.org

6 7

Re: [Python-Dev] [Python-checkins] python/nondist/peps pep-0343.txt, 1.8, 1.9
by Raymond Hettinger May 15, 2005

May 15, 2005

> - was, under the covers, a (optential) looping construct. This > + was, under the covers, a (potential) looping construct. This I'm glad I didn't fix this one. I thought he meant to use "optional". Raymond Hettinger

1 0

New Py_UNICODE doc
by Nicholas Bastin May 14, 2005

May 14, 2005

The current documentation for Py_UNICODE states: "This type represents a 16-bit unsigned storage type which is used by Python internally as basis for holding Unicode ordinals. On platforms where wchar_t is available and also has 16-bits, Py_UNICODE is a typedef alias for wchar_t to enhance native platform compatibility. On all other platforms, Py_UNICODE is a typedef alias for unsigned short." I propose changing this to: "This type represents the storage type which is used by Python internally as the basis for holding Unicode ordinals. On platforms where wchar_t is available, Py_UNICODE is a typedef alias for wchar_t to enhance native platform compatibility. On all other platforms, Py_UNICODE is a typedef alias for unsigned short. Extension module developers should make no assumptions about the size of this type on any given platform." If no one has a problem with that, I'll make the change in CVS. -- Nick

9 86

Chained Exceptions
by Ka-Ping Yee May 14, 2005

May 14, 2005

Suppose exceptions have an optional "context" attribute, which is set when the exception is raised in the context of handling another exception. Thus: def a(): try: raise AError except: raise BError yields an exception which is an instance of BError. This instance would have as its "context" attribute an instance of AError. Or, in a more complex case: def compute(): try: 1/0 except Exception, exc: log(exc) def log(exc): try: file = open('error.log') # oops, forgot 'w' print >>file, exc file.close() except: display(exc) def display(exc): print 'Aaaack!', ex # oops, misspelled 'exc' Today, this just gives you a NameError about 'ex'. With the suggested change, you would still get a NameError about 'ex'; its 'context' attribute would show that it occurred while handling an IOError on error.log; and this IOError would have a 'context' attribute containing the original ZeroDivisionError that started it all. What do you think? -- ?!ng

5 13

Merging PEP 310 and PEP 340-redux?
by Guido van Rossum May 14, 2005

May 14, 2005

Apologies if this has been discovered and rejected already; I've had to skip most of the discussions but this though won't leave my head... So PEP 310 proposes this: with VAR = EXPR: BLOCK translated to VAR = EXPR\ if hasattr(VAR, "__enter__"): VAR.__enter__() try: BLOCK finally: VAR.__exit__() This equates VAR with the value of EXPR. It has a problem: what if inside BLOCK an assignment to VAR is made -- does this affect the finally clause or not? I think that the finally clause should use an internal variable that isn't affected by assignments to VAR. But what if we changed the translation slightly so that VAR gets assigned to value of the __enter__() call: abc = EXPR VAR = abc.__enter__() # I don't see why it should be optional try: BLOCK finally: abc.__exit__() Now it would make more sense to change the syntax to with EXPR as VAR: BLOCK and we have Phillip Eby's proposal. The advantage of this is that you can write a relatively straightforward decorator, call it @with_template, that endows a generator with the __enter__ and __exit__ methods, so you can write all the examples (except auto_retry(), which was there mostly to make a point) from PEP 340 like this: @with_template def opening(filename, mode="r"): f = open(filename, mode) yield f f.close() and so on. (Note the absence of a try/finally block in the generator -- the try/finally is guaranteed by the with-statement but not by the generator framework.) I used to dislike this, but the opposition and the proliferation of alternative proposals have made me realize that I'd rather have this (plus "continue EXPR" which will be moved to a separate PEP once I have some extra time) than most of the other proposals. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

17 75

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
by Guido van Rossum May 14, 2005

May 14, 2005

[Bill Janssen] > I agree. "with [VAR =] BLOCK:" just reads better. "with BLOCK [as > VAR]:" is OK, too. Maybe someone can set up a public poll (isn't that something you can do on Yahoo? Or some volunteer can probably write it in Zope in 3 minutes) asking whether people prefer 'do' or 'with'. I'll go with the outcome; this is pretty much the only contentious point in PEP 343 at this point. (That's http://www.python.org/peps/pep-0343.html in case you missed my announcement; somehow Gmail classified it as spam for me even though I sent it myself! :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] "with" use case: replacing a file
by Nick Coghlan May 13, 2005

May 13, 2005

Guido van Rossum wrote: >>P.S. The points regarding non-local flow control in Joel Spolsky's latest Joel >>on Software article (especially the links at the end) may have had something to >>do with my change of heart. . . > > > I'm a big fan of Joel. Care to share the specific URL for the article > you're referring to? > Sorry about that (I was in a hurry this morning). It was here: http://www.joelonsoftware.com/articles/Wrong.html The link of particular interest regarding exception handling was this one: http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx Some interesting points about some of the cons of exception based code (at least some of which relate to what we're dealing with in factoring out finally clauses, and C++ deals with via scope-based destruction). Anyway, it made me realise that having any callables you invoke potentially raise exceptions is already tricky to deal with, and allowing a different call to potentially *suppress* those exceptions is a recipe for serious confusion. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

2 2

the current behavior of try: ... finally:
by Michele Simionato May 13, 2005

May 13, 2005

All this talk about try: ... finally: and exceptions reminded me of a curious behavior I discovered a while back, i.e. that finally can swallow your exceptions. This is a contrived example, but shows the point: def divide1(n1, n2): try: result = n1/n2 finally: print "cleanup" result = "Infinity\n" return result # the exception is swallowed away def divide2(n1, n2): try: result = n1/n2 finally: print "cleanup" result = "Infinity\n" return result # the exception is NOT swallowed away print divide1(10, 0) # no-exception print divide2(10, 0) # error If there is an indentation error in "divide2" and the return line is too indented the exceptions get swallowed by the finally clause. I am not sure if this is good or bad, but sure it surprised me that a finally clause could hide my exception. Michele Simionato

3 3

Re: [Python-Dev] Chained Exceptions
by Delaney, Timothy C (Timothy) May 13, 2005

May 13, 2005

James Y Knight wrote: > Of course you can already do similar with current python, it just > can't be spelled as nicely, and the default traceback printer won't > use the info: > > try: > raise AError > except: > newException = BError() > newException.cause=sys.exc_info() > raise newException Well, one thing you can do is (somewhat evil ;) :: import sys try: raise AError, 'message' except: exc_type, exc_value, exc_traceback - sys.exc_info() raise BError, exc_value, exc_traceback with the result: Traceback (most recent call last): File ... raise AError, 'message' BError: message So you store the original exception as the argument to the new exception (so it's accessible). This has the nice side effect that message is displayed in the traceback - but the type has changed. Whilst in the above example, it's particularly evil, in the case where the original exception came from a function call and you want to translate the type it works very nicely. Tim Delaney

1 0

a patch to inspect and a non-feature request
by Michele Simionato May 12, 2005

May 12, 2005

Well, I logged into Sourceforge with the idea of filing my feature request about copying functions, and then my eye went on my previous submissions. It seems it takes some time to fix non-critical bugs, isn't it? ;) Two years ago, I discovered a bug with pydoc for classes containing "super" objects: >>> class C(object): ... pass >>> C.s = super(C) >>> help(C) # aargh!! I filed that bug 25 months ago and it is still there (actually Brett Cannot fixed it but then somebody else broke his patch). Clearly nobody uses this feature and the bug fixing is not at all urgent still it disturbs me, so I have worked out a patch. Actually, the problem is not in pydoc but in inspect, that treats super objects as methods, whereas they should be treated as data. Here is the patch: $ diff -c /home/micheles/python/dist/src/Lib/inspect.py inspect.py *** /home/micheles/python/dist/src/Lib/inspect.py Thu May 12 13:05:10 2005 --- inspect.py Thu May 12 13:06:55 2005 *************** *** 77,83 **** and not hasattr(object, "__set__") # else it's a data descriptor and not ismethod(object) # mutual exclusion and not isfunction(object) ! and not isclass(object)) def isdatadescriptor(object): """Return true if the object is a data descriptor. --- 77,84 ---- and not hasattr(object, "__set__") # else it's a data descriptor and not ismethod(object) # mutual exclusion and not isfunction(object) ! and not isclass(object) ! and not isinstance(object, super)) def isdatadescriptor(object): """Return true if the object is a data descriptor. It changes the code of ismethoddescriptor to make sure that super objects are not treated as methods. BTW, I have downloaded the CVS version of Python and run test_inspect against the patch and it is working. However, introspection tools have the tendency to be very fragile (especially with the rate of changes in Python) and it is possible that this fix would break something else. Let The Powers That Be to decide. The test suite should be augmented with a test such >>> inspect.ismethoddescriptor(C.s) False In my experience super is a huge can of worms and actually I have a non-feature request about the descriptor aspect of super: I would like super's __get__ method and the possibily to call super with just one argument to be removed in Python 3000. They are pretty much useless (yes I know of "autosuper") and error prone. Michele Simionato

2 2