Mailman 3 February 2007 - Python-Dev

GeneratorExit inheriting from Exception
by Nick Coghlan Feb. 28, 2007

Feb. 28, 2007

Should GeneratorExit inherit from Exception or BaseException? Currently, a generator that catches Exception and continues on to yield another value can't be closed properly (you get a runtime error pointing out that the generator ignored GeneratorExit). The only decent reference I could find to it in the old PEP 348/352 discussions is Guido writing [1]: > when GeneratorExit or StopIteration > reach the outer level of an app, it's a bug like all the others that > bare 'except:' WANTS to catch. (at that point in the conversation, I believe bare except was considered the equivalent of "except Exception:") While I agree with what Guido says about GeneratorExit being a bug if it reaches the outer level of an app, it seems like a bit of a trap that a correctly written generator can't write "except Exception:" without preceding it with an "except GeneratorExit:" that reraises the exception. Isn't that exactly the idiom we're trying to get rid of for SystemExit and KeyboardInterrupt? Regards, Nick. [1] http://mail.python.org/pipermail/python-dev/2005-August/055173.html -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

16 41

zipfile patch (1121142) updated
by Alan McIntyre Feb. 28, 2007

Feb. 28, 2007

I posted what I hope can be the final update to patch 1121142 (adding an open() method to ZipFile that returns a read-only file-like object). If anybody has time to review and apply it I would appreciate it. https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_… If I find time later I may start another patch to add a ZipFile method analogous to TarFile.extract, and any neat features from the module Glyph suggested, but I figured it was best to stick to the scope of the original patch and get it wrapped up. Thanks, Alan

1 0

Adding timeout option to httplib...connect()
by Guido van Rossum Feb. 27, 2007

Feb. 27, 2007

