Re: [Python-Dev] Major revision of PEP 348 committed
Raymond Hettinger wrote: If the PEP can't resist the urge to create new intermediate groupings, then start by grepping through tons of Python code to find-out which exceptions are typically caught on the same line. That would be a worthwhile empirical study and may lead to useful insights. I was curious, so I did a little grepping (ok, os.walking and re.findalling) ;-) through the Python source. The only exceptions that were caught together more than 5 times were: AttributeError and TypeError (23 instances) in code.py doctest.py linecache.py mailbox.py idlelib/rpc.py lib-old/newdir.py lib-tk/Tkinter.py test/test_descr.py test/test_file.py test/test_funcattrs.py test/test_os.py Though these occur in a few different contexts, one relatively common one was when the code tried to set a possibly read-only attribute. ImportError and AttributeError (9 instances), in getpass.py locale.py pydoc.py tarfile.py xmlrpclib.py lib-tk/tkFileDialog.py test/test_largefile.py test/test_tarfile.py This seemed to be used when an incompatible module might be present. (Attributes were tested to make sure the module was the right one.) Also used when code tried to use private module attributes (e.g. _getdefaultlocale()). OverflowError and ValueError (9 instances), in csv.py ftplib.py mhlib.py mimify.py warnings.py test/test_resource.py These were generally around a call to int(x). I assume they're generally unnecessary now that int() silently converts to longs. IOError and OSError (6 instances), in pty.py tempfile.py whichdb.py distutils/dir_util.py idlelib/configHandler.py test/test_complex.py These were all around file/directory handling that I didn't study in too much detail. With the current hierarchy, there's no reason these couldn't just be catching EnvironmentError anyway. As you can see, even for the most common pairs of exceptions, the total number of times these pairs were caught was pretty small. Even ignoring the low counts, we see that the last two pairs or exceptions aren't really necessary, thanks to int/long unification and the existence of EnvironmentError, and the former two pairs argue *against* added nesting as it is unclear whether to group AttributeError with ImportError or TypeError. So it doesn't really look like the stdlib's going to provide much of a case for adding nesting to the exception hierarchy. Anyway, I know PEP 348's been scaled back at this point anyway, but I figured I might as well post my findings in case anyone was curious. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Trent Mick wrote: One feature I like in Perforce (which Subversion doesn't have) is the ability to have pending changesets. That sounds useful. Currently with svn you have to manually specify those 9 to be sure to not include the remaining one. With p4 you just say to check-in the whole tree and then remove that one from the list give you in your editor with entering the check-in message. Not that big of a deal. Depends on the client also. With Tortoise SVN, you do get a checkbox list where you can exclude files from the checkin. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative suggestion, Re: pdb: should next command be extended?
Ilya Sandler wrote: So, would implementing gdb's until command instead of next N be a better idea? In its simplest form (without arguments) until advances to the next (textually) source line... This would solve the original problem of getting over list comprehensions... I like that idea. There is a bit of a problem with abbreviation of until: gdb abbreviates it as u, while in pdb u means up...It might be a good idea to have the same abbreviations Indeed. I don't know much about pdb internals, but I think u should become unbound, and up and unt should become the shortest abbreviations. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generalised String Coercion
James Y Knight wrote: Hum, actually, it somewhat makes sense for the open builtin to become what is now codecs.open, for convenience's sake, although it does blur the distinction between a byte stream and a character stream somewhat. If that happens, I suppose it does actually make sense to give makefile the same signature. We could always give the text mode/binary mode distinction in open a real meaning - text mode deals with character sequences, binary mode deals with byte sequences. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Major revision of PEP 348 committed
Steven Bethard [EMAIL PROTECTED] writes: Raymond Hettinger wrote: If the PEP can't resist the urge to create new intermediate groupings, then start by grepping through tons of Python code to find-out which exceptions are typically caught on the same line. That would be a worthwhile empirical study and may lead to useful insights. I was curious, so I did a little grepping (ok, os.walking and re.findalling) ;-) through the Python source. The only exceptions that were caught together more than 5 times were: AttributeError and TypeError (23 instances) in code.py doctest.py linecache.py mailbox.py idlelib/rpc.py lib-old/newdir.py lib-tk/Tkinter.py test/test_descr.py test/test_file.py test/test_funcattrs.py test/test_os.py Though these occur in a few different contexts, one relatively common one was when the code tried to set a possibly read-only attribute. This TypeError/AttributeError one is long known, and a bit of a mess, really. Finding an attribute usually fails because the object is not of the expected type, after all. ImportError and AttributeError (9 instances), in getpass.py locale.py pydoc.py tarfile.py xmlrpclib.py lib-tk/tkFileDialog.py test/test_largefile.py test/test_tarfile.py This seemed to be used when an incompatible module might be present. (Attributes were tested to make sure the module was the right one.) Also used when code tried to use private module attributes (e.g. _getdefaultlocale()). This seems like ever-so-faintly lazy programming to me, but maybe that's overly purist. OverflowError and ValueError (9 instances), in csv.py ftplib.py mhlib.py mimify.py warnings.py test/test_resource.py These were generally around a call to int(x). I assume they're generally unnecessary now that int() silently converts to longs. Yes, I think so. IOError and OSError (6 instances), in pty.py tempfile.py whichdb.py distutils/dir_util.py idlelib/configHandler.py test/test_complex.py These were all around file/directory handling that I didn't study in too much detail. With the current hierarchy, there's no reason these couldn't just be catching EnvironmentError anyway. Heh. I'd have to admit that I rarely know which of IOError or OSError I should be expecting in a given situation, nor that EnvironmentError is a common subclass that I could catch instead... [...] Anyway, I know PEP 348's been scaled back at this point anyway, but I figured I might as well post my findings in case anyone was curious. Was interesting, thanks! Cheers, mwh -- freeside On a scale of One to AWESOME, twisted.web is PRETTY ABSTRACT -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
Raymond Hettinger wrote: TerminatingException The rationale for adding TerminatingException needs to be developed or reconsidered. AFAICT, there hasn't been an exploration of existing code bases to determine that there is going to be even minimal use of except TerminatingException. Are KeyboardInterrupt and SystemExit often caught together on the same line and handled in the same way? Yes, to avoid the current overbroad inheritance of except Exception: by intercepting and reraising these two terminating exceptions. If so, isn't except TerminatingException less explicit, clear, and flexible than except (KeyboardInterrupt, SystemExit)? No, TerminatingException makes it explicit to the reader what is going on - special handling is being applied to any exceptions that indicate the interpreter is expected to exit as a result of the exception. Using except (KeyboardInterrupt, SystemExit): is less explicit, as it relies on the reader knowing that these two exceptions share the common characteristic that they are generally meant to terminate the Python interpreter. Are there any benefits sufficient to warrant yet another new built-in? Does it also warrant violating FIBTN by introducing more structure? While I'm clear on why KeyboardInterrupt and SystemExit were moved from under Exception, it is not at all clear what problem is being solved by adding a new intermediate grouping. The main benefits of TerminatingException lie in easing the transition to Py3k. After transition, except Exception: will already do the right thing. However, TerminatingException will still serve a useful documentational purpose, as it sums up in two words the key characteristic that caused KeyboardInterrupt and SystemExit to be moved out from underneath Exception. Bare excepts defaulting to Exception After further thought, I'm not as sure about this one and whether it is workable. The code fragment above highlights the issue. In a series of except clauses, each line only matches what was not caught by a previous clause. This is a useful and basic part of the syntax. It leaves a bare except to have the role of a final catchall (much like a default in C's switch-case). If one line uses except Exception, then a subsequence bare except should probably catch KeyboardInterrupt and SystemExit. Otherwise, there is a risk of creating optical illusion errors (code that looks like it should work but is actually broken). I'm not certain on this one, but the PEP does need to fully explore the implications and think-out the consequent usability issues. I'm also concerned about this one. IMO, bare excepts in Python 3k should either not be allowed at all (use except BaseException: intead), or they should be synonyms for except BaseException:. Having a bare except that doesn't actually catch everything just seems wrong - and we already have style guides that say except Exception: is to be generally preferred over a bare except. Consenting adults and all that. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __traceback__ and reference cycles
Tim Peters wrote: I can't think of a Python feature with a higher aggregate braincell_burned / benefit ratio than __del__ methods. If P3K retains them-- or maybe even before --we should consider taking the Java dodge on this one. That is, decree that henceforth a __del__ method will get invoked by magic at most once on any given object O, no matter how often O is resurrected. Jython __del__ support is already layered on Java finalize, so that's what one gets. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On Mon, 2005-08-08 at 19:29, Tim Peters wrote: Currently with svn you have to manually specify those 9 to be sure to not include the remaining one. With p4 you just say to check-in the whole tree and then remove that one from the list give you in your editor with entering the check-in message. Not that big of a deal. As a purely theoretical exercise wink, the last time I faced that under SVN, I opened the single file I didn't want to check-in in my editor, did svn revert on it from the cmdline, checked in the whole tree, and then hit the editor's save button. This doesn't scale well to skipping 25 of 50, but it's effective enough for 1 or 2. Or one could use a decent client, like say psvn under XEmacs wink which presents you a list of all modified files and lets you select which ones you want to commit. The one thing I dislike about svn (in my day-to-day use of it) is that it can take a VERY long time to do updates at the roots of very large trees. I once tried to check out the root of our dev tree, which contains all branches and tags. Of course the initial checkout took forever. But an update at the root made this approach unusable. svn would sit there, seemingly idle for 30-45 minutes and then take another 30-45 minutes updating the changes, which typically consisted of maybe 50 files out of thousands. And this on a gig LAN with fast h/w all around (and for Tim's sake I won't even complain about how some operating systems appear to perform much worse than others :). The smaller you can keep your working copies, the better. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/8/05, Raymond Hettinger [EMAIL PROTECTED] wrote: [Brett Cannon] At this point the only changes to the hierarchy are the addition of BaseException and TerminatingException, and the change of inheritnace for KeyboardInterrupt, SystemExit, and NotImplementedError. TerminatingException The rationale for adding TerminatingException needs to be developed or reconsidered. AFAICT, there hasn't been an exploration of existing code bases to determine that there is going to be even minimal use of except TerminatingException. Are KeyboardInterrupt and SystemExit often caught together on the same line and handled in the same way? The problem with existing code checking for this situation is that the situation itself is not the same as it will be if bare 'except's change:: try: ... except: ... except TerminatingException: ... has never really been possible before, but will be if the PEP goes forward. If so, isn't except TerminatingException less explicit, clear, and flexible than except (KeyboardInterrupt, SystemExit)? Do we need a second way to do it? But what if we add other exceptions that don't inherit from Exception that was want to typically propagate up? Having a catch-all for exceptions that a bare 'except' will skip that is more explicit than ``except BaseException`` seems reasonable to me. As Nick said in another email, it provides a more obvoius self-documentation point to catch TerminatingException than ``(KeyboardInterrupt, SystemExit)``, plus you get some future-proofing on top of it in case we add more exceptions that are not caught by a bare 'except'. Doesn't the new meaning of Exception already offer a better idiom: try: suite() except Exception: log_or_recover() except: handle_terminating_exceptions() else: Are there any benefits sufficient to warrant yet another new built-in? Does it also warrant violating FIBTN by introducing more structure? While I'm clear on why KeyboardInterrupt and SystemExit were moved from under Exception, it is not at all clear what problem is being solved by adding a new intermediate grouping. The PEP needs to address all of the above. Right now, it contains a definition rather than justification, research, and analysis. WindowsError This should be kept. Unlike module specific exceptions, this exception occurs in multiple places and diverse applications. It is appropriate to list as a builtin. Too O/S specific is not a reason for eliminating this. Looking at the codebase there does not appear to be a good substitute. Eliminating this one would break code, decrease clarity, and cause modules to grow competing variants. I unfortunately forgot to add that the exception would be moved under os, so it would be more of a renaming than a removal. The reason I pulled it was that Guido said UnixError and MacError didn't belong, so why should WindowsError stay? Obviously there are backwards-compatibility issues with removing it, but why should we have this platform-specific thing in the built-in namespace? Nothing else is platform-specific in the language until you go into the stdlib. The language itself is supposed to be platform-agnostic, and yet here is this exception that is not meant to be used by anyone but by a specific OS. Seems like a contradiction to me. After the change, nothing would be better and many things would be worse. NotImplementedError --- Moving this is fine. Removing unnecessary nesting is a step forward. The PEP should list that as a justification. Yay, something uncontraversial! =) Bare excepts defaulting to Exception After further thought, I'm not as sure about this one and whether it is workable. The code fragment above highlights the issue. In a series of except clauses, each line only matches what was not caught by a previous clause. This is a useful and basic part of the syntax. It leaves a bare except to have the role of a final catchall (much like a default in C's switch-case). If one line uses except Exception, then a subsequence bare except should probably catch KeyboardInterrupt and SystemExit. Otherwise, there is a risk of creating optical illusion errors (code that looks like it should work but is actually broken). I'm not certain on this one, but the PEP does need to fully explore the implications and think-out the consequent usability issues. This is Guido's thing. You will have to convince him of the change. I can flesh out the PEP to argue for which ever result he wants, but that part of the proposal is in there because Guido wanted it. I am just a PEP lackey in this case. =) And once that is settled I guess it is either time for pronouncement or it just sits there until Python 3.0 actually starts to come upon us. What happened to don't take this too
Re: [Python-Dev] Major revision of PEP 348 committed
On Tue, Aug 09, 2005 at 12:28:08AM -0600, Steven Bethard wrote:
Raymond Hettinger wrote:
If the PEP can't resist the urge to create new intermediate groupings,
then start by grepping through tons of Python code to find-out which
exceptions are typically caught on the same line. That would be a
worthwhile empirical study and may lead to useful insights.
I was curious, so I did a little grepping (ok, os.walking and
re.findalling) ;-) through the Python source. The only exceptions
that were caught together more than 5 times were:
AttributeError and TypeError (23 instances)
ImportError and AttributeError (9 instances)
OverflowError and ValueError (9 instances)
IOError and OSError (6 instances)
I grepped my own source (ok, find, xargs, and grep'd ;) and here is
what I found. 40 KLOCs, it is a web app so I mainly catch multiple
exceptions when interpreting URLs and doing type convertions. Unexpected
quacks from inside the app are allowed to rise to the top because at
that point all the input should be in a good state.
All of these arise because more than one operation is happening
in the try/except each of which could raise an exception (even if it
is a one-liner).
ValueError, TypeError (6 instances)
Around calls to int() like
foo = int(cgi_dict.get('foo', None))
This is pretty domain specific, cgi variables are in a dict-alike object
that returns None for missing keys. If it was a proper dict instead
this pairing would be (ValueError, KeyError).
The rest are a variation on the above where the result is used in the
same couple lines to do some kind of a lookup in a dict, list, or
namespace.
client_id = int(cgi_dict.get('foo', None))
client_name = names[client_id]
ValueError, TypeError, AttributeError (2 instances)
ValueError, TypeError, KeyError (3 instances)
ValueError, TypeError, IndexError (3 instances)
And finally this one because bsddb can say Failed in more than one way.
IOError, bsddb.error (2 incstances)
btree = bsddb.btopen(self.filename, open_type)
-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Sourceforge CVS down?
I've been getting: ssh: connect to host cvs.sourceforge.net port 22: Connection refused for the past few hours. Their Site News doesn't say anything about downtime. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sourceforge CVS down?
Neil Schemenauer wrote: I've been getting: ssh: connect to host cvs.sourceforge.net port 22: Connection refused for the past few hours. Their Site News doesn't say anything about downtime. I'm seeing the same. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sourceforge CVS down?
[Neil Schemenauer[ I've been getting: ssh: connect to host cvs.sourceforge.net port 22: Connection refused for the past few hours. Their Site News doesn't say anything about downtime. A cvs update doesn't work for me either now. I did finish one sometime before noon (EDT) today, though. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 348 and ControlFlow
Dear all, Sorry to bring this up again, but I think there is an inconsistency in PEP 348 in its current formulation. From PEP: In Python 2.4, a bare except clause will catch any and all exceptions. Typically, though, this is not what is truly desired. More often than not one wants to catch all error exceptions that do not signify a bad interpreter state. In the new exception hierarchy this is condition is embodied by Exception. Thus bare except clauses will catch only exceptions inheriting from Exception. So, bare except will catch anything that is an Exception. This includes GeneratorExit and StopIteration, which contradicts: It has been suggested that ControlFlowException should inherit from Exception. This idea has been rejected based on the thinking that control flow exceptions typically should not be caught by bare except clauses, whereas Exception subclasses should be. To me this means GeneratorExit and StopIteration are to be taken out of the Exception subtree. It seems to me rather awkward to put them at the same level as Exception and TerminatingException. So there comes the old (yeah, I know REJECTED) idea of a ControlFlowException class, right next to Exception and TerminatingException: BaseException +TerminatingException + ... + Exception + ... + ControlFlowException + GeneratorExit + StopIteration Is my logic flawed (again ;-)? --eric Eric Nieuwland ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PSF grant / contacts
Hi, I'm working with support from the Python Software Foundation to develop an open source course on basic software development skills for people with backgrounds in science and engineering. I have a beta version of the course notes ready for review, and would like to pull in Python-friendly people in scieng to look it over and give me feedback. If you know people who fit this bill (particularly people who might be interested in following along with a trial run of the course this fall), I'd be grateful for pointers. Thanks, Greg Wilson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
[Brett] The problem with existing code checking for this situation is that the situation itself is not the same as it will be if bare 'except's change:: try: ... except: ... except TerminatingException: ... has never really been possible before, but will be if the PEP goes forward. That's not an improvement. The above code fragment should trigger a gag reflex indicating that something is wrong with the proposed default for a bare except. Having a catch-all for exceptions that a bare 'except' will skip that is more explicit than ``except BaseException`` seems reasonable to me. The data gathered by Jack and Steven's research indicate that the number of cases where TerminatingException would be useful is ZERO. Try not to introduce a new builtin that no one will ever use. Try not to add a new word whose only function is to replace a two-word tuple (TOOWTDI). Try not to unnecessarily nest the tree (FITBN). Try not to propose solutions to problems that don't exist (PBP). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PSF grant / contacts
On Tuesday 09 August 2005 09:05, Greg Wilson wrote: I'm working with support from the Python Software Foundation to develop an open source course on basic software development skills for people with backgrounds in science and engineering. I have a beta version of the course notes ready for review, and would like to pull in Python-friendly people in scieng to look it over and give me feedback. If you know people who fit this bill (particularly people who might be interested in following along with a trial run of the course this fall), I'd be grateful for pointers. Yeah, I would be interested. I have taught my fellow grad students last semester Python, but the docs out there were not that good for teaching scientific data analysis. I am planning to repeat the course with Physics undergrad students this Fall. If you could send me the material, I would appreciate it. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
