[ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 09:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 05:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 07:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 04:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 16:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 12:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 09:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 05:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-890010 ] Odd warning behaviors
Bugs item #890010, was opened at 2004-02-03 17:25
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Georg Brandl (birkenfeld)
Summary: Odd warning behaviors
Initial Comment:
This is from Evan Simpson, on the zope-dev list. The
bulk have to do with what happens if __name__ is set to
None:
Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> range(1.0)
__main__:1: DeprecationWarning: integer argument
expected, got float
[0]
>>>
So far, so good. However:
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> __name__=None
>>> range(1.0)
[]
>>> 1+1
Traceback (most recent call last):
File "/usr/lib/python2.3/warnings.py", line 57, in warn
warn_explicit(message, category, filename, lineno,
module, registry)
File "/usr/lib/python2.3/warnings.py", line 63, in
warn_explicit
if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
>>>
...and...
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import warnings
>>> warnings.simplefilter("error",
category=DeprecationWarning)
>>> range(1.0)
[]
>>> 1+1
Traceback (most recent call last):
File "/usr/lib/python2.3/warnings.py", line 57, in warn
warn_explicit(message, category, filename, lineno,
module, registry)
File "/usr/lib/python2.3/warnings.py", line 92, in
warn_explicit
raise message
DeprecationWarning: integer argument expected, got
float
>>>
...and...
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import pdb
>>> __name__ = None
>>> pdb.run('range(1.0)')
> (1)?()
(Pdb) s
--Call--
> /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning:
tp_compare didn't return
-1 or -2 for exception
i = max(0, len(stack) - 1)
[traceback snipped]
Looks like something isn't properly propagating
exceptions.
Cheers,
Evan @ 4-am
--
>Comment By: Tim Peters (tim_one)
Date: 2006-01-17 16:53
Message:
Logged In: YES
user_id=31435
No, it's certainly not OK for range(1.0) to raise either
DeprecationWarning or TypeError depending on what __name__
happens to be. But I may not understand what you mean.
This is a screen scrape from current SVN trunk, on Windows:
>>> __name__ = None; range(1.0)
None:1: DeprecationWarning: integer argument expected, got float
[0]
I don't see TypeError there, so I'm not sure what
"""
In current SVN heads, range(1.0) gives DeprecationWarning and
__name__=None; range(1.0) gives TypeError.
"""
means.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 17:28
Message:
Logged In: YES
user_id=1188172
In current SVN heads, range(1.0) gives DeprecationWarning and
__name__=None; range(1.0) gives TypeError.
Is this okay?
--
Comment By: Tim Peters (tim_one)
Date: 2004-02-16 19:51
Message:
Logged In: YES
user_id=31435
I'm listening, but with half of part of one ear. Have to agree
convertsimple() was wrong in these cases, but can't make
time for more than that. Reassigned to Jeremy, partly at
random (his is one of the names that shows up as a recent
getargs.c changer).
--
Comment By: Michael Hudson (mwh)
Date: 2004-02-12 09:09
Message:
Logged In: YES
user_id=6656
Is anyone listening?
--
Comment By: Michael Hudson (mwh)
Date: 2004-02-04 10:05
Message:
Logged In: YES
user_id=6656
Oops, wrong file.
--
Comment By: Michael Hudson (mwh)
Date: 2004-02-04 10:03
Message:
Logged In: YES
user_id=6656
How's this? It's horrible, but I'm not sure that can be avoided.
--
Comment By: Michae
[ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 18:47 Message: Logged In: YES user_id=12800 I hear what you're saying, but so far, it has been more convenient for developers when the generator outputs native line endings. I can see a case for a flag or other switch on the Generator instance to force RFC 2822 line endings. I would suggest joining the email-sig and posting a request there so the issue can be discussed as an RFE. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 11:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 07:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 04:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
