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 r.david.murray
Recipients Dmitry.Jemerov, giampaolo.rodola, ncoghlan, pitrou, r.david.murray
Date 2010-09-20.02:04:40
SpamBayes Score 1.7216512e-10
Marked as misclassified No
Message-id <1284948286.97.0.989901474065.issue9360@psf.upfronthosting.co.za>
In-reply-to
Content
I tested this against my existing py3k nttp client code.

Why is it a good thing to make file a keyword only parameter? But given that it is, line 720 needs to use it as such, which omission means your missing at least one test :)

On line 193 you index fmt, and *then* you check the length.  When the number of tokens is too long, an IndexError is raised.  (Note that the offending overview line comes from the gmane group comp.lang.python.mime.devel, and the offense is an extra '' field on one of the records.  No idea why it got added to that one record.  Looks like it is message 701, artid <4111BBA9.3040302@harvee.org>)

Could the 'date' field in the xover headers also be a DateTime rather than a string?  And :bytes and :lines be ints?  Or is that being to DWIMish?  If the date field isn't returned as a datetime, though, should there be a helper method for converting it, or should we just assume that email.utils mktime_tz and parsedate_tz?

Am I correct that the purpose of _NNTPBase is to make testing easier?

There seem to be only three lines of code in common between the file and the non-file case in _getlongresp.  I think it would be clearer to make them two different routines, or at least move the three common lines to the top and then do an if test on file is None (that is, put the simpler, non-file case first).

My little nttp client script doesn't really test very much of the nttplib interface, nor is it very complex.  The change to xover considerably simplified that part of my script, so I very much like that change.  I was also able to drop my implementation of decode_header.  So overall this patch is significant improvement, IMO.

I haven't given the code as thorough a review as might be optimal, but I certainly think you are headed in the right direction.
History
Date User Action Args
2010-09-20 02:04:47r.david.murraysetrecipients: + r.david.murray, ncoghlan, pitrou, giampaolo.rodola, Dmitry.Jemerov
2010-09-20 02:04:46r.david.murraysetmessageid: <1284948286.97.0.989901474065.issue9360@psf.upfronthosting.co.za>
2010-09-20 02:04:43r.david.murraylinkissue9360 messages
2010-09-20 02:04:40r.david.murraycreate