[ python-Bugs-1591774 ] Urllib2.urlopen() raises OSError w/bad HTTP Location header

2007-03-13 Thread SourceForge.net
Bugs item #1591774, was opened at 2006-11-07 03:08
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591774&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: nikitathespider (nikitathespider)
Assigned to: Nobody/Anonymous (nobody)
Summary: Urllib2.urlopen() raises OSError w/bad HTTP Location header

Initial Comment:
The documentation for urllib2.urlopen() says that it
"[r]aises URLError on errors". But if urllib2 requests
a resource from a (misconfigured) Web server and that
server returns 302 response with the Location header
set to "file:", urlopen raises "OSError: [Errno 2] No
such file or directory: ''". I have seen such a
misconfiguration in the wild; I've also created a URL
on my server that reproduces the problem in case the
real-world URL disappears or is fixed. Both URLs are in
the attachment with code to reproduce the problem.

I can recreate this under Python 2.3 - 2.5 under Mac OS
X, FreeBSD and Win2k.

I would be satisfied if the module simply followed the
documentation and actually returned URLError.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 08:15

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

Fixed with said patch. Thanks for the report!

--

Comment By: Jerry Seutter (jseutter)
Date: 2007-02-24 23:23

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

Fix submitted in patch 1668100 - urllib2.urlopen() raises OSError instead
of URLError

http://sourceforge.net/tracker/index.php?func=detail&aid=1668100&group_id=5470&atid=305470

--

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



[ python-Feature Requests-1634717 ] csv.DictWriter: Include offending name in error message

2007-03-13 Thread SourceForge.net
Feature Requests item #1634717, was opened at 2007-01-13 14:53
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634717&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: Accepted
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: csv.DictWriter: Include offending name in error message

Initial Comment:
In csv.py, class DictWriter, method _dict_to_list, when rowdict contains a key 
that is not a known field name, a ValueError is raised, but no reference to the 
offending name is given.
As the code iterates along the dict keys, and stops at the first unknown one, 
its trivial to include such information.
Replace lines:

if k not in self.fieldnames:
raise ValueError, "dict contains fields not in fieldnames"

with:

if k not in self.fieldnames:
raise ValueError, "dict contains field not in fieldnames: %r" % k


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 09:32

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

Patch was applied, closing this as Accepted.

--

Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-15 00:04

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

Even better would be a list of all extraneous fields fields.

I offered patch 1635454.

--

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



[ python-Bugs-1679652 ] error in the sys module documentation

2007-03-13 Thread SourceForge.net
Bugs item #1679652, was opened at 2007-03-13 10:57
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=1679652&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Fillinger (daikinoko)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in the sys module documentation

Initial Comment:
In this text from the sys module documentation: 
http://docs.python.org/lib/module-sys.html

"argv
The list of command line arguments passed to a Python script. argv[0] is 
the script name (it is operating system dependent whether this is a full 
pathname or not). If the command was executed using the -c command line option 
to the interpreter, argv[0] is set to the string '-c'. If no script name was 
passed to the Python interpreter, argv has zero length."

the second argv[0] should be argv[1] because argv[0] is the name of the script.

--

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



[ python-Bugs-1622896 ] Exception when compressing certain data with bz2

2007-03-13 Thread SourceForge.net
Bugs item #1622896, was opened at 2006-12-27 14:26
Message generated for change (Comment added) made by indi4source
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Gontmakher (gsasha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exception when compressing certain data with bz2

Initial Comment:
Looks like an out-of-bounds array access... might be a security problem.

The attached file includes a script which, when executed, tries to pack the two 
given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu 
Edgy), the program fails with the following exception: 

Traceback (most recent call last):
  File "test.py", line 13, in ?
block = compressor.compress(open("compress-0067/"+file, "rb").read())
ValueError: the bz2 library has received wrong parameters


The problem occurs under either python2.4 or 2.5 (I don't have other versions 
to test with).

Sorry, the file is large... I tried to reduce the example to smaller number of 
files etc., but no such luck. The file is too large to be submitted here as an 
attachment, so I have uploaded it to 
http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2



--

Comment By: ralf (indi4source)
Date: 2007-03-13 12:25

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

