[issue9360] nntplib cleanup

Antoine Pitrou added the comment: I've committed the latest patch in r85111. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: And here is a patch integrating doc fixes and updates. -- Added file: http://bugs.python.org/file19011/nntplib_cleanup7.patch ___ Python tracker ___

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: Here is a patch adding tests for article(), head() and body(), as well as for the "file" parameter. As far as code is concerned, this should now be complete. Documentation remains to be updated :) -- Added file: http://bugs.python.org/file19002/nntpli

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: Yes, unescaped utf-8 is explicitly allowed in headers by RFC 3977: The content of a header SHOULD be in UTF-8. However, if an implementation receives an article from elsewhere that uses octets in the range 128 to 255 in some other manner, it MAY pass

[issue9360] nntplib cleanup

R. David Murray added the comment: OK. It doesn't seem all that likely that we'll be adding parameters, but you never know. So I'm OK with file becoming keyword only. As for the overview headers...if they aren't decoded through decode_header already, why are they unicode? If they haven't b

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: > Gah. I reviewed patch4, didn't noticed today's update :( Oops, I'm sorry for that. It turns out most of your comments are useful anyway. > Why is it a good thing to make file a keyword only parameter? I was thinking that if we want to add other function pa

[issue9360] nntplib cleanup

R. David Murray added the comment: Gah. I reviewed patch4, didn't noticed today's update :( -- ___ Python tracker ___ ___ Python-bugs

[issue9360] nntplib cleanup

R. David Murray added the comment: 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,

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: > To make the distinction easier to remember, would it help if the > methods that are currently set to return bytes instead accepted the > typical encoding+errors parameters, with parallel *b APIs to get at > the raw bytes? Not really, no. For raw messages, whi

[issue9360] nntplib cleanup

Nick Coghlan added the comment: To make the distinction easier to remember, would it help if the methods that are currently set to return bytes instead accepted the typical encoding+errors parameters, with parallel *b APIs to get at the raw bytes? My concern with the current API is that there

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: Here is the current state of the cleanup work. Coding is roughly finished; most methods are unit-tested. The documentation remains to be done. Review welcome. -- stage: -> patch review Added file: http://bugs.python.org/file18931/nntplib_cleanup5.patc

[issue9360] nntplib cleanup

Changes by Antoine Pitrou : Added file: http://bugs.python.org/file18894/nntplib_cleanup4.patch ___ Python tracker ___ ___ Python-bugs-list mai

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: Here is a further, still work-in-progress, patch. I'm posting it here so that interested people can give advice. -- Added file: http://bugs.python.org/file18882/nntplib_cleanup3.patch ___ Python tracker

[issue9360] nntplib cleanup

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue9360] nntplib cleanup

R. David Murray added the comment: Assuming we can break backward compatibility, it sounds fine to me. -- ___ Python tracker ___ ___ P

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: Here is an updated patch, but it's a work in progress. Since we are breaking compatibility anyway, I think a larger cleanup is deserved. For example: - remove old exception aliases - make return types consistent (for example, newgroups() should returned struc

[issue9360] nntplib cleanup

Antoine Pitrou added the comment: Note that according to RFC 3977, “The character set for all NNTP commands is UTF-8”. But it also says this about multi-line data blocks: Note that texts using an encoding (such as UTF-16 or UTF-32) that may contain the octets NUL, LF, or CR other than a

[issue9360] nntplib cleanup

R. David Murray added the comment: Correct, if by 'article content' you mean what is returned by the article command. So I think it is necessary to be able to get bytes for two commands: article and body. Then for symmetry it should also be possible to get bytes from the head command. (It

[issue9360] nntplib cleanup

Dmitry Jemerov added the comment: This is an issue only for the actual article content, right? I'll be happy to extend the API to allow getting the original bytes of the article content, while keeping the rest of API (like group names) string-based. -- ___

[issue9360] nntplib cleanup

R. David Murray added the comment: I haven't looked at the patch in detail, but if my quick skim is correct, it looks like you are decoding using latin1. If you don't provide any way to get at the original bytes (which I presume you don't if you have "converted the API to return strings"), t

[issue9360] nntplib cleanup

New submission from Dmitry Jemerov : The patch performs an extensive cleanup of nntplib: - Change API methods to return strings instead of bytes. This breaks API compatibility, but given that the parameters need to be passed as strings and many of the returned values would need to be passed to