[Python-Dev] os.path.walk() lacks 'depth first' option
Tue, 22 Apr 2003 09:34:29 +0100
Tim Peters <email@example.com> writes:
> [Jeremy Fincher]
>> This code brought up an interesting question to me: if sets have
>> a .discard method that removes an element without raising KeyError
>> if the element isn't in the set, should lists perhaps have that same
> I don't think list.remove(x) is used enough to care, when the presence of x
> in the list is unknown.
I've wished for this, more than once, in the past. I can't quite
remember why, I have to admit.
while x in seq:
is vulgar, on at least two levels.
For all that, I'm not sure this is worth the pain.
>> On another related front, sets (in my Python 2.3a2) raise KeyError on a
>> .remove(elt) when elt isn't in the set. Since sets aren't mappings,
>> should that be a ValueError (like list raises) instead?
> Since sets aren't sequences either, why should sets raise the same exception
> lists raise? It's up to the type to use whichever fool exceptions it
> chooses. This doesn't always make life easy for users, alas -- there's not
> much consistency in exception behavior across packages. In this case, a
> user would be wise to avoid expecting IndexError or KeyError, and catch
> their common base class (LookupError) instead. The distinction between
> IndexError and KeyError isn't really useful (IMO; LookupError was injected
> as a base class recently in Python's life).
Without me noticing, too! Well, I knew there was a lookup error that
you get when failing to find a codec, but I didn't know IndexError and
KeyError derived from it...
Also note that Jeremy was suggesting *ValueError*, not
IndexError... that any kind of index-or-key-ing is going on is trivia
of the implementation, surely?
First of all, email me your AOL password as a security measure. You
may find that won't be able to connect to the 'net for a while. This
is normal. The next thing to do is turn your computer upside down
and shake it to reboot it. -- Darren Tucker, asr