I had the same problem with the BZ2Compressor. (reproducible under 2.5)
It was working fine with BZ2File.

Unfortunately I cannot check the proposed fix as I don't have the
environment to compile python...

--

Comment By: Alex Gontmakher (gsasha)
Date: 2006-12-28 10:17

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

I saw that the effect occurs only when one compressor finishes and is
destroyed, and then the second one gives the "wrong parameters". Usually,
for such an effect to happen, the first compressor must have some permanent
effect on the system - and since it was destroyed before the second one was
created, it was only natural to assume that the reason was an out of bounds
access.

My approach is that such a bug should be suspected as an out-of-bounds
access until shown othervise, especially in a language like Python where it
is natural to assume that such problems shouldn't occur and that it is safe
to use security-wise. Of course I'll be happy to learn that it's just a
simple bug.

On a related note, will the fix be backported to all the relevant Python
versions? If you understand why the bug happens (I don't, sorry, have no
idea of internals of Python), you might be able to generate a compact test
case that would capture the erroneous behavior.

Best regards,
Alex


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-12-28 09:27

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

I don't understand why you think this is an array out of bounds.  I ran
your test case under valgrind and it reported no problems.

I can reproduce the problem.  I have attached a patch that fixes the
problem for me.  I am not certain it's the correct fix however.  The unit
tests pass with this modification.
File Added: bz2.diff

--

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



[ python-Bugs-1622896 ] Exception when compressing certain data with bz2

2007-03-13 Thread SourceForge.net
Bugs item #1622896, was opened at 2006-12-27 13:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alex Gontmakher (gsasha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exception when compressing certain data with bz2

Initial Comment:
Looks like an out-of-bounds array access... might be a security problem.

The attached file includes a script which, when executed, tries to pack the two 
given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu 
Edgy), the program fails with the following exception: 

Traceback (most recent call last):
  File "test.py", line 13, in ?
block = compressor.compress(open("compress-0067/"+file, "rb").read())
ValueError: the bz2 library has received wrong parameters


The problem occurs under either python2.4 or 2.5 (I don't have other versions 
to test with).

Sorry, the file is large... I tried to reduce the example to smaller number of 
files etc., but no such luck. The file is too large to be submitted here as an 
attachment, so I have uploaded it to 
http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2



--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 12:35

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

I think Neal's patch is correct, the equivalent needed to be applied in
several other places as well.

Committed as rev. 54336, 54337 (2.5).

--

Comment By: ralf (indi4source)
Date: 2007-03-13 11:25

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

I had the same problem with the BZ2Compressor. (reproducible under 2.5)
It was working fine with BZ2File.

Unfortunately I cannot check the proposed fix as I don't have the
environment to compile python...

--

Comment By: Alex Gontmakher (gsasha)
Date: 2006-12-28 09:17

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

I saw that the effect occurs only when one compressor finishes and is
destroyed, and then the second one gives the "wrong parameters". Usually,
for such an effect to happen, the first compressor must have some permanent
effect on the system - and since it was destroyed before the second one was
created, it was only natural to assume that the reason was an out of bounds
access.

My approach is that such a bug should be suspected as an out-of-bounds
access until shown othervise, especially in a language like Python where it
is natural to assume that such problems shouldn't occur and that it is safe
to use security-wise. Of course I'll be happy to learn that it's just a
simple bug.

On a related note, will the fix be backported to all the relevant Python
versions? If you understand why the bug happens (I don't, sorry, have no
idea of internals of Python), you might be able to generate a compact test
case that would capture the erroneous behavior.

Best regards,
Alex


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-12-28 08:27

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

I don't understand why you think this is an array out of bounds.  I ran
your test case under valgrind and it reported no problems.

I can reproduce the problem.  I have attached a patch that fixes the
problem for me.  I am not certain it's the correct fix however.  The unit
tests pass with this modification.
File Added: bz2.diff

--

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



[ python-Bugs-1679784 ] "my" should be "may"

2007-03-13 Thread SourceForge.net
Bugs item #1679784, was opened at 2007-03-13 15:18
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=1679784&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: edward (edwarddsp)
Assigned to: Nobody/Anonymous (nobody)
Summary: "my" should be "may"

