FTP v. ftplib

Since I’m already complaining about Python, I might as well add my dislike of one other standard library: ftplib. I don’t have any criticism of how the library works, I just don’t like the names given to many of the functions.

Here’s the thing: There are a set of commands defined by the FTP protocol that a client program sends to the server. These are three- or four-letter codes like

Command Functions
CWD change working directory
LIST list the contents of a directory
DELE delete file
RETR retrieve a file from the server
STOR store a file on the server
QUIT quit the session

Command-line ftp client programs, like the ftp that’s on your Macintosh, Linux, or Windows machine, use these commands to communicate with the server but not with the user. User commands tend to be more friendly and easier to remember:

Command Functions
cd change directory
dir or ls list the contents of a directory
delete delete file
get get a file from the server
put put a file on the server
quit or bye quit the session

(OK, cd isn’t the most friendly command, but it’s easy to remember because it’s the same command used by the shell.)

So which set of names does ftplib use for its FTP methods? I’d rather it used the second set, because that’s what I’m more familiar with,1 but if it wanted to use the server commands, I could live with that, too. Maddeningly, uses a mixture:

Method Functions
cwd() change directory
dir() list the contents of a directory
delete delete file
retrlines() retrieve a file from the server (ASCII mode)
retrbinary() retrieve a file from the server (binary mode)
storlines() store a file on the server (ASCII mode)
storbinary() store a file on the server (binary mode)
quit() quit the session

We see the echoes of CWD, RETR, and STOR from the server command set, but also dir and delete from the user command set.

I’m sure that if I used ftplib regularly, I’d get used to this set of names, but I don’t and I haven’t. A more consistent set of names—one way or the other—would make the library easier to use.

I also wish the distinction between ASCII and binary transfer was handled by a flag passed as an argument rather than by separate methods for each mode. That would allow the method names to match RETR and STOR better and would eliminate the rather silly lines suffix.

  1. Both from using command line ftp itself and from using the Net::FTP Perl module, whose method names match the user-level names almost perfectly. 

4 Responses to “FTP v. ftplib”

  1. Carl says:

    The problem with the “batteries included” philosophy of Python is that a lot of batteries got written back in the Python 2.0 days and haven’t been updated since, but because they already exist, no third party libraries catch on to serve the same niche. Python date/time handling is also pretty bad for this same reason. Http is sort of an exception that proves the rule. It’s important enough for enough people that urllib2 got written and added to the standard library, but it still needs more clean up if it were possible.

    I’m curious if Google’s Go language will be able to escape this problem. It has a mechanism for importing from github as part of the language spec. It could give them the advantages of Perl’s CPAN without the need for centralization if the experiment works, but that remains to be seen.

  2. Clark says:

    Have you looked at using fabric to do sftp? (I never ftp anymore) You can see the sftp code to see how to use it.

  3. Dr. Drang says:

    Much as I like seeing your comments here, Carl, you really should be expanding on ideas like this on your blog. It would be even better than the 3D wigglepics.

    Clark, I stripped the FTP code out of the few scripts it was in a while ago. But the bad taste lingered, hence this post. I’m bookmarking fabric in case I need SFTP in the future.

  4. Ask Bjørn Hansen says:

    Carl: The “centralization” of CPAN also brings the advantage of having lots and lots of tools for uploading, searching and exploration, automated testing at scale, etc etc.

    The amount of CPAN that’s truly centralized is relatively small. Certainly smaller than github (the example you used for “not centralized”).