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 pitrou
Recipients amaury.forgeotdarc, aymanhs, giampaolo.rodola, pitrou, rdevaughn, vstinner
Date 2010-08-19.11:45:57
SpamBayes Score 9.15934e-15
Marked as misclassified No
Message-id <1282218354.3253.4.camel@localhost.localdomain>
In-reply-to <1282196788.58.0.629431175469.issue6822@psf.upfronthosting.co.za>
Content
> I do not agree with Antoine.  For binary transfer, another method is
> called, and it does work fine.  However, storelines would be called
> for ASCII mode, in which encoding and decoding should be done by the
> FTP program.  ASCII mode would translate files, so a file loaded on a
> PC may not be identical to the same file when loaded on a Mac.

Well if it's really "ASCII" mode, it should refuse any character > 127,
in which case I would agree to hardcode ascii as an encoding.

But, in any case, storing "lines" has a meaning in binary mode, as
witnessed by the fact that binary files in Python 3 have a readline()
method. This means storlines should still succeed for binary input, even
if it is made compatible with text input.

I would personally argue that the text transfer mode in FTP is an
ill-conceived feature from the start and ftplib should do whatever is
reasonable nowadays, rather than what looked reasonable 30 years ago.
History
Date User Action Args
2010-08-19 11:46:00pitrousetrecipients: + pitrou, amaury.forgeotdarc, vstinner, giampaolo.rodola, aymanhs, rdevaughn
2010-08-19 11:45:58pitroulinkissue6822 messages
2010-08-19 11:45:57pitroucreate