This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients arigo, giampaolo.rodola, gregory.p.smith, gvanrossum, koobs, larry, neologix, pitrou, sbt, vstinner
Date 2013-12-01.19:14:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1385925241.06.0.376665358842.issue18885@psf.upfronthosting.co.za>
In-reply-to
Content
I do not consider this a feature; that EINTR is exposed as an exception from the API is a bug.  But Larry is the only one who can actually make that decision as the 3.4 release manager (+nosy'd).

> by returning an empty list you force the user to handle EINTR -
> just in a different way.

The user now only has one thing to deal with instead of two: an empty list being returned; something they should already have been dealing with. Gone will be the OSError(EINTR) exception as a rare, often never tested for, alternate form of the same retry needed indication.

I never see code intentionally wanting to receive and handle an OSError(EINTR) exception but I constantly run into code that is buggy due to some library it is using not getting this right... Where it isn't up to the code exhibiting the problem because the only place to fix it is within the library they use that is outside of that code's control.

We've got the opportunity to fix this nit once and for all here, lets do it.
History
Date User Action Args
2013-12-01 19:14:01gregory.p.smithsetrecipients: + gregory.p.smith, gvanrossum, arigo, pitrou, vstinner, larry, giampaolo.rodola, neologix, sbt, koobs
2013-12-01 19:14:01gregory.p.smithsetmessageid: <1385925241.06.0.376665358842.issue18885@psf.upfronthosting.co.za>
2013-12-01 19:14:01gregory.p.smithlinkissue18885 messages
2013-12-01 19:14:00gregory.p.smithcreate