[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?

[SourceForge.net]

Bugs item #1645148, was opened at 2007-01-26 10:04
Message generated for change (Comment added) made by aalbrecht
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&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: Open
Resolution: None
Priority: 7
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?

Initial Comment:
>>> from email.MIMEText import MIMEText
>>> o=MIMEText('hello')
>>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
>>> o.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
>>>


The '6 7 8\n\t9 1 2 3'  clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :

'6 7 8 \n\t9 1 2 3'


? 

as there is also the space preserved in 
'6 7 8 9 \n\nhello'


--

Comment By: Andi Albrecht (aalbrecht)
Date: 2007-08-17 08:18

Message:
Logged In: YES 
user_id=1693212
Originator: NO

The problem occurs, when you are using strings, not when you use
the Header class directly.
The reason for this behaviour is the way the Generator creates
Header instances from strings: It initializes the class with
continuation_ws set to '\t' instead of the default ' ' 
(email/generator.py in method _write_headers).

>>> from email.MIMEText import MIMEText
>>> msg = MIMEText("Just a test.")
>>> msg["Subject"] = "foo "*22
>>> print msg.as_string()
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
foo
foo foo foo foo foo 

Just a test.
>>> 

Tab as the whitespace character is no problem for most email clients. But
i.e. Outlook removes it.

When using the Header class you get the following

>>> from email.MIMEText import MIMEText
>>> from email.header import Header
>>> msg = MIMEText("Just a test.")
>>> msg["Subject"] = Header("foo "*22)
>>> print msg.as_string()
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
foo foo foo
 foo foo foo 

Just a test.
>>> 

The last message shows up in Outlook correctly.

--

Comment By: kxroberto (kxroberto)
Date: 2007-08-06 17:18

Message:
Logged In: YES 
user_id=972995
Originator: YES

the bug appears to be quite frequent now (once one knows it :-) ).
Possibly for the same reason one sees this kind of subject alteration by
one space often on the usenet.

--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-06-09 05:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

Quoting RFC2822 section 2.2.3
: 

"""The general rule is that wherever this standard allows for folding
white space (not simply WSP characters), a CRLF may be inserted before any
WSP. For example, the header field:

   Subject: This is a test

can be represented as:

   Subject: This
is a test

[...]Unfolding is accomplished by simply removing any CRLF that is
immediately followed by WSP."""

That is, folding is done by inserting ONLY the sequence CRLF before any
folding whitespace. When the header is interpreted, the whitespace is NOT
removed, only the CRLF. The posted Subject header should become "Subject: 1
2 3...7 8\n\r 9 1 2...'

I think this is a bug in the email.header.Header class; its __init__ says,
about the continuation_ws argument: "[it] must be RFC 2822 compliant
folding whitespace (usually either a space or a hard tab) which will be
prepended to continuation lines.". Folding does not involve *prepending*
any whitespace, just inserting CRLF right before *existing* whitespace.

Note that this is wrong even for the old RFC 822 (with slightly different
rules for line folding.)


--

Comment By: kxroberto (kxroberto)
Date: 2007-06-08 12:11

Message:
Logged In: YES 
user_id=972995
Originator: YES

What would be the RFC definition for a correct auto-line break in a
(subject) mail header line?
Wouldn't it be more simple to not do any auto-line break for the subject?
or is there a requirement for the line break in the RFC. Don't think any
reader program would fai

[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory

[SourceForge.net]

Bugs item #1776160, was opened at 2007-08-17 13:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&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: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bj�rn Lindqvist (sonderblade)
Assigned to: Nobody/Anonymous (nobody)
Summary: Buffer overflow when listing deeply nested directory

Initial Comment:
This code:

import os
import os.path
TARGET='C:/code/python/foo'
base = TARGET
for x in range(200):
subdirs = os.listdir(base)
base = os.path.join(base, subdirs[0])
print base

Produces a TypeError (buffer overflow) when run on a to deeply nested directory 
for windows to handle:

.. more output here..
C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo 
bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo 
bar.png\foo bar.png\foo bar.p
ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo 
bar.png
Traceback (most recent call last):
  File "killdir.py", line 6, in 
subdirs = os.listdir(base)
TypeError: listdir() argument 1 must be (buffer overflow), not str


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1000] Test

[Martin v. Löwis]

New submission from Martin v. Löwis:

This contains a word egastono that is unlikely to occur elsewhere

--
messages: 55039
nosy: loewis
severity: normal
status: open
title: Test

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1619060 ] bisect on presorted list

[SourceForge.net]

Feature Requests item #1619060, was opened at 2006-12-19 22:14
Message generated for change (Comment added) made by karlb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1619060&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: Extension Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeffrey C. Jacobs (timehorse)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bisect on presorted list

