[issue3714] nntplib module broken by str to unicode conversion

Christian Heimes <[EMAIL PROTECTED]> added the comment: Applied in revision r67108 -- nosy: +christian.heimes resolution: accepted -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue3714] nntplib module broken by str to unicode conversion

STINNER Victor <[EMAIL PROTECTED]> added the comment: Le Tuesday 04 November 2008 01:08:25 Barry A. Warsaw, vous avez écrit : > Please fix the test as Benjamin suggests ("network") Done: see new attached patch. Added file: http://bugs.python.org/file11941/nntp-bytes-2.patch ___

[issue3714] nntplib module broken by str to unicode conversion

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11913/nntp-bytes.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3714] nntplib module broken by str to unicode conversion

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- assignee: -> benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

[issue3714] nntplib module broken by str to unicode conversion

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: Please fix the test as Benjamin suggests ("network"). While I'd prefer a more fleshed out test suite, I think in time you can add that. For now, this is still an improvement and likely the best we're going to get before 3.0. Thanks for wor

[issue3714] nntplib module broken by str to unicode conversion

Changes by STINNER Victor <[EMAIL PROTECTED]>: -- keywords: +needs review ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-lis

[issue3714] nntplib module broken by str to unicode conversion

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I haven't been able to examine the patch in depth, but one thing I see is that the test case needs to call test.support.requires("network"). -- nosy: +benjamin.peterson ___ Python tracker <[EMAI

[issue3714] nntplib module broken by str to unicode conversion

STINNER Victor <[EMAIL PROTECTED]> added the comment: After testing many different emails servers (POP3, IMAP4 and NNTP), I think that the best type is bytes and not str (unicode). Attached patch changes nntplib to use bytes: - write tests using Gmane NNTP public server - use bytes everywhere

[issue3714] nntplib module broken by str to unicode conversion

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11787/nntplib_unicode.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3714] nntplib module broken by str to unicode conversion

STINNER Victor <[EMAIL PROTECTED]> added the comment: As I did for POP3 (poplib) and IMAP4 (imaplib), nntplib should use bytes instead of characters because the charset may be different for each message and nntplib is unable to retreive the charset from the email header. _

[issue3714] nntplib module broken by str to unicode conversion

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3714] nntplib module broken by str to unicode conversion

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: This issue does not seem close to resolution and the nntplib is not critical enough to block the release, so I'm deferring this to rc3. -- nosy: +barry priority: release blocker -> deferred blocker __

[issue3714] nntplib module broken by str to unicode conversion

STINNER Victor <[EMAIL PROTECTED]> added the comment: Ok for UTF-8 which is a superset of ASCII and raise an error when trying to decode Latin1 or KOI-8. > You need to have a possibility to change encoding after object creation If you share a connection for the different groups, you will have

[issue3714] nntplib module broken by str to unicode conversion

Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: Oh, you need to read the comments first: - Use of ISO-8859-1 it's a bad idea here. See msg72776 for details. Moreover RFC-3977 explicitly say about UTF-8, so I think we need to use UTF-8. - Maybe set_encoding() isn't needed but you need to h

[issue3714] nntplib module broken by str to unicode conversion

STINNER Victor <[EMAIL PROTECTED]> added the comment: Instead of ASCII, I think that it would be better to use ISO-8859-1 since it's the most common charset. New patch: - use ISO-8859-1 as the default charset - remove set_encoding() method: was it really needed - use makefile('r', encoding=s

[issue3714] nntplib module broken by str to unicode conversion

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- priority: critical -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3714] nntplib module broken by str to unicode conversion

Senthil <[EMAIL PROTECTED]> added the comment: So, in effect, if we settle for ASCII as the default encoding, then the attached patch is good enough. Someone should check this in. Should it go in py3k, release? Because, without this patch(which is again simple), nntplib is almost unusable.

[issue3714] nntplib module broken by str to unicode conversion

Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: RFC-3977 say the following about headers: - The names of headers (e.g., "From" or "Subject") MUST be in US-ASCII. - Header values SHOULD use US-ASCII or an encoding based on it, such as RFC 2047 [RFC2047], until such time as another app

[issue3714] nntplib module broken by str to unicode conversion

Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: If I understand it correctly there is no "character set used by server" because every article can be in different encoding. RFC-3977 say: """ The character set of article bodies SHOULD be indicated in the article headers, and this SHOULD be

[issue3714] nntplib module broken by str to unicode conversion

Senthil <[EMAIL PROTECTED]> added the comment: When the default encoding 'ascii' failed, I tried, 'utf-8', even that failed to retrieve the message headers from comp.lang.python. 'latin1' succeeded. That was reason for my suggestion, considering 'latin1' to be superset of 'ascii'. But, yes che

[issue3714] nntplib module broken by str to unicode conversion

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Setting the default encoding as "ascii" is very conservative until we know the encoding actually used by the server. Are you sure that comp.lang.python uses latin-1? RFC3977, which re-defines the NNTP protocol, prefers utf-8 for the cha

[issue3714] nntplib module broken by str to unicode conversion

Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: Actually RFC-977 said all characters must be in ASCII, but RFC-3977 changed default character set to UTF-8. So I think UTF-8 must be default encoding, not Latin-1. Moreover Latin-1 can silently hide a real encoding, for example: >>> u'\u0422

[issue3714] nntplib module broken by str to unicode conversion

Senthil <[EMAIL PROTECTED]> added the comment: I verified the patch against the trunk. It works fine and solves the issue. But, I have a minor concern over 'ascii' as the default encoding, which you have chosen. For e.g, when I ran python3.0 nntplib.py (It would run tests, as the module does not

[issue3714] nntplib module broken by str to unicode conversion

Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: I've attached the patch which adds encoding parameter to the NNTP class. -- keywords: +patch Added file: http://bugs.python.org/file11292/nntplib.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue3714] nntplib module broken by str to unicode conversion

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Yes, the module is unusable in the current state. -- nosy: +amaury.forgeotdarc priority: -> critical ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3714] nntplib module broken by str to unicode conversion

New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>: The following commands fail badly: >>> from nntplib import NNTP >>> s = NNTP("free-text.usenetserver.com") Traceback (most recent call last): File "", line 1, in File "/py3k/Lib/nntplib.py", line 116, in __init__ self.welcome = se