[NEWBIE] ftplib error?

[Steve Holden]

I would recommend setting debugging, but unfortunately it's the initializer
that's failing, before you'd have a chance to call its set_debuglevel()
method. __init__() in 2.0 starts out:

def __init__(self, host = '', user = '', passwd = '', acct = ''):
  # Initialize the instance to something mostly harmless
  self.debugging = 0

You might try modifying the module source to intialize self.debugging to 2?
Mostly what you appear to need is more information!

regards
 Steve
--
Consulting, training, speaking: http://www.holdenweb.com/
Python Web Programming: http://pydish.holdenweb.com/pwp/


"Bruce Dykes" <bkd at graphnet.com> wrote in message
news:mailman.1011193524.25209.python-list at python.org...
> ----- Original Message -----
> From: "Steve Holden" <sholden at holdenweb.com>
> Newsgroups: comp.lang.python
> To: <python-list at python.org>
> Sent: Wednesday, January 16, 2002 08:42
> Subject: Re: [NEWBIE] ftplib error?
>
>
>
> > > Is this an authentication failure? That shouldn't be happening because
> the
> > > interactive ftp session works just fine. Does ftplib not understand
that
> > an
> > > IP address is equivalent to a name? That shouldn't be happening
either.
> > >
> > > What's going on here?
> >
> > Don't want to seem simple-minded, but does your interactive FTP client
> work
> > from the same machine you are running the Python script on? The error
> > message seems pretty unequivocal: the FTP server isn't prepared to
accept
> > your request.
> >
> > Given that you're using private IP addresses, maybe there's a firewall
> > component between your machine and the server that's rejectong your FTP
> > connection?
>
> The IP addy, userid and password have all been changed to protect the
> guilty, but yes, the ftp client (Windows' default client) is running on
the
> same machine the code is running on, and the userid, password, directory,
> and ip addy strings are all exactly the same between the interactive
session
> and the scripting code. All the printed server responses in the
interactive
> session look to be quite standard, though the unprinted protocol exchange
> may have some funky goings on.
>
> > Otherwise, replace your host address with some known-accessible public
> host
> > and see what gives.
>
> Yep...I just needed to rule out anything quirky in my code or with the
> library, and I wasn't sure about the traceback...
>
> thanks
> bkd
>
>
>