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 nikratio
Recipients benjamin.peterson, docs@python, eric.araujo, ezio.melotti, georg.brandl, hynek, ncoghlan, nikratio, pitrou, r.david.murray, rhettinger, stutzbach
Date 2014-06-17.20:13:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <87fvj3z444.fsf@rath.org>
In-reply-to <1403014034.86.0.103235757476.issue21763@psf.upfronthosting.co.za> (R. David Murray's message of "Tue, 17 Jun 2014 14:07:14 +0000")
Content
"R. David Murray" <report@bugs.python.org> writes:
> R. David Murray added the comment:
>
> Nikolaus: while I agree that Raymond's comments were a bit strongly
> worded, it doesn't read to me as if the thread you link to is on point
> for this issue.  The thread was focused on a *specific* question, that
> of calling close twice.  The question of what the docs mean by "a file
> like object" is a different question.  Specifically, you will note
> that "duck typing" never came up in that thread (as far as I
> remember).

That's quite correct. But did not come up in the original issue report
either - that's why I still don't understand why we're discussing it
here at all.

My line of thought was as follows:

 - Standard library assumes that close() is idempotent in many places
 - Currently this isn't documented clearly
 - The best place to make it more explicit seemed to be the description
   of IOBase
 - However, changing the description of only IOBase.close() could easily
   give the impression that close() is somehow special, and that
   fewer/no assumptions are made in the standard lbirary about the
   presence/behavior of the other methods (e.g. fileno or readable).
 - Therefore, to me the best course of action seemed to add a paragraph
   explicitly describing that the standard library may assume that 
   *any* method/attribute of a stream object behaves as described for
   IOBase.

I still don't see how this contradicts / interacts with the concept of
duck typing. I think the documentation (with and without the patch)
clearly implies that you can implement an object that does not have the
full IOBase API and successfully hand it to some standard library
function - it's just that in that case you can't complain if it
breaks.

Or is the point of contention just the title of this issue? Maybe it was
poorly chosen, I guess "Clarify standard library's expectations from
stream objects" would have been better.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«
History
Date User Action Args
2014-06-17 20:13:35nikratiosetrecipients: + nikratio, georg.brandl, rhettinger, ncoghlan, pitrou, benjamin.peterson, stutzbach, ezio.melotti, eric.araujo, r.david.murray, docs@python, hynek
2014-06-17 20:13:35nikratiolinkissue21763 messages
2014-06-17 20:13:34nikratiocreate