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, hynek, loewis, nikratio, pitrou, stutzbach, vstinner
Date 2014-04-14.02:19:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
(Rietveld is giving me errors, so I'm replying here)

On 2014/04/13 02:22:23, loewis wrote:
>>> Again, why a separate implementation here?
>> For performance reasons. Relying on the default implementation
>> would fall back to using read1(), which means a new bytes object
>> is created first.
> Hmm.
> a) if performance was relevant, it should apply to readinto() as well.

I didn't even notice the readinto implementation was missing. But I
agree, if we keep readinto1(), we should also add readinto().

> b) if the code is duplicated for performance only, a comment should
>    state that explicitly.

I'm very sorry, but I still don't see which code in readinto1() is
duplicate. You don't mean duplicate between io and _pyio, do you?

> c) to justify a performance argument, you should really provide hard
>    numbers that demonstrate a performance gain justifying the code
>    duplication.

I posted a small benchmark to the issue tracker. Personally, I think
the more important argument is to keep the Python and C
implementations similar. It's really nice if you can look at _pyio to
find out at least roughly what happens in io.

(Yes, I did put performance first in my last reply, but only because I
thought you were asking about readinto1 in general, rather than the
additional Python implementation in _pyio.)
Date User Action Args
2014-04-14 02:19:52nikratiosetrecipients: + nikratio, loewis, pitrou, vstinner, benjamin.peterson, stutzbach, hynek
2014-04-14 02:19:52nikratiosetmessageid: <>
2014-04-14 02:19:52nikratiolinkissue20578 messages
2014-04-14 02:19:51nikratiocreate