Charles-François Natali added the comment: > I agree it is not necessary for sendfile() (you were right).
Good we agree :-) > Do not introducing it for send(), though, poses some questions. > For instance, should we deprecate or ignore 'blocksize' argument in ftplib as > well? Honestly, we should deprecate the whole ftplib module :-) More seriously, it's really low-level, I don't understand the point of this whole callback-based API: FTP.storbinary(command, file[, blocksize, callback, rest])Why not simply a: FTP.store(source, target, binary=True) If you have time and it interest you, trying to improve this module would be great :-) > Generally speaking, when using send() there are circumstances where you might > want to adjust the number of bytes to read from the file, for instance: > > - 1: set a small blocksize (say 512 bytes) on systems where you have a > limited amount of memory > > - 2: set a big blocksize (say 256000) in order to speed up the transfer / use > less CPU cycles; on very fast networks (e.g. LANs) this may result in a > considerable speedup (I know 'cause I conducted these kind of tests in > pyftpdlib: https://code.google.com/p/pyftpdlib/issues/detail?id=94). I agree, but both points are addressed by sendfile(): internally, the kernel will use whatever block size it likes, depending on the source file type, page size, target NIC ring buffer size. So to reply to your above question, I wouldn't feel too bad about simply ignoring the blocksize argument in e.g. shutil.copyfile(). For ftplib, it's a little harder since we're supposed to support an optional callback, but calling a callback for every block will drive performance down... So I'd really like it if you could push the version without the blocksize, and then we'll see (and hopefully fix the non-sensical libraries that depend on it). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17552> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com