Initial Comment:
In the third last paragraph of section 8.3 of the tutorial, the text "One my 
also instantiate an exception" should be "One may also instantiate an 
exception".


--

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



[ python-Bugs-1679784 ] "my" should be "may"

2007-03-13 Thread SourceForge.net
Bugs item #1679784, was opened at 2007-03-13 13:18
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679784&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: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: edward (edwarddsp)
Assigned to: Nobody/Anonymous (nobody)
Summary: "my" should be "may"

Initial Comment:
In the third last paragraph of section 8.3 of the tutorial, the text "One my 
also instantiate an exception" should be "One may also instantiate an 
exception".


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 13:22

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

Thanks for the report, this is already fixed in SVN.

--

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



[ python-Bugs-1679652 ] error in the sys module documentation

2007-03-13 Thread SourceForge.net
Bugs item #1679652, was opened at 2007-03-13 09:57
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679652&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: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: David Fillinger (daikinoko)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in the sys module documentation

Initial Comment:
In this text from the sys module documentation: 
http://docs.python.org/lib/module-sys.html

"argv
The list of command line arguments passed to a Python script. argv[0] is 
the script name (it is operating system dependent whether this is a full 
pathname or not). If the command was executed using the -c command line option 
to the interpreter, argv[0] is set to the string '-c'. If no script name was 
passed to the Python interpreter, argv has zero length."

the second argv[0] should be argv[1] because argv[0] is the name of the script.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 13:23

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

No, it's correct as it is. There *is no* scriptname with -c.

--

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



[ python-Bugs-1680034 ] Importing SystemRandom wastes entropy.

2007-03-13 Thread SourceForge.net
Bugs item #1680034, was opened at 2007-03-13 17:17
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=1680034&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steve Tyler (stephent98)
Assigned to: Nobody/Anonymous (nobody)
Summary: Importing SystemRandom wastes entropy.

Initial Comment:
Importing SystemRandom wastes entropy.
The strace snippet shows a 16 byte read from /dev/urandom, which is presumably 
done to seed a random number generator. However SystemRandom does not need a 
seed, so the read is not needed.

test case:
#!/usr/bin/python
from random import SystemRandom

strace snippet:
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4
read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16
close(4)= 0

Python version:
python-2.4.4-1.fc6 (Fedora Core 6)


--

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



[ python-Bugs-1680034 ] Importing SystemRandom wastes entropy.

2007-03-13 Thread SourceForge.net
Bugs item #1680034, was opened at 2007-03-13 17:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&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.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Steve Tyler (stephent98)
Assigned to: Nobody/Anonymous (nobody)
Summary: Importing SystemRandom wastes entropy.

Initial Comment:
Importing SystemRandom wastes entropy.
The strace snippet shows a 16 byte read from /dev/urandom, which is presumably 
done to seed a random number generator. However SystemRandom does not need a 
seed, so the read is not needed.

test case:
#!/usr/bin/python
from random import SystemRandom

strace snippet:
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4
read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16
close(4)= 0

Python version:
python-2.4.4-1.fc6 (Fedora Core 6)


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 17:32

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

This is not caused by SystemRandom, but by instantiating (and thereby
seeding) the normal (Mersenne Twister) random number generator, which is
done automatically when random is imported.

--

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



[ python-Bugs-1556895 ] typo in encoding name in email package

2007-03-13 Thread SourceForge.net
Bugs item #1556895, was opened at 2006-09-12 03:33
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&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: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Guillaume Rousse (guillomovitch)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: typo in encoding name in email package

Initial Comment:
gb2132 should be gb2312...

Here is a patch against email-2.5.8

--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-13 14:17

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

r54342

--

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



[ python-Bugs-1680034 ] Importing SystemRandom wastes entropy.

2007-03-13 Thread SourceForge.net
Bugs item #1680034, was opened at 2007-03-13 17:17
Message generated for change (Comment added) made by stephent98
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&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.4
>Status: Open
>Resolution: None
Priority: 5
Private: No
Submitted By: Steve Tyler (stephent98)
Assigned to: Nobody/Anonymous (nobody)
Summary: Importing SystemRandom wastes entropy.