Initial Comment:
The python and c implementation of bisect do not support custom-sorted lists 
using the list.sort method.

In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I 
have added 3 corresponding parameters to the bisect methods for bisection and 
insort (insert-sorted) corresponding to the parameters in sort.  This would be 
useful if a list is initially sorted by its sort method and then the client 
wishes to maintain the sort order (or reverse-sort order) while inserting an 
element.  In this case, being able to use the same, arbitrary binary function 
cmp, unary function key and boolean reverse flag to preserve the list order.

The change imposes 3 new branch conditions and potential no-op function calls 
for when key is None.  I have here implemented and partially tested the python 
implementation and if someone besides me would find this useful, I will update 
the _bisectmodule.c for this change as well.

The Heap functions may also find use of an arbitrary predicate function so I 
may look at that later, but because bisect goes hand in hand with sorting, I 
wanted to tackle that first.

--

Comment By: Karl Bartel (karlb)
Date: 2007-08-17 17:09

Message:
Logged In: YES 
user_id=787
Originator: NO

+1 for adding a reverse parameter.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-12-19 22:43

Message:
Logged In: YES 
user_id=80475
Originator: NO

I'm -1 on this patch.  At first blush it would seem nice to progagate
sort's notion of a key= function; however, sort() is an all at once
operation that can guarantee the function gets called only once per key. 
In contrast, bisect() is more granualar so consecutive calls may need to
invoke the same key= function again and again.  This is almost always the
the-wrong-way-to-do-it (the key function should be precomputed and either
stored separately or follow a decorate-sort pattern).  By including custom
sorting in bisect's API we would be diverting users away from better
approaches.

A better idea would be to create a recipe for a SortedList class that
performed pre-calculated custom keys upon insertion and maintained an
internal, decorated list.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1619060&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1698167 ] xml.etree document element.tag

[SourceForge.net]

Bugs item #1698167, was opened at 2007-04-11 06:25
Message generated for change (Comment added) made by dlocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698167&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: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: paul rubin (phr)
Assigned to: Fredrik Lundh (effbot)
Summary: xml.etree document element.tag

Initial Comment:
The xml.etree docs vaguely mention an implementation-dependent Element 
interface without describing it in any detail.  I could not figure out from the 
docs how to get the tag name of an element returned from (say) the getiterator 
interface.  That is, for an element like , I wanted the string "foo".  
Examining the library source showed that e.tag does the job, at least some of 
the time, and that was enough to get my app working.  Could the actual 
situation please be documented--thanks.

--

Comment By: dlocke (dlocke)
Date: 2007-08-17 18:56

Message:
Logged In: YES 
user_id=1525611
Originator: NO

I concur that any documentation about the Element object seems to be
missing.  Is there any timetable for getting this added to the
documentation?

--

Comment By: Fredrik Lundh (effbot)
Date: 2007-04-13 13:32

Message:
Logged In: YES 
user_id=38376
Originator: NO

Looks like the entire Element section is missing from the current
documentation.  Thanks for reporting this; I'll take a look when I find the
time.

In the meantime, you'll find additional documentation here:
http://effbot.org/zone/element.htm

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698167&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1776674 ] glob.glob inconsistent

[SourceForge.net]

Bugs item #1776674, was opened at 2007-08-18 02:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776674&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: norbidur (norbidur)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob.glob inconsistent

Initial Comment:
On windows, glob.glob gives different results if you use a wildcard or not and 
if you use unix-style paths.

exemple : 
import glob
print glob.glob("c:/tmp/3691674.jpg")
print glob.glob("c:/tmp/3691674.jpg*")
print glob.glob("c:/res.txt")
print glob.glob("c:/res.txt*")

gives :
['c:/tmp/3691674.jpg']
['c:/tmp\\3691674.jpg']
['c:/res.txt']
['c:/res.txt']


the two first calls give the same result but one with a platform specific 
separator, and not the other.
One can think that if there is no wildcard, this is normal behavior to return 
the path given to glob.glob but then I have the second inconsitency : in that 
case the last result should be c:\\res.txt.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776674&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1776696 ] tempfile.TemporaryFile differs between platforms

[SourceForge.net]

Bugs item #1776696, was opened at 2007-08-18 02:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kenneth Loafman (loafman)
Assigned to: Nobody/Anonymous (nobody)
Summary: tempfile.TemporaryFile differs between platforms

Initial Comment:
When running the following:

import tempfile
foo=tempfile.TemporaryFile
type(foo)

Linux returns:


Windows and Cygwin return:


It should return the same across platforms, or return an undefined indication 
if not possible.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com