On Thu, 22 Jul 2010 17:50:00 +0900
"Stephen J. Turnbull" <step...@xemacs.org> wrote:
> Greg Ewing writes:
> > Glyph Lefkowitz wrote:
> >
> > > The selection of RuntimeError in this particular case seems
> > > somewhat random and ad-hoc,
>
> Well, I guess we'd have to catch the person who wrote the code and
> ask.
>
> > Maybe this is something that could be considered in the
> > exception hierarchy revamp proposal that was posted recently?
>
> I think that's Antoine's PEP 3151. Interestingly, he doesn't mention
> EINVAL at all.
>
> http://www.python.org/dev/peps/pep-3151/
That's right. It is based on a survey of existing exception-catching
code in the stdlib. There's only one match in the whole Lib/ subtree:
$ grep -r EINVAL Lib/
Lib/plat-sunos5/STROPTS.py:968:EINVAL = 22
I guess EINVAL would most often indicate a programming error, which is
why it doesn't get handled specifically in except clauses. Semantically,
EINVAL seems close to ValueError. If I search inside the man pages
here, I get excerpts such as:
- wait(2):
EINVAL The options argument was invalid.
- gettimeofday(2):
EINVAL Timezone (or something else) is invalid.
- socket(2):
EINVAL Unknown protocol, or protocol family not available.
EINVAL Invalid flags in type.
- rename(2):
EINVAL The new pathname contained a path prefix of the old,
or, more generally, an attempt was made to make a directory a
subdirectory of itself.
Regards
Antoine.
_______________________________________________
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
