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 giampaolo.rodola
Recipients akira, asvetlov, christian.heimes, giampaolo.rodola, gvanrossum, josh.r, josiah.carlson, neologix, pitrou, rosslagerwall, yselivanov
Date 2014-04-24.15:56:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1398355010.3.0.612729909059.issue17552@psf.upfronthosting.co.za>
In-reply-to
Content
> [...] I'd like a parameter for the offset, and another one for the
> number of bytes to send.
> To sum up, I think there's a fundamental confusion between blocksize
> and count in this API.

Ah OK, I see what you mean now. If seems we didn't understand each other. =)
And yes, I suppose you're right: if possible we should pass a high value and let sendfile() do its thing.
Note that we still have to implement an internal loop ourselves though because if the socket has a timeout sendfile() will return before EOF (I've checked this just now).

As for what to do, here's what I propose:
- we provide a blocksize argument defaulting to None
- in case of send() and blocksize == None we set it to 262144
- in case of sendfile() we set it to a very high value (4M or something)
- using os.path.getsize(file.name) looks risky to me as the user might have changed CWD in the meantime or something

I'm -1 about adding "count" *and* "blocksize" parameters. "blocksize" alone is good enough IMO and considering what I've just described it is a better name than "count".
History
Date User Action Args
2014-04-24 15:56:50giampaolo.rodolasetrecipients: + giampaolo.rodola, gvanrossum, pitrou, christian.heimes, josiah.carlson, asvetlov, neologix, akira, rosslagerwall, yselivanov, josh.r
2014-04-24 15:56:50giampaolo.rodolasetmessageid: <1398355010.3.0.612729909059.issue17552@psf.upfronthosting.co.za>
2014-04-24 15:56:50giampaolo.rodolalinkissue17552 messages
2014-04-24 15:56:50giampaolo.rodolacreate