[Python-ideas] PEP-3151 pattern-matching

[Eric Snow]

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

> On Fri, Apr 8, 2011 at 3:06 PM, Antoine Pitrou <solipsis at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110408/9f5b5de3/attachment.html>