Initial Comment:
Importing SystemRandom wastes entropy.
The strace snippet shows a 16 byte read from /dev/urandom, which is presumably 
done to seed a random number generator. However SystemRandom does not need a 
seed, so the read is not needed.

test case:
#!/usr/bin/python
from random import SystemRandom

strace snippet:
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4
read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16
close(4)= 0

Python version:
python-2.4.4-1.fc6 (Fedora Core 6)


--

>Comment By: Steve Tyler (stephent98)
Date: 2007-03-13 18:30

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

Entropy is not an unlimited quantity,
therefore the existing behavior is undesirable.
My app is a random password generator which may need the entropy for
itself.
https://sourceforge.net/projects/gnome-password/


--

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 17:32

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

This is not caused by SystemRandom, but by instantiating (and thereby
seeding) the normal (Mersenne Twister) random number generator, which is
done automatically when random is imported.

--

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



[ python-Bugs-1680034 ] Importing SystemRandom wastes entropy.

2007-03-13 Thread SourceForge.net
Bugs item #1680034, was opened at 2007-03-13 17:17
Message generated for change (Comment added) made by stephent98
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steve Tyler (stephent98)
Assigned to: Nobody/Anonymous (nobody)
Summary: Importing SystemRandom wastes entropy.

Initial Comment:
Importing SystemRandom wastes entropy.
The strace snippet shows a 16 byte read from /dev/urandom, which is presumably 
done to seed a random number generator. However SystemRandom does not need a 
seed, so the read is not needed.

test case:
#!/usr/bin/python
from random import SystemRandom

strace snippet:
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4
read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16
close(4)= 0

Python version:
python-2.4.4-1.fc6 (Fedora Core 6)


--

>Comment By: Steve Tyler (stephent98)
Date: 2007-03-13 19:08

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

Here is a little more background on why wasting entropy is a problem.

"When accessed as /dev/urandom, as many bytes as are requested are
returned even when the entropy pool is exhausted."
http://www.linux.com/howtos/Secure-Programs-HOWTO/random-numbers.shtml

When the entropy pool is exhausted, the Linux RNG (accessed via
/dev/urandom) behaves like a pseudo-random number generator, which is not
acceptable for cryptographic applications such as password generators.

Analysis of the Linux Random Number Generator
http://www.pinkas.net/PAPERS/gpr06.pdf

Of course one can work around this issue by not using the "random" module
and accessing /dev/urandom or /dev/random directly.

