SilentGhost <ghost....@gmail.com> added the comment:
Here is a patch incorporating some of the changes proposed by Eric:
* drop callback, return generator of (filename, fact-dict)
> Aren't you modifying the state on the server (via "OPTS MLST"), and then if
> you make a subsequent call without specifying "facts" you'll be using the
> value of "facts" from the previous call to MLSD? I don't think that's
> desirable, but short of calling "OPTS MLST" every time (possibly with the
> results of an initial FEAT) there's no way around it.
This is the behaviour according to RFC. MLSD will return the set of facts,
until a new OPTS MLST issued.
> I don't like the "isdigit" test. Shouldn't this decision be left to the
> caller? What if a fact happens to look like an integer some of the time, but
> not always? Maybe "unique" is a hex string. I don't think you'd want it
> converted to an int on the occasions where it was all decimal digits, but a
> string otherwise. Also look at your "modify" facts. Those are not very useful
> as ints.
Drop the isdigit test: some value such as timestamps ('modify') might be
"digits" for one files and would remain strings for the others.
> If a fact=value string does not have an '=', you silently ignore it. I'd
> rather this raise an exception and not pass silently. It's not compliant. You
> should have a test for this.
I don't think it should raise an error, i'd rather just pass it to the caller.
There is a wide variety of possible non-compliant responses. For example there
is a rigid format for time stamps, do we have to check for that?
One thing, that my patch doesn't do at the moment, but I think would be useful
is to normalise all fact names to lower case. What do you think?
I hope that MLSD_DATA now covers wider range of cases (it's from
http://tools.ietf.org/html/rfc3659#section-7.7.4). Note that server MUST NOT
return facts that weren't requested.
What would be the return values check here?
----------
Added file: http://bugs.python.org/file21047/issue11072.diff
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
