On Fri, Apr 8, 2011 at 3:14 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:

On Fri, Apr 8, 2011 at 3:06 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
> True, but that's like saying we should use sprintf() for string
> formatting and fgets() for file access since other languages such as C
> and PHP use them. In trying to find elegant solutions to problems, we
> often diverge from solutions common in other languages.
>
> (actually, if we followed the errno paradigm closely, we shouldn't even
> raise exceptions, but return the error code or store it in a
> thread-local variable instead ;-))
>
> Regards
>
> Antoine.

Well, not quite. The only case that I can see where errnos are
obviously bad is with multiple errnos that mean the same thing in
practice (so much so that they might even have the same value), making
proper IO handling inconvenient and non-obvious. In particular I'm
thinking of errors like EAGAIN and EWOULDBLOCK. The PEP's suggested
exception hierarchy, and its collapse of some errnos into the same
exception, is nice on that front (for example, BlockingIOError).
However, I interpret what you say as a complaint that errnos are
obscure and thus we should avoid making programmers memorize them, and
avoid encouraging their use. I don't agree with that. They aren't
obscure, they're a legitimate part of POSIX and fairly well-known.
Beginners to IO will have to memorize something anyway, and it may as
well be errnos.

I see your point about that value of knowing stuff, but why should I need to learn errnos until I need them? I deal with IO errors on occasion and end up having to look it up each time. That's a pain.

Consider how much IO is used in Python and how often people have to deal with IO exceptions. Why should we have to deal with errnos if there is a way that fits into the exception hierarchy? It's not that they are obscure. It's that we don't need the actual numbers or mnemonics in our Python code. We can hide them behind more meaningful exceptions. At least, that's my take.

FYI, the the exception objects will still have the errno attribute that you would find in the plain IOError:

http://www.python.org/dev/peps/pep-3151/#id26

-eric

A more experienced programmer might come from from C
or C# or Ruby, or whatever, and would get less educational overhead
when doing Python IO, because all these languages share a little bit
of POSIX in their IO APIs.

It's not even about following it closely, but about building on what
people know. Python doesn't support sprintf, but it does (or perhaps
"did") support the sprintf syntax. It didn't follow it *closely* --
"%s" % 2 doesn't result in a segfault or anything -- but closely
enough so that programmers familiar with sprintf could get started
quickly, and programmers familiar with Python could understand
sprintf. The replacement, str.format, doesn't come from nowhere
either, but builds on a different string formatting tradition also
shared by C#. Having these ties to the outside world is useful and
desirable, it makes everyone's life easier. I think that breaking
these ties needs an overriding reason, generally relating to the
outside world actually hurting people. The PEP solves the issue where
people don't necessarily handle all the right errnos, without breaking
ties to the IO community and eliminating them altogether. That's
pretty cool. It also offers a way to make errno handling easier.
That's also pretty cool.

Devin

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas