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 -- 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 , 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 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] Generalised String Coercion
On 8/9/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 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. I thought that's what I proposed before. I'm still for it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
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 sci&eng 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 sci&eng 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
