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 martin.panter
Recipients Ankur.Ankan, Lita.Cho, berker.peksag, ezio.melotti, jesstess, martin.panter, mattrope, pitrou
Date 2014-08-22.01:47:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1408672062.47.0.933920911809.issue1186900@psf.upfronthosting.co.za>
In-reply-to
Content
NNTPConnectError does still seem a slightly awkward name. I would go for NNTPConnectionError instead, but I’m also happy to put my bikeshed paint away let this patch be applied as is :)

Handling of NNTPTemporaryError with a code of 400 is similar to handling of this EOFError. But I guess there is not much you could do with the API unless you made a separate subclass for 400 errors (like all the new EnvironmentError/OSError subclasses), which would be rather severe. My current workaround looks a bit like this:

try:
    [_, info] = nntp.body(...)
except NNTPTemporaryError as err:
    [code, *msg] = err.response.split(maxsplit=1)
    if code != "400":
        raise
except EOFError:  # Or NNTPConnect(ion)Error
    msg = ()
else:
    break  # Handle successful response
[msg] = msg or ("Server shut down connection",)
# Handle connection shutdown by server
History
Date User Action Args
2014-08-22 01:47:42martin.pantersetrecipients: + martin.panter, pitrou, mattrope, ezio.melotti, jesstess, berker.peksag, Ankur.Ankan, Lita.Cho
2014-08-22 01:47:42martin.pantersetmessageid: <1408672062.47.0.933920911809.issue1186900@psf.upfronthosting.co.za>
2014-08-22 01:47:42martin.panterlinkissue1186900 messages
2014-08-22 01:47:41martin.pantercreate