For some perspective, simply importing the gnome.ui module consumes 4096
bytes of random data in a library I have not been able to completely
identify. (I don't think it is Python, though.)

--

Comment By: Steve Tyler (stephent98)
Date: 2007-03-13 18:30

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

Entropy is not an unlimited quantity,
therefore the existing behavior is undesirable.
My app is a random password generator which may need the entropy for
itself.
https://sourceforge.net/projects/gnome-password/


--

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 17:32

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

This is not caused by SystemRandom, but by instantiating (and thereby
seeding) the normal (Mersenne Twister) random number generator, which is
done automatically when random is imported.

--

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



[ python-Bugs-1680034 ] Importing SystemRandom wastes entropy.

2007-03-13 Thread SourceForge.net
Bugs item #1680034, was opened at 2007-03-13 12:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&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.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Steve Tyler (stephent98)
Assigned to: Nobody/Anonymous (nobody)
Summary: Importing SystemRandom wastes entropy.

Initial Comment:
Importing SystemRandom wastes entropy.
The strace snippet shows a 16 byte read from /dev/urandom, which is presumably 
done to seed a random number generator. However SystemRandom does not need a 
seed, so the read is not needed.

test case:
#!/usr/bin/python
from random import SystemRandom

strace snippet:
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4
read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16
close(4)= 0

Python version:
python-2.4.4-1.fc6 (Fedora Core 6)


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-13 15:17

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

Sorry, am closing this as won't fix.  The 16 bytes are used to seed the
MersenneTwister which is used by tempfile.py upon startup.  That is a
reasonable use of the resource.  

FWIW, it is possible for you to recover most of those 16 bytes of entropy
just by calling the twister itself.  Also, it is my understanding that
/dev/urandom is continuously refilling its hardware based entropy source
(so the supply is limitless, but not instant).



--

Comment By: Steve Tyler (stephent98)
Date: 2007-03-13 14:08

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

Here is a little more background on why wasting entropy is a problem.

"When accessed as /dev/urandom, as many bytes as are requested are
returned even when the entropy pool is exhausted."
http://www.linux.com/howtos/Secure-Programs-HOWTO/random-numbers.shtml

When the entropy pool is exhausted, the Linux RNG (accessed via
/dev/urandom) behaves like a pseudo-random number generator, which is not
acceptable for cryptographic applications such as password generators.

Analysis of the Linux Random Number Generator
http://www.pinkas.net/PAPERS/gpr06.pdf

Of course one can work around this issue by not using the "random" module
and accessing /dev/urandom or /dev/random directly.

For some perspective, simply importing the gnome.ui module consumes 4096
bytes of random data in a library I have not been able to completely
identify. (I don't think it is Python, though.)

--

Comment By: Steve Tyler (stephent98)
Date: 2007-03-13 13:30

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

Entropy is not an unlimited quantity,
therefore the existing behavior is undesirable.
My app is a random password generator which may need the entropy for
itself.
https://sourceforge.net/projects/gnome-password/


--

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 12:32

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

This is not caused by SystemRandom, but by instantiating (and thereby
seeding) the normal (Mersenne Twister) random number generator, which is
done automatically when random is imported.

--

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



[ python-Bugs-1680159 ] Misleading exception from unicode.__contains__

2007-03-13 Thread SourceForge.net
Bugs item #1680159, was opened at 2007-03-13 21:33
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=1680159&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: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Hudec (bulbjh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Misleading exception from unicode.__contains__

Initial Comment:
Hello Folks,

unicode.__contains__ throws:

>>> '\xff' in u'foo'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'in ' requires string as left operand

while:

Traceback (most recent call last):
  File "", line 1, in 
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal 
not in range(128)

would be more helpful, because that's what really fails there. The exception it 
throws now does not indicate that unicode is involved.

(tried this with 2.4.4 and 2.5.0 and happens in both)

--

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



[ python-Bugs-1326406 ] pdb breaks programs which import from __main__

2007-03-13 Thread SourceForge.net
Bugs item #1326406, was opened at 2005-10-14 04:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326406&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: Fixed
Priority: 5
Private: No
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb breaks programs which import from __main__

Initial Comment:
The following example illustrates the problem:

  bagira:~/python/dist/src/Lib> cat tt/xx
  hello=None
  import yy
  print "in xx:yy imported"

  bagira:~/python/dist/src/Lib> cat tt/yy.py
  from __main__ import hello
  print "in yy: yy imported "

this works by itself:

  bagira:~/python/dist/src/Lib> ../python tt/xx
  in yy: yy imported 
  in xx:yy imported

But breaks under pdb

 bagira:~/python/dist/src/Lib> ../python -m pdb tt/xx 
 > /home/ilya/python/dist/src/Lib/tt/xx(1)?()
 -> hello=None
  (Pdb) c
  Traceback (most recent call last):
   File "/home/ilya/python/dist/src/Lib/pdb.py", line
1057, in main
pdb._runscript(mainpyfile)
   File "/home/ilya/python/dist/src/Lib/pdb.py", line
982, in   _runscript
 self.run(statement, globals=globals_, locals=locals_)
   File "/home/ilya/python/dist/src/Lib/bdb.py", line
367, in run
 exec cmd in globals, locals
   File "", line 1, in ?
   File "tt/xx", line 2, in ?
 import yy
   File "/home/ilya/python/dist/src/Lib/tt/yy.py", line
1, in ?
 from __main__ import hello
 ImportError: cannot import name hello
 Uncaught exception. Entering post mortem debugging
 Running 'cont' or 'step' will restart the program
  > /home/ilya/python/dist/src/Lib/tt/yy.py(1)?()
 -> from __main__ import hello




--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 22:00

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

Fixed with said patch.

--

Comment By: Ilya Sandler (isandler)
Date: 2006-05-18 00:53

Message:
Logged In: YES 
user_id=971153

I have submitted a patch #1429539 for this


--

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



[ python-Bugs-796219 ] ntpath.expanduser() is still wrong

2007-03-13 Thread SourceForge.net
Bugs item #796219, was opened at 2003-08-27 20:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&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: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Georg Brandl (gbrandl)
Summary: ntpath.expanduser() is still wrong

Initial Comment:
I found a system with the following setup:

- os.getenv("HOME") returns "%USERPROFILE%"
- os.getenv("USERPROFILE") returns the home directory

Currently, ntpath.py doesn't expand ~ correctly in this
case.
The fix is pretty simple, I'll try to submit it if I
have time.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 22:08

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

This is finally fixed with patch #957650.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-05-20 20:45

Message:
Logged In: YES 
user_id=341410

I have submitted sf patch #957650 to fix the bug listed.

There is still an issue when there actually exists folders
with names that mirror environment variables, but regardless
of whether we stat the filesystem, the meaning of such a
thing is ambiguous.

The patch also includes ~user\subpath functionality, which
has been missing in ntpath.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-03-27 00:53

Message:
Logged In: YES 
user_id=341410

After doing some more playing around, I discovered a few
other examples that would kill either method described below:
HOME=%USERDRIVE%%USERPATH%
HOME=C:\%userprofiles\%USERNAME%

The real trick is that % can exist in a path on windows, so
even c:\%HOME% is a vaild path:
 Directory of D:\test

03/26/2004  03:58p.
03/26/2004  03:58p..
03/26/2004  03:59p%HOME%
   0 File(s)  0 bytes
   3 Dir(s)   5,355,511,808 bytes free

D:\test>

I suppose the question remains as to what cases do we want
to cover.  If we assume that there aren't any % symbols in a
path, then the code is straightforward, and I can have a
patch for you in a few minutes.  If % can be in a path, then
the problem is a pain, and a miniature parser needs to be
written to deal with it.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 22:49

Message:
Logged In: YES 
user_id=6380

Unclear what I'm asked to do here. Josiah, could you produce
an actual patch against CVS rather than random example code?

If you have forward slashes, you should use
os.path.normpath(). Why doesn't that work?

--

Comment By: Tim Peters (tim_one)
Date: 2003-09-30 14:00

Message:
Logged In: YES 
user_id=31435

Assigned back to Guido.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-09-30 06:33

Message:
Logged In: YES 
user_id=341410

I just noticed that I've got some forward slashes in various
paths on my windows machines...here's some updated code:

def expandfull(var, rem=3):
if not rem:
return os.path.expandvars(var)
a = os.path.expandvars(var)
b = []
d = [b.extend(i.split('\\')) for i in a.split('/')]
c = []
for i in b:
if '%' in i:
c.append(expandfull(i), rem-1)
else:
c.append(i)
return '\\'.join(c)


--

Comment By: Christos Georgiou (tzot)
Date: 2003-08-30 09:55

Message:
Logged In: YES 
user_id=539787

I stand corrected; multiple backslashes inside a path are not 
merged into one on Windows.  Thank you.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 18:48

Message:
Logged In: YES 
user_id=341410

Sourceforge ate my double-backslashes.
All '\\' should be ''.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 18:20

Message:
Logged In: YES 
user_id=341410

The code you offered won't work correctly for all
environment variable returns.  An example that would kill
your code:
%SYSTEMROOT%\System32

def expandfull(var, rem=3):
if not rem:
return expandvars(var)
a = expandvars(var)
b = a.split('\\')
c = []
for i in b:
if '%' in i:
c.append(expandfull(i), rem-1)

[ python-Bugs-1085283 ] binascii.b2a_qp oddities

2007-03-13 Thread SourceForge.net
Bugs item #1085283, was opened at 2004-12-14 18:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085283&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: Fixed
Priority: 2
Private: No
Submitted By: DSM (dsm001)
Assigned to: Nobody/Anonymous (nobody)
Summary: binascii.b2a_qp oddities

Initial Comment:
[Python 2.5a0 (#9, Dec  8 2004, 12:37:01); the
behaviours go way back.]

binascii.b2a_qp has several quirks discovered when
reimplementing.

(1) It lets low bytes pass through unescaped -- e.g.
binascii.b2a_qp('\x08') == '\x08' -- unless quotetabs
is True.  This looks to be an error in program logic at
lines ~1165 and ~1234, unless this is intended
(although quopri's internal version quotes them).  This
doesn't seem RFC 1521 compatible on my reading of
section 5 (admittedly I only read it for the first time
last week. :-)

(2) It determines whether to enforce \n or \r\n by
scanning the string for the first occurrence [which
should be mentioned in the docs].  binascii.c does this
by calling strchr, which stops at the first \x00.  

This means that:

>>> s0 = "The quick " + chr(0) + "brown fox.\r\n"
>>> s1 = "The quick " + chr(1) + "brown fox.\r\n"
>>> binascii.b2a_qp(s0)
'The quick \x00brown fox.\n'
>>> binascii.b2a_qp(s1)
'The quick \x01brown fox.\r\n'

and related strangenesses.

(3) The code escapes the period "." if and only if it's
the second character in a line.  I'm not sure why; the
only mention I can find in 1521 is in appendix B of
escaping a period ALONE on a line in some situations,
which binascii.b2a_qp doesn't do in any event.  This
behaviour may be prescribed by some other spec but is
strange enough to be mentioned in the docs if it's
intentional.

A new strictly RFC1521-compliant qp encoding would be a
good thing if backwards compatibility prevents changing
some of these.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 22:51

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

Fixed (1) and (3) in rev. 54367. I think (2) is not important enough to do
anything about it.

--

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



[ python-Bugs-1678102 ] zlib.crc32() not cross-platform

2007-03-13 Thread SourceForge.net
Bugs item #1678102, was opened at 2007-03-10 20:07
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&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: Ben Collver (bencollver)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib.crc32() not cross-platform

Initial Comment:
The zlib.crc32() function sometimes produces different results for the same 
input on big and little-endian processors.  Same for zlib.adler32().

sparc64:
>>> import zlib
>>> print zlib.adler32("--", 1)
> 3763407051
>>> print zlib.crc32("--", 1)
3044228349

i386:
>>> import zlib
>>> print zlib.adler32("--", 1)
> -531560245
>>> print zlib.crc32("--", 1)
-1250738947


--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-03-13 19:52

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

py> -531560245 & 0x
3763407051L

It's the same number (actually, the same bit pattern). The i386 version is
signed, the other unsigned. The i386 platform uses a 32 bit "int"; the
sparc64 uses 64 bits (I presume). 3763407051 doesnt fit in 31bits, so it's
seen as a negative number.



--

Comment By: Ben Collver (bencollver)
Date: 2007-03-10 20:13

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

The extra > characters before the first results come from me pasting the
results to my irc client, then copying from there and pasting here.  Sorry
for any confusion.

--

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



[ python-Bugs-1680230 ] urllib.urlopen() raises AttributeError

2007-03-13 Thread SourceForge.net
Bugs item #1680230, was opened at 2007-03-14 00:09
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=1680230&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: 5
Private: No
Submitted By: Bj�rn Lindqvist (sonderblade)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen() raises AttributeError

Initial Comment:
When you connect urlopen() to a socket that does not send any data, it produces 
an AttributeError. 

File "/lib/python2.6/urllib.py", line 608, in http_error_default
return addinfourl(fp, headers, "http:" + url)
  File "/lib/python2.6/urllib.py", line 951, in __init__
addbase.__init__(self, fp)
  File "/lib/python2.6/urllib.py", line 898, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

Raising an exception is OK (I think?), but it should be an IOError instead of 
an AttributeError. See the attached patch for a test case for the bug.

--

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



[ python-Bugs-1680230 ] urllib.urlopen() raises AttributeError

2007-03-13 Thread SourceForge.net
Bugs item #1680230, was opened at 2007-03-14 00:09
Message generated for change (Comment added) made by sonderblade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680230&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: 5
Private: No
Submitted By: Bj�rn Lindqvist (sonderblade)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen() raises AttributeError

Initial Comment:
When you connect urlopen() to a socket that does not send any data, it produces 
an AttributeError. 

File "/lib/python2.6/urllib.py", line 608, in http_error_default
return addinfourl(fp, headers, "http:" + url)
  File "/lib/python2.6/urllib.py", line 951, in __init__
addbase.__init__(self, fp)
  File "/lib/python2.6/urllib.py", line 898, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'

Raising an exception is OK (I think?), but it should be an IOError instead of 
an AttributeError. See the attached patch for a test case for the bug.

--

>Comment By: Bj�rn Lindqvist (sonderblade)
Date: 2007-03-14 00:13

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

File Added: test-urllib-tc-attr-err.patch

--

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



[ python-Bugs-1680312 ] httplib fails to parse response on HEAD request

2007-03-13 Thread SourceForge.net
Bugs item #1680312, was opened at 2007-03-13 23:33
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=1680312&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: Patrick Altman (altman)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib fails to parse response on HEAD request

Initial Comment:
When attempting to get the response headers to a HEAD request, httplib hangs 
and then eventually throws an exception.

Details can be found in the following post:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/ff9fa7c5e6dbea7f/

Thanks,
Patrick Altman
[EMAIL PROTECTED]


--

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



[ python-Bugs-1680312 ] httplib fails to parse response on HEAD request

2007-03-13 Thread SourceForge.net
Bugs item #1680312, was opened at 2007-03-13 23:33
Message generated for change (Settings changed) made by altman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680312&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: 7
Private: No
Submitted By: Patrick Altman (altman)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib fails to parse response on HEAD request

Initial Comment:
When attempting to get the response headers to a HEAD request, httplib hangs 
and then eventually throws an exception.

Details can be found in the following post:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/ff9fa7c5e6dbea7f/

Thanks,
Patrick Altman
[EMAIL PROTECTED]


--

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



[ python-Bugs-1582282 ] email.header decode within word

2007-03-13 Thread SourceForge.net
Bugs item #1582282, was opened at 2006-10-22 09:16
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&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: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.header decode within word

Initial Comment:
The problem is filed in mailman bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1578539&group_id=103&atid=100103

While Microsoft Entourage's way of encoding iso-8859-1
text is not compliant with RFC-2047, Python
email.header.decode_header should treat this 'word' as
a simple us-ascii string and should not parse into
series of string/charset list.

Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord
should be parsed as
[('Sm=?ISO-8859-1?B?9rg==?=g=?ISO-8859-1?B?5Q==?=sbord',
None)], not as [('Sm', None), ('\xf6', 'iso-8859-1'),
('g', None), ('\xe5', 'iso-8859-1'), ('sbord', None)]



--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-14 01:00

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

r54370 for Python 2.5
r54371 for Python 2.6

--

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



[ python-Bugs-1572084 ] .eml attachments in email

2007-03-13 Thread SourceForge.net
Bugs item #1572084, was opened at 2006-10-06 08:23
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: rainwolf8472 (rainwolf8472)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: .eml attachments in email

Initial Comment:
I think there's a bug somewhere in the email package. 
I wanted to write a 
script to send emails with certain attachments using
libgmail, and found 
this one, http://pramode.net/articles/lfy/fuse/4.txt ,
it works fine with 
most files, but it fails with .eml files, and what i
can't understand is 
that if I change the extension of those .eml files to
.txt, the script works 
fine.  However, when trying to mail a simple textfile
containing "hello", en 
changing the extension to .eml before sending, it fails
again. it doesn't 
fail when I don't change the extension to .eml.
Any help please? I pasted the output I get (over and
over again) in the attached textfile.

--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-14 01:04

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

I'll need more information in order to debug this.  Please try to create a
small, standalone, reproducible test case.  I don't have libgmail available
so please don't write a test case that depends on that.


--

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



[ python-Bugs-1680312 ] httplib fails to parse response on HEAD request

2007-03-13 Thread SourceForge.net
Bugs item #1680312, was opened at 2007-03-14 04:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680312&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: Closed
>Resolution: Duplicate
Priority: 7
Private: No
Submitted By: Patrick Altman (altman)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib fails to parse response on HEAD request

Initial Comment:
When attempting to get the response headers to a HEAD request, httplib hangs 
and then eventually throws an exception.

Details can be found in the following post:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/ff9fa7c5e6dbea7f/

Thanks,
Patrick Altman
[EMAIL PROTECTED]


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-14 07:00

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

This is a duplicate of #1486335.

--

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