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