I recently needed to access an HTTP URL with a timeout. I ended up monkey-patching httplib.HTTPConnection so that the connect() method has an optional second paramer, timeout, defaulting to None; if not None, a call to settimeout() is added right after successful creation of the socket. Does anybody else think this is a good idea? (Personally I think this should've been done years ago. :-) Shall I check it into the head? Index: httplib.py =================================================================== --- httplib.py (revision 53456) +++ httplib.py (working copy) @@ -656,7 +656,7 @@ def set_debuglevel(self, level): self.debuglevel = level - def connect(self): + def connect(self, timeout=None): """Connect to the host and port specified in __init__.""" msg = "getaddrinfo returns an empty list" for res in socket.getaddrinfo(self.host, self.port, 0, @@ -664,6 +664,8 @@ af, socktype, proto, canonname, sa = res try: self.sock = socket.socket(af, socktype, proto) + if timeout is not None: + self.sock.settimeout(timeout) if self.debuglevel > 0: print "connect: (%s, %s)" % (self.host, self.port) self.sock.connect(sa) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

8 17

A Survey on Defect Management Practices in Free/Open Source Software
by Anu Gupta DCSA Feb. 27, 2007

Feb. 27, 2007

Sir/Madam I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta(a)pu.ac.in anugupta98(a)gmail.com

1 0

A Reminder : A Survey on Defect Management Practices in Free/Open Source Software
by Anu Gupta DCSA Feb. 27, 2007

Feb. 27, 2007

Sir/Madam I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta(a)pu.ac.in anugupta98(a)gmail.com

1 0

with_traceback
by Andrew Dalke Feb. 26, 2007

Feb. 26, 2007

Guido's talk at PyCon said: > Use raise E(arg).with_traceback(tb) > instead of raise E, arg, tb That seems strange to me because of the mutability. Looking through the back discussions on this list I see Guido commented: http://mail.python.org/pipermail/python-3000/2007-February/005689.html > Returning the mutated object is acceptable here > because the *dominant* use case is creating and raising an exception > in one go: > > raise FooException(<args>).with_traceback(<tb>) The 3 argument raise statement is rarely used, in my experience. I believe most don't even know it exists, excepting mostly advanced Python programmers and language lawyers. My concern when I saw Guido's keynote was the worry that people do/might write code like this NO_END_OF_RECORD = ParserError("Cannot find end of record") def parse_record(input_file): ... raise NO_END_OF_RECORD ... That is, create instances at the top of the module, to be used later. This code assume that the NO_END_OF_RECORD exception instance is never modified. If the traceback is added to its __traceback__ attribute then I see two problems if I were to write code like the above: - the traceback stays around "forever" - the code is no longer thread-safe. As an example of code which is affected by this, see pyparsing, which has code that looks like class Token(ParserElement): """Abstract ParserElement subclass, for defining atomic matching patterns."" " def __init__( self ): super(Token,self).__init__( savelist=False ) self.myException = ParseException("",0,"",self) .... class Literal(Token): .... def parseImpl( self, instring, loc, doActions=True ): if (instring[loc] == self.firstMatchChar and (self.matchLen==1 or instring.startswith(self.match,loc)) ): return loc+self.matchLen, self.match #~ raise ParseException( instring, loc, self.errmsg ) exc = self.myException exc.loc = loc exc.pstr = instring raise exc The "Literal" and other token classes are part of the grammar definition and usually exist in module scope. There's another question I came up with. If the exception already has a __traceback__, will that traceback be overwritten if the instance is reraised? Consider this code, loosly derived from os._execvpe import os, sys _PATH = ["here", "there", "elsewhere"] def open_file_on_path(name): # If nothing exists, raises an exception based on the # first attempt saved_err = None saved_tb = None for dirname in _PATH: try: return open(os.path.join(dirname, name)) except Exception, err: if not saved_err: saved_err = err saved_tb = sys.exc_info()[2] raise saved_err.__class__, saved_err, saved_tb open_file_on_path("spam") which generates this Traceback (most recent call last): File "raise.py", line 19, in <module> open_file_on_path("spam") File "raise.py", line 11, in open_file_on_path return open(os.path.join(dirname, name)) IOError: [Errno 2] No such file or directory: 'here/spam' What is the correct way to rewrite this for use with "with_traceback"? Is it def open_file_on_path(name): # If nothing exists, raises an exception based on the # first attempt saved_err = None for dirname in _PATH: try: return open(os.path.join(dirname, name)) except Exception, err: if not saved_err: saved_err = err saved_tb = sys.exc_info()[2] raise saved_err.with_traceback(saved_err.__traceback__) One alternative, btw, is raise saved_err.with_traceback() to have it use the existing __traceback__ (and raising its own exception if __traceback__ is None?) Andrew dalke(a)dalkescientific.com

2 1

bool conversion wart?
by Neal Becker Feb. 26, 2007

Feb. 26, 2007

>>> int ('4') 4 >>> bool ('False') True

14 22

Bug in PyErr_WriteUnraisable ?
by Gabriel Becedillas Feb. 26, 2007

Feb. 26, 2007

I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer. We are embedding Python 2.5 and a string instance is raised using PyThreadState_SetAsyncExc. I can fix that in my code, by raising an appropiate exception instance, but I think PyErr_WriteUnraisable lacks some checks. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES

2 3

microthreading vs. async io
by dustin＠v.igoro.us Feb. 26, 2007

Feb. 26, 2007

I've steered clear of this conversation for a while, because it drifted a little bit off my original topic. But I did want to straighten a little bit of terminology out, if only to resolve some of my own confusion over all the hubbub. I don't pretend to define the words others use; these definitions are mine, and apply to what I write below. cooperative multitasking: Dynamically executing multiple tasks in a single thread; comes in two varieties: continuations: Breaking tasks into discrete "chunks", and passing references those chunks around as a means of scheduling. microtreading: Exploiting language features to use cooperative multitasking in tasks that "read" like they are single-threaded. asynchronous IO: Performing IO to/from an application in such a way that the application does not wait for any IO operations to complete, but rather polls for or is notified of the readiness of any IO operations. Twisted is, by the above definitions, a continuation-based cooperative multitasking library that includes extensive support for asynchronous IO, all the way up the network stack for an impressive array of protocols. It does not itself implement microthreading, but Phillip provided a nice implementation of such on top of Twisted[1]. Asyncore *only* implements asynchronous IO -- any "tasks" performed in its context are the direct result of an IO operation, so it's hard to say it implements cooperative multitasking (and Josiah can correct me if I'm wrong, but I don't think it intends to). Much of the discussion here has been about creating a single, unified asynchronous IO mechanism that would support *any* kind of cooperative multitasking library. I have opinions on this ($0.02 each, bulk discounts available), but I'll keep them to myself for now. Instead, I would like to concentrate on producing a small, clean, consistent, generator-based microthreading library. I've seen several such libraries (including the one in PEP 342, which is fairly skeletal), and they all work *almost* the same way, but differ in, for example, the kinds of values that can be yielded, their handling of nested calls, and the names for the various "special" values one can yield. That similar mouldes are being written repeatedly, and presumably applications and frameworks are being built on top of those modules, seems to me to suggest a new "standard" implementation should be added to the standard library. I realize that I'm all talk and no code -- I've been busy, but I hope to rectify the imbalance tonight. Dustin [1] http://mail.python.org/pipermail/python-dev/2007-February/071076.html

9 21

status of switch to Roundup off of SF
by Brett Cannon Feb. 25, 2007

Feb. 25, 2007

When I gave the PSF members an update on the work to move the python-dev tracker over to Roundup Andrew Kuchling asked me to also send an email to python-dev since October/November. As of right now the biggest thing holding up the transition is documentation. A doc needs to get written explaining basic workflow of how issues should be handled. Also need to go through and remove SF references and make them more general (e.g., mention an "issue tracker" when possible). After that some redirects need to be tweaked. www.python.org/sf/ needs to redirect to the Roundup installation (which is keeping SF bug numbers). bugs.python.org will also be set to point to the Roundup server. After all of that we will find out from Anthony and Neal when a release is going to be so as to do the switch when it won't run into a release (before or after). The current test tracker is at http://psf.upfronthosting.co.za/roundup/tracker/ . The meta tracker for dealing with this stuff is at http://psf.upfronthosting.co.za/roundup/meta/ . Feel free to have a look, but please don't go overboard with the suggestions on changes. It is not difficult to change the tracker after it launches. The last thing any of us want to see is the tracker launch delayed because someone wants a feature that takes a while to implement. Unless there is a critical issue you find it would be appreciated if you file the suggestion and just let us push after the launch if it is deemed it will take too much time to implement. The mailing list where all discussions take place is http://mail.python.org/mailman/listinfo/tracker-discuss . Fairly low-traffic although all updates to the meta tracker get sent there. Obviously if you have questions feel free to ask. And if you want to help with getting the switch to happen just speak up. =) -Brett

1 0