~sschwarzer/ftputil#95: 
IBM AS/400 ftpserver

We need support for AS/400 ftpservers. I have created a dirty patch.

Status
RESOLVED WONT_FIX
Submitter
ftputiluser (unverified)
Assigned to
No-one
Submitted
9 years ago
Updated
9 years ago
Labels
enhancement library

schwa (unverified) 9 years ago · edit

Thanks for the report and especially the patch. :-)

Since AS/400 systems are probably very rare, I'd prefer not to put this into ftputil itself. The idea is to keep ftputil as simple as possible, especially if workarounds exist. An example of this approach is that ftputil only supports "Microsoft" and "Unix" directory listings out of the box, but you can write and use a custom parser.

From looking at the patch, I think you can have the AS/400 server support without modifying ftputil.

One option is to subclass the FTP session factory of your choice and put the AS/400 compatibility code in the constructor.

If you want to use different session factories, another option is to subclass FTPHost and override _make_session. An untested example:

class FTPHostWithAS400Support(ftputil.FTPHost):

    def _make_session(self):
        session = super(FTPHostWithAS400Support, self)._make_session()
        # Act on the session as in your patch.
        ...
        return session

For Python 3 you can omit the super arguments.

A potential disadvantage of this approach is that _make_session may not exist in future versions of ftputil, but it has existed for a long time and currently I don't see a reason why that should change (although it could of course).

If you're thinking of using a different session factory in the future (say, switching from ftplib.FTP to ftplib.FTP_TLS) and don't want to rely on _make_session, you should write a factory function or method which returns an FTPHost instance modified for AS/400 server support. This would be similar to the first approach with a custom session factory, but it would hide the creation/use of the session factory from other code.

Please let me know if you need more help.

schwa (unverified) 8 years ago · edit

I'm closing this ticket because workarounds exist (see comment:1) and the ticket reporter didn't reply with any problems of the workarounds.

In case the workarounds don't work as expected, please feel free to reopen the ticket.

Register here or Log in to comment, or comment via email.