From report at bugs.python.org  Fri Aug  1 00:56:37 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 31 Jul 2008 22:56:37 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217544997.56.0.921461920116.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Nick,

Working with Andrii's patch I'm trying to add a couple test cases to 
make sure the methods you and I both demonstrated still work.  Mine is 
no problem, but I must be doing something wrong trying to use/adapt your 
example.  I freely admit I am not an itertools user, but I can't get 
your example to work as written:

>>> r = csv.DictReader(open("foo.csv", "rb"))
>>> r.fieldnames
['f1', 'f2', 'f3']
>>> r.next()
{'f1': '1', 'f2': '2', 'f3': 'abc'}
>>> r = csv.DictReader(open("foo.csv", "rb"))
>>> first = next(r)
>>> first
{'f1': '1', 'f2': '2', 'f3': 'abc'}
>>> import itertools
>>> for x in itertools.chain(first, r):
...   print x
... 
f1
f2
f3

If I place first in a list it works:

>>> r = csv.DictReader(open("foo.csv", "rb"))
>>> first = next(r)
>>> for x in itertools.chain([first], r):
...   print x
... 
{'f1': '1', 'f2': '2', 'f3': 'abc'}

That makes intuitive sense to me.  Is that what you intended?

S

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 01:33:01 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 31 Jul 2008 23:33:01 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217530574.17.0.656215776787.issue3474@psf.upfronthosting.co.za>
Message-ID: <bbaeab100807311632v8a954a4u412ac81afac1aaee@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Jul 31, 2008 at 11:56 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Alternatively, you could move reduce to functools and have the builtin
> module issue a warning and call it.
>

That's what 3.0 did; created _functools and that holds the original
implementation from __builtins__. But that is a lot more work. =)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Fri Aug  1 02:08:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Aug 2008 00:08:44 +0000
Subject: [issue2491] io.open() handles errors differently on different
	platforms
In-Reply-To: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za>
Message-ID: <1217549324.43.0.387334707461.issue2491@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r65343: os.fdopen accepts the same parameters as io.open().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2491>
_______________________________________

From report at bugs.python.org  Fri Aug  1 02:17:05 2008
From: report at bugs.python.org (Dominique Parolin)
Date: Fri, 01 Aug 2008 00:17:05 +0000
Subject: [issue3481] Length of struct.pack('HL', 1,
	1) incorrect (8 instead of 6 bytes)
In-Reply-To: <1217549825.77.0.356584888827.issue3481@psf.upfronthosting.co.za>
Message-ID: <1217549825.77.0.356584888827.issue3481@psf.upfronthosting.co.za>


New submission from Dominique Parolin <d.parolin at gmx.net>:

Python Versions tested:
Windows 2.5.2 (r252:60911)
Debian Linux Python 2.4.4 

Example:
>>> import struct
>>> struct.pack('HL', 1, 1)

results in '\x01\x00\x00\x00\x01\x00\x00\x00'
although '\x01\x00\x01\x00\x00\x00' was expected.

if concatenated or done separately
>>> struct.pack('H', 1) + struct.pack('L', 1) 

result is as expected '\x01\x00\x01\x00\x00\x00'
or
'\x01\x00' and '\x01\x00\x00\x00' respectively

Error:
Length is 8 where it should be 6
This is as well true for "hl", "hL" and "Hl".


Free description:
I could not find another error regarding that, nor any information using
popular search.
Further no explanation found why that might be valid behaviour.

Regards,
Dominique

----------
components: Library (Lib)
messages: 70535
nosy: dparolin
severity: normal
status: open
title: Length of struct.pack('HL', 1,1) incorrect (8 instead of 6 bytes)
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3481>
_______________________________________

From report at bugs.python.org  Fri Aug  1 02:40:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Aug 2008 00:40:33 +0000
Subject: [issue3481] Length of struct.pack('HL', 1,
	1) incorrect (8 instead of 6 bytes)
In-Reply-To: <1217549825.77.0.356584888827.issue3481@psf.upfronthosting.co.za>
Message-ID: <1217551233.54.0.394983940783.issue3481@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The struct module is correct.
You see here the result of "alignment": the address of a long is always
 a multiple of the size of a long.

The struct module mimics the C compiler: a "struct { short x; long y;
}", will actually occupy 8 bytes in memory (on a 32bit processor).
There are two padding bytes, that are not used.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3481>
_______________________________________

From report at bugs.python.org  Fri Aug  1 02:59:55 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 01 Aug 2008 00:59:55 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217552395.61.0.869279692607.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I added a comment to Andrii's patch and added simple test cases
which check to make sure the way Nick and I currently use the
DictReader class (or at least envision using it) still works.

Added file: http://bugs.python.org/file11021/csv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 03:00:04 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 01 Aug 2008 01:00:04 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217552404.51.0.908890086071.issue3436@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Removed file: http://bugs.python.org/file10978/csv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 03:06:05 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 01 Aug 2008 01:06:05 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217552765.71.0.163485942796.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Andrii, If my view of the Python 3.0 development process is correct and 
this change makes it into the 2.6 code, one of the 3.0 developers will 
merge to the py3k branch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 03:22:33 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 01 Aug 2008 01:22:33 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1217553753.95.0.259767449278.issue3419@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Ben's incref error != the connection refused error. Here's some information 
from Scott Leerssen who is using the original .52 code:

Hi Jesse,

I am having some trouble with the processing module (0.52) and thought you 
might be of some help since you were so involved with it in the PEP process.

I have a queue of Process objects from which a runner thread pulls and starts 
processes.  The producers for the queue are many, many threads.  I'm seeing 
some very odd behavior when lots of processes try to start while others are 
being reaped at the same time.  I see tracebacks that look like the one below, 
and also occasionally get "hangs" where the process module "seems" to take over 
the GIL and never give it back.  I did find a race condition bug in process.py 
where a _cleaner function is run in start(), potentially joining on processes 
that other threads may also be joining at the same time, which leads to 
KeyError exceptions coming from _cleaner.  I mutexed all my starts and joins to 
get around that for now, but am stumped on the issue below.  Does it look 
familiar to you?

Thanks, and feel free to shrug and reply "beats me".
Scott

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,609 SYSMESG  Process Process-24:
[dmbd:32451:-1236096096] 2008-07-31 16:52:10,612 SYSMESG

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,613 SYSMESG  Traceback (most 
recent call last):

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,613 SYSMESG    File 
"/opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site-
packages/processing/process.py", line 224, in _bootstrap

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,615 SYSMESG      
_runAfterForkers()

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,616 SYSMESG    File 
"/opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site-
packages/processing/process.py", line 300, in _runAfterForkers

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,617 SYSMESG      func(obj)

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,617 SYSMESG    File 
"/opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site-
packages/processing/managers.py", line 806, in _afterFork

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,620 SYSMESG      self._incref()

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,621 SYSMESG    File 
"/opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site-
packages/processing/managers.py", line 760, in _incref

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,621 SYSMESG      
dispatch(connection, None, 'incref', (self._id,))

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,622 SYSMESG    File 
"/opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site-
packages/processing/managers.py", line 92, in dispatch

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,623 SYSMESG      raise result

[dmbd:32451:-1236096096] 2008-07-31 16:52:10,624 SYSMESG  RemoteError:
---------------------------------------------------------------------------
Remote Traceback (most recent call last):
 File "/opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site-
packages/processing/managers.py", line 190, in handleRequest
   result = func(c, *args, **kwds)
 File "/opt/race/share/sw/os/Linux_2.6_i686/python/lib/python2.5/site-
packages/processing/managers.py", line 404, in incref
   self.id_to_refcount[ident] += 1
KeyError: 2880341100L

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Fri Aug  1 05:43:16 2008
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 01 Aug 2008 03:43:16 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1217562196.11.0.281268296469.issue2260@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

+0

* The peepholer comment promises "Optimizations are restricted to simple
transformations occuring within a single basic block." and this goes
beyond that.  You could patch that comment.
* This needs a matching patch to Lib/test/test_peepholer.py
* Deeply nested "if"s suffer a flat penalty because the unconditional
jump peepholer figures this out after the first extra POP_TOP (notice
the JUMP_ABSOLUTE in your second disassembly).
* I noticed the NOP assignment is commented out in your patch, was that
unsafe?

I searched for old threads on the peephole optimizer and came up with these:
Skip Montanaro's paper
  http://www.webfast.com/~skip/python/spam7/optimizer.html
Two old python-dev threads
  http://www.gossamer-threads.com/lists/python/dev/645669
  http://www.gossamer-threads.com/lists/python/dev/645669

I was hoping to find out if writing a bytecode optimizer in python had
been discussed because a generic version of your optimization would be
really easy to write in pure python (using a dict for the jump table,
for instance).  I found nothing;  my search terms might have been
insufficient.

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Fri Aug  1 06:38:19 2008
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 01 Aug 2008 04:38:19 +0000
Subject: [issue2676] email/message.py [Message.get_content_type]: Trivial
	regex hangs on pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1217565499.45.0.664008377249.issue2676@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Augmented version of Daniel's patch.

This makes an internal function that does the same work.  It uses
txt.find() instead of split() or partition() because for pathologically
long strings find() is noticeably faster.  It also does the strip()
before the lower() which helps with evilly long strings.

I didn't remove the module global "paramre" because an external module
might be using it.  I did update its comment.

Do bugfixes get applied to 2.6 or 3.0?  I'm a bit out of practice.

----------
nosy: +jackdied
Added file: http://bugs.python.org/file11022/email.message.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2676>
_______________________________________

From report at bugs.python.org  Fri Aug  1 07:58:55 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 01 Aug 2008 05:58:55 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1217570335.88.0.38952984562.issue2275@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file10862/issue2275-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Aug  1 07:59:02 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 01 Aug 2008 05:59:02 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1217570342.79.0.61397720773.issue2275@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file10863/issue2275-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Aug  1 07:59:38 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 01 Aug 2008 05:59:38 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1217570378.72.0.215199404761.issue2275@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file11023/issue2275-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Aug  1 08:00:05 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 01 Aug 2008 06:00:05 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1217570405.07.0.308679275414.issue2275@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file11024/issue2275-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Aug  1 08:12:24 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 01 Aug 2008 06:12:24 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1217571144.69.0.26412253846.issue2275@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I am submitting a revised patch for this issue.
I did some analysis on the history of this issue and found that this
.capitalize() vs .title() changes had come up earlier too (
issue1542948)and decision was taken to:
- To retain the Header format in .capitalize() to maintain backward
compatibility.
- However, when the headers are passed to httplib, they are converted to
.title() format ( see AbstractHTTPHandler method )
- It is encouraged that users uses .add_header(), .has_header(),
.get_header() methods to check for headers instead of using the .headers
dict directly (which will still remain undocumented interface).

Note to Hans-Peter would be: Changing the headers to .title() tends to
make the .header_items() retrieval backward incompatible, so the headers
will still be stored in .capitalize() format.

And I have made the following changes to the patch:
1) Support for case insensitive dict look up which will work with for
.has_header, .get_header(). So when .has_header("User-Agent") will
return True even when .headers give {"User-agent":"blah"}
2) Added tests to tests the behavior.
3) Changes to doc to reflect upon this issue.

Btw, the undocumented .headers interface will also support
case-insensitive lookup, so I have added tests for that too.

Let me know if you have any comments. Lets plan to close this issue.

Thanks,

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Fri Aug  1 09:20:22 2008
From: report at bugs.python.org (Benoit Thiell)
Date: Fri, 01 Aug 2008 07:20:22 +0000
Subject: [issue3482] re.split, re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>


New submission from Benoit Thiell <badzil at gmail.com>:

Given that the search operations support flags, it seems natural for a
developer that the other functions in the module support flags as well.
So when running "re.split(pattern, string, re.I)", the split() command
seems to not work and don't return a message error (I understand that
're.I' is understood as 'maxsplit=0'.)

This is confusing and I think that it should be changed so that all
functions in the module are consistent.

----------
messages: 70543
nosy: benoit
severity: normal
status: open
title: re.split, re.sub and re.subn should support flags

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________

From report at bugs.python.org  Fri Aug  1 09:20:37 2008
From: report at bugs.python.org (Benoit Thiell)
Date: Fri, 01 Aug 2008 07:20:37 +0000
Subject: [issue3482] re.split, re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1217575237.99.0.106657369998.issue3482@psf.upfronthosting.co.za>


Changes by Benoit Thiell <badzil at gmail.com>:


----------
components: +Regular Expressions
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________

From report at bugs.python.org  Fri Aug  1 10:11:21 2008
From: report at bugs.python.org (=?utf-8?q?David_K=C3=A5gedal?=)
Date: Fri, 01 Aug 2008 08:11:21 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1217578281.81.0.954419202085.issue3392@psf.upfronthosting.co.za>


Changes by David K?gedal <davidk at lysator.liu.se>:


----------
nosy: +d_kagedal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Fri Aug  1 10:21:08 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Fri, 01 Aug 2008 08:21:08 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217578868.32.0.27664885381.issue3436@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

Oh, so this is how the process looks like...
/me removes patches
I've uploaded both py3k and trunk patches just because I'm fixing things
the other way round -- first I write a patch for 3.0 and only after that
I backport it to 2.6. Stupid me. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 10:21:13 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Fri, 01 Aug 2008 08:21:13 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217578873.01.0.0829691945481.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Removed file: http://bugs.python.org/file11016/issue3436.py3k.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 10:21:16 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Fri, 01 Aug 2008 08:21:16 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217578876.67.0.297046440226.issue3436@psf.upfronthosting.co.za>


Changes by Andrii V. Mishkovskyi <mishok13 at gmail.com>:


Removed file: http://bugs.python.org/file11017/issue3436.trunk.csv.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 10:28:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Aug 2008 08:28:01 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1217579281.71.0.0461127037161.issue2260@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Fri Aug  1 11:18:23 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 09:18:23 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217582303.22.0.945336662533.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Toned down note in docs (at Raymond's request) in r65366.

While I'd really like to see an lsum-based version go in instead, I 
think it's too close to the release to make this change right now.

There was also originally some talk of a complex math version.  What do 
people think about this?  Personally, I suspect that the use cases would 
be few and far between, and anyone who *really* needs a complex high-
precision sum can just apply math.fsum to real and imaginary parts.  
(This is easier now that x.imag and x.real make sense for integers as 
well as floats.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Fri Aug  1 11:41:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 09:41:23 +0000
Subject: [issue2260] conditional jump to a POP_TOP optimization
In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za>
Message-ID: <1217583683.09.0.494578750921.issue2260@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

While this patch is interesting, I think it would be more efficient to
introduce variants of JUMP_IF_FALSE and JUMP_IF_TRUE which pop their
argument rather than leaving it on the stack (like I did in #2459).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2260>
_______________________________________

From report at bugs.python.org  Fri Aug  1 12:10:32 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Aug 2008 10:10:32 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1217585432.44.0.146237802382.issue3436@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Skip's patch looks good to me (as Skip discovered, I left out the
necessary step of putting the first row back into an iterable before
invoking chain in my example code)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Fri Aug  1 12:15:34 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Aug 2008 10:15:34 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1217585734.42.0.934612767654.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Guido, does that mean we can apply this patch to get the cleaner
list-like behaviour for 3.0, and then work on the sq_item/sq_len fixes
for 3.1 as a separate issue?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Fri Aug  1 12:47:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 10:47:36 +0000
Subject: [issue2860] re module fails to handle byte strings
In-Reply-To: <1210838903.44.0.718972367839.issue2860@psf.upfronthosting.co.za>
Message-ID: <1217587656.71.0.189556714755.issue2860@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a duplicate of #3231 and was fixed in r65185.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2860>
_______________________________________

From report at bugs.python.org  Fri Aug  1 14:19:52 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 01 Aug 2008 12:19:52 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1217593192.56.0.638262736942.issue1342811@psf.upfronthosting.co.za>


Robert Schuppenies <okkotonushi at googlemail.com> added the comment:

The problem does still exist (Python 2.6b2).

I attached a patch for Tkinter.py which addresses this problem. It is
the same as in the first proposed fix, but adds an additional check
whether the menu item has a 'command' property.
I also removed the "INDEX2 (is included)" comment, as it is not the
desired behavior (see http://www.tcl.tk/man/tcl8.5/TkCmd/text.htm#M98).
I cannot confirm the behavior, but it should be a separate issue
nevertheless.

----------
keywords: +patch
nosy: +schuppenies
Added file: http://bugs.python.org/file11025/tkinter_menuleak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Fri Aug  1 15:51:01 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 13:51:01 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217598661.32.0.408220659616.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I finally found some more time to look at this.  I cut down the test-suite 
to try to find a minimal failing example.  I can fairly reliably make a 
debug build of the trunk crash using the following nine lines

import multiprocessing.managers
def sqr(x): return x*x
manager = multiprocessing.managers.SyncManager()
manager.start()
pool = manager.Pool(4)
it = pool.imap_unordered(sqr, range(10000))
assert sorted(it) == map(sqr, range(10000))
pool.terminate()
manager.shutdown()

Typical output is:

Fatal Python error: UNREF invalid object
(followed by traceback)

or:

Assertion failed: (bp != NULL), function PyObject_Malloc, file 
Objects/obmalloc.c, line 755.

or:

Debug memory block at address p=0x247778:
    26 bytes originally requested
    The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb):
        at p-4: 0xdb *** OUCH
        at p-3: 0xdb *** OUCH
        at p-2: 0xdb *** OUCH
        at p-1: 0xdb *** OUCH
    Because memory is corrupted at the start, the count of bytes requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 4 pad bytes at tail=0x247792 are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x35 *** OUCH
        at tail+1: 0x00 *** OUCH
        at tail+2: 0xfb
        at tail+3: 0xfb
    The block was made by call #4227530756 to debug malloc/realloc.
    Data at p: 00 00 00 00 00 00 00 00 ... 00 00 08 00 00 00 b0 72
Fatal Python error: bad leading pad byte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 15:57:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Aug 2008 13:57:38 +0000
Subject: [issue3420] 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2
In-Reply-To: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za>
Message-ID: <1217599058.75.0.817920912613.issue3420@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is a duplicate of #3131.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3420>
_______________________________________

From report at bugs.python.org  Fri Aug  1 16:16:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 14:16:53 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1217600213.98.0.67907887555.issue3131@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Installation of PatternGrammar pickle is now fixed in r65368 and r65369.

HWJ, please don't report multiple problems in a single tracker issue;
instead, create separate tracker issues for independent problems.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Fri Aug  1 16:21:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Aug 2008 14:21:08 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217600468.12.0.655535268262.issue3399@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Assertion failed: (bp != NULL), function PyObject_Malloc, file 
> Objects/obmalloc.c, line 755.

This one gives one probable cause of the problem:

- in Modules/_multiprocessing/connection.h, connection_send_obj()
releases the GIL around a call to conn_send_string().
- in Modules/_multiprocessing/socket_connection.c, conn_send_string()
uses PyMem_Malloc()

This is wrong (the GIL must be held when using the PyMem_* and
PyObject_* functions), and is probably the cause of the failed assertion.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 16:29:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 14:29:08 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217600948.6.0.899200568172.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Amaury, I think the issue of thread-safety of the io library should be
decoupled from this issue. I don't think it is release-critical that the
io library is thread-safe (and even if it is release-critical, the
problem should be tracked in a different issue, as it requires a
completely independent patch).

The original issue (bytearrays are not thread-safe) will not be
completely resolved (for a certain definition of "thread-safe"): it will
always be possible that one thread observes a locked byte object - this
is by design of the buffer interface, and it is a good design.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 16:31:26 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 14:31:26 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217601086.05.0.946018914061.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> This is wrong (the GIL must be held when using the PyMem_* and
> PyObject_* functions), and is probably the cause of the failed 
assertion.

This sounds quite likely.

I just managed (using the low-tech method of setting a static variable 
on entry and clearing it on exit) to confirm that PyObject_Malloc in 
obmalloc.c is being accessed simultaneously by multiple threads when
test_multiprocessing is run.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 16:38:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 14:38:59 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217600948.6.0.899200568172.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217601536.4893200051103@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon "Martin v. L??wis" <report at bugs.python.org>:
>
> Amaury, I think the issue of thread-safety of the io library should be
> decoupled from this issue. I don't think it is release-critical that the
> io library is thread-safe (and even if it is release-critical, the
> problem should be tracked in a different issue, as it requires a
> completely independent patch).

Sorry Martin, I forgot to mention that I did open a separate issue in #3476.

Regards

Antoine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 16:48:25 2008
From: report at bugs.python.org (jan matejek)
Date: Fri, 01 Aug 2008 14:48:25 +0000
Subject: [issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error
In-Reply-To: <1213472808.51.0.731079646072.issue3111@psf.upfronthosting.co.za>
Message-ID: <1217602105.72.0.0562196244806.issue3111@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

> "as it doesn't seem /dev/shm is the culprit"

Mounting /dev/shm seems to fix the problem in suse's autobuild (chroot)
environment, so for me it actually was the culprit. Perhaps you should
recheck your buildbots?

----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3111>
_______________________________________

From report at bugs.python.org  Fri Aug  1 17:23:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 15:23:34 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217604214.72.0.370472763481.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now updated the patch to fix the socket bug, and the rejects
bytearray for t#.

As for making Py_buffer own a reference to the object: what should be
the semantics for PyObject_ReleaseBuffer? I see the following options:
- Drop PyObject_ReleaseBuffer
- make it DECREF the embedded object, whether or not it is the same as
the object being passed in
- leave it as-is, and require the caller to DECREF.

Added file: http://bugs.python.org/file11026/s_star.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 17:23:46 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 15:23:46 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217604226.25.0.758629820342.issue3139@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file10969/s_star.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 17:37:25 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 15:37:25 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217605045.29.0.883573169717.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that fixes the problem for me.  It releases the GIL around
the calls to _conn_sendall within conn_send_string, instead of releasing 
the GIL for the whole call to conn_send_string.

----------
keywords: +patch
Added file: http://bugs.python.org/file11027/issue3399.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 17:45:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 15:45:39 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1217605539.5.0.942982690815.issue3476@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think the proposed patch (file11012) makes it thread-safe, and I
believe you cannot get it thread-safe without using thread synchronization.

For example, if two threads simultaneously determine that there is still
space left (len(b) <= free), they might both write to self._write_buf
and self._write_end, and the last writer would win. (In case it isn't
clear how this might happen: thread 1 exhausts its Py_Ticker just after
checking the size, then thread 2 runs a full .write(), then thread 1
continues filling the buffer)

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Fri Aug  1 17:46:25 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 15:46:25 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217604214.72.0.370472763481.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217605582.48932fce9282b@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon "Martin v. L??wis" <report at bugs.python.org>:
>
> As for making Py_buffer own a reference to the object: what should be
> the semantics for PyObject_ReleaseBuffer? I see the following options:
> - Drop PyObject_ReleaseBuffer
> - make it DECREF the embedded object, whether or not it is the same as
> the object being passed in
> - leave it as-is, and require the caller to DECREF.

I don't know, is there supposed to be a semantic difference between
PyObject_ReleaseBuffer and PyBuffer_Release? If not, I'd say drop it.

Also, I think it's fine if you commit your fix without adding an incref/decref.
In the absence of the designer of the buffer API it is difficult to know what
subtleties should be taken into account when trying to change that API...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 17:55:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 15:55:03 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217605539.5.0.942982690815.issue3476@psf.upfronthosting.co.za>
Message-ID: <1217606100.489331d4ac51e@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

Selon "Martin v. L??wis" <report at bugs.python.org>:
>
> I don't think the proposed patch (file11012) makes it thread-safe, and I
> believe you cannot get it thread-safe without using thread synchronization.

I should have precised that in the context of this issue, "thread-safe" does not
mean "produces perfectly correct output" but simply "does not raise exceptions
when using the same buffered object from two different threads". The former
would be preferable but is not required, IMHO, for a buffered IO library; the
latter is much more critical because as Amaury points out, you otherwise get
exceptions when printing e.g. debut output from multiple threads.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Fri Aug  1 17:57:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Aug 2008 15:57:02 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217606222.89.0.522559803203.issue3399@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

To be complete, the patch should also deal with conn_recv_string() which
has the same problem.
And please do not forget the win32 implementation, in pipe_connection.c.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 18:06:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Aug 2008 16:06:08 +0000
Subject: [issue3483] sys.stdin.read won't return on EOF
In-Reply-To: <1217606768.05.0.96179990455.issue3483@psf.upfronthosting.co.za>
Message-ID: <1217606768.05.0.96179990455.issue3483@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

$ ./python.exe -c "import sys; sys.stdin.read()"
^D

In 2.6, this returns, but in 3.0, it still hangs despite having gotten
EOF. When a KeyboardInterrupt is given, this is the traceback:

^CTraceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/temp/python/py3k/Lib/io.py", line 1692, in read
    decoder.decode(self.buffer.read(), final=True))
  File "/temp/python/py3k/Lib/io.py", line 923, in read
    chunk = self.raw.read()
KeyboardInterrupt

----------
components: Library (Lib)
messages: 70565
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: sys.stdin.read won't return on EOF
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3483>
_______________________________________

From report at bugs.python.org  Fri Aug  1 18:25:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Aug 2008 16:25:42 +0000
Subject: [issue3483] sys.stdin.read won't return on EOF
In-Reply-To: <1217606768.05.0.96179990455.issue3483@psf.upfronthosting.co.za>
Message-ID: <1217607942.58.0.332802504057.issue3483@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm sorry. This is my oversight.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3483>
_______________________________________

From report at bugs.python.org  Fri Aug  1 18:26:09 2008
From: report at bugs.python.org (Rob Cakebread)
Date: Fri, 01 Aug 2008 16:26:09 +0000
Subject: [issue3484] Sphinx tests fail because of missing dir
In-Reply-To: <1217607969.56.0.300706889583.issue3484@psf.upfronthosting.co.za>
Message-ID: <1217607969.56.0.300706889583.issue3484@psf.upfronthosting.co.za>


New submission from Rob Cakebread <cakebread at gmail.com>:

When I try to run the unit tests with tests/run.py they fail because
this directory is missing: tests/root/_build

If I simply create the directory and run the tests, they pass.


Running Sphinx test suite...
EEE...
======================================================================
ERROR: test_config.test_core_config
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/case.py", line 182, in runTest
    self.test(*self.arg)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py",
line 20, in test_core_config
    cfg = TestApp(confoverrides=overrides).config
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py",
line 106, in __init__
    freshenv)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py",
line 101, in __init__
    self.builder = builderclass(self, freshenv=freshenv)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py",
line 58, in __init__
    os.mkdir(self.doctreedir)
OSError: [Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees'

======================================================================
ERROR: test_config.test_extension_values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/case.py", line 182, in runTest
    self.test(*self.arg)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py",
line 65, in test_extension_values
    app = TestApp()
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py",
line 106, in __init__
    freshenv)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py",
line 101, in __init__
    self.builder = builderclass(self, freshenv=freshenv)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py",
line 58, in __init__
    os.mkdir(self.doctreedir)
OSError: [Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees'

======================================================================
ERROR: Failure: OSError ([Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_markup.py",
line 21, in <module>
    app = TestApp()
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py",
line 106, in __init__
    freshenv)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py",
line 101, in __init__
    self.builder = builderclass(self, freshenv=freshenv)
  File
"/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py",
line 58, in __init__
    os.mkdir(self.doctreedir)
OSError: [Errno 2] No such file or directory:
'/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees'

----------------------------------------------------------------------
Ran 6 tests in 3.785s

FAILED (errors=3)

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 70567
nosy: cakebread, georg.brandl
severity: normal
status: open
title: Sphinx tests fail because of missing dir
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3484>
_______________________________________

From report at bugs.python.org  Fri Aug  1 18:28:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Aug 2008 16:28:03 +0000
Subject: [issue3484] Sphinx tests fail because of missing dir
In-Reply-To: <1217607969.56.0.300706889583.issue3484@psf.upfronthosting.co.za>
Message-ID: <1217608083.14.0.0137687797287.issue3484@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Sorry, time machine! I fixed this just 2 days ago. :)

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3484>
_______________________________________

From report at bugs.python.org  Fri Aug  1 18:33:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 16:33:08 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217608388.94.0.0515369951273.issue3399@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Amaury!  How's this?

I have no access to a Windows machine, so this patch is untested on 
Windows.

Added file: http://bugs.python.org/file11028/issue3399_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 18:40:54 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 16:40:54 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1217608854.36.0.338834281759.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm also seeing the incref error occasionally, on OS X 10.5.4:

======================================================================
ERROR: test_remote (__main__.WithManagerTestRemoteManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 1157, in test_remote
    queue = manager2.get_queue()
  File "/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", line 635, in temp
    authkey=self._authkey, exposed=exp
  File "/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", line 887, in AutoProxy
    incref=incref)
  File "/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", line 696, in __init__
    self._incref()
  File "/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", line 743, in _incref
    dispatch(conn, None, 'incref', (self._id,))
  File "/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", line 79, in dispatch
    raise convert_to_error(kind, result)
RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", line 181, in handle_request
    result = func(c, *args, **kwds)
  File "/Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py", line 397, in incref
    self.id_to_refcount[ident] += 1
KeyError: '6fdb78'
---------------------------------------------------------------------------

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:16:06 2008
From: report at bugs.python.org (Isaac Morland)
Date: Fri, 01 Aug 2008 17:16:06 +0000
Subject: [issue3485] os.path.normcase documentation/behaviour unclear on Mac
	OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>


New submission from Isaac Morland <ijmorlan at uwaterloo.ca>:

$ python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import normcase
>>> normcase ('aB')
'aB'
>>>

>From http://docs.python.org/lib/module-os.path.html:  "On Unix, this
returns the path unchanged; on case-insensitive filesystems, it converts
the path to lowercase."  Of course, Mac OS X is both Unix and
case-insensitive, which is a rather bizarre combination, but that's it
is.  Where is the item for "make all file systems case-sensitive, put
the case-insensitivity in the user interface"?

----------
components: Macintosh
messages: 70571
nosy: ijmorlan
severity: normal
status: open
title: os.path.normcase documentation/behaviour unclear on Mac OS X
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:42:09 2008
From: report at bugs.python.org (Kevin Watters)
Date: Fri, 01 Aug 2008 17:42:09 +0000
Subject: [issue3006] subprocess.Popen causes socket to remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1217612529.21.0.820372306208.issue3006@psf.upfronthosting.co.za>


Kevin Watters <kevinwatters at gmail.com> added the comment:

I found a workaround for this issue (attached) via the kernel32.dll
function SetHandleInformation. You can patch the socket class to set all
newly created sockets as uninheritable.

It's not perfect--another thread could still spawn a subprocess in
between.  We probably need some kind of API for setting socket inheritance.

Added file: http://bugs.python.org/file11029/socketinherit.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:47:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 17:47:30 +0000
Subject: [issue3486] bytes.join does not accept a sequence of bytearrays
In-Reply-To: <1217612850.46.0.924257550681.issue3486@psf.upfronthosting.co.za>
Message-ID: <1217612850.46.0.924257550681.issue3486@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This works in py3k but not in 2.x. I don't know if it is deliberate:

Python 3.0b2+ (py3k, Jul 27 2008, 12:52:40) 
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> b"".join([bytearray(b"")])
b''

Python 2.6b2+ (trunk, Aug  1 2008, 01:47:52) 
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> b"".join([bytearray(b"")])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sequence item 0: expected string, bytearray found

----------
components: Interpreter Core
messages: 70573
nosy: pitrou
priority: normal
severity: normal
status: open
title: bytes.join does not accept a sequence of bytearrays
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3486>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:53:33 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Aug 2008 17:53:33 +0000
Subject: [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Attached is a verifier for the binary code used by the _sre module (this
is often called bytecode, though to distinguish it from Python bytecode
I put it in quotes).

I wrote this for Google App Engine, and am making the patch available as
open source under the Apache 2 license.  Below are the copyright
statement and license, for completeness.

Barry, I'm assigning this to you only so that you can decide whether
this is okay to check in before beta3.  The patch works for 2.6 as well
as for 3.0 (and even for 2.5, but I don't think it's worth changing that
-- or is it?).  If you agree (which I hope you will do), please assign
back to me with instructions and I'll submit it.  The performance impact
is minimal: it only runs when the compiled "bytecode" is passed from the
re compiler (written in Python) to the C code, during the sre
compilation stage.  All tests pass.  We've had this code in use in App
Engine since April without complaints.

# Copyright 2008 Google Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

It's not necessary to include these copyrights and bytecode in the
source file.  Google has signed a contributor's agreement with the PSF
already.

----------
assignee: barry
files: sre-verifier.diff
keywords: patch, patch
messages: 70574
nosy: barry, gvanrossum
priority: release blocker
severity: normal
status: open
title: sre "bytecode" verifier
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11030/sre-verifier.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:53:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Aug 2008 17:53:49 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217613229.32.0.270035641585.issue3139@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Martin, 

There is a small issue with the patch: in the "w#" format handler,
bf_getwritebuffer(arg, 0, res) is wrong. The third argument should be
&res (there is a compilation warning on windows),

And a few lines after, in the "if (*format == '#')" block, there should
be a line like 
     *p = res;
otherwise the user code never sees the buffer...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:54:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Aug 2008 17:54:03 +0000
Subject: [issue3486] bytes.join does not accept a sequence of bytearrays
In-Reply-To: <1217612850.46.0.924257550681.issue3486@psf.upfronthosting.co.za>
Message-ID: <1217613243.58.0.900508791314.issue3486@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I suppose this is because bytes is simply aliased to str. I propose we
just leave it as is. The ultimate solution is probably backporting th
py3k PyBytes type.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3486>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:54:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Aug 2008 17:54:12 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217613252.03.0.631800079732.issue3399@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Mark,
There are 3 semicolons missing in your patch, in pipe_connection.c, just
after the calls to WriteFile and ReadFile.
After this, it compiles and runs correctly. Tests pass.

Note that on Windows, your "nine lines" cannot work as is, because the
processes are spawned, not forked: the sqr() function is not copied.
And if you save the lines in a script file, it will be imported by every
subprocess, and every subprocess will start its own manager... and
memory explodes.

import multiprocessing.managers
def sqr(x): return x*x
if __name__ == '__main__':
    manager = multiprocessing.managers.SyncManager()
    manager.start()
    pool = manager.Pool(4)
    it = pool.imap_unordered(sqr, range(1000))
    assert sorted(it) == [sqr(x) for x in range(1000)]
    pool.terminate()
    manager.shutdown()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:56:56 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 01 Aug 2008 17:56:56 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>


New submission from Anand B Pillai <abpillai at gmail.com>:

Python has great in-built support for all sorts of text compression
including bzip, gzip, tarfile and other general purpose modules like
zlib etc.

Of these, I have a gripe with gzip - it does not provide a simple
way of compressing/uncompressing a string like the other modules
to (namely bzip, zlib) at the module level.

It is relatively easy to perform gzip de-compression using the
GzipFile class and StringIO objects, but compression is not
that straight-forward.

It would be great for the gzip module to have "compress"
and "uncompress" functions at the module level without having
to go through GzipFile every-time.

I think being able to send gzip compressed strings directly would be
useful for applications which require to send gzip data over the wire
without having to write to files and read-back.

----------
components: Library (Lib)
messages: 70578
nosy: pythonhacker
severity: normal
status: open
title: Provide compress/uncompress functions on the gzip module
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:57:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 17:57:58 +0000
Subject: [issue3489] add rotate{left,right} methods to bytearray
In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>
Message-ID: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

While tweaking the BufferedWriter implementation it came to me that it
would be useful to have rotate_left and rotate_right methods on
bytearray,  so as to rotate the array by a number of bytes without any
wasteful memory allocations and copies.

(or, if memoryview is one day implemented it could be a memoryview
method instead...)

----------
components: Interpreter Core
messages: 70579
nosy: pitrou
priority: normal
severity: normal
status: open
title: add rotate{left,right} methods to bytearray
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________

From report at bugs.python.org  Fri Aug  1 19:58:52 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 01 Aug 2008 17:58:52 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217613532.89.0.347028079845.issue3399@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I added the semicolons Amaury, and have it teed up in my local repo for 
submit. Can you review this diff just to confirm?

Added file: http://bugs.python.org/file11031/add_semicolons.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 20:30:40 2008
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 01 Aug 2008 18:30:40 +0000
Subject: [issue2688] Error when nesting many while loops
In-Reply-To: <1209125459.31.0.611110117308.issue2688@psf.upfronthosting.co.za>
Message-ID: <1217615440.21.0.547328186158.issue2688@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

This was fixed in more recent versions of 2.5, it now raises a
"SystemError: too many statically nested blocks"

Thanks for the tip Guilherme.

Marking closed.

----------
nosy: +jackdied
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2688>
_______________________________________

From report at bugs.python.org  Fri Aug  1 20:45:41 2008
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 01 Aug 2008 18:45:41 +0000
Subject: [issue2935] rfc822.py line 395 strings connection
In-Reply-To: <1211381079.94.0.309829253424.issue2935@psf.upfronthosting.co.za>
Message-ID: <1217616341.56.0.592997252353.issue2935@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

This is a bug in the external ClientCookie module (and their website
hasn't been updated since 2006).

Marking closed.

----------
nosy: +jackdied
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2935>
_______________________________________

From report at bugs.python.org  Fri Aug  1 20:48:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 18:48:28 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217613229.32.0.270035641585.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217616501.5918.4.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 01 ao?t 2008 ? 17:53 +0000, Amaury Forgeot d'Arc a ?crit :
> There is a small issue with the patch: in the "w#" format handler,
> bf_getwritebuffer(arg, 0, res) is wrong. The third argument should be
> &res (there is a compilation warning on windows),
> 
> And a few lines after, in the "if (*format == '#')" block, there should
> be a line like 
>      *p = res;
> otherwise the user code never sees the buffer...

Nice catch! Making those changes actually fixes a segfault I had in
testReadinto in test_file.py.
?
By the way, please note bytearray.decode is broken:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ascii_decode() argument 1 must be string or pinned buffer, not bytearray
>>> bytearray(b"").decode("utf8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/bufferedwriter/Lib/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
TypeError: utf_8_decode() argument 1 must be string or pinned buffer, not bytearray
>>> bytearray(b"").decode("latin1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: latin_1_decode() argument 1 must be string or pinned buffer, not bytearray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 21:01:54 2008
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Aug 2008 19:01:54 +0000
Subject: [issue3485] os.path.normcase documentation/behaviour unclear on Mac
	OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1217617314.03.0.325545349897.issue3485@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"Of course, Mac OS X is both Unix and case-insensitive"

Not so. Case-{in|}sensitivity is an attribute of HFS+ file systems that is 
specifiable when a file system is created; it's true that the default is 
still case-insensitive. There are also other case-sensitive file systems 
supported on OS X.

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________

From report at bugs.python.org  Fri Aug  1 21:16:29 2008
From: report at bugs.python.org (Tim Peters)
Date: Fri, 01 Aug 2008 19:16:29 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217618189.51.0.150426240402.issue2819@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Mark, changing API is something to avoid after beta cycles begin (so,
e.g., it's late in the game to /add/ a new API, like a new method for
complex summation).  But there's no particular reason to fear changing
implementation for an API that's already in.  If the test suite supplies
good coverage, the buildbots will catch significant portability snafus
in plenty of time for the next release.

The big attraction to the lsum-like approach for users is that it "just
works", without requiring weasel words in the docs about overflows,
underflows, or esoteric details about various HW FP quirks.  Integer
arithmetic is just plain better behaved across platforms ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Fri Aug  1 21:19:51 2008
From: report at bugs.python.org (Isaac Morland)
Date: Fri, 01 Aug 2008 19:19:51 +0000
Subject: [issue3485] os.path.normcase documentation/behaviour unclear on Mac
	OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1217618391.22.0.730180674516.issue3485@psf.upfronthosting.co.za>


Isaac Morland <ijmorlan at uwaterloo.ca> added the comment:

Ok, good point.  Perhaps the documentation should be updated to clarify
that Mac OS is treated as Unix even though a default Mac OS X
installation will have a case-insensitive file system.  Wouldn't it be
possible for a Windows machine to have a case-sensitive file system
similarly?  Or is it more "built-in" that the file system on a Windows
box will be case-insensitive?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________

From report at bugs.python.org  Fri Aug  1 21:32:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 19:32:16 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217616501.5918.4.camel@fsol>
Message-ID: <1217619133.5918.6.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm attaching a patch for getargs.c and another patch for the codecs
module.

Added file: http://bugs.python.org/file11032/codecs.patch
Added file: http://bugs.python.org/file11033/getargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: codecs.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080801/9cff21bf/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: getargs.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080801/9cff21bf/attachment-0003.txt>

From report at bugs.python.org  Fri Aug  1 21:33:07 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 01 Aug 2008 19:33:07 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217619187.35.0.93578777535.issue3139@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy:  -giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 21:42:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 Aug 2008 19:42:44 +0000
Subject: [issue3469] Umlauts make conf.latex_documents fail
In-Reply-To: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za>
Message-ID: <1217619764.21.0.853917085389.issue3469@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Indeed, you're correct with that. This is now fixed in the 0.4 branch
with r65375.

----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3469>
_______________________________________

From report at bugs.python.org  Fri Aug  1 21:50:51 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 01 Aug 2008 19:50:51 +0000
Subject: [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za>
Message-ID: <1217620251.62.0.544158874263.issue3399@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've committed this as-is based off my last patch. I will watch the 
buildbots for failures. 

Mark/Amaury - if I see you guys at pycon, I owe you a drink.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________

From report at bugs.python.org  Fri Aug  1 22:11:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 20:11:41 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217606100.489331d4ac51e@imp.free.fr>
Message-ID: <1217621494.5918.24.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Attaching a new patch with better performance characteristics than my
previous one, and the non-blocking test rewritten in a sane way.

Some timeit runs:

-s "import io; f=io.open('/dev/null', 'wb'); s=b'a'*1" "for i in xrange(100): f.write(s)"

without patch: 533 usec per loop
with patch: ?724 usec per loop
with builtin open(): 59.6 usec per loop

-s "import io; f=io.open('/dev/null', 'wb'); s=b'a'*100" "for i in xrange(100): f.write(s)"

without patch: 563 usec per loop
with patch: 768 usec per loop
?with builtin open(): 67.8 usec per loop

-s "import io; f=io.open('/dev/null', 'wb'); s=b'a'*10000" "for i in xrange(100): f.write(s)"

without patch: 1.35 msec per loop
with patch: 1.34 msec per loop
?with builtin open(): 194 usec per loop

-s "import io; f=io.open('/dev/null', 'wb'); s=b'a'*100000" "for i in xrange(100): f.write(s)"

without patch: 4.92 msec per loop
with patch: 1.34 msec per loop
?with builtin open(): 199 usec per loop

-s "import io; f=io.open('/dev/null', 'wb'); s=b'a'*1000000" "for i in xrange(100): f.write(s)"

without patch: 173 msec per loop
with patch: 1.35 msec per loop
?with builtin open(): 194 usec per loop

Added file: http://bugs.python.org/file11034/bufferedwriter2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bufferedwriter2.patch
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080801/9614cdbf/attachment.txt>

From report at bugs.python.org  Fri Aug  1 22:28:54 2008
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 01 Aug 2008 20:28:54 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217622534.54.0.56879461022.issue3228@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

mailbox.py uses os.open instead of the builtin open() because it wants
to pass the exclusive flag (O_EXCL).  As a result your 0077 umask gets
combined with the default of 0777 like this:

0777 & ~0077 == 0700 == '-rwx------'

So you probably want to change your default umask when creating
mailboxes.  Or submit a patch to mailbox.py to allow a different default
mode ;)

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:01:17 2008
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 01 Aug 2008 21:01:17 +0000
Subject: [issue2951] ElementTree parsing bus error (but only from mod_python)
In-Reply-To: <1211565579.45.0.763330988931.issue2951@psf.upfronthosting.co.za>
Message-ID: <1217624477.93.0.546804320526.issue2951@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

It is a common apache problem.  Elementree imports an expat parser
(presumably cElementree doesn't) and different versions of expat play
together very poorly.  Lots of apache modules load one xml lib version
or another and they tend to step on each others toes .. and then segfault.

IIRC the only way to resolve this is to figure out which loaded apache
modules are using expat and recompile them all against the same version.
 Not fun.

----------
nosy: +jackdied
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2951>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:20:04 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 01 Aug 2008 21:20:04 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217625604.42.0.581597751481.issue1563@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

The current revision of 3.0 handles the case where reading from the
socket returns a Python 3.0 str object, which it then translates into
bytes objects.  This is sufficient for passing the 3.0 unittests.  See
asynchat.async_chat.use_encoding and asynchat.async_chat.encoding .

>From what I understand, the OP wants to be able to pass unicode strings
across a network connection.  I'm not sure that such is generally
desirable to be within the standard library.  I would actually argue
that being able to transparently pass unicode across a socket is a
misfeature; especially considering 1 unciode character can become 2 or
more bytes when encoded as utf-8, etc., and sockets make no guarantees
about an entire packet being delivered.

In terms of sending (push_str), it should be an error that the user
software is attempting to send textual data (all reasonable RFCs define
protocols in terms of ascii, not utf).  Handling incoming data
(set_terminator_str) follows the same argument against handling unicode
data as push_str, only in reverse.

This should not be backported to any version of Python.


Before discussion about actually applying any patch to
asyncore/asynchat/smtpd continues, I would like to hear of a use-case
for wanting to pass textual unicode data across a socket connection.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:23:40 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 01 Aug 2008 21:23:40 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217625820.93.0.495931182381.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Uploading a file containing two functions which can be used to provide
compress/uncompress on gzip.

This is not a patch to gzip.py, but a stand-alone file. It this looks
fine, I will make a patch.

Added file: http://bugs.python.org/file11035/gzip_patch.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:44:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 21:44:40 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217605582.48932fce9282b@imp.free.fr>
Message-ID: <489383C0.4020607@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't know, is there supposed to be a semantic difference between
> PyObject_ReleaseBuffer and PyBuffer_Release? If not, I'd say drop it.

There are existing callers of it which would need to be changed, perhaps
outside the core also; plus it's in PEP 3118.

Technically, they do the same.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:46:31 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Aug 2008 21:46:31 +0000
Subject: [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217627191.56.0.229848636848.issue3487@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Based on my understanding of the above and PyDev discussions, I see the
arguments in favor of quick inclusion as being the following:
1. This will be user invisible, so it is not a new interface feature.
2. This will prevent possible interpreter crashes or other bad behavior
as a result of malformed SREcode.  So it could be considered a bug fix.
3. Google considered this enough of a potential problem to pre-emptively
fix it.  Now that that problem has been publicly exposed, other careful
users will expect it to be fixed and will find Python more attractive
when it has been.

If this is included in the next betas, the announcement of such might
say so and encourage re users to re-run any re-based test code.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:47:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Aug 2008 21:47:10 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1217627230.15.0.0364562552699.issue3473@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I will not have internet access for the next week. 
Raymond, would you take care of this issue?

----------
assignee: amaury.forgeotdarc -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:51:03 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 21:51:03 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217606100.489331d4ac51e@imp.free.fr>
Message-ID: <48938544.1010500@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I should have precised that in the context of this issue, "thread-safe" does not
> mean "produces perfectly correct output" but simply "does not raise exceptions
> when using the same buffered object from two different threads".

In that case, I'm -1 for this patch. Raising exceptions is much more
preferable to silently losing data, or writing garbage.

> The former would be preferable but is not required, IMHO, for a buffered IO library; the
> latter is much more critical because as Amaury points out, you otherwise get
> exceptions when printing e.g. debut output from multiple threads.

And that's a good thing, when using a library that is not thread-safe.

Either the library provides thread-safety, or it doesn't. If it doesn't,
it's the application's responsibility to not use the library from
multiple threads, or protect all access with appropriate
synchronization. Now that print is a function, it's easy to implement
a version of it that synchronizes all prints.

With the status quo, people have at least a chance of learning that the
library is not thread-safe. If the shallow problems are resolved, people
will cry FOUL loudly when they learn about the deep problems.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Fri Aug  1 23:56:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Aug 2008 21:56:15 +0000
Subject: [issue3485] os.path.normcase documentation/behaviour unclear on Mac
	OS X
In-Reply-To: <1217610966.27.0.918507533161.issue3485@psf.upfronthosting.co.za>
Message-ID: <1217627775.76.0.0841939589543.issue3485@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

On Windows, case-insensitivity is part of the API, not of the file
system. NTFS itself is case-sensitive, and there are case-sensitive
subsystems on top of it (e.g. the POSIX subsystem, Interix). Win32, when
calling the file system, asks for case-insensitive lookup (which NTFS
also supports efficiently).

I believe FAT is inherently case-insensitive.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3485>
_______________________________________

From report at bugs.python.org  Sat Aug  2 00:08:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 22:08:57 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <48938544.1010500@v.loewis.de>
Message-ID: <1217628534.5918.41.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 01 ao?t 2008 ? 21:51 +0000, Martin v. L?wis a ?crit :
> With the status quo, people have at least a chance of learning that the
> library is not thread-safe. If the shallow problems are resolved, people
> will cry FOUL loudly when they learn about the deep problems.

But the current implementation can also silently produce garbage without
raising an exception. It's only if the context switch happens at a
certain precise point that an exception is raised. If the internal
buffer is mutated without resizing of the backing memory area (or
without any buffer being currently held), there is no exception and
still the behaviour is incorrect.
?
> Now that print is a function, it's easy to implement
> a version of it that synchronizes all prints.

Well, if that resolution is prefered, I think it should be integrated to
the builtin print function, rather than forcing users to monkeypatch it
(but a debugging facility directly calling sys.stdout.write or
equivalent will not be helped).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Sat Aug  2 00:15:29 2008
From: report at bugs.python.org (Daniel Arbuckle)
Date: Fri, 01 Aug 2008 22:15:29 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217628929.76.0.161660026581.issue1563@psf.upfronthosting.co.za>


Daniel Arbuckle <djarb at highenergymagic.org> added the comment:

> From what I understand, the OP wants to be able to pass unicode strings
> across a network connection.

That's incorrect.

At the time I formulated this patch, asyncore/asynchat were slated for
removal from the standard lib unless somebody stepped up and made it
work correctly after the str/bytes transition. That's what
asyn_py3k.diff and its predecessors do, as well as adding sorely-needed
docstrings to the module. This patch may be a little more complete than
the currently committed code, or it may be largely redundant. The
docstrings, at least, are still needed.

The asyn_py3k_restructured.diff patch is a superset of asyn_py3k.diff,
which additionally removes the "producer" type from the module,
replacing it with iterators. This is controversial, and seems unlikely
to be committed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Sat Aug  2 00:26:25 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 01 Aug 2008 22:26:25 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217629585.22.0.570072450169.issue1563@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Asyncore and asynchat are not going to be removed, and were not being
seriously discussed as being removable in Python 3.0 since January of
2007 when I took over maintenance.  If there was a miscommunication in
an email thread on python-3000 or python-dev, then I'm sorry, as I was
relatively incommunicado for about a year.

As of right now, the tests for 3.0 pass, and when passing only bytes in
and out of asyncore and asynchat, everything works just fine.  Mixing
and matching might or might not work, but explicitly allowing an error
to pass silently (passing text where bytes should be passed) is the
wrong thing to do.

If you want to change the docstrings, that's fine, submit a patch that
includes docstring changes only, and I'll probably commit it some time
next week.  Functionality changes will need to be discussed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Sat Aug  2 00:32:20 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 22:32:20 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1217629940.47.0.0249490507699.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For the connection refused error, the following script fails for me 
(again, on OS X 10.5.4) with the message:

errno: [Errno 61] Connection refused

on most runs.  (If xrange(10) is replaced by a smaller range like 
xrange(4) then the script usually runs without error.)  Looks like
something in semaphore.c needs fixing, but I've no idea what.



from multiprocessing import Process, Manager
sleeping = Manager().Semaphore(0)

def f():
    sleeping.release()

for _ in xrange(10):
    Process(target=f).start()
for _ in xrange(10):
    sleeping.acquire()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sat Aug  2 01:05:19 2008
From: report at bugs.python.org (Daniel Arbuckle)
Date: Fri, 01 Aug 2008 23:05:19 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217631919.78.0.752553891026.issue1563@psf.upfronthosting.co.za>


Daniel Arbuckle <djarb at highenergymagic.org> added the comment:

As of December 2007, Guido did not believe that you or anyone else cared
enough about asyncore/asynchat to update them to py3k:
http://mail.python.org/pipermail/python-dev/2007-December/075574.html

Thankfully there's been a resurgence of activity on the modules, and
they're well out of danger now.

I _am_not_ proposing that passing unicode into asyncore should do
anything other than fail. I have never proposed such, and my patch
tightened those constraints rather than loosening them. Please stop
beating that horse; it's dead.

On a more positive note, I'll put together that docstring patch for you
at the same time I'm evaluating whether any of the rest of my patch
remains necessary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Sat Aug  2 01:20:51 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Aug 2008 23:20:51 +0000
Subject: [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217632851.72.0.253332599253.issue3459@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

How much does the optimization speed up (or slow down?) a more normal
case when it is applicable?
  bl = [b'', b'a']

How much does the optimization slow down the normal case where it is not
applied?
  bl = [b'a']*2
  bl = [b'a']*10000

Could not the .join user simply not add empty list items?

Looking at the code, there appear to be 4 extra operations for every
item in the normal case: assign item_size, test item_size, assign
nonempty, increment nb_nonempty.  I believe this alternative might be
generally faster.  Before the normal scan,

if seplen == 0:
  for item in seq:
    <if second non-null item>: break
  else:
    <do shortcut and return>

<do normal process>

Then normal cases will bail out on the second item and continue without
further impact.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________

From report at bugs.python.org  Sat Aug  2 01:41:14 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Aug 2008 23:41:14 +0000
Subject: [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217634074.5.0.121809023326.issue3487@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> 3. Google considered this enough of a potential problem to pre-emptively
> fix it.  Now that that problem has been publicly exposed, other careful
> users will expect it to be fixed and will find Python more attractive
> when it has been.
> 
> If this is included in the next betas, the announcement of such might
> say so and encourage re users to re-run any re-based test code.

I should add that the protection this offers is against attempts to
cause crashes by passing bad RE "bytecode" into the _sre.compile().

It is not possibly to generate such bad RE "bytecode" by writing an evil
regular expression; you must have access to the _sre module in order to
be able to exploit this vulnerability.  In other words, the
vulnerability is equivalent to having ctypes accessible.

Thus, only people who are worried about malicious use of ctypes should
be worried about this vulnerability.  Google's App Engine is one of
those (rare) places, since it lets anybody run their Python code in a
Google datacenter.  If you offer the ability to run arbitrary Python
code to strangers, you should worry about this.  Otherwise, there is no
reason to worry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________

From report at bugs.python.org  Sat Aug  2 01:44:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Aug 2008 23:44:06 +0000
Subject: [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217634246.09.0.357922311854.issue3459@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

bl = [b'', b'a'] gives a 20% speedup:

before patch:
1000000 loops, best of 3: 0.443 usec per loop
after patch:
1000000 loops, best of 3: 0.349 usec per loop
(20% speedup)

bl = [b'a']*2 gives a 2% slowdown:

before patch:
1000000 loops, best of 3: 0.439 usec per loop
after patch:
1000000 loops, best of 3: 0.447 usec per loop

bl = [b'a']*10000 gives a 1% slowdown:

before patch:
1000 loops, best of 3: 510 usec per loop
after patch:
1000 loops, best of 3: 515 usec per loop

So, even in the worst case of joining the shortest possible non-empty
strings, the overhead is still minimal.

> Could not the .join user simply not add empty list items?

The .join user could also detect whether there is a single element in
the list and the separator is empty, and then avoid calling join :)

The point of integrating the optimization in bytes.join is that:
1) it makes it implicit, so that user code stays clean of "performance
hacks"
2) the optimization itself has much less overhead, since it is written
in C rather than in Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________

From report at bugs.python.org  Sat Aug  2 01:50:50 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Aug 2008 23:50:50 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1217634650.39.0.320136287346.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Looks like something in semaphore.c needs fixing, but I've no idea what.

I take that back.  It's nothing to do with semaphore.c.  I'll keep trying.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sat Aug  2 02:01:34 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 02 Aug 2008 00:01:34 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1217634650.39.0.320136287346.issue3419@psf.upfronthosting.co.za>
Message-ID: <11279739-FC61-4D57-84AA-7CE5D6C6BBF2@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

Are you looking at the conn refused or the incref error?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sat Aug  2 02:18:43 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Aug 2008 00:18:43 +0000
Subject: [issue3463] make life.py use more rendering characters
In-Reply-To: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za>
Message-ID: <1217636323.15.0.7565520013.issue3463@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Summary: This patch makes a non-essential change to a curses demo.  It
also reverses several 2.x to 3.0 edits, turning it back to 2.x code.  So
the current version must be rejected.  Even if corrected, I would still
recommend closing.

To me, allowing any printable ascii char, even space, to represent live
cells adds nothing to the file's value as a curses demo.  Perhaps # as
an altnative, but even that would be a distraction from the main purpose.

The large bash-specific input chart is very nice.  I wish I has had
something like that when I worked with sh and csh.  But it has little to
do with this program in particular or Python as such and I think it
would be a distraction if added.

These diffs and others like them replace 3.0 code with 2.x code that in
two cases will not work in 3.0.

-            raise ValueError("Coordinates out of range %i,%i"% (y,x))
+            raise ValueError, "Coordinates out of range %i,%i"% (y,x)

-                live = (i,j) in self.state
+                live = self.state.has_key( (i,j) )

-    xpos, ypos = board.X//2, board.Y//2
+    xpos, ypos = board.X/2, board.Y/2

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3463>
_______________________________________

From report at bugs.python.org  Sat Aug  2 02:51:40 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Aug 2008 00:51:40 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217638300.31.0.0440927506587.issue2819@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Comment: as a user (on x86) I agree with Tim.  I could almost see the
new version as a bugfix.

Question: I see "math module patch committed, r63542" in May 22.  But in
3.0b2, there is no math.fsum and math.sum seems to be a wrapper for
builtin sum.  Has this not been forward ported (merged) yet?
>>> math.sum
<built-in function sum>
>>> sum
<built-in function sum>
>>> math.sum is sum
False

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Sat Aug  2 03:50:25 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 02 Aug 2008 01:50:25 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217628534.5918.41.camel@fsol>
Message-ID: <4893BD5E.2030709@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, if that resolution is prefered, I think it should be integrated to
> the builtin print function, rather than forcing users to monkeypatch it
> (but a debugging facility directly calling sys.stdout.write or
> equivalent will not be helped).

True. I think it is the stream's write method that must be
synchronized, e.g. by renaming the current write function to
_write_locked, and adding a write function that obtains a per-file
lock, and calls write_locked. Other methods accessing the buffer
need to get synchronized with the same lock as well.

This is how it's done in about any stdio implementation I ever looked at.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Sat Aug  2 04:54:19 2008
From: report at bugs.python.org (Adam)
Date: Sat, 02 Aug 2008 02:54:19 +0000
Subject: [issue3490] Example Code Error in Tutorial Documentation
In-Reply-To: <1217645659.61.0.258873000656.issue3490@psf.upfronthosting.co.za>
Message-ID: <1217645659.61.0.258873000656.issue3490@psf.upfronthosting.co.za>


New submission from Adam <yoshokun at gmail.com>:

In section 4.4 of the Python Tutorial
(http://docs.python.org/tut/node6.html) there is a code example using
prime numbers that results extraneous output. The else is incorrectly
indented one tab too far to the right and is nested under (for x in
range) rather than (for n in range).

Current:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break
...     else:
...         # loop fell through without finding a factor
...         print n, 'is a prime number'
... 

Correct:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break
...  else:
...      # loop fell through without finding a factor
...      print n, 'is a prime number'
...

----------
assignee: georg.brandl
components: Documentation
messages: 70613
nosy: georg.brandl, yoshokun
severity: normal
status: open
title: Example Code Error in Tutorial Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3490>
_______________________________________

From report at bugs.python.org  Sat Aug  2 04:57:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Aug 2008 02:57:31 +0000
Subject: [issue3490] Example Code Error in Tutorial Documentation
In-Reply-To: <1217645659.61.0.258873000656.issue3490@psf.upfronthosting.co.za>
Message-ID: <1217645851.48.0.974731118396.issue3490@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r65382.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3490>
_______________________________________

From report at bugs.python.org  Sat Aug  2 04:59:59 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 02 Aug 2008 02:59:59 +0000
Subject: [issue3491] compile error fixing (_multiprocessing, windows)
In-Reply-To: <1217645999.36.0.923455204468.issue3491@psf.upfronthosting.co.za>
Message-ID: <1217645999.36.0.923455204468.issue3491@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

This will fix the compile error on buildbot. Thank you.

----------
components: Windows
files: fix_compile_error.patch
keywords: patch, patch
messages: 70615
nosy: ocean-city
severity: normal
status: open
title: compile error fixing (_multiprocessing, windows)
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file11036/fix_compile_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3491>
_______________________________________

From report at bugs.python.org  Sat Aug  2 05:02:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Aug 2008 03:02:02 +0000
Subject: [issue3490] Example Code Error in Tutorial Documentation
In-Reply-To: <1217645659.61.0.258873000656.issue3490@psf.upfronthosting.co.za>
Message-ID: <1217646122.95.0.796792008727.issue3490@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Sorry, the example actually is correct. (reverted)

----------
resolution: fixed -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3490>
_______________________________________

From report at bugs.python.org  Sat Aug  2 05:12:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Aug 2008 03:12:02 +0000
Subject: [issue3491] compile error fixing (_multiprocessing, windows)
In-Reply-To: <1217645999.36.0.923455204468.issue3491@psf.upfronthosting.co.za>
Message-ID: <1217646722.2.0.0858155958014.issue3491@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r65385.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3491>
_______________________________________

From report at bugs.python.org  Sat Aug  2 05:39:46 2008
From: report at bugs.python.org (Collin Winter)
Date: Sat, 02 Aug 2008 03:39:46 +0000
Subject: [issue3480] Fix_imports pattern optimization
In-Reply-To: <1217534405.3.0.224427460631.issue3480@psf.upfronthosting.co.za>
Message-ID: <1217648386.26.0.815951898376.issue3480@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Committed as r65397. Nice work!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3480>
_______________________________________

From report at bugs.python.org  Sat Aug  2 05:41:04 2008
From: report at bugs.python.org (Collin Winter)
Date: Sat, 02 Aug 2008 03:41:04 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217648464.05.0.952907266055.issue3358@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Nick, what do you think about that?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Sat Aug  2 05:42:48 2008
From: report at bugs.python.org (Nick Edds)
Date: Sat, 02 Aug 2008 03:42:48 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217648568.32.0.974166814401.issue3358@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Sounds good to me. I should have a chance to implement this and submit
it within the next couple of days.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Sat Aug  2 09:24:56 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 02 Aug 2008 07:24:56 +0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1217661896.7.0.711652707025.issue799428@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch, committed as r65399, r65400, and r65401.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
_______________________________________

From report at bugs.python.org  Sat Aug  2 09:25:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 02 Aug 2008 07:25:12 +0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1217661912.45.0.0660665384825.issue799428@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
_______________________________________

From report at bugs.python.org  Sat Aug  2 10:03:03 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Sat, 02 Aug 2008 08:03:03 +0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1217664183.54.0.563644901314.issue1563@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Sounds good.  I look forward to seeing the patch :) .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
_______________________________________

From report at bugs.python.org  Sat Aug  2 10:57:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Aug 2008 08:57:14 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1217667434.47.0.770731192577.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Question: I see "math module patch committed, r63542" in May 22.  But in
> 3.0b2, there is no math.fsum and math.sum seems to be a wrapper for
> builtin sum.  Has this not been forward ported (merged) yet?

I'm pretty sure it *was* merged:  math.sum should be the full-precision 
summation in both recent betas (2.6b2 and 3.0b2).  Try comparing
sum([1e100, 1, -1e100, -1]) and math.sum([1e100, 1, -1e100, -1])---they 
should produce -1.0 and 0.0 respectively.

The name change to fsum only happened in the last few days.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Sat Aug  2 12:01:34 2008
From: report at bugs.python.org (=?utf-8?q?Niels_Gust=C3=A4bel?=)
Date: Sat, 02 Aug 2008 10:01:34 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217671294.74.0.642308605704.issue3228@psf.upfronthosting.co.za>


Niels Gust?bel <niels at gustaebel.de> added the comment:

The problem is not limited to mboxes but also applies to maildirs. Any
message file created inside a maildir has execute permissions set as
well because the same function _create_carefully() is used.

Changing the umask is not an option because it also affects any folders
that are created. Setting the umask to something like 0177 would render
the base folder and the {new,cur,tmp} folders of a newly created Maildir
unusable.

To me the only solution is changing the _create_carefully() function, so
that it provides a mode argument to os.open() as done in the attached patch.

The patch also fixes another instance of this problem: the empty file
"maildirfolder" which is created inside a maildir's base folder. It
should not be executable as well.

----------
keywords: +patch
nosy: +ngustaebel
Added file: http://bugs.python.org/file11037/python-mailbox-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Sat Aug  2 12:15:59 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Sat, 02 Aug 2008 10:15:59 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>


New submission from Anand B Pillai <abpillai at gmail.com>:

>>> import zlib
>>> s='This is a string'
>>> sc=zlib.compress(s)
>>> sc
bytearray(b'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\x92\xa2\xcc\xbct\x00/\xc2\x05\xcd')
>>> zlib.decompress(sc)
bytearray(b'This is a string')
>>>

This is wrong behavior as compress functions should return byte
,not a bytearray. Same for decompress.

----------
components: Library (Lib)
messages: 70625
nosy: pythonhacker
severity: normal
status: open
title: Zlib compress/decompress functions returning bytearray
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Sat Aug  2 13:48:36 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 02 Aug 2008 11:48:36 +0000
Subject: [issue3039] tarfile.TarFileCompat.writestr(ZipInfo,
	str) raises AttributeError
In-Reply-To: <1212632567.86.0.457282985708.issue3039@psf.upfronthosting.co.za>
Message-ID: <1217677716.54.0.64092710587.issue3039@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Thank you very much for your patch, I applied it to the trunk as r65402.
However, I decided to remove the TarFileCompat class from the Python 3.0
branch, see
http://mail.python.org/pipermail/python-3000/2008-July/014448.html for
details.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3039>
_______________________________________

From report at bugs.python.org  Sat Aug  2 14:01:50 2008
From: report at bugs.python.org (Adam)
Date: Sat, 02 Aug 2008 12:01:50 +0000
Subject: [issue3490] Example Code Error in Tutorial Documentation
In-Reply-To: <1217645659.61.0.258873000656.issue3490@psf.upfronthosting.co.za>
Message-ID: <1217678510.39.0.479011490858.issue3490@psf.upfronthosting.co.za>


Adam <yoshokun at gmail.com> added the comment:

You know what, you're absolutely right. My apologies for sending the bad
submission. =\

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3490>
_______________________________________

From report at bugs.python.org  Sat Aug  2 14:41:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 12:41:09 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217680869.74.0.95291677261.issue3228@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would be nice if the patch came with a test.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Sat Aug  2 15:00:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Aug 2008 13:00:09 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1217682009.63.0.863238187088.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Sorry, I'm not going to be able to work on this soon.

----------
assignee: benjamin.peterson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Sat Aug  2 15:44:20 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Aug 2008 13:44:20 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1217684660.86.0.707387583889.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Are you looking at the conn refused or the incref error?

The connection refused error.

The attached patch fixes the problem, for me.  On my machine, the 
connection refused error code was 61 rather than 10061.  With this patch, 
I'm no longer seeing any hangs in test_multiprocessing.py (at least, not in 
the last 500 runs :-)).  (Though I am still seeing the incref error 
occasionally.)

If anyone's prepared to answer a stupid question:  I'm curious why failed 
socket connections occur at all.  Is connecting to a socket generally 
considered an unreliable operation, or is there some aspect of the 
multiprocessing module that makes it potentially unreliable?

----------
keywords: +patch
Added file: http://bugs.python.org/file11038/mp_nohang.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sat Aug  2 16:23:57 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 02 Aug 2008 14:23:57 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1217684660.86.0.707387583889.issue3419@psf.upfronthosting.co.za>
Message-ID: <C3DECAA0-2819-4226-AA28-A3E6BB1BCF35@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Aug 2, 2008, at 9:44 AM, Mark Dickinson <report at bugs.python.org>  
wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
>> Are you looking at the conn refused or the incref error?
>
> The connection refused error.
>
> The attached patch fixes the problem, for me.  On my machine, the
> connection refused error code was 61 rather than 10061.  With this  
> patch,
> I'm no longer seeing any hangs in test_multiprocessing.py (at least,  
> not in
> the last 500 runs :-)).  (Though I am still seeing the incref error
> occasionally.)
>
> If anyone's prepared to answer a stupid question:  I'm curious why  
> failed
> socket connections occur at all.  Is connecting to a socket generally
> considered an unreliable operation, or is there some aspect of the
> multiprocessing module that makes it potentially unreliable?
>

I believe the conn refused error is another race, the child processes  
are connecting to a manager which is shutting down/gone

Thanks again mark- when I get a chance today I'll review/test/apply  
the patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sat Aug  2 16:32:54 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 02 Aug 2008 14:32:54 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217687574.3.0.274060770682.issue3139@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Two comments:

 * I like the new *-getarg parameters, but it would be better to test
   for '#' first since this is still by far the most used getarg
   parameter.

 * Antoine, I think your codecs.c patch has a glitch:

+    decoded = PyUnicode_DecodeMBCSStateful(pbuf.buf, pbuf.len, errors,
+					   final ? NULL : &consumed);
+	PyBuffer_Release(&pbuf);
+    if (decoded == NULL)
 	return NULL;
-    return codec_tuple(decoded, final ? size : consumed);
+    return codec_tuple(decoded, consumed);
 }
 
   You dropped the "final ? size : " for no apparent reason.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Aug  2 16:49:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 14:49:54 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217688594.31.0.975553653454.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You've missed the preceding line that says:

+    consumed = pbuf.len;

If final is NULL, consumed isn't updated by the call to
PyUnicode_DecodeMBCSStateful and keeps its original value of pbuf.len.

(in all honesty, I didn't test under Windows so this particular function
wasn't enabled when I compiled and ran the test suite)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Aug  2 19:22:58 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 02 Aug 2008 17:22:58 +0000
Subject: [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217697778.7.0.693007229642.issue3459@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I dislike this change, not because of the potential slowdown, but
because of the added code complexity.

How plausible is it that you want to join a list of bytes objects, and
the list has more than one item, yet all but one item are empty? If you
have such an application, and performance matters, you shouldn't add the
empty bytes to the list in the first place.

Tentatively rejecting the patch.

----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________

From report at bugs.python.org  Sat Aug  2 20:57:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 18:57:36 +0000
Subject: [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217703456.4.0.257165915696.issue3459@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well as I said it occurred to me when doing some measurements of
BufferedReader performance, but I agree that the gain may not justify
the complexity. If nobody objects, feel free to close the issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________

From report at bugs.python.org  Sat Aug  2 21:03:48 2008
From: report at bugs.python.org (Marc Rambert)
Date: Sat, 02 Aug 2008 19:03:48 +0000
Subject: [issue3493] No Backslash (\) in IDLE 1.2.2
In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
Message-ID: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>


New submission from Marc Rambert <rambert.marc at free.fr>:

With my MacBook, on IDLE application, I can't type any character like this 
one \.

----------
components: IDLE
messages: 70637
nosy: Marc67
severity: normal
status: open
title: No Backslash (\) in IDLE 1.2.2
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3493>
_______________________________________

From report at bugs.python.org  Sat Aug  2 21:05:25 2008
From: report at bugs.python.org (Marc Rambert)
Date: Sat, 02 Aug 2008 19:05:25 +0000
Subject: [issue3493] No Backslash (\) in IDLE 1.2.2
In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
Message-ID: <1217703925.38.0.906001641067.issue3493@psf.upfronthosting.co.za>


Changes by Marc Rambert <rambert.marc at free.fr>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3493>
_______________________________________

From report at bugs.python.org  Sat Aug  2 21:11:17 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Sat, 02 Aug 2008 19:11:17 +0000
Subject: [issue3494] "[Errno 11] Resource temporarily unavailable" while using
	tracing facility/threads (in linux listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

A bug has been reported against pydev complaining about os.listdir()
failing while debugging (with a unicode path).

The link for that is:
http://sourceforge.net/tracker/index.php?func=detail&aid=2012138&group_id=85796&atid=577329

After trying to find its cause, it appears that pydev is exercising a
python bug (which is reproduced in the file attached). I have no idea
why that's happening. 

I've reproduced it in python 2.4 and python 2.5 under ubuntu 6.10, but I
believe it happens on other versions too -- the original bug was
reported in Ubuntu 8.04 AMD64 Hardy Heron)

----------
components: Interpreter Core, Library (Lib)
files: listdir_problem.py
messages: 70638
nosy: fabioz
severity: normal
status: open
title: "[Errno 11] Resource temporarily unavailable" while using tracing facility/threads (in linux listdir with unicode path)
type: crash
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file11039/listdir_problem.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________

From report at bugs.python.org  Sat Aug  2 21:50:29 2008
From: report at bugs.python.org (Dustin J. Mitchell)
Date: Sat, 02 Aug 2008 19:50:29 +0000
Subject: [issue1187] pipe fd handling issues in subprocess.py on POSIX
In-Reply-To: <1190400129.03.0.21752289973.issue1187@psf.upfronthosting.co.za>
Message-ID: <1217706629.2.0.881380985099.issue1187@psf.upfronthosting.co.za>


Dustin J. Mitchell <dustin at v.igoro.us> added the comment:

Thoughts on this patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1187>
_______________________________________

From report at bugs.python.org  Sat Aug  2 22:13:13 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 02 Aug 2008 20:13:13 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1217688594.31.0.975553653454.issue3139@psf.upfronthosting.co.za>
Message-ID: <4894BFD5.9060501@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-08-02 16:49, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> You've missed the preceding line that says:
> 
> +    consumed = pbuf.len;
> 
> If final is NULL, consumed isn't updated by the call to
> PyUnicode_DecodeMBCSStateful and keeps its original value of pbuf.len.
> 
> (in all honesty, I didn't test under Windows so this particular function
> wasn't enabled when I compiled and ran the test suite)

Thanks for clarifying this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Aug  2 22:16:57 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Aug 2008 20:16:57 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1217667434.47.0.770731192577.issue2819@psf.upfronthosting.co.za>
Message-ID: <4894C0B5.1000408@udel.edu>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> I'm pretty sure it *was* merged:  math.sum should be the full-precision 
> summation in both recent betas (2.6b2 and 3.0b2).  Try comparing
> sum([1e100, 1, -1e100, -1]) and math.sum([1e100, 1, -1e100, -1])---they 
> should produce -1.0 and 0.0 respectively.

They do.  I realize now that two different built-in funcs in two 
different modules but with the same name will give the same 
representation.  That is so unusual, I was not expecting it.

> The name change to fsum only happened in the last few days.

Which will prevent the confusion I had ;-).  Good idea.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Sat Aug  2 22:36:34 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Aug 2008 20:36:34 +0000
Subject: [issue3459] optimize bytes.join()
In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za>
Message-ID: <1217709394.04.0.289812501399.issue3459@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>bl = [b'a']*2 gives a 2% slowdown:
>bl = [b'', b'a'] gives a 20% speedup:

If the second case is less than 9% of cases, which I expect is true,
the change would cause an average slowdown ;-)

>I encountered this when trying to optimize io.BufferedReader.

Is there something peculiar about that code (and potentially fixable)
that it tries to join lots of null strings?

>I dislike this change... because of the added code complexity.

That was part of my reason for suggesting the new code be separated from
the old, but it would not much change the calculation above.
So I agree on closing this.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3459>
_______________________________________

From report at bugs.python.org  Sat Aug  2 22:44:10 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 02 Aug 2008 20:44:10 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1217709850.5.0.56352673825.issue2275@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I'm ok with these patchs, Senthil.

John, what do you think about this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Sat Aug  2 23:03:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 21:03:19 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1217710999.56.0.67167927648.issue2538@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65420, with a test.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2538>
_______________________________________

From report at bugs.python.org  Sun Aug  3 00:48:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 22:48:23 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217717303.87.0.540743265537.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch wrapping up Martin's patch with the following additions:
- getargs.c fixes
- codecs module fixes
- multiprocessing module fix
- fileobject readinto fix
- in bytearray deallocator, print out a SystemError if there are
existing exports

The whole test suite now passes, which is a good start :-)

Added file: http://bugs.python.org/file11040/s_star2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Aug  3 00:51:49 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 22:51:49 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217717509.8.0.131340771005.issue3139@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11032/codecs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Aug  3 00:51:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 22:51:55 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1217717515.73.0.653315858055.issue3139@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11033/getargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Aug  3 01:14:26 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Aug 2008 23:14:26 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217718866.51.0.0767346221719.issue3488@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the functionality is useful, although it may be too late to make
it into 2.6/3.0. Some comments:
- the functions should have docstrings
- there should be unit tests
- style nit: named parameters in function calls (and default values in
function declarations) shouldn't have spaces around the '=' sign

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Sun Aug  3 02:09:01 2008
From: report at bugs.python.org (Ian Stokes-Rees)
Date: Sun, 03 Aug 2008 00:09:01 +0000
Subject: [issue3495] site module doc typo
In-Reply-To: <1217722141.33.0.0489020423949.issue3495@psf.upfronthosting.co.za>
Message-ID: <1217722141.33.0.0489020423949.issue3495@psf.upfronthosting.co.za>


New submission from Ian Stokes-Rees <ijstokes at alumni.uwaterloo.ca>:

http://docs.python.org/lib/module-site.html | sed -e "s/2.3/2.5/g"

----------
assignee: georg.brandl
components: Documentation
messages: 70647
nosy: georg.brandl, ijstokes
severity: normal
status: open
title: site module doc typo
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3495>
_______________________________________

From report at bugs.python.org  Sun Aug  3 03:45:11 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Aug 2008 01:45:11 +0000
Subject: [issue2396] Backport memoryview object to Python 2.6
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1217727911.22.0.976920597594.issue2396@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

But the warning in 2.6 for buffer() says to use memoryview(), which does
not exist. So either the backport needs to happen in 2.6 or the warning
needs to go away for generic buffer() usage and instead be changed to
only occur when the 2to3 fixer won't work (which, I am guessing, is only
needed when more than one argument to buffer() is used).

----------
nosy: +brett.cannon
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Sun Aug  3 04:00:25 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Aug 2008 02:00:25 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1217728825.77.0.240676033051.issue3474@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Sun Aug  3 07:24:49 2008
From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=)
Date: Sun, 03 Aug 2008 05:24:49 +0000
Subject: [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1217741089.88.0.0954146719467.issue3424@psf.upfronthosting.co.za>


Ilpo Nyyss?nen <iny at iki.fi> added the comment:

jpeg
exif
png
gif
tiff

and then the rest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________

From report at bugs.python.org  Sun Aug  3 08:08:03 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 03 Aug 2008 06:08:03 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217743683.74.0.649199326814.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Thanks. The file I uploaded was not an actual patch but just how the
functions would appear in the gzip module, to illustrate the code.

I can make an actual patch to gzip.py with docstrings, unit-tests and
taking care of your other comments. Do you think this will be in time
for Python 3.0 ? I can do this right away.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Sun Aug  3 11:21:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Aug 2008 09:21:30 +0000
Subject: [issue3495] site module doc typo
In-Reply-To: <1217722141.33.0.0489020423949.issue3495@psf.upfronthosting.co.za>
Message-ID: <1217755290.21.0.225146073636.issue3495@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65430.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3495>
_______________________________________

From report at bugs.python.org  Sun Aug  3 12:13:03 2008
From: report at bugs.python.org (=?utf-8?q?Niels_Gust=C3=A4bel?=)
Date: Sun, 03 Aug 2008 10:13:03 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217758383.59.0.768577472329.issue3228@psf.upfronthosting.co.za>


Niels Gust?bel <niels at gustaebel.de> added the comment:

I've added tests for all mailbox formats and the maildirfolder marker,
so I think all aspects of the fix are covered. The permissions of
temporary files and lock files are not checked, but they are basically
all using the _create_carefully() function and they are not persistent
anyway.

Added file: http://bugs.python.org/file11041/mailbox-fix-w-tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Sun Aug  3 12:40:21 2008
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 03 Aug 2008 10:40:21 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217760021.04.0.256526531018.issue3228@psf.upfronthosting.co.za>


Jakub Wilk <ubanus at users.sf.net> added the comment:

For consistency with other methods, test_folder_file_permissions()
should set umask to 0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Sun Aug  3 12:54:08 2008
From: report at bugs.python.org (=?utf-8?q?Niels_Gust=C3=A4bel?=)
Date: Sun, 03 Aug 2008 10:54:08 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217760848.37.0.350083487799.issue3228@psf.upfronthosting.co.za>


Niels Gust?bel <niels at gustaebel.de> added the comment:

Of course you are right...

Added file: http://bugs.python.org/file11042/mailbox-fix-w-tests-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Sun Aug  3 18:12:57 2008
From: report at bugs.python.org (Paul Moore)
Date: Sun, 03 Aug 2008 16:12:57 +0000
Subject: [issue3496] distutils fails with mingw binutils 2.18.50.20080109
In-Reply-To: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>
Message-ID: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

The latest version of Mingw binutils, 2.18.50.20080109, uses a 4-part
version number which distutils does not like (StrictVersion only allows
for 3 parts).

The attached patch fixes this, simply by using LooseVersion (the version
number has already been checked to be a series of numbers in the regex
check just previous).

Can this be fixed for 2.6/3.0, as it is likely that the new binutils
will become common while these versions of Python are current?

----------
components: Distutils
files: distutils.patch
keywords: patch
messages: 70655
nosy: pmoore
severity: normal
status: open
title: distutils fails with mingw binutils 2.18.50.20080109
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11043/distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3496>
_______________________________________

From report at bugs.python.org  Sun Aug  3 20:40:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Aug 2008 18:40:48 +0000
Subject: [issue3496] distutils fails with mingw binutils 2.18.50.20080109
In-Reply-To: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>
Message-ID: <1217788848.89.0.605034696315.issue3496@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> critical
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3496>
_______________________________________

From report at bugs.python.org  Sun Aug  3 20:49:22 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 03 Aug 2008 18:49:22 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1217789362.58.0.995519667832.issue3475@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

This is fixed in the ET 1.3-compatible codebase.  Since it's too late to
add ET 1.3 to 2.6, I guess it's time to make a new 1.2 bugfix release
for 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3475>
_______________________________________

From report at bugs.python.org  Sun Aug  3 21:21:40 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 03 Aug 2008 19:21:40 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217791300.04.0.91753903662.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

I have uploaded the actual patch file which can be applied against the
gzip.py module. I did not modify the _test() function since it is
written for testing file compression. I can modify test_gzip.py if this
patch is accepted.

----------
keywords: +patch
Added file: http://bugs.python.org/file11044/gzip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Sun Aug  3 21:35:57 2008
From: report at bugs.python.org (vadim suvorov)
Date: Sun, 03 Aug 2008 19:35:57 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>


New submission from vadim suvorov <zzPythonTracker at stelary.com>:

The result of the attached script execution is extremely unstable. The
change in the print statement in line 146 from 'print "1"' to 'print 1'
(string literal to numerical) changes the result of execution to the
correct (presumably) one. The results are also affected by commenting
out calls to empty method in lines 143 or 227. The use of dis.dis()
affects results of the execution as well. More than, the location of
error (the triggered assert) shifts in the code, or it is possible that
an Exception is raised.

The script was tested in Python 2.5.2 in Windows XP SP2 and SP3,
2.6beta2 in Windows XP SP3 and in 2.5.2 Ubuntu 8.0.4 with consistent
results. (I mean that behavior of the script is changed by calling of
empty methods or irrelevant print statements. The assert shifts.)

Sorry for the long script. I failed to further reduce its size because
effect disappears.

Expected output:
~~~~~~~~~~~~~~~~~~~~~
1
1
1
1
1
1
1
1
1
1
1
1
Congratulations: grid solved!
    1 2 3 4 5 6 7 8 910
 1  B B B B B . B . . B
 2  . B . . B B B B . B
 3  . . . . . B B . B B
 4  . . . B B B B B B .
 5  B . B B B . . B B B
~~~~~~~~~~~~~~~~~~~~~


Received output (example):
~~~~~~~~~~~~~~~~~~~~~
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Traceback (most recent call last):
  File "E:\pet projects\nonograms\nonogramsolver10.py", line 244, in
<module>
    g.solve()
  File "E:\pet projects\nonograms\nonogramsolver10.py", line 230, in solve
    seq.simplescan()
  File "E:\pet projects\nonograms\nonogramsolver10.py", line 99, in
simplescan
    assert self.clues, "a seq with no clues"
AssertionError: a seq with no clues
~~~~~~~~~~~~~~~~~~~~~

----------
components: Interpreter Core
files: nonogramsolver10.py
messages: 70658
nosy: bad
severity: normal
status: open
title: a bug in the interpreter?
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file11045/nonogramsolver10.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Sun Aug  3 21:37:17 2008
From: report at bugs.python.org (vadim suvorov)
Date: Sun, 03 Aug 2008 19:37:17 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217792237.97.0.00386322709008.issue3497@psf.upfronthosting.co.za>


Changes by vadim suvorov <zzPythonTracker at stelary.com>:


Added file: http://bugs.python.org/file11046/nonogramsolver09.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Sun Aug  3 21:48:30 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 03 Aug 2008 19:48:30 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1217792910.15.0.683238642458.issue3492@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Hi, I have a patch ready for this to be applied to zlibmodule.c. The
patch is attached. I have tested it and it is working fine.

----------
keywords: +patch
Added file: http://bugs.python.org/file11047/zlibmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Sun Aug  3 21:59:59 2008
From: report at bugs.python.org (vadim suvorov)
Date: Sun, 03 Aug 2008 19:59:59 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217793599.53.0.17081590986.issue3497@psf.upfronthosting.co.za>


vadim suvorov <zzPythonTracker at stelary.com> added the comment:

tested Python 2.4.4 on WinXP SP3. It required minor modifications of the
code (removing conditional expressions), but the effect stayed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Sun Aug  3 22:00:09 2008
From: report at bugs.python.org (vadim suvorov)
Date: Sun, 03 Aug 2008 20:00:09 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217793609.17.0.438511551321.issue3497@psf.upfronthosting.co.za>


Changes by vadim suvorov <zzPythonTracker at stelary.com>:


----------
versions: +Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Sun Aug  3 22:06:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 03 Aug 2008 20:06:08 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217793968.23.0.263882887606.issue3497@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Sun Aug  3 23:50:59 2008
From: report at bugs.python.org (Tim Peters)
Date: Sun, 03 Aug 2008 21:50:59 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217800259.3.0.792333538468.issue3497@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

I doubt this is a bug in Python.  It's more likely an error (one or more
;-)) in the logic of the script, triggered by the inherently
unpredictable order of set iteration.

Some evidence:  I added a `.counter` member to the Sequence class, and
changed Sequence.__init__ like so:

counter = 0
...
    global counter
...
    self.counter = counter
    counter += 1

This gives a way to identify the order in which Sequence objects are
created.  Then I replaced:

      seq = self.dirty.pop()

with:

      seq = min((s.counter, s) for s in self.dirty)[1]
      self.dirty.remove(seq)

This forces removal of the earliest-created Sequence object (instead of
an unpredictable one).

After those changes, the script runs the same way every time, regardless
of whether `print 1` or `print "1"` is used, etc.

Then change `min` to `max` above, deterministically forcing removal of
the most recently created Sequence object instead, and again the script
runs the same way every time, but with different output:

AssertionError: an attempt to re-paint cell:(2, 8)

This all strongly suggests that the algorithm itself is supremely
sensitive to the order in which Sequence objects are removed from the
self.dirty set.  And that can indeed change across runs depending on all
sorts of seemingly irrelevant details (unless, as above, the order is
forced in some way).

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Mon Aug  4 00:13:44 2008
From: report at bugs.python.org (vadim suvorov)
Date: Sun, 03 Aug 2008 22:13:44 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217801624.62.0.450200626635.issue3497@psf.upfronthosting.co.za>


vadim suvorov <zzPythonTracker at stelary.com> added the comment:

Thank you very much, Tim. 

I am still very much confused, how change in print statement changes
order in which items are removed from a set. I presumed it to be
undefined but deterministic (similar to dict()): while I cannot tell
which order it is going to be, I can be sure it does not depend on
changes in other objects. For example, it does not depend on things like
if something is printed, or some dummy method called.

I have little doubts that the script contains (or might contain) bugs. I
am now trying to use 3.0b2, which shows deterministic (in the sense
above) behaviour.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Mon Aug  4 00:17:13 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 03 Aug 2008 22:17:13 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217801833.73.0.199944977887.issue3497@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Just run it a couple of times and you will hit the problem in both
"failing" and "running" examples you added.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Mon Aug  4 00:18:50 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 03 Aug 2008 22:18:50 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217801624.62.0.450200626635.issue3497@psf.upfronthosting.co.za>
Message-ID: <48962EC7.7070506@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I am still very much confused, how change in print statement changes
> order in which items are removed from a set. I presumed it to be
> undefined but deterministic (similar to dict()): while I cannot tell
> which order it is going to be, I can be sure it does not depend on
> changes in other objects.

It will certainly depend on other objects, like dict(). Order of objects
in a set or dict depends on the hash values. The hash values depend on
the addresses of the objects in main memory, unless __hash__ is
overridden. In many modern operating systems, the main memory addresses
change with each program start (a feature called address space
randomization). Changing a string literal to an int will mean that a
different object is created, or that objects get created in a different
order, and thus have different addresses.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Mon Aug  4 00:39:37 2008
From: report at bugs.python.org (vadim suvorov)
Date: Sun, 03 Aug 2008 22:39:37 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217803177.19.0.709469204122.issue3497@psf.upfronthosting.co.za>


vadim suvorov <zzPythonTracker at stelary.com> added the comment:

Tim, Martin, thank you very much.

I think now it is not an issue, and the record can be closed.

Thank you very much again, and please accept my apology.

2 Guilherme Polo: I ran it many times. The results in WinXP (with
constant script) are very consistent.

2 Martin v. L?wis: Thank you very much for the excellent explanation. It
was exactly what I needed. I did not realize that hash depends on memory
location.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Mon Aug  4 00:40:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Aug 2008 22:40:20 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217803220.02.0.318188290555.issue3497@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think we have enough evidence now to close this bug as invalid. :)

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Mon Aug  4 00:42:38 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 03 Aug 2008 22:42:38 +0000
Subject: [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1217803358.43.0.622104042444.issue2744@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Not anymore! :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2744>
_______________________________________

From report at bugs.python.org  Mon Aug  4 01:37:14 2008
From: report at bugs.python.org (Tim Peters)
Date: Sun, 03 Aug 2008 23:37:14 +0000
Subject: [issue3497] a bug in the interpreter?
In-Reply-To: <1217792156.96.0.844275585646.issue3497@psf.upfronthosting.co.za>
Message-ID: <1217806634.9.0.240044732206.issue3497@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Vadim, to see how memory addresses change, simply add something like

    print "id", id(self)

to Sequence.__init__.  On Windows (Vista, Python 2.5.1), I see different
addresses printed each time the program is run.  Then, as Martin said,
the default implementation of __hash__ for a type uses the object's
memory address, and that's both unpredictable across runs and influenced
within a run by just about everything the script does (indeed, adding
the `print` statement above may well change the addresses of Sequence
objects created after the print executes!).

What is deterministic:  within a single program run, if you iterate over
a given set multiple times, the set elements will be delivered in the
same order each time, provided you don't mutate the set for the duration.

More than that isn't guaranteed.  For example, if you have two sets x
and y, it's not even the case that x == y implies list(x) == list(y). 
For example,

>>> x = set(range(-10, 11))
>>> y = set(reversed(range(-10, 11)))
>>> x == y
True
>>> list(x) == list(y)
False

If I were you, I'd change the script to use lists instead of sets here
until the algorithm is debugged.  Then you'll get wholly deterministic
behavior, which will make debugging easier.  You can make it run faster
later ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3497>
_______________________________________

From report at bugs.python.org  Mon Aug  4 02:13:46 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 04 Aug 2008 00:13:46 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1217808826.82.0.930822674291.issue3492@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Could you submit unified diff--i.e., with 'diff -u' or 'svn diff'?

Also, could you add tests for this fix?

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Mon Aug  4 02:16:17 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 00:16:17 +0000
Subject: [issue1857] subprocess.Popen.poll/__del__ API breakage
In-Reply-To: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za>
Message-ID: <1217808977.1.0.210714136926.issue1857@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Fixed in trunk r65459.  release25-maint r65460.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1857>
_______________________________________

From report at bugs.python.org  Mon Aug  4 02:17:13 2008
From: report at bugs.python.org (mvngu)
Date: Mon, 04 Aug 2008 00:17:13 +0000
Subject: [issue3463] make life.py use more rendering characters
In-Reply-To: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za>
Message-ID: <1217809033.04.0.316618758589.issue3463@psf.upfronthosting.co.za>


mvngu <nguyenminh2 at gmail.com> added the comment:

Thank you Terry. I highly appreciate your comments.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3463>
_______________________________________

From report at bugs.python.org  Mon Aug  4 02:21:51 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 00:21:51 +0000
Subject: [issue3120] subprocess module truncates handles on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1217809311.25.0.814769085618.issue3120@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in release25-maint r65461.  already merged into py3k from trunk.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3120>
_______________________________________

From report at bugs.python.org  Mon Aug  4 02:48:02 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 00:48:02 +0000
Subject: [issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X
In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za>
Message-ID: <1217810882.28.0.806242989034.issue1471@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

committed to release25-maint as r65466.  if testing on 64bit openbsd or
similar reveals that this is not fixed, please reopen the bug.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471>
_______________________________________

From report at bugs.python.org  Mon Aug  4 03:04:49 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 01:04:49 +0000
Subject: [issue1606] Doc: subprocess wait() may lead to dead lock
In-Reply-To: <1197511478.48.0.254025525321.issue1606@psf.upfronthosting.co.za>
Message-ID: <1217811889.5.0.317034793682.issue1606@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

See the documentation update in trunk r65469.  It adds warnings about
both common pipe related pitfalls discussed in this bug.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606>
_______________________________________

From report at bugs.python.org  Mon Aug  4 03:44:02 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Aug 2008 01:44:02 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217814242.99.0.391413510715.issue3228@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Committed to trunk in rev. 65472, along with two corresponding tests.

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Mon Aug  4 03:44:47 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 04 Aug 2008 01:44:47 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1217814287.71.0.338735560474.issue3385@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I got a preliminary patch that adds the dispatch dictionary. However,
the patch leaks and it doesn't expose the save_reduce() method (which is
needed by ForkingPickler).

----------
keywords: +patch
Added file: http://bugs.python.org/file11048/add_dispatch_check-0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Mon Aug  4 03:57:08 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Aug 2008 01:57:08 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217815028.53.0.263536722655.issue3228@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

There's another use of os.open in the module in the MH class's
__setitem__ that doesn't provide a mode, but I think this occurrence is
harmless; it's truncating a file that always exists, so the existing
mode is preserved.  Here's the little test I tried:

#!./python.exe

import os
os.umask(0077)

from mailbox import MH

m = MH('/tmp/foobar')

m.add('123') ; m.add('456')

m[1] = 'abc' ; m[2] = 'def'

m.close()

The files /tmp/foobar/{1,2} both end up with 0600 permissions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Mon Aug  4 04:05:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 04 Aug 2008 02:05:55 +0000
Subject: [issue2222] Memory leak in os.rename?
In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za>
Message-ID: <1217815555.13.0.719043733904.issue2222@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2222>
_______________________________________

From report at bugs.python.org  Mon Aug  4 05:16:24 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 03:16:24 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1217819784.67.0.810035120305.issue3210@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I tried closing -all- of the handles listed here (the std ones used as
input to _get_handles and the pipe read/write ones returned) on an
OSError during CreateProcess but the problem still occurs for me using
the test code in msg68787.

        (p2cread, p2cwrite,
         c2pread, c2pwrite,
         errread, errwrite) = self._get_handles(stdin, stdout, stderr)

someone with more windows willingness/knowledge/fu should take this one on.

----------
assignee: gregory.p.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Mon Aug  4 05:24:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 03:24:00 +0000
Subject: [issue2113] Bad interaction between signal and subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1217820240.18.0.818608138116.issue2113@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in release25-maint r65475.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
_______________________________________

From report at bugs.python.org  Mon Aug  4 05:56:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 03:56:00 +0000
Subject: [issue2277] MozillaCookieJar does not support Firefox3 cookie files
In-Reply-To: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za>
Message-ID: <1217822160.77.0.803913164557.issue2277@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks.  I've looked over your code.  The logic looks good, however I'd
like to propose a better design and that this not be included in 2.6.

Instead of putting this functionality in the MozCookieJar class, it
should be its own new Firefox3CookieJar class as it is an entirely new
file format.

A much better implementation could be made that actually works with the
sqlite3 file as a database rather than taking ownership of it and
deleting all cookies and rewriting the entire file on save:

The FileCookieJar.delayload flag could now be honored.

The save() method should only do the necessary update/insert/delete
commands rather than rewriting everything.

Its a bit late to get this into Python 2.6/3.0 as the final beta is due
out next week.  But thats fine.  People who need to manipulate ff3
cookie files can use sqlite directly and when a nicer FileCookieJar for
them has been written we can consider including it in python 2.7/3.1. 
Until then it can be an external just like the the one for IE currently is.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2277>
_______________________________________

From report at bugs.python.org  Mon Aug  4 06:01:23 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Aug 2008 04:01:23 +0000
Subject: [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217822483.95.0.724774474054.issue3487@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

+1  I'd like to see this make it in.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________

From report at bugs.python.org  Mon Aug  4 06:04:14 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 04 Aug 2008 04:04:14 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1217822654.63.0.819265094451.issue3492@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Uploading svn diff for zlibmodule.c. Btw, how do I add unit tests for a
fix ? You want me to create a simple test file and upload it here, or is
there a standard procedure for this ? Please advise.

Added file: http://bugs.python.org/file11049/zlibmodule_svn_diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Mon Aug  4 06:10:17 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 04 Aug 2008 04:10:17 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217823017.71.0.183794481813.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Uploading the svn diff.

Added file: http://bugs.python.org/file11050/gzip_svn_diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Mon Aug  4 06:24:59 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 04 Aug 2008 04:24:59 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1217823899.34.0.191133627008.issue3492@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Ok. I added two tests for checking the type of the returned object for
zlib.compress and zlib.decompress in test_zlib.py in the py3k branch. 

Btw, my code uses assertEqual(type(...), bytes). Is this the proper way
of type checking in py3k ? I could not see any formal type for "bytes"
type in the types module. 

Attaching the svn diff for test_zlib.py .

Added file: http://bugs.python.org/file11051/test_zlib_svn_diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Mon Aug  4 06:30:05 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 04 Aug 2008 04:30:05 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1217824201.68.0.682612880029.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Added test case in test_gzip.py. Attaching svn diff of the same.

Added file: http://bugs.python.org/file11052/test_gzip_svn_diff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Mon Aug  4 09:35:37 2008
From: report at bugs.python.org (tav)
Date: Mon, 04 Aug 2008 07:35:37 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1217835337.0.0.738711844597.issue1745@psf.upfronthosting.co.za>


tav <tav at espians.com> added the comment:

What's holding back the backport to 2.6?

----------
nosy: +tav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Mon Aug  4 10:03:29 2008
From: report at bugs.python.org (=?utf-8?q?Niels_Gust=C3=A4bel?=)
Date: Mon, 04 Aug 2008 08:03:29 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217837009.04.0.548805635517.issue3228@psf.upfronthosting.co.za>


Niels Gust?bel <niels at gustaebel.de> added the comment:

I agree regarding the os.open call in MH.__setitem__. It does not
include the O_CREAT flag, so the mode would never be used.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Mon Aug  4 11:18:19 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 04 Aug 2008 09:18:19 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1217841499.88.0.521143232144.issue1432@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Yes, I agree with you, Roman. 

I have made changes to urlparse.urljoin which would behave confirming to
RFC3986. The join of BASE ("http://a/b/c/d;p?q") with REL("?y") would
result in "http://a/b/c/d;p?y" as expected.

I have added a set of testcases for conformance with RFC3986 as well.

Facundo: would you like to review this patch and commit it?

Thanks!

----------
keywords: +patch
nosy: +facundobatista
versions: +Python 3.0
Added file: http://bugs.python.org/file11053/issue1432-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Mon Aug  4 11:19:00 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 04 Aug 2008 09:19:00 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1217841540.89.0.747701690034.issue1432@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Patch for py3k

Added file: http://bugs.python.org/file11054/issue1432-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Mon Aug  4 11:19:07 2008
From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=)
Date: Mon, 04 Aug 2008 09:19:07 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217274175.27.0.163167367727.issue3455@psf.upfronthosting.co.za>
Message-ID: <83794ac50808040219s1aaf3c3dofcafa2c42a183c52@mail.gmail.com>


??? <zkfarmer at gmail.com> added the comment:

I can't understand you. Could you explain more?

2008/7/29 Georg Brandl <report at bugs.python.org>

>
> Georg Brandl <georg at python.org> added the comment:
>
> Can a file be "in use" other than being opened? If not, wouldn't be
> "opened" be a better wording?
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3455>
> _______________________________________
>

Added file: http://bugs.python.org/file11055/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080804/05e4bb87/attachment.txt>

From report at bugs.python.org  Mon Aug  4 11:19:08 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 04 Aug 2008 09:19:08 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1217841548.9.0.257821777788.issue1432@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file9035/urlparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Mon Aug  4 11:35:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Aug 2008 09:35:24 +0000
Subject: [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217842524.28.0.415071598071.issue3487@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Shouldn't there be any unit tests? :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________

From report at bugs.python.org  Mon Aug  4 11:46:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Aug 2008 09:46:48 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1217843208.6.0.905821659942.issue3297@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> critical
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Mon Aug  4 12:01:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Aug 2008 10:01:44 +0000
Subject: [issue3455] os.remove()method document error
In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za>
Message-ID: <1217844104.51.0.823337713798.issue3455@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, you seemed to be misled by the wording "in use". Therefore, I
propose to change "in use" to "opened", but only if "in use" always
means "opened".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3455>
_______________________________________

From report at bugs.python.org  Mon Aug  4 14:13:17 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Aug 2008 12:13:17 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1217851997.65.0.00305646517598.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Attaching a documentation patch for the moment until I get some info
back from Georg as to why I can't build the docs locally.

Once I get my local doc build working again, I'll check the formatting
and check it in.

----------
assignee:  -> ncoghlan
Added file: http://bugs.python.org/file11056/special_method_lookup_docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Aug  4 14:14:02 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Aug 2008 12:14:02 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1217852042.5.0.217292097031.issue643841@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
components: +Documentation -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Aug  4 14:26:38 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 04 Aug 2008 12:26:38 +0000
Subject: [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217852798.13.0.450918663033.issue3487@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Guido, this is fine for 3.0 and 2.6.  As Terry points out, it's not user
visible and it improves reliability.  I'm -0 on backporting it to 2.5,
but don't really feel strongly about that.

Go for it!

----------
assignee: barry -> gvanrossum
priority: release blocker -> high
resolution:  -> accepted
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________

From report at bugs.python.org  Mon Aug  4 14:42:38 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Aug 2008 12:42:38 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1217853758.43.0.0864783440054.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed for 2.6 as r65487.

I also blocked the automatic merge to 3.0 since the references to
old-style classes don't make sense there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Aug  4 14:47:18 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 04 Aug 2008 12:47:18 +0000
Subject: [issue3498] mod_cls
In-Reply-To: <1217854037.97.0.189815073445.issue3498@psf.upfronthosting.co.za>
Message-ID: <1217854037.97.0.189815073445.issue3498@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <okkotonushi at googlemail.com>:

Using sphinx I get the following error if I want to document methods via
automethod:

reading sources... copyright glossary [..] refbrowser Exception
occurred: File
  "[..]/doctools/sphinx/ext/autodoc.py", line 313, in resolve_name
    if not mod_cls:
UnboundLocalError: local variable 'mod_cls' referenced before
assignment. [..]

I am not familiar with the code base, but from the comments the attached
patch should address the issue.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: mod_cls.patch
keywords: patch
messages: 70697
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: mod_cls
type: behavior
Added file: http://bugs.python.org/file11057/mod_cls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3498>
_______________________________________

From report at bugs.python.org  Mon Aug  4 14:54:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Aug 2008 12:54:55 +0000
Subject: [issue3498] mod_cls
In-Reply-To: <1217854037.97.0.189815073445.issue3498@psf.upfronthosting.co.za>
Message-ID: <1217854495.9.0.509162657809.issue3498@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65489.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3498>
_______________________________________

From report at bugs.python.org  Mon Aug  4 14:55:26 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Aug 2008 12:55:26 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1217854526.16.0.232082776719.issue643841@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

But don't the docs with patch describe the behavior of new-style classes
better?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Aug  4 15:29:01 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Aug 2008 13:29:01 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1217856541.27.0.574792076489.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I meant to say that I will be merging it manually to avoid bringing the
old-style class specific parts over (that's why I left the issue open
and assigned to me).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Aug  4 16:23:00 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Aug 2008 14:23:00 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1217859780.77.0.404302939356.issue643841@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ah, I'm sorry for the noise then.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Mon Aug  4 17:51:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 15:51:57 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217865117.4.0.953123905443.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's also the recursive division algorithm due
to Burnikel and Ziegler;  this might be worth a look.
I think it's the same asymptotic complexity (constant
times karatsuba multiplication complexity), but may
turn out to be faster for one reason or another.

I had a Python implementation of this somewhere;
I'll see if I can dig it out.

Assigning this to me so that it doesn't get lost or
forgotten;  but note that I don't intend to do
anything about it before 2.6/3.0 final.  If anyone else
wants to take it off my hands before then, feel free.

----------
assignee:  -> marketdickinson
priority:  -> normal
type:  -> performance
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Aug  4 17:57:55 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 15:57:55 +0000
Subject: [issue1746088] long.__str__ is quadratic time
Message-ID: <1217865475.26.0.564582130675.issue1746088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this as a duplicate; it's superseded by issue 3451.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Asymptotically faster divmod and str(long)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746088>
_______________________________________

From report at bugs.python.org  Mon Aug  4 17:58:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 15:58:07 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217865487.13.0.960172839894.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 1746088.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Aug  4 18:06:05 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 04 Aug 2008 16:06:05 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1217865965.21.0.57452792509.issue3358@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Here is a patch that tries to use the faster recursive matching, but if
there is a RuntimeError, it will use the iterative matching. It passes
all the tests and works on the ssl.py file that were known to break the
recursive matching.

Added file: http://bugs.python.org/file11058/iterative_recursive.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Mon Aug  4 18:36:17 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Aug 2008 16:36:17 +0000
Subject: [issue3499] Python 2.6 requires pre-installed Python to build
In-Reply-To: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>
Message-ID: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

Here's the "make -d" output:

         Prerequisite `Parser/Python.asdl' is older than target
`Include/Python-ast.h'.
         Prerequisite `Parser/asdl.py' is older than target
`Include/Python-ast.h'.
         Prerequisite `Parser/asdl_c.py' is newer than target
`Include/Python-ast.h'.
        Must remake target `Include/Python-ast.h'.
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
/usr/bin/env: No such file or directory

And these are the file times:

orig/Python-2.6b2> ls -l Include/Python-ast.h
-rw-r--r-- 1 lemburg users 20081 2008-03-30 08:40 Include/Python-ast.h
orig/Python-2.6b2> ls -l Parser/asdl*
-rw-r--r-- 1 lemburg users 11306 2006-03-01 23:49 Parser/asdl.py
-rwxr-xr-x 1 lemburg users 39771 2008-06-09 06:58 Parser/asdl_c.py

Because Python-ast.h is older than the script used for generating it
(asdl_c.py), it always tries to rebuild the .h file. Since this requires
Python to be installed, it fails on a machine that doesn't always have
an existing Python binary installed.

This happens in both 2.6b1 and 2.6b2.

I guess the release process should make sure that the Python-ast.h and
Python-ast.c are always newer than the scripts used to build them.

----------
components: Build
messages: 70706
nosy: lemburg
priority: critical
severity: normal
status: open
title: Python 2.6 requires pre-installed Python to build
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3499>
_______________________________________

From report at bugs.python.org  Mon Aug  4 18:37:40 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Aug 2008 16:37:40 +0000
Subject: [issue3499] Python 2.6 requires pre-installed Python to build
In-Reply-To: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>
Message-ID: <1217867860.88.0.177092406333.issue3499@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

As work-around, you can untar the source tarball and then touch the
files in question:

touch Include/Python-ast.h
touch Python/Python-ast.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3499>
_______________________________________

From report at bugs.python.org  Mon Aug  4 20:07:53 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Aug 2008 18:07:53 +0000
Subject: [issue3463] make life.py use more rendering characters
In-Reply-To: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za>
Message-ID: <1217873273.32.0.694705198152.issue3463@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I agree with tjreedy that this change is not very interesting for a demo
program.  It would be more interesting to add larger features such as
different cellular automata, mouse or colour support, or something like
that.

Thanks for your patch, anyway.

----------
nosy: +akuchling
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3463>
_______________________________________

From report at bugs.python.org  Mon Aug  4 20:10:37 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Aug 2008 18:10:37 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1217873437.38.0.810345097842.issue2305@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
_______________________________________

From report at bugs.python.org  Mon Aug  4 20:11:42 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Aug 2008 18:11:42 +0000
Subject: [issue836088] Update htmllib to HTML 4.01
Message-ID: <1217873502.27.0.37390845629.issue836088@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Closing -- I'm not going to work on this patch further, and it seems
irrelevant.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue836088>
_______________________________________

From report at bugs.python.org  Mon Aug  4 20:26:27 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Aug 2008 18:26:27 +0000
Subject: [issue2396] Backport memoryview object to Python 2.6
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1217874387.31.0.972704856942.issue2396@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Is there still time to do the backport for 2.6 at this late date?

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Mon Aug  4 20:30:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Aug 2008 18:30:16 +0000
Subject: [issue2396] Backport memoryview object to Python 2.6
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1217874616.79.0.50126173633.issue2396@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not only there may not be enough time, but:
1. the memoryview implementation itself is not finished (that is, in py3k)
2. polishing and documenting the buffer API is more important
3. there doesn't seem to be any use for memoryview objects right now

So, IMO, this can be re-targeted to 2.7.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Mon Aug  4 20:32:39 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 04 Aug 2008 18:32:39 +0000
Subject: [issue2470] Need fixer for dl (removed) -> ctypes module
In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
Message-ID: <1217874759.98.0.747017889619.issue2470@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

If nobody else is interested in or currently in the process of making a
fixer for this, I can do it. I'm not sure if I completely understand the
changes I need to make though. Importing dl needs to be replaced by
importing ctypes, calls to dl.open() need to be replaced by calls to
ctypes.CDLL(), and calls to call() from an open dl object need to be
replaced to calls to funcname, where funcname is the first argument to
call(). Also, any strings in the other arguments should be preceded with
b to make them byte objects. Is this all that needs doing or am I
missing something else? Are there more complicated cases that I should
also take into account?

----------
nosy: +nedds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2470>
_______________________________________

From report at bugs.python.org  Mon Aug  4 20:40:19 2008
From: report at bugs.python.org (Collin Winter)
Date: Mon, 04 Aug 2008 18:40:19 +0000
Subject: [issue2470] Need fixer for dl (removed) -> ctypes module
In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
Message-ID: <1217875219.09.0.994139387659.issue2470@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

I'd prefer it if someone better-versed in ctypes/dl wrote this fixer (or
at the very least, someone with access to Windows to test the translation).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2470>
_______________________________________

From report at bugs.python.org  Mon Aug  4 21:13:34 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 04 Aug 2008 19:13:34 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

If a method is inherited by two different classes, then the unbound
method objects which can be retrieved from those classes compare equal
to each other.  For example:

  Python 2.6b2+ (trunk:65502M, Aug  4 2008, 15:05:07)
  [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> class X:
  ...     def y(self):
  ...             pass
  ...
  >>> class A(X):
  ...     pass
  ...
  >>> class B(X):
  ...     pass
  ...
  >>> A.y == B.y
  True

This is bad behavior because A.y and B.y are otherwise distinguishable
(for example, they repr differently, they have different values for the
`im_class? attribute, they cannot be used interchangably for invoking
the method because they place different type restrictions on the `self?
parameter, etc).

----------
components: Interpreter Core
messages: 70714
nosy: exarkun
severity: normal
status: open
title: unbound methods of different classes compare equal
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Mon Aug  4 21:25:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Aug 2008 19:25:16 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217877916.16.0.541456049458.issue3500@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, I'm not sure. One could also argue that 1 and 1.0 mustn't compare
equal because they cannot be used equally in all circumstances (e.g.
__index__), they have different repr's, different types, etc.

The question is: what kind of use case does it help to have them compare
unequal? I can see the utility of having them compare equal: to check
whether a method has been overriden or not.

(I'm removing 2.4 and 2.5 anyway since the change would break compatibility)

----------
nosy: +pitrou
versions: +Python 3.0 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Mon Aug  4 21:37:27 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 04 Aug 2008 19:37:27 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217878648.0.0.626907047575.issue3500@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

The reason I noticed this is that since they compare and hash equal, if
you put two such methods into a set, you end up with a set with one
method.  Currently, this is preventing me from running two test methods
because the method itself is defined on a base class and two subclasses
which customize several other methods inherit it.  I can only run one
test at a time.

Having them compare unequal means you can't actually trust unbound
method comparison, nor using unbound methods as keys in a dictionary. 
This means some other mapping structure is required if you want to keep
around a bunch of methods and arguments to pass to them.  It also means
that any time you want to check two methods against each other with the
goal of eventually calling one or both of them, you need to use
something other than `==?.  It seems like calling methods is likely to
be a more common use-case than anything else.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Mon Aug  4 22:07:51 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Aug 2008 20:07:51 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217878648.0.0.626907047575.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217880462.5773.26.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The reason I noticed this is that since they compare and hash equal, if
> you put two such methods into a set, you end up with a set with one
> method.  Currently, this is preventing me from running two test methods
> because the method itself is defined on a base class and two subclasses
> which customize several other methods inherit it.  I can only run one
> test at a time.

But you acknowledge they are really the same method attached to
different classes, right? The notion of "unbound method" is mostly an
implementation detail. The term occurs only 4 times in the whole Python
documentation (according to Google). And in py3k they are gone. (*)

Moreover, you say you want them to compare unequal because you
*explicitly* want the same method called separately for each class it is
defined on. Is there anything preventing you to have a set of (class,
method) tuples instead? Because it sounds like the logical thing to do
in your case.

> Having them compare unequal means you can't actually trust unbound
> method comparison, nor using unbound methods as keys in a dictionary.

"Trust" is a strong word. You can trust the comparison operator if you
agree with its semantics, you cannot trust it if you want different
semantics. But that doesn't mean it is generally trustworthy or
untrustworthy.

Really, this is the same as with numbers:

'b'

There are probably use cases where the above is annoying. But,
conversely, there are probably use cases where a stricter behaviour
would be annoying too.

> This means some other mapping structure is required if you want to keep
> around a bunch of methods and arguments to pass to them.

I disagree. The general use case of keeping a bunch of callables with
their respective arguments implies storing bound, not unbound, methods.
(how often do you feed an unbound method to an addCallback() ?)

> It also means
> that any time you want to check two methods against each other with the
> goal of eventually calling one or both of them, you need to use
> something other than `==?.

I don't think there are lots of use cases for comparing *unbound*
methods. One such use case is checking for redefinition of inherited
methods, and the current __eq__ semantics look fine for that.

(*)
Python 3.0b2+ (py3k, Jul 29 2008, 20:37:34) 
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...  def f(): pass
... 
>>> type(A.f)
<class 'function'>
>>> a = A()
>>> type(a.f)
<class 'method'>
>>> def g(): pass
... 
>>> class B:
...  g = g
... 
>>> B.g is g
True

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Mon Aug  4 22:10:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Aug 2008 20:10:47 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217880647.61.0.251562419245.issue3500@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently Roundup snipped my numbers example :-)
Here it is, hoping it will pass through this time :

>>> d = {}
>>> d[1] = 'a'
>>> d[1.0] = 'b'
>>> d[1]
'b'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Mon Aug  4 22:38:24 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 20:38:24 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217882304.13.0.925742767644.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a pure Python implementation of the Burnikel and Ziegler recursive 
division algorithm.  I've no idea whether it's faster or slower than 
Newton, but it might be worth a look.  It depends heavily on bit 
operations, which ought to be much faster when coded in C.  (Some of the 
shifts would be completely unnecessary---replaced by changes in indexing 
instead.)

The original paper describing the algorithm is available here:

http://cr.yp.to/bib/1998/burnikel.ps

Added file: http://bugs.python.org/file11059/fast_str.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Aug  4 22:39:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 20:39:00 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217882340.28.0.759366792063.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Oops.  Wrong file.  Here's the right one.

Added file: http://bugs.python.org/file11060/fast_div.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Aug  4 22:39:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 20:39:07 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1217882347.11.0.924422546982.issue3451@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file11059/fast_str.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Aug  4 23:32:24 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 21:32:24 +0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1217885544.9.0.362593903006.issue1481296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

New patch committed, r65518.  Conversion of a nan to an integer now raises 
ValueError consistently across platforms.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_______________________________________

From report at bugs.python.org  Mon Aug  4 23:39:33 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 04 Aug 2008 21:39:33 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1217885973.79.0.40655661125.issue2211@psf.upfronthosting.co.za>


Changes by Toshio Kuratomi <a.badger at gmail.com>:


----------
nosy: +a.badger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Tue Aug  5 00:20:47 2008
From: report at bugs.python.org (Mike Speciner)
Date: Mon, 04 Aug 2008 22:20:47 +0000
Subject: [issue3501] expm1 missing
In-Reply-To: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za>
Message-ID: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za>


New submission from Mike Speciner <speciner_michael at emc.com>:

The math module contains log1p but is missing expm1 (the inverse of
log1p). These functions are necessary to avoid loss of precision in
floating point calculations, and are part of the C99 standard math library.

----------
components: None
messages: 70722
nosy: ms
severity: normal
status: open
title: expm1 missing
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3501>
_______________________________________

From report at bugs.python.org  Tue Aug  5 00:44:58 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 22:44:58 +0000
Subject: [issue3501] expm1 missing
In-Reply-To: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za>
Message-ID: <1217889898.57.0.767056225891.issue3501@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Mike,

Can you propose an implementation, for those platforms that haven't yet 
caught up with C99?  Something comparable to the implementation of log1p 
in Python/pymath.c would be appropriate.  Ideally, such an 
implementation would:

- be accurate to within a few ulps across the whole domain,
- be not too long, and not too slow
- have a decent chance of working with strange floating-point formats 
(Python doesn't assume IEEE 754)
- handle IEEE 754 values 'correctly' (i.e., as recommended by Annex F to 
the C99 standard)

It's too late to get this into Python 2.6/3.0, but patches aimed at 2.7 
or 3.1 would be welcome.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3501>
_______________________________________

From report at bugs.python.org  Tue Aug  5 01:07:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Aug 2008 23:07:07 +0000
Subject: [issue3501] expm1 missing
In-Reply-To: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za>
Message-ID: <1217891227.2.0.198065157565.issue3501@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A cheap trick would be to use the identity

  expm1(x) = 2*exp(x/2)*sinh(x/2)

This could also be used in Python as a
workaround, for now.  But I agree that
expm1 should go into the math library.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3501>
_______________________________________

From report at bugs.python.org  Tue Aug  5 02:33:54 2008
From: report at bugs.python.org (Ramon Garcia)
Date: Tue, 05 Aug 2008 00:33:54 +0000
Subject: [issue3502] Inconsistency between string.letters and default encoding.
In-Reply-To: <1217896433.93.0.654864556475.issue3502@psf.upfronthosting.co.za>
Message-ID: <1217896433.93.0.654864556475.issue3502@psf.upfronthosting.co.za>


New submission from Ramon Garcia <ramong at cnmv.es>:

In python on Windows, under Idle, the string.letters includes extended
characters. But the default codec, used when translating from string to
unicode, is still ascii. This behaviour causes crashes with python win32
extensions.

>>> string.letters

'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\x83\x8a\x8c\x8e\x9a\x9c\x9e\x9f\xaa\xb5\xba\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'

But still, unless the user customizes the installation,
sys.getdefaultencoding() returns ascii.

The consequence is that after instating a COM object, pywin32 211 issues
this exception:

  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
297, in MakeFuncMethod
    return self.MakeDispatchFuncMethod(entry, name, bMakeClass)
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
318, in MakeDispatchFuncMethod
    s = linePrefix + 'def ' + name + '(self' + BuildCallList(fdesc,
names, defNamedOptArg, defNamedNotOptArg, defUnnamedArg, defOutArg) + '):'
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
604, in BuildCallList
    argName = MakePublicAttributeName(argName)
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in MakePublicAttributeName
    return filter( lambda char: char in valid_identifier_chars, className)
  File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in <lambda>
    return filter( lambda char: char in valid_identifier_chars, className)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 52:
ordinal not in range(128)



The line that causes this exception is from win32com.client.build.

This fragment is enough to reproduce the bug (from build.py in
win32com/client):

valid_identifier_chars = string.letters + string.digits + "_"
...
return filter( lambda char: char in valid_identifier_chars, className)

Try to print the expression in the return statement and set className to
anything you wish in Unicode. It will crash

It is contradictory that the default codec does not allow translation of
characters  0x83, and that string.letters includes it. If one regards
this character as printable, then it should be encoded successfully.

----------
components: Windows
messages: 70725
nosy: ramong
severity: normal
status: open
title: Inconsistency between string.letters and default encoding.
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3502>
_______________________________________

From report at bugs.python.org  Tue Aug  5 03:07:34 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 05 Aug 2008 01:07:34 +0000
Subject: [issue3228] mailbox.mbox creates files with execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1217898454.19.0.369694531316.issue3228@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I took one test and an idea from Niels' patch -- checking for the
existence of 
os.stat as well as os.umask -- and applied it as rev. 65536.  

Closing this issue now.  Thanks, everyone!

----------
assignee:  -> akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3228>
_______________________________________

From report at bugs.python.org  Tue Aug  5 03:51:04 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Tue, 05 Aug 2008 01:51:04 +0000
Subject: [issue3503] Calls to print() function in Python 3.0 tutorial
In-Reply-To: <1217901064.2.0.318710120877.issue3503@psf.upfronthosting.co.za>
Message-ID: <1217901064.2.0.318710120877.issue3503@psf.upfronthosting.co.za>


New submission from Jim Sizelove <jimsize at gmail.com>:

I decided to learn more about the coming changes in Python 3.0 by
installing the beta and working through the tutorial.  I found some
discrepancies between the code examples and the output I got.  The
attached patch shows several places where the print() function is called
incorrectly.  These are mostly examples that are missing the parentheses.

The rest of this comment pertains to only one change included in the
patch that I find less than satisfactory.  In introduction.html, there
is an example of printing a fibonacci sequence in one line of output by
using the end keyword.  When actually run in the python interpreter, the
>>> prompt shows at the end of the same line as the fibonacci numbers. 
The patch fixes this by enclosing a "print()" within an else clause.

This "fix" produces the expected output, but I don't think the else
clause has been described yet in the tutorial.  A better fix would be to
wrap the while statement in a function with a print() function call
after the end of the while statement (this is how the fib() function is
defined in http://docs.python.org/dev/3.0/tutorial/modules.html).  But
functions have not been explained this early in the tutorial.

Perhaps it would be best to drop this example of using the end keyword
to the print function in the introduction and explain it later in the
tutorial.

----------
assignee: georg.brandl
components: Documentation
files: print.diff
keywords: patch
messages: 70727
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Calls to print() function in Python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11061/print.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3503>
_______________________________________

From report at bugs.python.org  Tue Aug  5 03:57:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 05 Aug 2008 01:57:45 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1217901465.46.0.59696892301.issue3367@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

This patch was applied in rev. 65539, but then reverted; it turns out to 
break Lib/test/test_parser.py.  The exception is:

    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 222, in test_position
    terminals)
AssertionError: [(1, 'def', 1, 0), (1, 'f', 1, 4), (7, '(', 1, 5), (1,
'x', 1, 6), (8, ')', 1, 7), (11, ':', 1, 8), (4, '', 1, 9), (5, '', 2,
-1), (1, 'return', 2, 4), (1, 'x', 2, 11), (14, '+', 2, 13), (2, '1', 2,
15), (4, '', 2, 16), (6, '', 2, -1), (4, '', 2, -1), (0, '', 2, -1)] != 
[(1, 'def', 1, 0), (1, 'f', 1, 7033504), (7, '(', 1, 7033505), (1, 'x',
1, 7033506), (8, ')', 1, 7033507), (11, ':', 1, 7033508), (4, '', 1,
7033509), (5, '', 2, -1), (1, 'return', 2, 7033514), (1, 'x', 2,
7033521), (14, '+', 2, 7033523), (2, '1', 2, 7033525), (4, '', 2,
7033526), (6, '', 2, 0), (4, '', 2, 0), (0, '', 2, 0)]

In the resulting output, the columns are incorrect large values
(7033504, 7033505) or they're 0 where -1 is expected.

I took a look into why this happened, but made no progress.  Removing
the 'easy' keyword.  :)

----------
keywords:  -easy
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Tue Aug  5 05:40:37 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 03:40:37 +0000
Subject: [issue3487] sre "bytecode" verifier
In-Reply-To: <1217613212.91.0.751968430358.issue3487@psf.upfronthosting.co.za>
Message-ID: <1217907637.58.0.265665490062.issue3487@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Submitted to 2.6 as r65544.

Will propagate to 3.0 as it gets merged -- should be a perfect merge.

Antoine: the re module has tons of unittests; showing that attempts to
break in are thwarted would be pretty boring. ;-)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3487>
_______________________________________

From report at bugs.python.org  Tue Aug  5 07:12:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 05 Aug 2008 05:12:48 +0000
Subject: [issue3502] Inconsistency between string.letters and default encoding.
In-Reply-To: <1217896433.93.0.654864556475.issue3502@psf.upfronthosting.co.za>
Message-ID: <1217913168.34.0.224292837191.issue3502@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That's a bug in the Win32 extensions. They shouldn't use string.letters,
but string.ascii_letters, in particular when they check for valid
identifier chars.

Closing this report as "won't fix".

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3502>
_______________________________________

From report at bugs.python.org  Tue Aug  5 11:05:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Aug 2008 09:05:20 +0000
Subject: [issue3503] Calls to print() function in Python 3.0 tutorial
In-Reply-To: <1217901064.2.0.318710120877.issue3503@psf.upfronthosting.co.za>
Message-ID: <1217927120.9.0.193100200318.issue3503@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the patch! Committed in r65545.

For the fibonacci example, I just left out the final print(). For
simplicity's case, it's fine for the example to have the minor flaw of
not printing a final newline -- it is there to show the end keyword,
after all.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3503>
_______________________________________

From report at bugs.python.org  Tue Aug  5 11:38:40 2008
From: report at bugs.python.org (paul stoop)
Date: Tue, 05 Aug 2008 09:38:40 +0000
Subject: [issue3504] Python Reference Manual inconsistency (Notation)
In-Reply-To: <1217929120.44.0.382303757014.issue3504@psf.upfronthosting.co.za>
Message-ID: <1217929120.44.0.382303757014.issue3504@psf.upfronthosting.co.za>


New submission from paul stoop <paul.stoop.nl at gmail.com>:

On page http://docs.python.org/ref/notation.html the following text:
    name  	::=  	lc_letter
    lc_letter 	::= 	"a"..."z"
The first line says that a name is an lc_letter followed by a sequence
of zero or more lc_letters and underscores
...

should read (imho) 
    name  	::=  	lc_letter(_|lc_letter)*
...

----------
assignee: georg.brandl
components: Documentation
messages: 70732
nosy: georg.brandl, pavlosto
severity: normal
status: open
title: Python Reference Manual inconsistency (Notation)
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3504>
_______________________________________

From report at bugs.python.org  Tue Aug  5 12:08:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Aug 2008 10:08:12 +0000
Subject: [issue3477] grammar productionlist are not properly indented
In-Reply-To: <1217504275.9.0.818427276788.issue3477@psf.upfronthosting.co.za>
Message-ID: <1217930892.04.0.686482387919.issue3477@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65547.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3477>
_______________________________________

From report at bugs.python.org  Tue Aug  5 12:10:00 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Aug 2008 10:10:00 +0000
Subject: [issue3504] Python Reference Manual inconsistency (Notation)
In-Reply-To: <1217929120.44.0.382303757014.issue3504@psf.upfronthosting.co.za>
Message-ID: <1217931000.77.0.506498126192.issue3504@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already fixed in the development docs:
http://docs.python.org/dev/reference/introduction.html#id2

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3504>
_______________________________________

From report at bugs.python.org  Tue Aug  5 14:42:57 2008
From: report at bugs.python.org (paul stoop)
Date: Tue, 05 Aug 2008 12:42:57 +0000
Subject: [issue3505] single/double quote error in Python v2.6b2 documentation
In-Reply-To: <1217940177.03.0.531342969311.issue3505@psf.upfronthosting.co.za>
Message-ID: <1217940177.03.0.531342969311.issue3505@psf.upfronthosting.co.za>


New submission from paul stoop <paul.stoop.nl at gmail.com>:

hi,

On http://docs.python.org/ref/strings.html we find
longstring ::= "'''" longstringitem* "'''" | '"""' longstringitem* '"""'
(correct),

but,

on http://docs.python.org/dev/reference/lexical_analysis.html#id7
we find:
                v                    v
longstring ::= ""'" longstringitem* ""'" | '"""' longstringitem* '"""'
                ^                    ^
(not correct, i think(?)).

----------
assignee: georg.brandl
components: Documentation
messages: 70735
nosy: georg.brandl, pavlosto
severity: normal
status: open
title: single/double quote error in Python v2.6b2 documentation
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3505>
_______________________________________

From report at bugs.python.org  Tue Aug  5 15:21:25 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 05 Aug 2008 13:21:25 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217942485.97.0.805495772408.issue3500@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> But you acknowledge they are really the same method attached to
> different classes, right? The notion of "unbound method" is mostly an
> implementation detail. The term occurs only 4 times in the whole Python
> documentation (according to Google). And in py3k they are gone. (*)

It's the same function attached to two different classes.  I don't
really buy the "implementation detail" argument - if Guido says it,
then I don't have much choice but to accept it, but I'm going to
argue about it with anyone else. :)  In this case, I'd say it's
definitely not an implementation detail because it has major
consequences visible to applications.  If I get method x from
class A and try to call it with an instance of class B, then
it's going to break.  I have to know about this behavior in order
to write a program that works.  Py3k may be different, but I'm
not going to talk about Py3k here because I'm only interested
in the Python 2.x behavior.

> Moreover, you say you want them to compare unequal because you
> *explicitly* want the same method called separately for each class it is
> defined on. Is there anything preventing you to have a set of (class,
> method) tuples instead? Because it sounds like the logical thing to do
> in your case.

I could do that.  I probably will, too, since this code needs to work
on Python 2.3 through Python 2.5.  I still want to make Python 2.6
better, though.  It seems to me that an unbound method is already
effectively a tuple of (class, function) - it has a reference to both
of those.  Requiring applications to tie it up with a class again is
just redundant.

> "Trust" is a strong word. You can trust the comparison operator if you
> agree with its semantics, you cannot trust it if you want different
> semantics. But that doesn't mean it is generally trustworthy or
> untrustworthy.

You're right.  "trust" was a bad word to use there.

> I don't think there are lots of use cases for comparing *unbound*
> methods. One such use case is checking for redefinition of inherited
> methods, and the current __eq__ semantics look fine for that.

This use-case is already satisfied though - if an application wants
to see if the function is the same, then the application can compare
the im_func attribute of the method objects.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Tue Aug  5 16:10:26 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Aug 2008 14:10:26 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217942485.97.0.805495772408.issue3500@psf.upfronthosting.co.za>
Message-ID: <1217944920.48985d58f0c93@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

> It's the same function attached to two different classes.  I don't
> really buy the "implementation detail" argument - if Guido says it,
> then I don't have much choice but to accept it, but I'm going to
> argue about it with anyone else. :)

I understand that :-)

> Py3k may be different, but I'm
> not going to talk about Py3k here because I'm only interested
> in the Python 2.x behavior.

Granted, but Python 2.6 (and subsequent 2.x versions) strives to make it easier
to port code to 3.x by gradually reducing compatibility issues. Your proposal to
change unbound method __eq__ behaviour would, on the contrary, add another
incompatibility between 3.x and 2.x.

> This use-case is already satisfied though - if an application wants
> to see if the function is the same, then the application can compare
> the im_func attribute of the method objects.

But your use case is already satisfied as well - you just have to use the
(class, method) tuple for comparison. In other words, both use cases can be
satisfied by circumventing, if needed, the default __eq__ behaviour. If there's
no overwhelming reason to change the current default, keeping 2.x and 3.0
compatibility should prevail.

Regards

Antoine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Tue Aug  5 16:15:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Aug 2008 14:15:29 +0000
Subject: [issue2396] Backport memoryview object to Python 2.6
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1217945729.98.0.303333410682.issue2396@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I concur.

----------
nosy: +benjamin.peterson
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Tue Aug  5 16:21:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Aug 2008 14:21:47 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1217835337.0.0.738711844597.issue1745@psf.upfronthosting.co.za>
Message-ID: <1afaf6160808050718k23c5d221md8d960ccc6e1fdc3@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Mon, Aug 4, 2008 at 1:35 AM, tav <report at bugs.python.org> wrote:
>
> tav <tav at espians.com> added the comment:
>
> What's holding back the backport to 2.6?

The fact that we are working towards the 3rd and final beta.
>
> ----------
> nosy: +tav
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1745>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Tue Aug  5 16:30:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Aug 2008 14:30:35 +0000
Subject: [issue3499] Python 2.6 requires pre-installed Python to build
In-Reply-To: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>
Message-ID: <1217946635.98.0.0625572550832.issue3499@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It should be simple to modify release.py to touch these files. Barry,
I'm on vacation now, but I should be able to do this before you spin the
releases.

----------
assignee:  -> benjamin.peterson
nosy: +barry, benjamin.peterson
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3499>
_______________________________________

From report at bugs.python.org  Tue Aug  5 16:30:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Aug 2008 14:30:41 +0000
Subject: [issue2396] Backport memoryview object to Python 2.6
In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za>
Message-ID: <1217946641.41.0.560477917525.issue2396@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not a release blocker then :-)

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2396>
_______________________________________

From report at bugs.python.org  Tue Aug  5 17:46:21 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 15:46:21 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1217951181.13.0.688281621088.issue2305@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

How's this coming along?

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
_______________________________________

From report at bugs.python.org  Tue Aug  5 17:49:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 15:49:20 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1217951360.2.0.369033283398.issue2389@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Agreed, this has been broken for a long time, and few people have
noticed or complained.  Let's wait.

----------
assignee: gvanrossum -> 
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:00:42 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:00:42 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1217952042.61.0.397698112099.issue1179@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The two segfaults reported in msg64682 are still there in 2.6.
I'm elevating this to release blocker but don't have time to fix this
myself.

----------
assignee: gvanrossum -> 
priority: critical -> release blocker
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1179>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:01:01 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:01:01 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1217952061.99.0.361474800261.issue1717@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Can someone other than me test and apply this?  It seems still relevant,
and __cmp__ is not coming back.

----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:02:48 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:02:48 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1217952168.05.0.971588945625.issue1518@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Won't have time myself.

----------
assignee: gvanrossum -> 
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:03:44 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:03:44 +0000
Subject: [issue1616] compiler warnings
In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za>
Message-ID: <1217952224.95.0.383129531234.issue1616@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Let someone else review this.

----------
assignee: gvanrossum -> 
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1616>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:07:58 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:07:58 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1217952478.61.0.199370422501.issue2235@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

How's this going?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:09:33 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:09:33 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1217952573.37.0.834942693004.issue3262@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think it's better to leave this alone.  Such a subtle change is likely
to trip over more people in worse ways than the alleged "bug".

----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:10:30 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:10:30 +0000
Subject: [issue1503] test_xmlrpc is still flakey
In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za>
Message-ID: <1217952630.55.0.278361927568.issue1503@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Without a patch this will not improve.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1503>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:14:49 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 16:14:49 +0000
Subject: [issue616013] cPickle documentation incomplete
Message-ID: <1217952889.62.0.299996880216.issue616013@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

2.6 should keep the original cPickle, warts and all, for backwards
compatibility.  I'd be okay though with also having _pickle there --
just don't call in cPickle (and don't import it from pickle.py either).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue616013>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:19:46 2008
From: report at bugs.python.org (Mike Coleman)
Date: Tue, 05 Aug 2008 16:19:46 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1217953186.82.0.349451466415.issue3262@psf.upfronthosting.co.za>


Mike Coleman <mkc at users.sourceforge.net> added the comment:

Okay.  For what it's worth, note that my original 2004 patch for this
(#988761) is completely backward compatible (a flag must be set in the
call to get the new behavior).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Tue Aug  5 18:32:52 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 05 Aug 2008 16:32:52 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1217953972.09.0.798581687089.issue2305@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

It's in good shape.  There are a few items in my saved-email folder that
need to be added, and a few XXX markers here and there, but I've done
the large stuff, like writing a section on the multiprocessing module.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
_______________________________________

From report at bugs.python.org  Tue Aug  5 20:44:53 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 18:44:53 +0000
Subject: [issue1985] Bug/Patch: Problem with xml/__init__.py when using
	freeze.py
In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
Message-ID: <1217961893.23.0.227446593222.issue1985@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Nobody seems to care enough.

----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1985>
_______________________________________

From report at bugs.python.org  Tue Aug  5 20:48:11 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Aug 2008 18:48:11 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Right now in 2.6, using buffer() warns that it is going away and to use
memoryview(). Unfortunately memoryview() won't be backported to 2.6 in
time for release.

That means the warning is covering something that is within 2to3's
realm. So the warning should be changed to more align with any specific
difference between buffer() and memoryview() (or bring buffer() back to
3.0).

----------
components: Interpreter Core
messages: 70755
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Change buffer/memoryview DeprecationWarning
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:28:57 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 19:28:57 +0000
Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file
In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za>
Message-ID: <1217964537.29.0.353791397561.issue2310@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Let's see if we can fix this by beta3.

----------
assignee: gvanrossum -> 
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2310>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:30:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 19:30:16 +0000
Subject: [issue2590] S_unpack_from() Read Access Violation
In-Reply-To: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>
Message-ID: <1217964616.2.0.712088643923.issue2590@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Ping? Patch?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2590>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:30:46 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 19:30:46 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1217964646.75.0.805377085564.issue1309567@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Is this still relevant?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309567>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:34:57 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 05 Aug 2008 19:34:57 +0000
Subject: [issue1503] test_xmlrpc is still flakey
In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za>
Message-ID: <1217964897.91.0.659294228746.issue1503@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I would say without a decision on what to do, there will be no patch :)

I can write a patch, which unconditionally turns on blocking mode for
sockets returned from accept (on unix-platforms). Would that be fine?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1503>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:35:31 2008
From: report at bugs.python.org (jqxvjqxv)
Date: Tue, 05 Aug 2008 19:35:31 +0000
Subject: [issue3507] spelling in try.html
In-Reply-To: <1217964931.67.0.287440079483.issue3507@psf.upfronthosting.co.za>
Message-ID: <1217964931.67.0.287440079483.issue3507@psf.upfronthosting.co.za>


New submission from jqxvjqxv <jqxv at mailinator.com>:

http://docs.python.org/ref/try.html
Please replace "propogate" with correct spelling "propagate".

----------
assignee: georg.brandl
components: Documentation
messages: 70760
nosy: georg.brandl, jqxvjqxv
severity: normal
status: open
title: spelling in try.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3507>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:39:46 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 19:39:46 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1217965186.1.0.173362838072.issue2305@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Great!  The same cannot be said of the 3.0 version, which is on my plate.

I wonder if you have an opinion on what to do with features that were
initially targeted for 3.0 and then backported to 2.6.  Should these
appear in "what's new in 2.6", in "what's new in 3.0", or in both?  I'm
thinking that perhaps these should appear in both, for the benefit of
folks planning to jump straight into 3.0 from 2.5.  After all, 2.6 and
3.0 are coming out at the same time.  Or should be just add these to 2.6
and add a generic clause to the 3.0 document saying "also see the 2.6
document"?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:41:18 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 19:41:18 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1217965278.53.0.655381868317.issue3506@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Definitely don't bring buffer() back in 3.0!  It needs to die.

If 2to3 can do this reasonably well, let's do that.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:50:26 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 05 Aug 2008 19:50:26 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1217965826.03.0.439295715507.issue2305@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I agree; we don't want to require people to read the 2.6 document, and
then the 3.0 document to get a complete picture.  

Besides, the organization of the 2.x documents may not be suitable for
the 3.0 document.  The 2.x documents are organized by PEP, then a
section for miscellaneous language changes, then a section for library
changes.  For 3.0, you probably want to do all language changes in one
section, ignoring how they were broken up into PEPs, then a section on 
the library reorganization, and then maybe sections on using 2to3 
or porting C extensions.

It's certainly OK with me to copy text from the 2.6 document into the
3.0 one, if some of the text is useful.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:52:01 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 05 Aug 2008 19:52:01 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1217965921.52.0.173156743894.issue2305@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Oh, and it might be more realistic to keep the 3.0 document as a set of
notes, and aim to have a more finished document in 3.1.  ISTM it'll be
hard to finish writing it in time for a planned 3.0 release, even if you
spent your 20% work-time on the task.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
_______________________________________

From report at bugs.python.org  Tue Aug  5 21:57:57 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Aug 2008 19:57:57 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1217966277.43.0.950215765684.issue2305@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks for the feedback, I'll do that.  I have 50% time instead of 20%,
though it doesn't feel that way lately. ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2305>
_______________________________________

From report at bugs.python.org  Tue Aug  5 22:10:30 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Tue, 05 Aug 2008 20:10:30 +0000
Subject: [issue1309567] linecache module returns wrong results
Message-ID: <1217967030.46.0.558157622627.issue1309567@psf.upfronthosting.co.za>


Hans Ulrich Niedermann <hun at n-dimensional.de> added the comment:

Unless someone has fixed it since 2008-07-05, it is still relevant.

I'll have to take a look at the current code first, though, to confirm
in either way.

There has been some discussion on this issue over at
http://bugs.python.org/issue1754483 but no complete resolution either.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309567>
_______________________________________

From report at bugs.python.org  Wed Aug  6 00:28:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 05 Aug 2008 22:28:45 +0000
Subject: [issue3026] integer overflow in hashlib causes wrong results for
	cryptographic hash functions [was: mmap broken with large files
	on 64bit system]
In-Reply-To: <1212373498.52.0.766248013838.issue3026@psf.upfronthosting.co.za>
Message-ID: <1217975325.96.0.802521577079.issue3026@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
title: mmap broken with large files on 64bit system -> integer overflow in hashlib causes wrong results for cryptographic hash functions [was: mmap broken with large files on 64bit system]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3026>
_______________________________________

From report at bugs.python.org  Wed Aug  6 00:32:26 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 05 Aug 2008 22:32:26 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1217975546.33.0.625788464058.issue3173@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Wed Aug  6 00:52:43 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Aug 2008 22:52:43 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217965278.53.0.655381868317.issue3506@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808051552k91a5c09lb06d0281189a24bd@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Tue, Aug 5, 2008 at 12:41 PM, Guido van Rossum
<report at bugs.python.org> wrote:
>
> Guido van Rossum <guido at python.org> added the comment:
>
> Definitely don't bring buffer() back in 3.0!  It needs to die.
>
> If 2to3 can do this reasonably well, let's do that.
>

There is already a fixer to go from buffer() to memoryview(), but I
don't know how compatible the APIs are. That might still require a
warning.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 02:56:44 2008
From: report at bugs.python.org (Viktor Ferenczi)
Date: Wed, 06 Aug 2008 00:56:44 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1217984204.29.0.519648945293.issue3160@psf.upfronthosting.co.za>


Viktor Ferenczi <python at cx.hu> added the comment:

Note: It is already fixed and should go into the next beta. Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Wed Aug  6 06:25:33 2008
From: report at bugs.python.org (Diego)
Date: Wed, 06 Aug 2008 04:25:33 +0000
Subject: [issue3508] range() is not a generator when used in for's
In-Reply-To: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
Message-ID: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>


New submission from Diego <jacobidiego at gmail.com>:

Hi.

I am a debian lenny user so i am still using python 2.5 so i dont know 
how is this "bug" working on newer pythons. Please close it if you find 
that it doesnt exists.

It may not be a bug but.

I have maked an script to optimice minterms sums (This is electronics 
stuff to reduce the number of logic devices in an electronic design).
The algorithm depends exponentially on the number of bits in the input 
and the output. So to test it i have to generate 2**N_input_bits 
strings in a list. Each string being of N_input_bits+N_output_bits long.

The problem starts when N_input_bits is too much long. (from 25 and up)
The function range(2**N_input_bits) instantiates a list with all thoose 
numbers.

I have maked a test script to check it out:

import time

N=32

try:
  range(2**N)
  # range(): allocates N's integer's items in a list
except Exception, error:
  print "ERROR: ",error, "   Items=",N
  print

time.sleep(10)

def RANGE(a):
  # GENERATOR: Creates one output eachtime it is called.
  i=0
  while i<a:
    yield i
    i=i+1
  return

try:
  for x in RANGE(2**N):
    if not x%100:
      print x
except Exception, error:
  print "ERROR: ",error, "   Items=",N
  print
      

If i am not mistaken, "RANGE" will only take up one integer of memory 
each time instead of a complete list with "range()".
So it is better to use RANGE (a generator) with for's when i do not 
need to edit the list.
I think that range is mostly used in for's, so it will be a big improve 
to make the line:

for ... in range(....):

as a generator behavior and the normal range use:

alist = range(50)

as the same list.

This for line is very common in many programs and the content of the 
list can not be edited inside the for, it is only used by the for.
So, it can speed up python a little without requiring any changes.


Please if you consider this i not a bug or suggestion, or what ever, 
just close/delete/ignore the post. :)

Cheers.
Diego.

----------
messages: 70769
nosy: epsilon_da
severity: normal
status: open
title: range() is not a generator when used in for's
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________

From report at bugs.python.org  Wed Aug  6 07:51:08 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Aug 2008 05:51:08 +0000
Subject: [issue3508] range() is not a generator when used in for's
In-Reply-To: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
Message-ID: <1218001868.63.0.373645917099.issue3508@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In Python 2.x range() always return a list.
In Python 3.x it will return an iterator.

Other functions will be changed to return an iterator too (see
http://www.python.org/dev/peps/pep-3100/#built-in-namespace).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________

From report at bugs.python.org  Wed Aug  6 07:59:44 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 06 Aug 2008 05:59:44 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218002384.67.0.585194589097.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Here's my version of how quote and unquote should be implemented in
Python 3.0.  I haven't looked at the uses of it in the library, but I'd
expect improper uses (and there are lots of them) will break, and thus
can be fixed.

Basically, percent-quoting is about creating an ASCII string that can be
safely used in URI from an arbitrary sequence of octets.  So, my version
of quote() takes either a byte sequence or a string, and percent-quotes
the unsafe ones, and then returns a str.  If a str is supplied on input,
it is first converted to UTF-8, then the octets of that encoding are
percent-quoted.

For unquote, there's no way to tell what the octets of the quoted
sequence may mean, so this takes the percent-quoted ASCII string, and
returns a byte sequence with the unquoted bytes.  For convenience, since
the unquoted bytes are often a string in some particular character set
encoding, I've also supplied unquote_as_string(), which takes an
optional character set, and first unquotes the bytes, then converts them
to a str, using that character set encoding, and returns the resulting
string.

----------
nosy: +janssen
Added file: http://bugs.python.org/file11062/myunquote.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug  6 09:26:37 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Aug 2008 07:26:37 +0000
Subject: [issue3508] range() is not a generator when used in for's
In-Reply-To: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
Message-ID: <1218007597.4.0.782591179118.issue3508@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The behavior of range is very unlikely to be changed in Python 2.x, for 
backwards compatibility reasons.

But it's a great idea!  So great, in fact, that it's already been 
implemented for Python 3.0.  :-)  There range() behaves like a generator 
(in all contexts);  if you really want a list, you'd write:

list(range(2**20))

Thanks!

----------
nosy: +marketdickinson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________

From report at bugs.python.org  Wed Aug  6 09:28:09 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Aug 2008 07:28:09 +0000
Subject: [issue3508] range() is not a generator when used in for's
In-Reply-To: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
Message-ID: <1218007689.31.0.992954932579.issue3508@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

By the way, do you already know about xrange?

xrange([start,] stop[, step]) -> xrange object

Like range(), but instead of returning a list, returns an object that
generates the numbers in the range on demand.  For looping, this is 
slightly faster than range() and more memory efficient.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________

From report at bugs.python.org  Wed Aug  6 09:29:15 2008
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Wed, 06 Aug 2008 07:29:15 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218007755.25.0.757481775255.issue2389@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

I guess it went unnoticed due to prevalence of little-endian 32-bit
machines.  With 64-bit architectures becoming more and more popular,
this might become a bigger issue.

Raymond, why do you think fixing this bug would complicate porting to
2.6/3.0?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Wed Aug  6 10:26:26 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Wed, 06 Aug 2008 08:26:26 +0000
Subject: [issue3509] La Lutte, Je Vais Vous Montrer Mon Piquer!
In-Reply-To: <01c8f7a6$7cc55c80$30c53a52@birick.mathieu>
Message-ID: <01c8f7a6$7cc55c80$30c53a52@birick.mathieu>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

Soyez heureux avec votre taille et de rendre votre partenaire heureux et satisfait.

Alors que VPXL elargissement chirurgie est couteux et parfois dangereux, pilules pourrait facilement etre oublie de prendre et d'autres produits sont le plus souvent que Travailler pour l'OMS, le VPXL est sur et facile a utiliser.}

Commander VPXL et bienvenue dans le monde de heureux et confiant hommes.

http://surekeep.com

----------
files: unnamed
messages: 70775
nosy: MrJean1
severity: normal
status: open
title: La Lutte, Je Vais Vous Montrer Mon Piquer!
Added file: http://bugs.python.org/file11063/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3509>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080806/d5f10bb3/attachment.txt>

From report at bugs.python.org  Wed Aug  6 10:51:51 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Wed, 06 Aug 2008 08:51:51 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1218012711.97.0.148487148556.issue3451@psf.upfronthosting.co.za>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

Indeed, that seems to be much faster. In the mean time, do you mind if I
steal the code? :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Wed Aug  6 11:00:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Aug 2008 09:00:29 +0000
Subject: [issue3509] La Lutte, Je Vais Vous Montrer Mon Piquer!
In-Reply-To: <01c8f7a6$7cc55c80$30c53a52@birick.mathieu>
Message-ID: <1218013229.68.0.170391445786.issue3509@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3509>
_______________________________________

From report at bugs.python.org  Wed Aug  6 11:44:27 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Aug 2008 09:44:27 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1218015867.26.0.644895016692.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The documentation and Py3k warning will be ready for the third beta next
week (the remaining part is a lot easier than the initial fix).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Wed Aug  6 11:49:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Aug 2008 09:49:14 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1218016154.09.0.343185498764.issue3506@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The memoryview implementation is still unfinished (in py3k), so I
suggest we drop the warning or comment it out.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 12:16:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Aug 2008 10:16:30 +0000
Subject: [issue1685] linecache .updatecache fails on utf8 encoded files
In-Reply-To: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za>
Message-ID: <1218017790.31.0.805132189472.issue1685@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After a look at the patch and at linecache.py, some comments:
- 'rbU' is strange, the 'U' flag has no effect for binary files, so it
should just be 'rb' instead
- I'm surprised we don't have a test_linecache.py in Lib/test
- The following lines at the end of updatecache() deserve a cleanup:

    try:
        lines = [line if isinstance(line, str) else str(line, coding)
                 for line in lines]
    except:
        pass  # Hope for the best

- The very shallow "except Exception as msg" should also be restricted
to (IOError, OSError) IMHO.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685>
_______________________________________

From report at bugs.python.org  Wed Aug  6 12:29:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Aug 2008 10:29:21 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1218018561.48.0.954920722503.issue2834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If nobody (except Amaury :-)) has anything to say about the current
patch, should it be committed?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Wed Aug  6 13:17:24 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Wed, 06 Aug 2008 11:17:24 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1218021444.15.0.949041317116.issue3492@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Any updates ? The py3k list is also very silent since the week-end...Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Wed Aug  6 15:24:12 2008
From: report at bugs.python.org (Diego)
Date: Wed, 06 Aug 2008 13:24:12 +0000
Subject: [issue3508] range() is not a generator when used in for's
In-Reply-To: <1218007689.31.0.992954932579.issue3508@psf.upfronthosting.co.za>
Message-ID: <5de034af0808060624l6a5f568fq35bcf6a5912fb611@mail.gmail.com>


Diego <jacobidiego at gmail.com> added the comment:

2008/8/6 Mark Dickinson <report at bugs.python.org>:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> By the way, do you already know about xrange?
>
> xrange([start,] stop[, step]) -> xrange object
>
> Like range(), but instead of returning a list, returns an object that
> generates the numbers in the range on demand.  For looping, this is
> slightly faster than range() and more memory efficient.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3508>
> _______________________________________
>

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

4294967296L

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: range() result has too many items

Sadly so high numbers are longs and xrange seems to get an integer.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________

From report at bugs.python.org  Wed Aug  6 15:26:01 2008
From: report at bugs.python.org (Diego)
Date: Wed, 06 Aug 2008 13:26:01 +0000
Subject: [issue3508] range() is not a generator when used in for's
In-Reply-To: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
Message-ID: <1218029161.93.0.585430048437.issue3508@psf.upfronthosting.co.za>


Diego <jacobidiego at gmail.com> added the comment:

>>> a = xrange(2**32)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

>>> 2**32
4294967296L

>>> a=range(2**32)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
OverflowError: range() result has too many items



Sadly so high numbers are longs and xrange seems to get an integer.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________

From report at bugs.python.org  Wed Aug  6 15:37:19 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 06 Aug 2008 13:37:19 +0000
Subject: [issue1985] Bug/Patch: Problem with xml/__init__.py when using
	freeze.py
In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
Message-ID: <1218029839.98.0.319762225736.issue1985@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1985>
_______________________________________

From report at bugs.python.org  Wed Aug  6 15:55:10 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 06 Aug 2008 13:55:10 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1218030910.82.0.650017131804.issue1432@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Senthil: We should ask for advice in the web-sig list to see if this is
enough a "bug to be fixed" now that we're in beta for the releases.

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Wed Aug  6 17:06:06 2008
From: report at bugs.python.org (P. Roebuck)
Date: Wed, 06 Aug 2008 15:06:06 +0000
Subject: [issue3510] Site-specific configuration hook documentation incorrect
In-Reply-To: <1218035166.89.0.646760261694.issue3510@psf.upfronthosting.co.za>
Message-ID: <1218035166.89.0.646760261694.issue3510@psf.upfronthosting.co.za>


New submission from P. Roebuck <plroebuck at mdanderson.org>:

Documentation does not match due to version number inconsistency.

Current:
< Then the following directories are added to sys.path, in this order:
<
<
< /usr/local/lib/python2.3/site-packages/bar
< /usr/local/lib/python2.3/site-packages/foo

Proposed:
> Then the following directories are added to sys.path, in this order:
>
>
> /usr/local/lib/python{X.Y}/site-packages/bar
> /usr/local/lib/python{X.Y}/site-packages/foo

Syntax for proposed documentation fix may be incorrect, but this gives 
the general idea anyway...

<http://svn.python.org/view/python/trunk/Doc/library/site.rst?
rev=62788&view=markup>

----------
assignee: georg.brandl
components: Documentation
messages: 70785
nosy: georg.brandl, proebuck
severity: normal
status: open
title: Site-specific configuration hook documentation incorrect
versions: Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3510>
_______________________________________

From report at bugs.python.org  Wed Aug  6 17:07:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Aug 2008 15:07:47 +0000
Subject: [issue3508] range() is not a generator when used in for's
In-Reply-To: <1217996732.69.0.453344669108.issue3508@psf.upfronthosting.co.za>
Message-ID: <1218035267.37.0.557984746253.issue3508@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Sadly so high numbers are longs and xrange seems to get an integer.

Something like that, yes:  the start, step and length of an xrange object 
are stored internally as C longs (just as Python ints are), and this is 
unlikely to change.

There's been quite a lot of recent discussion about the future of range 
and xrange:  see issue 2690, for example.

Maybe itertools.count would provide part of what you want?  Alternatively, 
if you've got a 64-bit machine you could try using a 64-bit build of 
Python---on platforms where a long is 64 bits, the limits should be 2**63 
instead of 2**31.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3508>
_______________________________________

From report at bugs.python.org  Wed Aug  6 18:34:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 06 Aug 2008 16:34:34 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1218040474.04.0.392054962635.issue2834@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Let's make sure the release manager is OK with this.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Wed Aug  6 18:49:39 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 06 Aug 2008 16:49:39 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218041379.23.0.22834335072.issue3300@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file11062/myunquote.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug  6 18:51:28 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 06 Aug 2008 16:51:28 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218041488.17.0.871891228926.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Here's a patch to parse.py (and test/test_urllib.py) that makes the
various tests (cgi, urllib, httplib) pass.  It basically adds
"unquote_as_string", "unquote_as_bytes", "quote_as_string",
"quote_as_bytes", and then define the existing "quote" and "unquote" in
terms of them.

Added file: http://bugs.python.org/file11064/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug  6 19:01:17 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Aug 2008 17:01:17 +0000
Subject: [issue3507] spelling in try.html
In-Reply-To: <1217964931.67.0.287440079483.issue3507@psf.upfronthosting.co.za>
Message-ID: <1218042077.72.0.953923113263.issue3507@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, this is already fixed in SVN.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3507>
_______________________________________

From report at bugs.python.org  Wed Aug  6 19:20:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Aug 2008 17:20:57 +0000
Subject: [issue3505] single/double quote error in Python v2.6b2 documentation
In-Reply-To: <1217940177.03.0.531342969311.issue3505@psf.upfronthosting.co.za>
Message-ID: <1218043257.18.0.757534520463.issue3505@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65558.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3505>
_______________________________________

From report at bugs.python.org  Wed Aug  6 19:29:33 2008
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 06 Aug 2008 17:29:33 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218043773.57.0.113447501207.issue3300@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

Is there still disagreement over anything except:

(1)  The type signature of quote and unquote (as opposed to the 
explicit "quote_as_bytes" or "quote_as string").

(2)  The default encoding (latin-1 vs UTF8), and (if UTF-8) what to do 
with invalid byte sequences?

(3)  Would waiting for 3.1 cause too many compatibility problems?

----------
nosy: +jimjjewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug  6 19:36:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 06 Aug 2008 17:36:37 +0000
Subject: [issue3509] La Lutte, Je Vais Vous Montrer Mon Piquer!
In-Reply-To: <01c8f7a6$7cc55c80$30c53a52@birick.mathieu>
Message-ID: <1218044197.37.0.767122391584.issue3509@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

When classifying stuff as spam, please also check for attachments that
might have been included in the email message, and show up as files -
files and messages are treated separately in the tracker.

----------
nosy: +georg.brandl, loewis -MrJean1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3509>
_______________________________________

From report at bugs.python.org  Wed Aug  6 20:39:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Aug 2008 18:39:43 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218047983.5.0.0177619326626.issue3300@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Bill, I haven't studied your patch in detail but a few comments:
- it would be nice to have more unit tests, especially for the various
bytes/unicode possibilities, and perhaps also roundtripping (Matt's
patch has a lot of tests)
- quote_as_bytes() should return a bytes object, not a bytearray
- using the "%02X" format looks clearer to me than going through the
_hextable lookup table...
- when the argument is of the wrong type, quote_as_bytes() should raise
a TypeError rather than a ValueError
- why is quote_as_string() hardwired to utf8 while unquote_as_string()
provides a charset parameter? wouldn't it be better for them to be
consistent with each other?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug  6 20:41:37 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 06 Aug 2008 18:41:37 +0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1218048097.86.0.906906433098.issue2065@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


Added file: http://bugs.python.org/file11065/ocean-remaining.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:05:53 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 19:05:53 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1218049553.02.0.166376661986.issue3506@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

How unfinished is it, Antoine? So much that it can't be used, or just to
the extent it doesn't take the same arguments as buffer()? If it is the
latter then the warning should be changed to warn about unsupported
arguments.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:08:58 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 19:08:58 +0000
Subject: [issue2885] Create the urllib package
In-Reply-To: <1210914691.08.0.848288242706.issue2885@psf.upfronthosting.co.za>
Message-ID: <1218049738.81.0.830367702809.issue2885@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixers are in, so this is a done deal.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2885>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:20:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 19:20:46 +0000
Subject: [issue2338] Backport reload() moving to imp.reload()
In-Reply-To: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za>
Message-ID: <1218050446.31.0.0779143598383.issue2338@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

A fixer is not going to work for this since it might require an import
to work. Instead reload() just needs to be added as imp.reload() and the
current warning stays.

----------
assignee: collinwinter -> brett.cannon
components: +Extension Modules -2to3 (2.x to 3.0 conversion tool), Interpreter Core
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2338>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:21:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 19:21:59 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1218050519.89.0.665395947074.issue2775@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies:  -Create the urllib package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:32:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Aug 2008 19:32:30 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1218051150.48.0.608980269909.issue3506@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm no buffer API/memoryview expert, but at least slicing is not
implemented, and there are almost no unit tests. It can probably be
used, but given the absence of tests and of actual uses in the stdlib,
I'm not sure we can say it is robust and therefore promote it as
replacement.

Hopefully Travis will be able to enlighten us when he is back.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:33:21 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Wed, 06 Aug 2008 19:33:21 +0000
Subject: [issue3081] Py_(X)SETREF macros
In-Reply-To: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>
Message-ID: <1218051201.94.0.111661134242.issue3081@psf.upfronthosting.co.za>


Paul Pogonyshev <pogonyshev at gmx.net> added the comment:

Just to note, I proposed similar macro on the mailing list under the
name Py_ASSIGN.

----------
nosy: +_doublep

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3081>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:42:15 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 06 Aug 2008 19:42:15 +0000
Subject: [issue3511] Incorrect charset range handling with ignore case flag?
In-Reply-To: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>
Message-ID: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>


New submission from Matthew Barnett <python at mrabarnett.plus.com>:

While working on the regex code in sre_compile.py I came across the
following code in the handling of charset ranges in _optimize_charset:

    for i in range(fixup(av[0]), fixup(av[1])+1):
        charmap[i] = 1

The function fixup converts the ends of the range to lower case if the
ignore-case flag is present. The problem with this approach is
illustrated below:

>>> import re
>>> print re.match(r'[9-A]', 'A')
<_sre.SRE_Match object at 0x00A78058>
>>> print re.match(r'[9-A]', 'a')
None
>>> print re.match(r'[9-A]', '_')
None
>>> print re.match(r'[9-A]', 'A', re.IGNORECASE)
<_sre.SRE_Match object at 0x00D0BFA8>
>>> print re.match(r'[9-A]', 'a', re.IGNORECASE)
<_sre.SRE_Match object at 0x00A78058>
>>> print re.match(r'[9-A]', '_', re.IGNORECASE)
<_sre.SRE_Match object at 0x00D0BFA8>
>>> 

'_' doesn't lie between '9' and 'A', but it does lie between '9' and 'a'.

Surely the ignore-case flag should not affect whether non-letters are
matched or not?

----------
components: Regular Expressions
messages: 70799
nosy: mrabarnett
severity: normal
status: open
title: Incorrect charset range handling with ignore case flag?
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3511>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:48:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Aug 2008 19:48:38 +0000
Subject: [issue3511] Incorrect charset range handling with ignore case flag?
In-Reply-To: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>
Message-ID: <1218052118.9.0.0459321151435.issue3511@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
priority:  -> normal
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3511>
_______________________________________

From report at bugs.python.org  Wed Aug  6 21:51:24 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 06 Aug 2008 19:51:24 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218052284.71.0.494984592787.issue3300@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Bill Janssen's "patch" breaks two unittests: test_email and
test_http_cookiejar.  Details for test_email:

======================================================================
ERROR: test_rfc2231_bad_character_in_filename
(email.test.test_email.TestRFC2231)
.
.
.
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib/parse.py",
line 267, in unquote_as_string
    return str(unquote_as_bytes(s, plus=plus), charset, 'strict')
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe2 in position 13:
unexpected end of data

======================================================================
FAIL: test_rfc2231_bad_character_in_charset
(email.test.test_email.TestRFC2231)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/google/home/guido/python/py3k/Lib/email/test/test_email.py",
line 3279, in test_rfc2231_bad_character_in_charset
    self.assertEqual(msg.get_content_charset(), None)
AssertionError: 'utf-8\\u201d' != None

Details for test_http_cookiejar:

======================================================================
FAIL: test_url_encoding (__main__.LWPCookieTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_http_cookiejar.py", line 1454, in test_url_encoding
    self.assert_("foo=bar" in cookie and version_re.search(cookie))
AssertionError: None

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug  6 22:09:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 20:09:00 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1218051150.48.0.608980269909.issue3506@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808061308k3a30dc35h6bf9f851104b2645@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Aug 6, 2008 at 12:32 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> I'm no buffer API/memoryview expert, but at least slicing is not
> implemented, and there are almost no unit tests. It can probably be
> used, but given the absence of tests and of actual uses in the stdlib,
> I'm not sure we can say it is robust and therefore promote it as
> replacement.
>

Well, if it can't replace buffer() then the warning needs to change to
just flat-out state that buffer() is gone and not suggest any
replacement.

> Hopefully Travis will be able to enlighten us when he is back.
>

Hopefully.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 22:12:37 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 06 Aug 2008 20:12:37 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1218053557.26.0.142168657254.issue3506@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> Well, if it can't replace buffer() then the warning needs to change to
> just flat-out state that buffer() is gone and not suggest any
> replacement.

+1.  buffer() stinks.  memoryview() rules.  They don't hvae the same use
cases.

Is there truly nobody else who understands PEP 3118 well enough?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 22:54:13 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Aug 2008 20:54:13 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218056053.33.0.655069269057.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I believe the conn refused error is another race, the child processes  
> are connecting to a manager which is shutting down/gone

After some research, I think it actually has to do with the value of the 
'backlog' parameter when creating a Listener instance: if there are too 
many queued requests to a socket then further connection requests are 
refused;  the 'backlog' parameter appears to set the maximum size of the 
queue.

...or something like that.  I'm a novice here... :-)

Anyway, in the __init__ method of the Server class, in managers.py, the 
Server creates a Listener instance with the line

        self.listener = Listener(address=address, backlog=5)

When I change backlog to 50 instead of 5, I don't see the connection 
refused error any more.

I'm not suggesting that the backlog value should be changed---it 
probably shouldn't.  But this does at least explain why connections can 
be refused, and why they should be retried in that case.

I do still think that the patch, or something like it, should be 
applied.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Wed Aug  6 23:03:12 2008
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 06 Aug 2008 21:03:12 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218056592.2.0.824884568293.issue3300@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

Matt pointed out that the email package assumes Latin-1 rather than UTF-8; I 
assume Bill could patch his patch the same way Matt did, and this would 
resolve the email tests.  (Unless you pronounce to stick with Latin-1)

The cookiejar failure probably has the same root cause; that test is 
encoding (non-ASCII) Latin-1 characters, and urllib.parse.py/Quoter assumes 
Latin-1.

So I see some evidence (probably not enough) for sticking with Latin-1 
instead of UTF-8.  But I don't see any evidence that fixing the semantics 
(encoded results should be bytes) at the same time made the conversion any 
more painful.  

On the other hand, Matt shows that some of those extra str->byte code 
changes might never need to be done at all, except for purity.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug  6 23:28:54 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 21:28:54 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1218053557.26.0.142168657254.issue3506@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808061428m223526deuadba6529fdbfdd39@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Aug 6, 2008 at 1:12 PM, Guido van Rossum <report at bugs.python.org> wrote:
>
> Guido van Rossum <guido at python.org> added the comment:
>
>> Well, if it can't replace buffer() then the warning needs to change to
>> just flat-out state that buffer() is gone and not suggest any
>> replacement.
>
> +1.  buffer() stinks.  memoryview() rules.  They don't hvae the same use
> cases.
>

That settles that then.

> Is there truly nobody else who understands PEP 3118 well enough?

Not me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 23:29:11 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 21:29:11 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1218058151.64.0.700109252405.issue3506@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Wed Aug  6 23:39:38 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 06 Aug 2008 21:39:38 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <0016369201ed9032030453d168b6@google.com>


Guido van Rossum <guido at python.org> added the comment:

Dear GvR,

New code review comments by GvR have been published.
Please go to http://codereview.appspot.com/2827 to read them.

Message:
Hi Matt,

Here's a code review of your patch.

I'm leaning more and more towards wanting this for 3.0, but I have some API
design issues and also some style nits.

I'm cross-linking this with the Python tracker issue, through the subject.

Details:

http://codereview.appspot.com/2827/diff/1/2
File Doc/library/urllib.parse.rst (right):

http://codereview.appspot.com/2827/diff/1/2#newcode198
Line 198: replaced by a placeholder character.
I don't think that's a good default.  I'd rather see it default to strict --
that's what encoding translates to everywhere else.  I believe that lenient
error handling by default can cause subtle security problems too, by hiding
problem characters from validation code.

http://codereview.appspot.com/2827/diff/1/2#newcode215
Line 215: An alias for :func:`quote`, intended for use with a :class:`bytes`
object
I'd rather see this as a wrapper that raises TypeError if the argument  
isn't a
bytes or bytearray instance.  Otherwise it's needless redundancy.

http://codereview.appspot.com/2827/diff/1/2#newcode223
Line 223: Replace ``%xx`` escapes by their single-character equivalent.
Should add what the argument type is -- I vote for str or bytes/bytearray.

http://codereview.appspot.com/2827/diff/1/2#newcode242
Line 242: .. function:: unquote_to_bytes(string)
Again, add what the argument type is.

http://codereview.appspot.com/2827/diff/1/4
File Lib/email/utils.py (right):

http://codereview.appspot.com/2827/diff/1/4#newcode224
Line 224: except:
An unqualified except clause is unacceptable here.  Why do you need this  
anyway?

http://codereview.appspot.com/2827/diff/1/5
File Lib/test/test_http_cookiejar.py (right):

http://codereview.appspot.com/2827/diff/1/5#newcode1450
Line 1450: "%3c%3c%0Anew%C3%A5/%C3%A5",
I'm guessing this test broke otherwise?  Given that this references an RFC,  
is
it correct to just fix it this way?

http://codereview.appspot.com/2827/diff/1/3
File Lib/urllib/parse.py (right):

http://codereview.appspot.com/2827/diff/1/3#newcode10
Line 10: "urlsplit", "urlunsplit"]
Please add all the quote/unquote versions here too.
(They were there in 2.5, but somehow got dropped from 3.0.

http://codereview.appspot.com/2827/diff/1/3#newcode265
Line 265: # Maps lowercase and uppercase variants (but not mixed case).
That sounds like a disaster.  Why would %aa and %AA be correct but not %aA  
and
%Aa?  (Even though the old code had the same problem.)

http://codereview.appspot.com/2827/diff/1/3#newcode283
Line 283: def unquote(s, encoding = "utf-8", errors = "replace"):
Please no spaces around the '=' when used for an argument default (or for a
keyword arg).

Also see my comment about defaulting to 'replace' in the doc file.

Finally -- let's be consistent about quotes.  It seems most of this file  
uses
single quotes, so lets stick to that (except docstrings always use double
quotes).

And more: what should a None value for encoding or errors mean?  IMO it  
should
mean "use the default".

http://codereview.appspot.com/2827/diff/1/3#newcode382
Line 382: safe = safe.encode('ascii', 'ignore')
Using errors='ignore' seems like a mistake -- it will hide errors.

I also wonder why safe should be limited to ASCII though.

http://codereview.appspot.com/2827/diff/1/3#newcode399
Line 399: if ' ' in s:
This test means that it won't work if the input is bytes.  E.g.

urllib.parse.quote_plus(b"abc def")

raises a TypeError.

Sincerely,

   Your friendly code review daemon (http://codereview.appspot.com/).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 00:25:38 2008
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 06 Aug 2008 22:25:38 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218061538.26.0.630668725783.issue3300@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

> http://codereview.appspot.com/2827/diff/1/5#newcode1450
> Line 1450: "%3c%3c%0Anew%C3%A5/%C3%A5",
> I'm guessing this test broke otherwise?  

Yes; that is one of the breakages you found in Bill's patch.  (He didn't 
modify the test.)

> Given that this references an RFC,
> is it correct to just fix it this way?

Probably.  Looking at http://www.faqs.org/rfcs/rfc2965.html

(1)  That is not among the exact tests in the RFC.
(2)  The RFC does not specify charset for the cookie in general, but the 
Comment field MUST be in UTF-8, and the only other reference I could find to 
a specific charset was "possibly in a server-selected printable ASCII 
encoding."

Whether we have to use Latin-1 (or document charset) in practice for 
compatibility reasons, I don't know.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 00:28:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Aug 2008 22:28:47 +0000
Subject: [issue2338] Backport reload() moving to imp.reload()
In-Reply-To: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za>
Message-ID: <1218061727.43.0.109816578969.issue2338@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Done in r65563.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2338>
_______________________________________

From report at bugs.python.org  Thu Aug  7 03:33:33 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Aug 2008 01:33:33 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218072813.77.0.810340057612.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's what's going on with the incref error:

Look in the Server class, in managers.py:  consider a shared object with 
id 'id'.  When a reference to the shared object is created, its id is 
added to the id_to_refcount dictionary:

{id: None}

and *shortly afterwards*, the refcount is incremented to get:

{id: 1}

When the object is deleted or goes out of scope later on, the refcount 
is decref'd, and id is removed entirely from id_to_refcount.

The problem occurs when there are two processes simultaneously asking 
for access to the same object.  If a second process happens to decref 
'id' in between the first process creating the reference and 
incrementing it, then the incref from the first process will fail.  This 
is exactly what's happening (some of the time) in test_remote in the 
test_suite.  The failing sequence of operations is:

initial state:         id not in id_to_refcount
(process 1): create    id_to_refcount[id] is None
(process 1): incref    id_to_refcount[id] == 1
(process 2): create    id_to_refcount[id] == 1
(process 1): decref    id not in id_to_refcount
(process 2): incref    KeyError!
(process 2): decref    (never get here...)

I'm not really familiar enough with the whole multiprocessing module to 
know what the right fix for this is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Thu Aug  7 06:07:41 2008
From: report at bugs.python.org (Ian Charnas)
Date: Thu, 07 Aug 2008 04:07:41 +0000
Subject: [issue3512] Change fsync to use fullfsync on platforms (like OS X)
	that have/need it
In-Reply-To: <1218082061.12.0.0384174375737.issue3512@psf.upfronthosting.co.za>
Message-ID: <1218082061.12.0.0384174375737.issue3512@psf.upfronthosting.co.za>


New submission from Ian Charnas <ian.charnas at gmail.com>:

fsync on OSX does not actually flush the file to disk as is desired. 
This is a problem because application developers rely on fsync for file
integrity.  SQLite [1] and MySQL [2] and other major database systems
all use 'fullfsync' on OS X instead of fsync, because 'fullfsync'
provides the desired behavior.

Because the documented behavior of python's fsync function is to "force
write of file with filedescriptor to disk", I believe that on OS X the
fullfsync call should be used instead of fsync.

The supplied patch adds this functionality in a non-platform-specific
way.  It checks if there is a FULLFSYNC fcntl call available (using
"#ifdef F_FULLFSYNC", where F_FULLFSYNC is defined in sys/fcntl.h), and
if this symbol is defined then a fnctl(F_FULLFSYNC, fd, 0) is called
instead of fsync.

[1] SQLite uses fullfsync on all platforms that define it:
http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c

[2] MySQL uses fullfsync only on the darwin platform and only when
F_FULLFSYNC is defined as 51, which seems to be short-sighted in that
this symbol may change value in future versions of OS X.  To see this
code, download a mysql 5.x source snapshot and open up
mysql-<version-number>/innobase/os/os0file.c

----------
components: Library (Lib)
files: fullfsync.patch
keywords: patch
messages: 70810
nosy: icharnas
severity: normal
status: open
title: Change fsync to use fullfsync on platforms (like OS X) that have/need it
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11066/fullfsync.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3512>
_______________________________________

From report at bugs.python.org  Thu Aug  7 06:09:42 2008
From: report at bugs.python.org (Ian Charnas)
Date: Thu, 07 Aug 2008 04:09:42 +0000
Subject: [issue3512] Change fsync to use fullfsync on platforms (like OS X)
	that have/need it
In-Reply-To: <1218082061.12.0.0384174375737.issue3512@psf.upfronthosting.co.za>
Message-ID: <1218082182.3.0.832813180997.issue3512@psf.upfronthosting.co.za>


Ian Charnas <ian.charnas at gmail.com> added the comment:

My patch is against trunk, but really this fix should be applied to all
versions that will have future releases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3512>
_______________________________________

From report at bugs.python.org  Thu Aug  7 06:47:56 2008
From: report at bugs.python.org (Karen Tracey)
Date: Thu, 07 Aug 2008 04:47:56 +0000
Subject: [issue1288615] Python code.interact() and UTF-8 locale
Message-ID: <1218084476.39.0.554404065575.issue1288615@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

I just stumbled on this bug, it is still a problem in 2.5 and 2.6.  I
tried the supplied patch on 2.6b2 and it works.  Before the patch:

Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr = u'?C?mo'      
>>> print ustr
?C?mo
>>> import code
>>> code.interact()
Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> ustr = u'?C?mo'      
>>> print ustr
??C??mo

After the patch:

Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr = u'?C?mo'
>>> print ustr
?C?mo
>>> import code
>>> code.interact()
Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> ustr = u'?C?mo'
>>> print ustr
?C?mo

I realize it's a pretty little problem, but it was quite puzzling to
track down, because naturally I wasn't doing that exactly but rather
using a tool that under the covers was using code.interact() and mostly
behaves just like a bare python prompt except it was mangling unicode
string literals.  Any chance the fix could get in the code base?  The
last comment makes it sound like the patch was missing at one point. 
It's there now.  Is there any concern about it breaking something?

----------
nosy: +kmtracey
versions: +Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288615>
_______________________________________

From report at bugs.python.org  Thu Aug  7 07:12:39 2008
From: report at bugs.python.org (Karen Tracey)
Date: Thu, 07 Aug 2008 05:12:39 +0000
Subject: [issue1288615] Python code.interact() and UTF-8 locale
Message-ID: <1218085959.24.0.500777274698.issue1288615@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

FWIW I also tried the fix on a Windows box with Python 2.5.1.  The
failure there is different since the Windows command prompt apparently
uses cp437 as its encoding:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr = u'?C?mo'
>>> ustr
u'\xbfC\xf3mo'
>>> print ustr
?C?mo
>>> import code
>>> code.interact()
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> ustr = u'?C?mo'
>>> print ustr
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "d:\bin\Python2.5.1\lib\encodings\cp437.py", line 12, in encode
    return codecs.charmap_encode(input,errors,encoding_map)
UnicodeEncodeError: 'charmap' codec can't encode character u'\xa8' in
position 0: character maps to <undefined>

Applying the patch resulted in correct behavior on Windows as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288615>
_______________________________________

From report at bugs.python.org  Thu Aug  7 07:32:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 05:32:55 +0000
Subject: [issue3513] test_multiprocessing hangs without this patch on win2k
In-Reply-To: <1218087175.32.0.636360370646.issue3513@psf.upfronthosting.co.za>
Message-ID: <1218087175.32.0.636360370646.issue3513@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

Hello. I'm not familiar with socket, but I found workaround for this
problem. socket.getfqdn("127.0.0.1") returns computer name, but with this
test_multiprocess doesn't work. With 'localhost' test works.

Maybe win2003 community buildbot hangs with same reason?
http://www.python.org/dev/buildbot/community/trunk/x86%20Windows%202003%20trunk/builds/13/step-test/0

----------
components: Extension Modules
files: workaround.patch
keywords: patch
messages: 70814
nosy: ocean-city
severity: normal
status: open
title: test_multiprocessing hangs without this patch on win2k
versions: Python 2.6
Added file: http://bugs.python.org/file11067/workaround.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3513>
_______________________________________

From report at bugs.python.org  Thu Aug  7 09:14:36 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 07:14:36 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1218093276.62.0.105061612949.issue3210@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Thu Aug  7 09:41:24 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 07 Aug 2008 07:41:24 +0000
Subject: [issue3514] pickle segfault with infinite loop in __getattr__
In-Reply-To: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>
Message-ID: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

I found a segfault in pickle.load when you overload __getattr__ and 
create yourself a infinite loop in the latest svn checkout of python 3:

########################################
import pickle

class Foo:
    def __getattr__(self, key):
        self.foo

with open('foo.db', 'wb') as f:
    foo = Foo()
    pickle.dump(foo, f)

with open('foo.db', 'rb') as f:
    pickle.load(f)
########################################

This results in this stack trace on my mac:

Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c
0x0000dc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at 
Objects/abstract.c:2174
2174		if ((call = func->ob_type->tp_call) != NULL) {
(gdb) bt
#0  0x0000dc6b in PyObject_Call (func=0x0, arg=0x44cd58, kw=0x0) at 
Objects/abstract.c:2174
#1  0x004c1b4d in unpickler_call (self=0x4a6240, func=0x0, arg=0x4b66c8) 
at /Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:413
#2  0x004cac9a in load_build (self=0x4a6240) at 
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:3844
#3  0x004cbb4f in load (self=0x4a6240) at 
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4047
#4  0x004cbe71 in Unpickler_load (self=0x4a6240) at 
/Users/Shared/erickt/Projects/py3k.svn/Modules/_pickle.c:4119
#5  0x000f2fef in call_function (pp_stack=0xbfffea84, oparg=0) at 
Python/ceval.c:3387
#6  0x000edfdb in PyEval_EvalFrameEx (f=0x326cd8, throwflag=0) at 
Python/ceval.c:2205
#7  0x000f157e in PyEval_EvalCodeEx (co=0x4a9628, globals=0x487f50, 
locals=0x0, args=0x32593c, argcount=1, kws=0x325940, kwcount=0, 
defs=0x0, defcount=0, kwdefs=0x4b6428, closure=0x0) at 
Python/ceval.c:2840
#8  0x000f39e5 in fast_function (func=0x4b4ab8, pp_stack=0xbfffee54, 
n=1, na=1, nk=0) at Python/ceval.c:3501
#9  0x000f35cf in call_function (pp_stack=0xbfffee54, oparg=1) at 
Python/ceval.c:3424
#10 0x000edfdb in PyEval_EvalFrameEx (f=0x3257f8, throwflag=0) at 
Python/ceval.c:2205
#11 0x000f157e in PyEval_EvalCodeEx (co=0x444c28, globals=0x255818, 
locals=0x255818, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2840
#12 0x000e564f in PyEval_EvalCode (co=0x444c28, globals=0x255818, 
locals=0x255818) at Python/ceval.c:519
#13 0x00122a96 in run_mod (mod=0x872c80, filename=0xbffff228 "foo.py", 
globals=0x255818, locals=0x255818, flags=0xbffff628, arena=0x322020) at 
Python/pythonrun.c:1553
#14 0x00122884 in PyRun_FileExFlags (fp=0xa00dcde0, filename=0xbffff228 
"foo.py", start=257, globals=0x255818, locals=0x255818, closeit=1, 
flags=0xbffff628) at Python/pythonrun.c:1510
#15 0x00120e39 in PyRun_SimpleFileExFlags (fp=0xa00dcde0, 
filename=0xbffff228 "foo.py", closeit=1, flags=0xbffff628) at 
Python/pythonrun.c:1048
#16 0x001202f9 in PyRun_AnyFileExFlags (fp=0xa00dcde0, 
filename=0xbffff228 "foo.py", closeit=1, flags=0xbffff628) at 
Python/pythonrun.c:845
#17 0x00134d1c in Py_Main (argc=2, argv=0x227028) at Modules/main.c:592
#18 0x00002574 in main (argc=2, argv=0xbffff748) at python.c:57


It seems that this isn't just for infinite loops. If you replace the 
class with this:


class Foo:
    def __init__(self):
        self.foo = {}

    def __getattr__(self, key):
        self.foo[5]


It still errors out. So I'm guessing pickle is just not handling 
exceptions properly.

----------
components: Library (Lib)
messages: 70815
nosy: erickt
severity: normal
status: open
title: pickle segfault with infinite loop in __getattr__
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3514>
_______________________________________

From report at bugs.python.org  Thu Aug  7 12:54:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 10:54:55 +0000
Subject: [issue3515] refcount gc bug?
In-Reply-To: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
Message-ID: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

I'm not sure this is bug or not, but shouldn't `io' be collected by
refcount GC? This happens on python2.5 but doesn't happend on python3.0.

import os

def foo():
    io = open("a.txt", "w")
    raise RuntimeError()

try:
    foo()
except:
    pass

os.remove("a.txt") # WindowsError (Error32)
    # Process cannot access to the file.
    # Another process is using it.

----------
messages: 70816
nosy: ocean-city
severity: normal
status: open
title: refcount gc bug?
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________

From report at bugs.python.org  Thu Aug  7 13:32:18 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 07 Aug 2008 11:32:18 +0000
Subject: [issue3515] refcount gc bug?
In-Reply-To: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
Message-ID: <1218108738.99.0.000750627779125.issue3515@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The interpreter holds onto sys.exc_traceback even after the except
block. This refers to the frame, which refers to the file object.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________

From report at bugs.python.org  Thu Aug  7 13:45:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2008 11:45:47 +0000
Subject: [issue1288615] Python code.interact() and UTF-8 locale
Message-ID: <1218109547.4.0.644639609536.issue1288615@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
nosy: +pitrou
type:  -> behavior
versions:  -Python 2.3, Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288615>
_______________________________________

From report at bugs.python.org  Thu Aug  7 14:11:34 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 07 Aug 2008 12:11:34 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218111094.15.0.50422980385.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Dear GvR,

New code review comments by mgiuca have been published.
Please go to http://codereview.appspot.com/2827 to read them.

Message:
Hi Guido,

Thanks very much for this very detailed review. I've replied to the
comments. I will make the changes as described below and send a new
patch to the tracker.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 14:55:57 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 12:55:57 +0000
Subject: [issue3515] refcount gc bug?
In-Reply-To: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
Message-ID: <1218113757.99.0.15519174758.issue3515@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

Hmm, when exception occurs in some frame, its reference will be
retained even after exiting function? Indeed, extra
exception fixed problem.

import os

def foo():
    io = open("a.txt", "w")
    raise RuntimeError()

try:
    foo()
except:
    pass

try:
    raise RuntimeError()
except:
    pass

os.remove("a.txt") # fine

But still I'm little confused why this code prints "del".

class A:
    def __del__(self):
        print "del"

def foo():
    a = A()
    raise RuntimeError()

try:
    foo()
except:
    pass

I found this behavior when investigating issue3210. When
Lib/subprocess.py (814)'s CreateProcess() raises exception,
p2cread will be freed by refcount GC, it never happen before
os.remove(). And this error is also fixed by same hack.

import subprocess, os

file = open("filename", "w")
try:
    proc = subprocess.Popen("nosuchprogram", stdout=file)
except OSError:
    pass

try:
    raise RuntimeError() # hack
except:
    pass

file.close()
os.remove("filename")

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________

From report at bugs.python.org  Thu Aug  7 14:58:04 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 12:58:04 +0000
Subject: [issue3515] refcount gc bug?
In-Reply-To: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
Message-ID: <1218113884.11.0.758800733642.issue3515@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

>But still I'm little confused why this code prints "del".

Oh, sorry, kick me. "del" should be printed when interpreter exits. :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________

From report at bugs.python.org  Thu Aug  7 15:07:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 07 Aug 2008 13:07:06 +0000
Subject: [issue3515] refcount gc bug?
In-Reply-To: <1218113757.99.0.15519174758.issue3515@psf.upfronthosting.co.za>
Message-ID: <489AF300.50205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Hmm, when exception occurs in some frame, its reference will be
> retained even after exiting function?

Correct. When a traceback is produced, all frames get linked, be
able to print later the traceback with source code information.
Each frame keeps all its local variables.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________

From report at bugs.python.org  Thu Aug  7 15:33:06 2008
From: report at bugs.python.org (nadav)
Date: Thu, 07 Aug 2008 13:33:06 +0000
Subject: [issue3516] string formatting quirk using %.%
In-Reply-To: <1218115986.04.0.715940138525.issue3516@psf.upfronthosting.co.za>
Message-ID: <1218115986.04.0.715940138525.issue3516@psf.upfronthosting.co.za>


New submission from nadav <blop.blopy at gmail.com>:

>>> "%.%s" % ()
'%s'
>>> "%(a).%(b)s" % dict(a=2)
'%(b)s'
>>> "%(a).%(b)s" % dict(a=2, b=3)
'%(b)s'
>>> "%(a).%(b)s" % dict()
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in -toplevel-
    "%(a).%(b)s" % dict()
KeyError: 'a'

this is counter intuitive and cannot be deduced from the documentation.

----------
components: Interpreter Core
messages: 70822
nosy: blop
severity: normal
status: open
title: string formatting quirk using %.%
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3516>
_______________________________________

From report at bugs.python.org  Thu Aug  7 15:37:40 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 13:37:40 +0000
Subject: [issue3515] refcount gc bug?
In-Reply-To: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
Message-ID: <1218116260.81.0.484740144309.issue3515@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

I understand. Thank you.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________

From report at bugs.python.org  Thu Aug  7 15:42:48 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 07 Aug 2008 13:42:48 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218116568.13.0.412365033565.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

A reply to a point on GvR's review, I'd like to open for discussion.
This relates to whether or not quote's "safe" argument should allow
non-ASCII characters.

> Using errors='ignore' seems like a mistake -- it will hide errors. I >
also wonder why safe should be limited to ASCII though.

The reasoning is this: if we allow non-ASCII characters to be escaped,
then we allow quote to generate invalid URIs (URIs are only allowed to
have ASCII characters). It's one thing for unquote to accept such URIs,
but I think we shouldn't be producing them. Albeit, it only produces an
invalid URI if you explicitly request it. So I'm happy to make the
change to allow any character to be safe, but I'll let it go to
discussion first.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 15:43:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2008 13:43:14 +0000
Subject: [issue3515] refcount gc bug?
In-Reply-To: <1218106495.5.0.346677441059.issue3515@psf.upfronthosting.co.za>
Message-ID: <1218116594.37.0.476524768082.issue3515@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You don't need to raise another exception, calling sys.exc_clear()
should be fine. But a cleaner way to write your example is:

def foo():
    with open("a.txt", "w") as io:
        raise RuntimeError()

"with" will automatically close the file when the block exits.
If you are concerned with Python < 2.5 compatibility, use "try: ...
finally:" instead.

And, you're right, the problem doesn't occur at all in Python 3.0
because the exception is cleaned up after the end of the "except:" block
catching it.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3515>
_______________________________________

From report at bugs.python.org  Thu Aug  7 15:49:15 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 13:49:15 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1218116955.34.0.660982119668.issue3210@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

Hello. I had lecture about exception & frames on issue3515.

When Lib/subprocess.py (814)'s CreateProcess() raises exception,
p2cread will be freed by refcount GC, but it never happen before
os.remove() because sys.exc_traceback holds reference to frame
which has p2cread.

import subprocess, os

file = open("filename", "w")
try:
    proc = subprocess.Popen("nosuchprogram", stdout=file)
except OSError:
    pass

try:
    raise RuntimeError() # hack to clear previous exc_traceback
except:
    pass

file.close()
os.remove("filename") # runs fine

So, I think subprocess module's practice which relys on refcount GC
is not good. (p2cread is PC/_subprocess.c 's sp_handle_object, so
automatically freed by refcount GC) I don't think attached "adhok.patch"
is enough, but seems to fix this issue at least.

----------
keywords: +patch
Added file: http://bugs.python.org/file11068/adhok.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Thu Aug  7 15:55:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 13:55:21 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1218117321.04.0.230966492011.issue3210@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Thu Aug  7 16:20:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2008 14:20:05 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218116568.13.0.412365033565.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218118802.5762.5.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 07 ao?t 2008 ? 13:42 +0000, Matt Giuca a ?crit :
> The reasoning is this: if we allow non-ASCII characters to be escaped,
> then we allow quote to generate invalid URIs (URIs are only allowed to
> have ASCII characters). It's one thing for unquote to accept such URIs,
> but I think we shouldn't be producing them. Albeit, it only produces an
> invalid URI if you explicitly request it. So I'm happy to make the
> change to allow any character to be safe, but I'll let it go to
> discussion first.

The important is that the defaults are safe. If users want to override
the defaults and produce potentially invalid URIs, there is no reason to
discourage them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 16:34:38 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 14:34:38 +0000
Subject: [issue3513] test_multiprocessing hangs without this patch on win2k
In-Reply-To: <1218087175.32.0.636360370646.issue3513@psf.upfronthosting.co.za>
Message-ID: <1218119678.98.0.119646778586.issue3513@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

I'll close this entry because this seems to be duplicate of issue3270.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3513>
_______________________________________

From report at bugs.python.org  Thu Aug  7 16:35:18 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 07 Aug 2008 14:35:18 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218119718.62.0.839900605692.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> The important is that the defaults are safe. If users want to override
> the defaults and produce potentially invalid URIs, there is no reason to
> discourage them.

OK I think that's a fairly valid argument. I'm about to head off so I'll
post the patch I have now, which fixes most of the other concerns. That
change will cause havoc to quote I think ;)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 16:36:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 07 Aug 2008 14:36:08 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1218119768.84.0.972440518098.issue1342811@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please apply (also to the 2.5 and 3.0 branches).
Don't forget a Misc/NEWS entry.

----------
assignee: loewis -> schuppenies
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Thu Aug  7 16:42:04 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 07 Aug 2008 14:42:04 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218120124.02.0.0405532170513.issue3270@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

Hello. I also experienced test_multiprocessing hang on win2k and I
workarounded this by this adhok patch.

Index: Lib/multiprocessing/connection.py
===================================================================
--- Lib/multiprocessing/connection.py	(revision 65551)
+++ Lib/multiprocessing/connection.py	(working copy)
@@ -217,7 +217,12 @@
         self._socket.listen(backlog)
         address = self._socket.getsockname()
         if type(address) is tuple:
-            address = (socket.getfqdn(address[0]),) + address[1:]
+            def getfqdn(s): # ???
+                if s == '127.0.0.1':
+                    return 'localhost'
+                else:
+                    return socket.getfqdn(s)
+            address = (getfqdn(address[0]),) + address[1:]
         self._address = address
         self._family = family
         self._last_accepted = None

I'm not familiar to socket, so probably this info is useless. ;-)

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Thu Aug  7 16:59:58 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 07 Aug 2008 14:59:58 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218121198.79.0.14201620078.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Following Guido and Antoine's reviews, I've written a new patch which
fixes *most* of the issues raised. The ones I didn't fix I have noted
below, and commented on the review site
(http://codereview.appspot.com/2827/). Note: I intend to address all of
these issues after some discussion.

Outstanding issues raised by the reviews:

Doc/library/urllib.parse.rst:
Should unquote accept a bytes/bytearray as well as a str?

Lib/email/utils.py:
Should encode_rfc2231 with charset=None accept strings with non-ASCII
characters, and just encode them to UTF-8?

Lib/test/test_http_cookiejar.py:
Does RFC 2965 let me get away with changing the test case to expect
UTF-8? (I'm pretty sure it doesn't care what encoding is used).

Lib/test/test_urllib.py:
Should quote raise a TypeError if given a bytes with encoding/errors
arguments? (Motivation: TypeError is what you usually raise if you
supply too many args to a function).

Lib/urllib/parse.py:
(As discussed above) Should quote accept safe characters outside the
ASCII range (thereby potentially producing invalid URIs)?

------

Commit log for patch8:

Fix for issue 3300.

urllib.parse.unquote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the decoding of percent-encoded octets.
As per RFC 3986, default is "utf-8" (previously implicitly decoded as
ISO-8859-1). Also fixed a bug in which mixed-case hex digits (such as
"%aF") weren't being decoded at all.

urllib.parse.quote: Added "encoding" and "errors" optional arguments,
allowing the caller to determine the encoding of non-ASCII characters
before being percent-encoded. Default is "utf-8" (previously characters
in range(128, 256) were encoded as ISO-8859-1, and characters above that
as UTF-8). Also characters/bytes above 128 are no longer allowed to be
"safe". Also now allows either bytes or strings.

Added functions urllib.parse.quote_from_bytes,
urllib.parse.unquote_to_bytes. All quote/unquote functions now exported
from the module.

Doc/library/urllib.parse.rst: Updated docs on quote and unquote to
reflect new interface, added quote_from_bytes and unquote_to_bytes.

Lib/test/test_urllib.py: Added many new test cases testing encoding
and decoding Unicode strings with various encodings, as well as testing
the new functions.

Lib/test/test_http_cookiejar.py, Lib/test/test_cgi.py,
Lib/test/test_wsgiref.py: Updated and added test cases to deal with
UTF-8-encoded URIs.

Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote
with encoding="latin-1", to preserve existing behaviour (which the whole
email module is dependent upon).

Added file: http://bugs.python.org/file11069/parse.py.patch8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 17:03:00 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 07 Aug 2008 15:03:00 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218121380.95.0.143702957244.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

I'm also attaching a "metapatch" - diff from patch 7 to patch 8. This is
to give a rough idea of what I changed since the review.

(Sorry - This is actually a diff between the two patches, so it's pretty
hard to read. It would have been nicer to diff the files themselves but
I'm not doing local commits so that's hard. Can one use the Bazaar
mirror for development, or is it too out-of-date?)

Added file: http://bugs.python.org/file11070/parse.py.metapatch8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 18:20:32 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 16:20:32 +0000
Subject: [issue3512] Change fsync to use fullfsync on platforms (like OS X)
	that have/need it
In-Reply-To: <1218082061.12.0.0384174375737.issue3512@psf.upfronthosting.co.za>
Message-ID: <1218126032.06.0.605864328582.issue3512@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

IMO it would be better not to confuse matters my having os.fsync() call
fullfsync(); it's better to add a separate os.fullfsync() call on
platforms that support it.  That way the application can choose.  I
suppose Apple had a reason for changing the behavior...

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3512>
_______________________________________

From report at bugs.python.org  Thu Aug  7 18:30:42 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 16:30:42 +0000
Subject: [issue3514] pickle segfault with infinite loop in __getattr__
In-Reply-To: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>
Message-ID: <1218126642.66.0.78348419669.issue3514@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Does this occur in 2.6 or 2.5?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3514>
_______________________________________

From report at bugs.python.org  Thu Aug  7 18:39:09 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 07 Aug 2008 16:39:09 +0000
Subject: [issue3514] pickle segfault with infinite loop in __getattr__
In-Reply-To: <1218126642.66.0.78348419669.issue3514@psf.upfronthosting.co.za>
Message-ID: <1ef034530808070939n53d038e4w7f2f2e40cdd0a576@mail.gmail.com>


Erick Tryzelaar <idadesub at users.sourceforge.net> added the comment:

> Guido van Rossum <guido at python.org> added the comment:
>
> Does this occur in 2.6 or 2.5?

It doesn't in python 2.5. The RuntimeError manages to get printed out.
I don't have 2.6 installed to test against at the moment. Here's the
equivalent code:

########################
import pickle

class Foo:
    def __getattr__(self, key):
        self.foo

f = open('foo.db', 'w')
foo = Foo()
pickle.dump(foo, f)
f.close()

f = open('foo.db', 'r')
pickle.load(f)
f.close()
########################

This also happens with cPickle.

----------
nosy: +idadesub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3514>
_______________________________________

From report at bugs.python.org  Thu Aug  7 18:51:15 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 16:51:15 +0000
Subject: [issue3516] string formatting quirk using %.%
In-Reply-To: <1218115986.04.0.715940138525.issue3516@psf.upfronthosting.co.za>
Message-ID: <1218127875.37.0.564791039456.issue3516@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

It's straightforward if you consider the implementation of the
requirement that %% renders a single percent sign: the second % is
parsed just like any other formatting code (i, d, f, etc.) and the stuff
between the first % and the formatting code is treated completely uniformly.

----------
nosy: +gvanrossum
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3516>
_______________________________________

From report at bugs.python.org  Thu Aug  7 18:53:30 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 16:53:30 +0000
Subject: [issue3512] Change fsync to use fullfsync on platforms (like OS X)
	that have/need it
In-Reply-To: <1218082061.12.0.0384174375737.issue3512@psf.upfronthosting.co.za>
Message-ID: <1218128010.71.0.308970444874.issue3512@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Based on discussion in python-dev, I'm rejecting this patch.

Open a new one if you want to make F_FULLSYNC available.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3512>
_______________________________________

From report at bugs.python.org  Thu Aug  7 18:59:54 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 16:59:54 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218121380.95.0.143702957244.issue3300@psf.upfronthosting.co.za>
Message-ID: <ca471dc20808070959xdf7a4fawe6f3b3190c0e19e3@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Thu, Aug 7, 2008 at 8:03 AM, Matt Giuca <report at bugs.python.org> wrote:
>
> Matt Giuca <matt.giuca at gmail.com> added the comment:
>
> I'm also attaching a "metapatch" - diff from patch 7 to patch 8. This is
> to give a rough idea of what I changed since the review.
>
> (Sorry - This is actually a diff between the two patches, so it's pretty
> hard to read. It would have been nicer to diff the files themselves but
> I'm not doing local commits so that's hard. Can one use the Bazaar
> mirror for development, or is it too out-of-date?)

A much better way to do this would be to use Rietveld; it can show
deltas between patch sets that are actually readable, and it keeps the
inline comments.  I've uploaded your patch #8 to the issue I created
there, and you can see the delta from patch7 starting here:

http://codereview.appspot.com/2827/diff2/1:17/27

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 19:19:30 2008
From: report at bugs.python.org (nadav)
Date: Thu, 07 Aug 2008 17:19:30 +0000
Subject: [issue3516] string formatting quirk using %.%
In-Reply-To: <1218127875.37.0.564791039456.issue3516@psf.upfronthosting.co.za>
Message-ID: <f046a5c0808071019n1185b094k95209e1db38f9c08@mail.gmail.com>


nadav <blop.blopy at gmail.com> added the comment:

The main problem with this is that the following code does not make any
sense:
"%(a)%" % dict(a=3)

It has no semantic meaning (take the dictionary paramater a, and do nothing
with it).
It must be a user bug (except in very wierd cases).

I agree that when I consider the implementaion, it makes sense, but as a
python user, this behavior is really non-intuitive.

2008/8/7 Guido van Rossum <report at bugs.python.org>

>
> Guido van Rossum <guido at python.org> added the comment:
>
> It's straightforward if you consider the implementation of the
> requirement that %% renders a single percent sign: the second % is
> parsed just like any other formatting code (i, d, f, etc.) and the stuff
> between the first % and the formatting code is treated completely
> uniformly.
>
> ----------
> nosy: +gvanrossum
> resolution:  -> rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3516>
> _______________________________________
>

Added file: http://bugs.python.org/file11071/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3516>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080807/2f193cb4/attachment.txt>

From report at bugs.python.org  Thu Aug  7 19:31:59 2008
From: report at bugs.python.org (Ian Charnas)
Date: Thu, 07 Aug 2008 17:31:59 +0000
Subject: [issue3517] PATCH - Providing fullfsync on supported platforms
In-Reply-To: <1218130319.91.0.361112026251.issue3517@psf.upfronthosting.co.za>
Message-ID: <1218130319.91.0.361112026251.issue3517@psf.upfronthosting.co.za>


New submission from Ian Charnas <ian.charnas at gmail.com>:

Python currently provides os.fsync to call the POSIX 'fsync' on
platforms that support it.  While this function forces the operating
system to force a file buffer to the storage device, data may still be
waiting in the hardware write buffers on the storage device.  Certain
platforms (so far, only OS X) provide "fullfsync" [1] to request that
storage devices flush their write buffers to the actual physical media.  

This functionality is especially useful to VCS and DB developers, and
already appears in SQLite [2] and MySQL [3], amongst others.

This patch includes code changes to Modules/posixmodule.c that exposes
os.fullfsync on supported platforms, including the appropriate
documentation added to Doc/library/os.rst

-Ian Charnas

[1] Discussion of fsync and fullfsync on darwin platform:
http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html

[2] SQLite uses fullfsync on all platforms that define it:
http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c

[3] MySQL uses fullfsync only on the darwin platform and only when
F_FULLFSYNC is defined as 51, which seems to be short-sighted in that
this symbol may change value in future versions of OS X.  To see this
code, download a mysql 5.x source snapshot and open up
mysql-<version-number>/innobase/os/os0file.c

----------
components: Library (Lib)
files: fullfsync.patch
keywords: patch
messages: 70842
nosy: icharnas
severity: normal
status: open
title: PATCH - Providing fullfsync on supported platforms
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11072/fullfsync.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3517>
_______________________________________

From report at bugs.python.org  Thu Aug  7 19:38:13 2008
From: report at bugs.python.org (Ian Charnas)
Date: Thu, 07 Aug 2008 17:38:13 +0000
Subject: [issue3512] Change fsync to use fullfsync on platforms (like OS X)
	that have/need it
In-Reply-To: <1218128010.71.0.308970444874.issue3512@psf.upfronthosting.co.za>
Message-ID: <18e505e30808071038g12ad7fc1tbbdbde795c22ffaa@mail.gmail.com>


Ian Charnas <ian.charnas at gmail.com> added the comment:

Done.  See 3517
http://bugs.python.org/issue3517

On Thu, Aug 7, 2008 at 12:53 PM, Guido van Rossum
<report at bugs.python.org> wrote:
>
> Guido van Rossum <guido at python.org> added the comment:
>
> Based on discussion in python-dev, I'm rejecting this patch.
>
> Open a new one if you want to make F_FULLSYNC available.
>
> ----------
> resolution:  -> rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3512>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3512>
_______________________________________

From report at bugs.python.org  Thu Aug  7 19:46:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Aug 2008 17:46:08 +0000
Subject: [issue3518] multiprocessing: BaseManager.from_address documented but
	doesn't exist
In-Reply-To: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za>
Message-ID: <1218131168.54.0.934616092257.issue3518@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The BaseManager.from_address method is documented at:

http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.ma
nagers.BaseManager.from_address

but it looks as though this method doesn't actually exist.  In contrast, 
the BaseManager.connect method appears to be necessary for making remote 
connections, but is not documented.

----------
assignee: jnoller
components: Documentation
messages: 70844
nosy: jnoller, marketdickinson
severity: normal
status: open
title: multiprocessing: BaseManager.from_address documented but doesn't exist
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3518>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:01:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Aug 2008 18:01:13 +0000
Subject: [issue3516] string formatting quirk using %.%
In-Reply-To: <1218115986.04.0.715940138525.issue3516@psf.upfronthosting.co.za>
Message-ID: <1218132073.12.0.362530433997.issue3516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd rather see it this way: It is a programming error if a format string
contains a reference to a nonexisting dictionary key, no matter what
formatting specifier is used. The implementation is quite consistent here.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3516>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:15:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Aug 2008 18:15:39 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1218132939.44.0.459472006185.issue1717@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Additionally, there are still lots of references to __cmp__ in the
library which should be ripped out.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:16:18 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 18:16:18 +0000
Subject: [issue3517] PATCH - Providing fullfsync on supported platforms
In-Reply-To: <1218130319.91.0.361112026251.issue3517@psf.upfronthosting.co.za>
Message-ID: <1218132978.18.0.180989401574.issue3517@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm sorry to have lead you this way, but since there is no fullfsync()
system call, IMO you should just make the F_FULLFSYNC constant
available.  That should go into fcntlmodule.c.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3517>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:38:34 2008
From: report at bugs.python.org (Rick Harris)
Date: Thu, 07 Aug 2008 18:38:34 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1218134314.14.0.546695402019.issue1346874@psf.upfronthosting.co.za>


Rick Harris <rconradharris at gmail.com> added the comment:

I'm implemented the behavior described by Mike above with a patch to
2.6. The patch will raise an ExpectationFailed before sending the body
if the server responds with a 417 (Expectation Failed).

This patch should only modify behavior for requests that specify
"Expect: 100-continue" in the request's headers.

Note: The spec says that the client should send the body if the server
does not respond within some reasonable period of time. This is not
currently supported. Anyone have any thoughts on how that could be done?

----------
keywords: +patch
nosy: +rharris
versions: +Python 2.6 -Python 2.4
Added file: http://bugs.python.org/file11073/issue1346874.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346874>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:43:28 2008
From: report at bugs.python.org (Ian Charnas)
Date: Thu, 07 Aug 2008 18:43:28 +0000
Subject: [issue3517] PATCH - Providing fullfsync on supported platforms
In-Reply-To: <1218130319.91.0.361112026251.issue3517@psf.upfronthosting.co.za>
Message-ID: <1218134608.9.0.00372141927635.issue3517@psf.upfronthosting.co.za>


Ian Charnas <ian.charnas at gmail.com> added the comment:

Sounds fair enough.  I was looking forward to the glitz and glamor of
the os module, but I'll settle for a good seat in fcntl.  Here's a patch
implementing just that.

-ian

Added file: http://bugs.python.org/file11074/fullfsync_fcntl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3517>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:44:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2008 18:44:01 +0000
Subject: [issue1288615] Python code.interact() and UTF-8 locale
Message-ID: <1218134641.13.0.967906813158.issue1288615@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65578.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288615>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:52:11 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 18:52:11 +0000
Subject: [issue3517] PATCH - Providing fullfsync on supported platforms
In-Reply-To: <1218130319.91.0.361112026251.issue3517@psf.upfronthosting.co.za>
Message-ID: <1218135131.18.0.55778516775.issue3517@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks, checked into the trunk as r65581.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3517>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:52:30 2008
From: report at bugs.python.org (Karen Tracey)
Date: Thu, 07 Aug 2008 18:52:30 +0000
Subject: [issue1288615] Python code.interact() and UTF-8 locale
Message-ID: <1218135150.52.0.142760440336.issue1288615@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

Cool, thanks! Do I take it from the Versions setting that the fix will
be available in the next 2.6 beta but not get propagated to prior
releases?  (I'm not very familiar with this issue tracker so am just
trying to understand what the various fields mean.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288615>
_______________________________________

From report at bugs.python.org  Thu Aug  7 20:58:50 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2008 18:58:50 +0000
Subject: [issue1288615] Python code.interact() and UTF-8 locale
In-Reply-To: <1218135150.52.0.142760440336.issue1288615@psf.upfronthosting.co.za>
Message-ID: <1218135525.5762.11.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 07 ao?t 2008 ? 18:52 +0000, Karen Tracey a ?crit :
> Karen Tracey <kmtracey at gmail.com> added the comment:
> 
> Cool, thanks! Do I take it from the Versions setting that the fix will
> be available in the next 2.6 beta but not get propagated to prior
> releases?  (I'm not very familiar with this issue tracker so am just
> trying to understand what the various fields mean.)

?Indeed, the fix will be present in the next 2.6 beta.

As for the 2.5 branch, it is in maintenance mode and we want to minimize
the amount the potential breakage that we might cause there. I don't
think the present bug is important enough to warrant a backport, but
other developers may disagree and fix 2.5 as well :-)

(as for 3.0, it is unaffected)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288615>
_______________________________________

From report at bugs.python.org  Thu Aug  7 21:29:14 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 07 Aug 2008 19:29:14 +0000
Subject: [issue2470] Need fixer for dl (removed) -> ctypes module
In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
Message-ID: <1218137354.67.0.26858934071.issue2470@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I can review and try out the fixer if someone provides a patch.  OTOH I
have never used the dl module.

Note that dl exposed a lot of RTLD_ constants that ctypes does not yet,
so there should be a patch for ctypes also.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2470>
_______________________________________

From report at bugs.python.org  Thu Aug  7 22:49:26 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 07 Aug 2008 20:49:26 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218142166.03.0.564419825964.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Just to reply to Antoine's comments on my patch:

- it would be nice to have more unit tests, especially for the various
bytes/unicode possibilities, and perhaps also roundtripping (Matt's
patch has a lot of tests)

Yes, I completely agree.

- quote_as_bytes() should return a bytes object, not a bytearray

Good point.

- using the "%02X" format looks clearer to me than going through the
_hextable lookup table...

Really?  I see it the other way.

- when the argument is of the wrong type, quote_as_bytes() should raise
a TypeError rather than a ValueError

Good point.

- why is quote_as_string() hardwired to utf8 while unquote_as_string()
provides a charset parameter? wouldn't it be better for them to be
consistent with each other?

To encourage the use of UTF-8.  The caller can alway explicitly encode
to some other character set, then pass in the bytes that result from
that encoding.  Remember that the RFC for percent-encoding really takes
bytes in, and produces bytes out.  The string-in and string-out versions
are to support naive programming (what a nice way of putting it!).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:03:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2008 21:03:41 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1218053557.26.0.142168657254.issue3506@psf.upfronthosting.co.za>
Message-ID: <1218143018.5762.17.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 06 ao?t 2008 ? 20:12 +0000, Guido van Rossum a ?crit :
> +1.  buffer() stinks.  memoryview() rules.  They don't hvae the same use
> cases.
> 
> Is there truly nobody else who understands PEP 3118 well enough?

PEP 3118 is not very detailed (for example the exact semantics of
slicing are not specified: should it return a copy? I suppose not).
Also, most advanced uses of the buffer API seem related to numpy and
similar packages, which I've never used.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:10:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Aug 2008 21:10:57 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218143457.69.0.253416522683.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmmm.  That last message wasn't too coherent;  I really shouldn't try to 
post at 2:30am.

Summary:  the refcounting logic in the Server class is flawed.  In 
Server.create(), the initial refcount of a newly-created shared object is 
set to None.  This is dangerous: the moment another thread gets a look-in, 
that refcount can be incremented to 1, then decremented to 0, at which 
point the shared object gets disposed of (by the code in Server.decref).   
And all this can happen before the Proxy object for the shared object gets 
initialized, at which point the KeyError occurs.

(Not much better.)

Can anyone suggest a way to fix this?  I can't see any easy fix.  
Nevertheless, I consider this a serious flaw that should be fixed before 
2.6 and 3.0 are released.

I've attached a minimal file that produces the incref error (on about 1 
run out of every 5) for me.

Added file: http://bugs.python.org/file11075/multibug3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:17:08 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 07 Aug 2008 21:17:08 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218143828.6.0.619997562476.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

My main fear with this patch is that "unquote" will become seen as
unreliable, because naive software trying to parse URLs will encounter
uses of percent-encoding where the encoded octets are not in fact UTF-8
bytes.  They're just some set of bytes.  A secondary concern is that it
will invisibly produce invalid data, because it decodes some
non-UTF-8-encoded string that happens to only use UTF-8-valid sequences
as the wrong string value.

Now, I have to confess that I don't know how common these use cases are
in actual URL usage.  It would be nice if there was some organization
that had a large collection of URLs, and could provide a test set we
could run a scanner over :-).

As a workaround, though, I've sent a message off to Larry Masinter to
ask about this case.  He's one of the authors of the URI spec.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:26:10 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Aug 2008 21:26:10 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218144370.25.0.290235416862.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Adding Richard Oudkerk to the nosy list in case he can shed any light on 
this.

Should this be considered a release-blocker?

----------
nosy: +roudkerk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:36:07 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 07 Aug 2008 21:36:07 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1218144370.25.0.290235416862.issue3419@psf.upfronthosting.co.za>
Message-ID: <18A8146D-7F3B-448B-9831-D1AD8876FBED@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Aug 7, 2008, at 5:26 PM, Mark Dickinson <report at bugs.python.org>  
wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Adding Richard Oudkerk to the nosy list in case he can shed any  
> light on
> this.
>
> Should this be considered a release-blocker?
>

I believe Richard is on summer break - I've dropped him a line on the  
open issues I need his input on.

As for if this should block the release, it should be resolved before  
final, but should not block the next beta.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:43:33 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 07 Aug 2008 21:43:33 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218143828.6.0.619997562476.issue3300@psf.upfronthosting.co.za>
Message-ID: <489B6C7C.4030803@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-08-07 23:17, Bill Janssen wrote:
> Bill Janssen <bill.janssen at gmail.com> added the comment:
> 
> My main fear with this patch is that "unquote" will become seen as
> unreliable, because naive software trying to parse URLs will encounter
> uses of percent-encoding where the encoded octets are not in fact UTF-8
> bytes.  They're just some set of bytes. 

unquote will have to be able to deal with old-style URLs that
use the Latin-1 encoding. HTML uses (or used to use) the Latin-1
encoding as default and that's how URLs ended up using it as well:

http://www.w3schools.com/TAGS/ref_urlencode.asp

I'd suggest to have it first try UTF-8 decoding and then fall back
to Latin-1 decoding.

> A secondary concern is that it
> will invisibly produce invalid data, because it decodes some
> non-UTF-8-encoded string that happens to only use UTF-8-valid sequences
> as the wrong string value.

It's rather unlikely that someone will have used a Latin-1 encoded
URL which happens to decode as valid UTF-8: The valid UTF-8 combinations
don't really make any sense when used as text, e.g.

?????1/4

> Now, I have to confess that I don't know how common these use cases are
> in actual URL usage.  It would be nice if there was some organization
> that had a large collection of URLs, and could provide a test set we
> could run a scanner over :-).
> 
> As a workaround, though, I've sent a message off to Larry Masinter to
> ask about this case.  He's one of the authors of the URI spec.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:46:24 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 21:46:24 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218143828.6.0.619997562476.issue3300@psf.upfronthosting.co.za>
Message-ID: <ca471dc20808071446i549063eo89f5060e1e72e818@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Thu, Aug 7, 2008 at 2:17 PM, Bill Janssen <report at bugs.python.org> wrote:
>
> Bill Janssen <bill.janssen at gmail.com> added the comment:
>
> My main fear with this patch is that "unquote" will become seen as
> unreliable, because naive software trying to parse URLs will encounter
> uses of percent-encoding where the encoded octets are not in fact UTF-8
> bytes.  They're just some set of bytes.

Apps that want to handle these correctly have no choice but to use
unquote_to_bytes(), or setting error='ignore' or error='replace'.

Your original proposal was to make unquote() behave like
unquote_to_bytes(), which would require changes to virtually every app
using unqote(), since almost all apps assume the result is a (text)
string.

Setting the default encoding to Latin-1 would prevent these errors,
but would commit the sin of mojibake (the Japanese word for Perl code
:-). I don't like that much either.

A middle ground might be to set the default encoding to ASCII --
that's closer to Martin's claim that URLs are supposed to be ASCII
only. It will fail as soon as an app receives encoded non-ASCII text.
This will require many apps to be changed, but at least it forces the
developers to think about which encoding to assume (perhaps there's
one handy in the request headers if it's a web app) or about error
handling or perhaps using unquote_to_bytes().

However I fear that this middle ground will in practice cause:

(a) more in-the-field failures, since devs are notorious for testing
with ASCII only; and

(b) the creation of a recipe for "fixing" unquote() calls that fail by
setting the encoding to UTF-8 without thinking about the alternatives,
thereby effectively recreating the UTF-8 default with much more pain.

Therefore I think that the UTF-8 default is probably the most pragmatic choice.

In the code review, I have asked Matt to change the default error
handling from errors='replace' to errors='strict'. I suppose we could
reduce outright crashes in the field by setting this to 'replace'
(even though for quote() I think it should remain 'strict'). But this
may cause more subtle failures, where apps simply receive garbage
data. At least when you're serving pages with error 500 the developers
tend to get called in. When the users merely get failing results such
bugs may remain lingering much longer.

> A secondary concern is that it
> will invisibly produce invalid data, because it decodes some
> non-UTF-8-encoded string that happens to only use UTF-8-valid sequences
> as the wrong string value.

In my experience this is very unlikely. UTF-8 looks like total junk in
Latin-1, so it's unlikely to occur naturally. If you see something
that matches a UTF-8 sequence in Latin-1 text, it's most likely that
in fact it was incorrectly decoded earlier...

> Now, I have to confess that I don't know how common these use cases are
> in actual URL usage.  It would be nice if there was some organization
> that had a large collection of URLs, and could provide a test set we
> could run a scanner over :-).
>
> As a workaround, though, I've sent a message off to Larry Masinter to
> ask about this case.  He's one of the authors of the URI spec.

Looking forward to his response.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:51:20 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Aug 2008 21:51:20 +0000
Subject: [issue3460] PyUnicode_Join could perhaps be simpler
In-Reply-To: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za>
Message-ID: <1218145880.89.0.104704825405.issue3460@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the patch in r65583.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3460>
_______________________________________

From report at bugs.python.org  Thu Aug  7 23:53:16 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Aug 2008 21:53:16 +0000
Subject: [issue3519] Evaluation order example lacks suffix
In-Reply-To: <1218145996.93.0.279881671552.issue3519@psf.upfronthosting.co.za>
Message-ID: <1218145996.93.0.279881671552.issue3519@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Language reference/ Expressions/ Evaluation order
...
In the following lines, expressions will be evaluated in the arithmetic
order of their suffixes:
...
func(expr1, expr2, *expr3, **expr4)

The omission of a suffix from the function expression could imply that
such are somehow not included in the left-to-right rule.  Suggest
'func0', 'f_expr0', 'func_expr0' or just 'expr0' possibly renumbered from 1.

expr1(expr2, expr3, *expr4, **expr5)
is probably most consistent with other examples.

----------
assignee: georg.brandl
components: Documentation
messages: 70864
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Evaluation order example lacks suffix
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3519>
_______________________________________

From report at bugs.python.org  Fri Aug  8 00:13:24 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Aug 2008 22:13:24 +0000
Subject: [issue3520] New Global Module Index glitch on WinXP
In-Reply-To: <1218147204.29.0.833867911272.issue3520@psf.upfronthosting.co.za>
Message-ID: <1218147204.29.0.833867911272.issue3520@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

New to beta2 (a4,b1 worked fine as I remember).
It is possible that I installed xp sp3 in between.
In any case, I keep xp updated as per MS downloads.

Windows XP: open Start/Python3.0/Python Manuals to get
'Python v3.0b2 documentation' window.  Click 'Global Module Index' on
contents list.  Get
Internet Explorer Script Error
   !An error has occurred in the script on this page.
Line 16
Char 7
Error: 'DOCUMENTATION_OPTIONS' is undefined
Code: 0
URL: mk at MSITStore:C:\Program
Files\Python30\Doc\python30b2.chm::/modindex.html

Do you want to continue running scripts on this page?

When I click yes, seems to work ok as before.
Error repeats when I go back to index again.

----------
assignee: georg.brandl
components: Documentation
messages: 70865
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: New Global Module Index glitch on WinXP
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3520>
_______________________________________

From report at bugs.python.org  Fri Aug  8 00:36:51 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Aug 2008 22:36:51 +0000
Subject: [issue3521] file.readline: bad exception recovery
In-Reply-To: <1218148611.21.0.579552262714.issue3521@psf.upfronthosting.co.za>
Message-ID: <1218148611.21.0.579552262714.issue3521@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

WinXP, 3.0b2
>>>f=open('somefile', 'r')
>>>f.readline(somefloat)
Traceback (most recent call last):
  File "<pyshell#70>", line 1, in <module>
    f.readline(1.0)
  File "C:\Program Files\Python30\lib\io.py", line 1766, in readline
    return line[:endpos]
TypeError: slice indices must be integers or None or have an __index__
method

At this point, any f.read or f.readline calls fail with a similar
TypeError.  The error recovery seems incomplete.  The same does *not*
happen with f.read(float).  Recovery is complete and subsequent
f.read/f.readline calls work.

In 2.5, float size arg worked with a deprecation warning, so issue does
not arise.  I presume same is true in 2.6.

----------
components: Interpreter Core
messages: 70866
nosy: tjreedy
severity: normal
status: open
title: file.readline: bad exception recovery
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3521>
_______________________________________

From report at bugs.python.org  Fri Aug  8 00:53:36 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 22:53:36 +0000
Subject: [issue3521] file.readline: bad exception recovery
In-Reply-To: <1218148611.21.0.579552262714.issue3521@psf.upfronthosting.co.za>
Message-ID: <1218149616.17.0.97087949429.issue3521@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Good catch!

This looks pretty simple to fix; I think a type check is missing
(actually several, there are at least two implementations in io.py).

In fact, the 2.6 version of io.py already has the necessary checks. 
(But merging those forward is not 100% trivial since in 3.0 the 'long'
type doesn't exist.)

----------
keywords: +easy
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3521>
_______________________________________

From report at bugs.python.org  Fri Aug  8 00:58:22 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 07 Aug 2008 22:58:22 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <ca471dc20808071446i549063eo89f5060e1e72e818@mail.gmail.com>
Message-ID: <4b3e516a0808071558r41892c2aud4b8060226355d6@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

> Your original proposal was to make unquote() behave like
> unquote_to_bytes(), which would require changes to virtually every app
> using unqote(), since almost all apps assume the result is a (text)
> string.

Actually, careful apps realize that the result of "unquote" in Python 2 is a
sequence of bytes, and do something careful with that.  So only careless
apps would break, and they'd break in such a way that their maintainers
would have to look at the situation again, and think about it.  Seems like a
'good thing', to me.  And since this is Python 3, fully allowed.  I really
don't understand your position here, I'm afraid.

Setting the default encoding to Latin-1 would prevent these errors,
> but would commit the sin of mojibake (the Japanese word for Perl code
> :-). I don't like that much either.

No, that would be wrong.  Returning a string just for the sake of returning
a string.  Remember, the data percent-encoded is not necessarily a string,
and not necessarily in any known encoding.

>
> A middle ground might be to set the default encoding to ASCII --
> that's closer to Martin's claim that URLs are supposed to be ASCII
> only.

URLs *are* supposed to be ASCII only -- but the percent-encoded byte
sequences in various parts of the path aren't.

This will require many apps to be changed, but at least it forces the
> developers to think about which encoding to assume (perhaps there's
> one handy in the request headers if it's a web app) or about error
> handling or perhaps using unquote_to_bytes().

Yes, this is closer to my line of reasoning.

> However I fear that this middle ground will in practice cause:
>
> (a) more in-the-field failures, since devs are notorious for testing
> with ASCII only; and

Returning bytes deals with this problem.

> (b) the creation of a recipe for "fixing" unquote() calls that fail by
> setting the encoding to UTF-8 without thinking about the alternatives,
> thereby effectively recreating the UTF-8 default with much more pain.

Could be, but at least they will have had to think about.  There's lots of
bad code out there, and maybe by making them think about it, some of it will
improve.

> A secondary concern is that it
> > will invisibly produce invalid data, because it decodes some
> > non-UTF-8-encoded string that happens to only use UTF-8-valid sequences
> > as the wrong string value.
>
> In my experience this is very unlikely. UTF-8 looks like total junk in
> Latin-1, so it's unlikely to occur naturally. If you see something
> that matches a UTF-8 sequence in Latin-1 text, it's most likely that
> in fact it was incorrectly decoded earlier...
>

Latin-1 isn't the only alternate encoding in the world, and not all
percent-encoded byte sequences in URLs are encoded strings.  I'd feel better
if we were being guided by more than your just experience (vast though it
may rightly be said to be!).  Say, by looking at all the URLs that Google
knows about :-).  I'd particularly feel better if some expert in Asian use
of the Web spoke up here...

Added file: http://bugs.python.org/file11076/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080807/4a574269/attachment.txt>

From report at bugs.python.org  Fri Aug  8 01:23:49 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Aug 2008 23:23:49 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <4b3e516a0808071558r41892c2aud4b8060226355d6@mail.gmail.com>
Message-ID: <ca471dc20808071623v74ca2f35m947484f381f2a3fe@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Thu, Aug 7, 2008 at 3:58 PM, Bill Janssen <report at bugs.python.org> wrote:
> Bill Janssen <bill.janssen at gmail.com> added the comment:
>> Your original proposal was to make unquote() behave like
>> unquote_to_bytes(), which would require changes to virtually every app
>> using unqote(), since almost all apps assume the result is a (text)
>> string.
>
> Actually, careful apps realize that the result of "unquote" in Python 2 is a
> sequence of bytes, and do something careful with that.

Given that in 2.x it's a string, and knowing my users, I expect that
careful apps are a tiny minority.

> So only careless
> apps would break, and they'd break in such a way that their maintainers
> would have to look at the situation again, and think about it.  Seems like a
> 'good thing', to me.  And since this is Python 3, fully allowed.  I really
> don't understand your position here, I'm afraid.

My position is that although 3.0 supports Unicode much better than 2.x
(I won't ever use pretentious and meaningless phrases like "fully
supports"), that doesn't mean that you *have* to use it. I expect lots
of simple web apps don't need Unicode but do need quote/unquote
functionality to get around "forbidden" characters in query strings
like &. I don't want to force such apps to become more aware of
Unicode than absolutely necessary.

>> A middle ground might be to set the default encoding to ASCII --
>> that's closer to Martin's claim that URLs are supposed to be ASCII
>> only.
>
> URLs *are* supposed to be ASCII only -- but the percent-encoded byte
> sequences in various parts of the path aren't.
>
>> This will require many apps to be changed, but at least it forces the
>> developers to think about which encoding to assume (perhaps there's
>> one handy in the request headers if it's a web app) or about error
>> handling or perhaps using unquote_to_bytes().
>
> Yes, this is closer to my line of reasoning.
>
>> However I fear that this middle ground will in practice cause:
>>
>> (a) more in-the-field failures, since devs are notorious for testing
>> with ASCII only; and
>
> Returning bytes deals with this problem.

In an unpleasant way. We might as well consider changing all APIs that
deal with URLs to insist on bytes.

>> (b) the creation of a recipe for "fixing" unquote() calls that fail by
>> setting the encoding to UTF-8 without thinking about the alternatives,
>> thereby effectively recreating the UTF-8 default with much more pain.
>
> Could be, but at least they will have had to think about.  There's lots of
> bad code out there, and maybe by making them think about it, some of it will
> improve.

I'd rather use a carrot than a stick. IOW I'd rather write aggressive
docs than break people's code.

>> A secondary concern is that it
>> > will invisibly produce invalid data, because it decodes some
>> > non-UTF-8-encoded string that happens to only use UTF-8-valid sequences
>> > as the wrong string value.
>>
>> In my experience this is very unlikely. UTF-8 looks like total junk in
>> Latin-1, so it's unlikely to occur naturally. If you see something
>> that matches a UTF-8 sequence in Latin-1 text, it's most likely that
>> in fact it was incorrectly decoded earlier...

> Latin-1 isn't the only alternate encoding in the world, and not all
> percent-encoded byte sequences in URLs are encoded strings.  I'd feel better
> if we were being guided by more than your just experience (vast though it
> may rightly be said to be!).  Say, by looking at all the URLs that Google
> knows about :-).  I'd particularly feel better if some expert in Asian use
> of the Web spoke up here...

OK, let's wait and see if one bites.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 02:04:30 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 08 Aug 2008 00:04:30 +0000
Subject: [issue3429] urllib.urlopen() return type
In-Reply-To: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za>
Message-ID: <20080808000411.GE3370@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

I agree with Benjamin on this issue, describing what is a "File like Object" is
so much un-needed in Python and especially at urlopen function. Users have been
able to understand and use it properly from a long time.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3429>
_______________________________________

From report at bugs.python.org  Fri Aug  8 02:11:53 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 00:11:53 +0000
Subject: [issue3522] zip() function example in tutorial
In-Reply-To: <1218154313.32.0.167482410859.issue3522@psf.upfronthosting.co.za>
Message-ID: <1218154313.32.0.167482410859.issue3522@psf.upfronthosting.co.za>


New submission from Jim Sizelove <jimsize at gmail.com>:

The zip() function is now a generator in Python 3.0.  There is an
example of using the zip() function in the Python 3.0 tutorial,
http://docs.python.org/dev/3.0/tutorial/datastructures.html.

When running the example, I got:

>>> mat = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
>>> zip(*mat)
<zip object at 0x70fc60>

I wrapped it in a call to list() to get the example output:

>>> list(zip(*mat))
[(1, 4, 7), (2, 5, 8), (3, 6, 9)]


The attached patch file contains this change.

----------
assignee: georg.brandl
components: Documentation
files: datastructures.diff
keywords: patch
messages: 70871
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: zip() function example in tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11077/datastructures.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3522>
_______________________________________

From report at bugs.python.org  Fri Aug  8 02:18:55 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 00:18:55 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <ca471dc20808071623v74ca2f35m947484f381f2a3fe@mail.gmail.com>
Message-ID: <4b3e516a0808071718p1621b455j86933e2f1a56f144@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

On Thu, Aug 7, 2008 at 4:23 PM, Guido van Rossum <report at bugs.python.org>wrote:

>
> >> However I fear that this middle ground will in practice cause:
> >>
> >> (a) more in-the-field failures, since devs are notorious for testing
> >> with ASCII only; and
> >
> > Returning bytes deals with this problem.
>
> In an unpleasant way. We might as well consider changing all APIs that
> deal with URLs to insist on bytes.
>

That seems a bit over-the-top.  Most URL operations *are* about strings, and
most of the APIs should deal with strings; we're talking about the return
result of an operation specifically designed to extract binary data from the
one place where it's allowed to occur.  Vastly smaller than "changing all
APIs that deal with URLs".

By the way, I see that the email package dodges this by encoding the bytes
to strings using the codec "raw-unicode-escape".  In other words, byte
sequences in the outward form of a string.  I'd be OK with that.  That is,
make the default codec for "unquote" be "raw-unicode-escape".  All the bytes
will come through unscathed, and people who are naively expecting ASCII
strings will still receive them, so the code won't break.  This actually
seems to be closest to the current usage, so I'm going to change my patch to
do that.

Added file: http://bugs.python.org/file11078/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080808/d30079da/attachment.txt>

From report at bugs.python.org  Fri Aug  8 02:24:22 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 00:24:22 +0000
Subject: [issue3523] Reverse quotes in Python 3.0 tutorial
In-Reply-To: <1218155062.71.0.673827854609.issue3523@psf.upfronthosting.co.za>
Message-ID: <1218155062.71.0.673827854609.issue3523@psf.upfronthosting.co.za>


New submission from Jim Sizelove <jimsize at gmail.com>:

The Input and Output section of the tutorial says: "Reverse quotes (``)
are equivalent to repr(), but they are no longer used in modern Python
code and are removed in future versions of the language."  Is now that
future time with Python 3.0?  I get syntax errors when I try to run the
examples that use reverse quotes.  The attached patch removes the
explanation and examples of reverse quotes.

----------
assignee: georg.brandl
components: Documentation
files: input_output.diff
keywords: patch
messages: 70873
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Reverse quotes in Python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11079/input_output.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3523>
_______________________________________

From report at bugs.python.org  Fri Aug  8 02:26:32 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 08 Aug 2008 00:26:32 +0000
Subject: [issue3466] urllib2 should support HTTPS connections with client keys
In-Reply-To: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za>
Message-ID: <1218155192.1.0.103705726934.issue3466@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3466>
_______________________________________

From report at bugs.python.org  Fri Aug  8 02:42:35 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 00:42:35 +0000
Subject: [issue3524] IOError when attempting negative seek in file (Python 3.0
	tutorial)
In-Reply-To: <1218156155.34.0.949676293741.issue3524@psf.upfronthosting.co.za>
Message-ID: <1218156155.34.0.949676293741.issue3524@psf.upfronthosting.co.za>


New submission from Jim Sizelove <jimsize at gmail.com>:

The Input and Output section of the Python 3.0 tutorial
(http://docs.python.org/dev/3.0/tutorial/inputoutput.html) shows an
example of seeking in a negative direction from the end of a file.  I
get an IOError when attempting to run the example in Python 3.0b2 on Mac
OS X 10.4 (PPC).  I don't know whether the tutorial or the code should
be changed.

>>> f = open('workfile', 'r+')
>>> f.write('0123456789abcdef')
16
>>> f.seek(-3, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Users/jimsize/Programming/Python/py3k/3.0b2/lib/python3.0/io.py", line
1609, in seek
    raise IOError("can't do nonzero end-relative seeks")
IOError: can't do nonzero end-relative seeks

----------
assignee: georg.brandl
components: Documentation
messages: 70874
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: IOError when attempting negative seek in file (Python 3.0 tutorial)
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3524>
_______________________________________

From report at bugs.python.org  Fri Aug  8 02:49:38 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Aug 2008 00:49:38 +0000
Subject: [issue896052] symtable module not documented
Message-ID: <1218156578.13.0.0891912072252.issue896052@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I notice that symtable is still in 3.0, still not in the index, and I
presume still not documented.  The help(symtable) says it defines classes
Symbol
SymbolTable
Class(SymbolTable)
Function(symbolTable)
so it seems to be used for parsing.  Is it for the old ast parser, and
therefore obsolete?  For the new AST parser and still relevant?  For an
experiment that ended?  Or something else?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue896052>
_______________________________________

From report at bugs.python.org  Fri Aug  8 03:10:28 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 01:10:28 +0000
Subject: [issue3525] Changes to exceptions not reflected in tutorial examples.
In-Reply-To: <1218157828.17.0.153809100644.issue3525@psf.upfronthosting.co.za>
Message-ID: <1218157828.17.0.153809100644.issue3525@psf.upfronthosting.co.za>


New submission from Jim Sizelove <jimsize at gmail.com>:

PEPs 3109 and 3110 describe changes to Exceptions.  The attached patch
file makes changes to the tutorial to bring it in line with the changes
to errors and exceptions implemented in Python 3.0.

I'll make a comment about the .args of exceptions instances.  The
tutorial states "use of .args is discouraged."  I found, however, that
the alternative of unpacking the args using __getitem__ raises a
TypeError.  

    >>> try:
    ...     raise Exception('spam', 'eggs')
    ... except Exception as inst:
    ...     x, y = inst
    ... 
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
    Exception: ('spam', 'eggs')
    
    During handling of the above exception, another exception occurred:
    
    Traceback (most recent call last):
      File "<stdin>", line 4, in <module>
    TypeError: 'Exception' object is not iterable

Does that mean that now .args is encouraged?

----------
assignee: georg.brandl
components: Documentation
files: errors.diff
keywords: patch
messages: 70876
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Changes to exceptions not reflected in tutorial examples.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11080/errors.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3525>
_______________________________________

From report at bugs.python.org  Fri Aug  8 03:22:55 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Fri, 08 Aug 2008 01:22:55 +0000
Subject: [issue3525] Changes to exceptions not reflected in tutorial examples.
In-Reply-To: <1218157828.17.0.153809100644.issue3525@psf.upfronthosting.co.za>
Message-ID: <1218158575.05.0.918667448801.issue3525@psf.upfronthosting.co.za>


Jim Sizelove <jimsize at gmail.com> added the comment:

The conversations that led to the removal of __getitem__ from Exceptions
can be found in issue2291 and issue2379.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3525>
_______________________________________

From report at bugs.python.org  Fri Aug  8 03:34:05 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 01:34:05 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218159245.24.0.0467802626348.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Now I'm looking at the failing test_http_cookiejar test, which fails
because it encodes a non-UTF-8 byte, 0xE5, in a path segment of a URI.
The question is, does the "http" URI scheme allow non-ASCII (say,
Latin-1) octets in path segments?  IANA says that the "http" scheme
is defined in RFC 2616, and that says:

   This specification adopts the
   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
   "host","abs_path", "rel_path", and "authority" from [RFC 2396].

But RFC 2396 says:

    An individual URI scheme may require a single charset, define a
    default charset, or provide a way to indicate the charset used.

And doesn't say anything about the "http" scheme.  Nor does it indicate
any default encoding or character set for URIs.  The update, 3986,
doesn't say anything new about this, though it does implore URI scheme
designers to represent characters in a textual segment with ASCII codes
where they exist, and to use UTF-8 when designing *new* URI schemes.

Barring any other information, I think that the "segments" in the path
of an "http" URL must also be assumed to be binary; that is, any octet
is allowed, and no character set can be presumed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 03:34:31 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 01:34:31 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218159271.39.0.309408603617.issue3300@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file11078/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 03:34:39 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 01:34:39 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218159279.14.0.661479228267.issue3300@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file11076/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 04:04:33 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 02:04:33 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218161073.38.0.550504443359.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Looks like the failing test in test_http_cookiejar is just a bad test;
it attempts to build an HTTP request object from an invalid URL, yet
still seem to expect to be able to extract a cookie from the response
headers for that request.  I'd expect some exception to be thrown.

So this probably indicates a bug in urllib.parse:

urllib.parse.urlparse("http://www.acme.com/foo%2f%25/<<%0anew\345/\346\370\345")


should throw an exception somewhere.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 04:07:02 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 02:07:02 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218161222.81.0.331518904627.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Just to be clear:  any octet would seem to be allowed in the "path" of
an "http" URL, but any non-ASCII octet must be percent-encoded.  So the
URL itself is still an ASCII string, considered opaquely.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 05:32:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Aug 2008 03:32:20 +0000
Subject: [issue896052] symtable module not documented
Message-ID: <1218166340.86.0.962008275531.issue896052@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue896052>
_______________________________________

From report at bugs.python.org  Fri Aug  8 06:17:45 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 Aug 2008 04:17:45 +0000
Subject: [issue3506] Change buffer/memoryview DeprecationWarning
In-Reply-To: <1217962091.36.0.181182833526.issue3506@psf.upfronthosting.co.za>
Message-ID: <1218169065.37.0.594625223984.issue3506@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

In r65584 I changed the warning to not mention memoryview(); it just
says that buffer() does not exist in 3.0.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3506>
_______________________________________

From report at bugs.python.org  Fri Aug  8 08:42:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Aug 2008 06:42:30 +0000
Subject: [issue3519] Evaluation order example lacks suffix
In-Reply-To: <1218145996.93.0.279881671552.issue3519@psf.upfronthosting.co.za>
Message-ID: <1218177750.97.0.192559758901.issue3519@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65591.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3519>
_______________________________________

From report at bugs.python.org  Fri Aug  8 08:43:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Aug 2008 06:43:01 +0000
Subject: [issue3429] urllib.urlopen() return type
In-Reply-To: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za>
Message-ID: <1218177781.7.0.68388477884.issue3429@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Agreed.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3429>
_______________________________________

From report at bugs.python.org  Fri Aug  8 08:44:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Aug 2008 06:44:22 +0000
Subject: [issue3522] zip() function example in tutorial
In-Reply-To: <1218154313.32.0.167482410859.issue3522@psf.upfronthosting.co.za>
Message-ID: <1218177862.88.0.876907931861.issue3522@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r65592.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3522>
_______________________________________

From report at bugs.python.org  Fri Aug  8 08:46:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Aug 2008 06:46:07 +0000
Subject: [issue3523] Reverse quotes in Python 3.0 tutorial
In-Reply-To: <1218155062.71.0.673827854609.issue3523@psf.upfronthosting.co.za>
Message-ID: <1218177967.62.0.885968928349.issue3523@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r65593.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3523>
_______________________________________

From report at bugs.python.org  Fri Aug  8 08:51:06 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Aug 2008 06:51:06 +0000
Subject: [issue3525] Changes to exceptions not reflected in tutorial examples.
In-Reply-To: <1218157828.17.0.153809100644.issue3525@psf.upfronthosting.co.za>
Message-ID: <1218178266.79.0.754740252222.issue3525@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r65594.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3525>
_______________________________________

From report at bugs.python.org  Fri Aug  8 09:05:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Aug 2008 07:05:03 +0000
Subject: [issue3524] IOError when attempting negative seek in file (Python 3.0
	tutorial)
In-Reply-To: <1218156155.34.0.949676293741.issue3524@psf.upfronthosting.co.za>
Message-ID: <1218179103.76.0.274394221955.issue3524@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Since the file is a text file, such seeking is not possible.

I've now updated the whole section about files; in particular there was
also an outdated description of text vs. binary mode.

Committed r65595.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3524>
_______________________________________

From report at bugs.python.org  Fri Aug  8 09:18:21 2008
From: report at bugs.python.org (ThomasH)
Date: Fri, 08 Aug 2008 07:18:21 +0000
Subject: [issue3429] urllib.urlopen() return type
In-Reply-To: <20080808000411.GE3370@gmail.com>
Message-ID: <de6ef73d0808080018w46f49d48k8bb1dde7f3e967bf@mail.gmail.com>


ThomasH <thomas.bugzilla at gmx.net> added the comment:

On Fri, Aug 8, 2008 at 2:04 AM, Senthil <report at bugs.python.org> wrote:
>
> Senthil <orsenthil at gmail.com> added the comment:
>
> I agree with Benjamin on this issue, describing what is a "File like Object" is
> so much un-needed in Python and especially at urlopen function. Users have been
> able to understand and use it properly from a long time.

If only it were more file-like. But, oh, it adds info() and geturl()
methods which you have to string-search for to find the proper
description in the prose. And, ah, the size argument of the read()
method doesn't quite behave like on other file-like objects, but there
you go. And, uh, by the way, you really can't use it in places "where
a true built-in file object is required" (and I'm sure everybody knows
what that means). - So much for file-like.

I have no doubt that people can get along with the description as it
is, because that's what they always try. My main point was that it is
"less approachable and breaks the usual format of a class
documentation". But I see there is much agreement in keeping the
status quo.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3429>
_______________________________________

From report at bugs.python.org  Fri Aug  8 09:39:55 2008
From: report at bugs.python.org (ThomasH)
Date: Fri, 08 Aug 2008 07:39:55 +0000
Subject: [issue3429] urllib.urlopen() return type
In-Reply-To: <1218177781.7.0.68388477884.issue3429@psf.upfronthosting.co.za>
Message-ID: <de6ef73d0808080039vf5cd856scecf2f3e7e445110@mail.gmail.com>


ThomasH <thomas.bugzilla at gmx.net> added the comment:

Georg,

you seem like a dedicated person. I'm sure you guys have thought about
documenting return types of methods and functions in a standardized
way, documenting classes so that you could fade in and out inherited
features, and such. Where do you guys discuss general documentation
issues? Is there a mailing list dedicated to Python documentation?!

On Fri, Aug 8, 2008 at 8:43 AM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> Agreed.
>
> ----------
> resolution:  -> works for me
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3429>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3429>
_______________________________________

From report at bugs.python.org  Fri Aug  8 11:12:05 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 08 Aug 2008 09:12:05 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218186725.27.0.358684542335.issue3270@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Jesse, thanks for capturing my e-mail thread in this issue.  Can you 
comment on my last three paragraphs?  Essentially, I think we should 
lock down the API and assert that Listener.address will always be 
a 'connectable' end-point.  (i.e. not a wildcard host, 0.0.0.0, that 
can't be bound to by a socket, for example)

This would mean raising an exception in Listener.__init__ if this 
invariant is violated.

----------
nosy: +Trent.Nelson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Fri Aug  8 11:26:55 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 08 Aug 2008 09:26:55 +0000
Subject: [issue1117601] os.path.exists returns false negatives in MAC
	environments.
Message-ID: <1218187615.08.0.350695176174.issue1117601@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

hsoft-dev:~ hsoft$ mkdir foobar
hsoft-dev:~ hsoft$ echo "baz" > foobar/baz
hsoft-dev:~ hsoft$ chmod 000 foobar/baz
hsoft-dev:~ hsoft$ python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.exists('foobar/baz')
True
>>> 
hsoft-dev:~ hsoft$ chmod 000 foobar
hsoft-dev:~ hsoft$ python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.exists('foobar/baz')
False
>>> os.path.exists('foobar')
True
>>> 

This seems like the correct behavior to me.

----------
nosy: +vdupras

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1117601>
_______________________________________

From report at bugs.python.org  Fri Aug  8 11:34:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Aug 2008 09:34:37 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218188077.45.0.231436073164.issue3270@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This would mean raising an exception in Listener.__init__ if this 
> invariant is violated.

If I understand the suggestion correctly, it would forbid people to
listen on 0.0.0.0. I'm not sure it is the right correction for the
problem. Listening on 0.0.0.0 can be handy when you are not sure which
address to use; it would be better to address the problem elsewhere.

IMO, the "FQDN removal patch" as uploaded by Jesse is simple and
straight-forward enough, provided it does fix the bug.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Fri Aug  8 11:41:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Aug 2008 09:41:18 +0000
Subject: [issue1117601] os.path.exists returns false negatives in MAC
	environments.
Message-ID: <1218188478.16.0.308518894902.issue1117601@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The only sane alternative to the current behaviour would be to raise an
Exception from os.path.exists rather than returning False. But it would
also break a lot of code, and complexify code using os.path.exists which
currently doesn't need to check for exceptions. Returning True sounds
completely incorrect on the other hand.

If there is no other straightforward method than stat() to know if a
path exists, I suggest closing this bug as wontfix.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1117601>
_______________________________________

From report at bugs.python.org  Fri Aug  8 11:45:45 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Fri, 08 Aug 2008 09:45:45 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1218188745.36.0.484987583913.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hi,

I have modified a bit this patch to make it work with Python 2.5.2 (see
attached patched).

It is a great enhancement for Python users on AIX to be able to use a
shared library instead of a static one, so I would appreciate if this
feature could be integrated in trunk.

We have various AIX 5.2 and 5.3 servers in the Sungard company where I
work, and we could run some tests according to your instructions. It may
also be possible to provide some limited access to one of those servers
if needed but it would require some time and paper work.

What kind of access would you need in order to validate those patchs?

thanks in advance

----------
keywords: +patch
nosy: +sable
Added file: http://bugs.python.org/file11081/patch_AIX_shared.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Aug  8 11:48:42 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 08 Aug 2008 09:48:42 +0000
Subject: [issue1117601] os.path.exists returns false negatives in MAC
	environments.
Message-ID: <1218188922.8.0.660590572326.issue1117601@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

Antoine, I think that when this bug was filed, the first 
"os.path.exists('foobar/baz')" in my example would return False.

So it's not that this bug shouldn't be fixed, but that it is already 
fixed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1117601>
_______________________________________

From report at bugs.python.org  Fri Aug  8 12:02:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Aug 2008 10:02:58 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1218189778.09.0.65444520121.issue941346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

S?bastien, what does your patch change exactly? Does it build a shared
lib for Python by default? If that's the case, I'm not sure it's a good
idea due to AIX's particular way of treating shared libraries; it might
break e.g. when trying to embed Python in another program.
(I say this while being an AIX novice, but I did have to compile Python
under AIX for embedded use in another third-party software...
unfortunately right now I don't have access to an AIX machine with a
compiler)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Aug  8 12:13:01 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Fri, 08 Aug 2008 10:13:01 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

Hi,

We run a big application mostly written in Python (with Pyrex/C
extensions) on different systems including Linux, SunOS and AIX.

The memory footprint of our application on Linux is fine; however we
found that on AIX and SunOS, any memory that has been allocated by our
application at some stage will never be freed at the system level.

After doing some analysis (see the 2 attached pdf documents), we found
that this is linked to the implementation of malloc on those various
systems:

The malloc used on Linux (glibc) is based on dlmalloc as described in
this document:
http://g.oswego.edu/dl/html/malloc.html

This implementation will use sbrk to allocate small chunks of memory,
but it will use mmap to allocate big chunks. This ensures that the
memory will actually get freed when free is called.

AIX and Sun have a more naive malloc implementation, so that the memory
allocated by an application through malloc is never actually freed until
the application leaves (this behavior has been confirmed by some experts
at IBM and Sun when we asked them for some feedback on this problem -
there is a 'memory disclaim' option on AIX but it is disabled by default
as it brings some major performance penalities).

For long running Python applications which may allocate a lot of memory
at some stage, this is a major drawback.

In order to bypass this limitation of the system on AIX and SunOS, we
have modified Python so that it will use the customized malloc
implementation dlmalloc like in glibc (see attached patch) - dlmalloc is
released in the public domain.

This patch adds a --enable-dlmalloc option to configure. When activated,
we observed a dramatic reduction of the memory used by our application.
I think many AIX and SunOS Python users could be interested by such an
improvement.

--
S?bastien Sabl?
Sungard

----------
files: customized_malloc_SUN.pdf
messages: 70897
nosy: sable
severity: normal
status: open
title: Customized malloc implementation on SunOS and AIX
type: resource usage
Added file: http://bugs.python.org/file11082/customized_malloc_SUN.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Aug  8 12:13:45 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Fri, 08 Aug 2008 10:13:45 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1218190425.81.0.54279159221.issue3526@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file11083/customized_malloc_AIX.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Aug  8 12:15:35 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Fri, 08 Aug 2008 10:15:35 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1218190535.51.0.478575150949.issue3526@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file11084/patch_dlmalloc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Aug  8 12:32:55 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 08 Aug 2008 10:32:55 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218191575.24.0.851557810629.issue3270@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Unfortunately, the patch while simple, is too simple. The removal of the 
_address attribute breaks a lot more than it fixes (it's heavily used 
elsewhere)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Fri Aug  8 12:44:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 08 Aug 2008 10:44:33 +0000
Subject: [issue3527] Py_WIN_WIDE_FILENAMES removal
In-Reply-To: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>
Message-ID: <1218192273.13.0.480212879714.issue3527@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

Py_WIN_WIDE_FILENAMES is not used anywhere, this patch removes this macro.

----------
files: remove_macro.patch
keywords: patch
messages: 70899
nosy: ocean-city
severity: normal
status: open
title: Py_WIN_WIDE_FILENAMES removal
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11085/remove_macro.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3527>
_______________________________________

From report at bugs.python.org  Fri Aug  8 13:01:29 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 08 Aug 2008 11:01:29 +0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1218193289.97.0.603291189971.issue2153@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

This patch has gone invalid due to some recent conflicting changes. I 
remade it and I'm resubmitting it hoping that it will get applied.

Added file: http://bugs.python.org/file11086/unittest_modern2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
_______________________________________

From report at bugs.python.org  Fri Aug  8 14:29:54 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 08 Aug 2008 12:29:54 +0000
Subject: [issue3528] TypeError when compiling with no translator
In-Reply-To: <1218198594.3.0.422262573033.issue3528@psf.upfronthosting.co.za>
Message-ID: <1218198594.3.0.422262573033.issue3528@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

I just ran 'make html' with the latest version and got this exception:

loading translations [en]... Exception occurred:
  File "/home/bob/data/dvl/python/svn/doctools/sphinx/builder.py", line
184, in load_i18n
    self.info('selected locale not available' % self.config.language)
TypeError: not all arguments converted during string f

The enclosed patch fixes the issue.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: str_formatting.patch
keywords: patch
messages: 70901
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: TypeError when compiling with no translator
type: behavior
Added file: http://bugs.python.org/file11087/str_formatting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3528>
_______________________________________

From report at bugs.python.org  Fri Aug  8 14:31:41 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Fri, 08 Aug 2008 12:31:41 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1218198701.13.0.397396333788.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hum, I tried to recompile Python without the --enable-shared option on
AIX and it crashed; so this patch may not be compatible with a static
version of Python (though I have other patches in my version - cf issue
3526 - which may be incompatible).

I will do a bit of cleanup in my environment and try to make a version
of the patch that works also when compiling a static Python.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Aug  8 15:00:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Aug 2008 13:00:37 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1218191575.24.0.851557810629.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218200255.489c42bfee6fb@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon Jesse Noller <report at bugs.python.org>:
>
> Unfortunately, the patch while simple, is too simple. The removal of the
> _address attribute breaks a lot more than it fixes (it's heavily used
> elsewhere)

I don't understand what you mean. The patch you uploaded doesn't remove the
_address attribute.

See http://bugs.python.org/file10801/connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Fri Aug  8 15:12:06 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 08 Aug 2008 13:12:06 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1218200255.489c42bfee6fb@imp.free.fr>
Message-ID: <4222a8490808080603jc2e7f35r583ad0d1fa7d8913@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

> I don't understand what you mean. The patch you uploaded doesn't remove the
> _address attribute.
>
> See http://bugs.python.org/file10801/connection.patch

Hmm. Then that was a mistake on my part: it's entirely possible the
patch didn't apply cleanly. I'll circle back to this shortly and
re-apply/test.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Fri Aug  8 15:51:42 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Aug 2008 13:51:42 +0000
Subject: [issue3528] TypeError when compiling with no translator
In-Reply-To: <1218198594.3.0.422262573033.issue3528@psf.upfronthosting.co.za>
Message-ID: <1218203502.6.0.110015934821.issue3528@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r65599 :-|.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3528>
_______________________________________

From report at bugs.python.org  Fri Aug  8 16:29:12 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 08 Aug 2008 14:29:12 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218205752.85.0.278421858389.issue3270@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Trent/Antoine - I'm stuck on the fence about this. Per trent's own 
suggestion - removing the allowance for the 0.0.0.0 style address means 
that the self._address is always a connectable end-point: this provides 
clarity to the API.

However - to Antoine's point - using 0.0.0.0 to listen on "all 
addresses" is actually pretty common, especially when working with 
bigger servers (which generally have multiple cores). Using the 0.0.0.0 
address makes it easy to say "listen everywhere" - where, in the case of 
a Manager is actually very useful (you could have processes connecting 
to a Manager on a machine from different networks).

Attached is a cleaned up diff of the removal of the fqdn call - this 
should resolve the original problem while leaving the door open for the 
ability to connect to the 0.0.0.0 "address".

I need someone with a windows machine (Hi Trent!) that exposed the 
original problem to test the patch. Currently I'm favoring this rather 
than locking out the 0.0.0.0 option.

Added file: http://bugs.python.org/file11088/connection_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Fri Aug  8 16:29:26 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 08 Aug 2008 14:29:26 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218205766.57.0.719054604919.issue3270@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file10801/connection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Fri Aug  8 18:14:26 2008
From: report at bugs.python.org (Karen Tracey)
Date: Fri, 08 Aug 2008 16:14:26 +0000
Subject: [issue2811] doctest doesn't treat unicode literals as specified by
	the file declared encoding
In-Reply-To: <1210445230.87.0.512222933205.issue2811@psf.upfronthosting.co.za>
Message-ID: <1218212066.25.0.0863479351419.issue2811@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

I believe the problem is in your test file, not doctest.  The enclosing
doctest string is not specified as a unicode literal, so the file
encoding specification ultimately has no effect on it.  At least that is
how I read the documentation regarding the effect of the ecoding
declaration ("The encoding is used for all lexical analysis, in
particular to find the end of a string, and to interpret the contents of
Unicode literals. String literals are converted to Unicode for
syntactical analysis, then converted back to their original encoding
before interpretation starts.")

If you change the test file so that the string enclosing the test is a
unicode literal then the test passes:

user at gutsy:~/tmp$ cat test_iso-8859-15.py
# -*- coding: utf-8 -*-

import doctest

def normalize(s):
    u"""
    >>> normalize(u'??')
    u'b'
    """
    return s.translate({ord(u'??'): u'b'})
    
doctest.testmod()
print 'without doctest ===>>>', normalize(u'??')

user at gutsy:~/tmp$ python test_iso-8859-15.py
without doctest ===>>> b

-----

There is a problem with this, though: doctest now will be unable to
correctly report errors when there are output mismatches involving
unicode strings with non-ASCII chars.  For example if you add an 'x' to
the front of your unicode literal to be normalized you'll get this when
you try to run it:

user at gutsy:~/tmp$ python test_iso-8859-15.py
Traceback (most recent call last):
  File "test_iso-8859-15.py", line 12, in <module>
    doctest.testmod()
  File "/usr/lib/python2.5/doctest.py", line 1799, in testmod
    runner.run(test)
  File "/usr/lib/python2.5/doctest.py", line 1345, in run
    return self.__run(test, compileflags, out)
  File "/usr/lib/python2.5/doctest.py", line 1261, in __run
    self.report_failure(out, test, example, got)
  File "/usr/lib/python2.5/doctest.py", line 1125, in report_failure
    self._checker.output_difference(example, got, self.optionflags))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in
position 149: ordinal not in range(128)
user at gutsy:~/tmp$ 

This issue is reported in #1293741, but there is no fix or guidance
offered there on how to work around the problem.

I'd appreciate feedback on whether what I've said here is correct.  I'm
currently trying to diagnose/fix problems with use of unicode literals
in some tests and this is as far as I've got. That is, I think I need to
be specifying the enclosing strings as unicode literals, but then I run
into #1293741.  If the conclusion I've reached is correct, then trying
to figure out a fix for that problem should be where I focus my efforts.
 If, however, I shouldn't be specifying the enclosing string as a
unicode literal, then attempting to fix the problem as described here
would perhaps be more useful.  Though I do not know how the doctest code
can know the file's encoding specification?

----------
nosy: +kmtracey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2811>
_______________________________________

From report at bugs.python.org  Fri Aug  8 21:12:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Aug 2008 19:12:11 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1218222731.02.0.948406171475.issue3526@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is very interesting, although it should probably go through
discussion on python-dev since it involves integrating a big chunk of
external code.

----------
components: +Interpreter Core
nosy: +pitrou
priority:  -> normal
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Fri Aug  8 22:38:31 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 Aug 2008 20:38:31 +0000
Subject: [issue3489] add rotate{left,right} methods to bytearray
In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>
Message-ID: <1218227911.07.0.696687308019.issue3489@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Sadly, this isn't quite as easy as it would seem.  The O(1) memory
overhead version of this requires 2n reads and 2n writes, but does both
reads and writes at two memory locations at a time, which may have
nontrivial performance implications.

The simple version that copies out the small part of the shift into a
temporary buffer, doing a memcpy/memmov internally, then copying the
small data back is likely to have much better performance (worst-case
1.5n reads and 1.5n writes.

Offering this ability in the momoryview object would be very
interesting, though I'm not sure that the memoryview object is able to
offer a multi-segment buffer interface where the segments are not the
same length (this could be hacked by having a single pointer per byte,
but at that point we may as well perform a copy).

----------
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________

From report at bugs.python.org  Fri Aug  8 22:49:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Aug 2008 20:49:32 +0000
Subject: [issue3489] add rotate{left,right} methods to bytearray
In-Reply-To: <1218227911.07.0.696687308019.issue3489@psf.upfronthosting.co.za>
Message-ID: <1218228569.5779.7.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

> Sadly, this isn't quite as easy as it would seem.

You are right, I was overly optimist when thinking about this.

> Offering this ability in the momoryview object would be very
> interesting, though I'm not sure that the memoryview object is able to
> offer a multi-segment buffer interface where the segments are not the
> same length (this could be hacked by having a single pointer per byte,
> but at that point we may as well perform a copy).

I'm not sure what you mean, but I think we can just restrict it to the
simple case of a single contiguous buffer.

shift{left,right} could be useful too (and faster).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________

From report at bugs.python.org  Fri Aug  8 23:04:19 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Aug 2008 21:04:19 +0000
Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal
	interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1218229459.91.0.0671241518941.issue2704@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On windows: type
>>> zomeinput
Press home key.  In command window (terminal interface), cursor goes to
just before z, where one would want.  In IDLE (2.5.2, 3.0b2), it goes to
beginning of line.  If current patch does not fix this (there is no
mention), would it be easy to add?

I would expect so because the current page up places the cursor 4 chars
to the right of the margin (if there is text not visible above the
window to jump to and if there is text on the line jumped to).  So
PageUp PageDn will sometimes simulate the desired Home behavior.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2704>
_______________________________________

From report at bugs.python.org  Fri Aug  8 23:22:03 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Aug 2008 21:22:03 +0000
Subject: [issue1721083] Add File - Reload
Message-ID: <1218230523.7.0.897895476992.issue1721083@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to me to duplicate and supercede
http://bugs.python.org/issue1175686
If so, could that be closed as superceded?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721083>
_______________________________________

From report at bugs.python.org  Fri Aug  8 23:28:12 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 21:28:12 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218230892.86.0.0420253977993.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Here's the updated version of my patch.  It returns a string, but
doesn't clobber bytes that are contained in the string.  Naive code
(basically code that expects ASCII strings from unquote) should continue
to work as well as it ever did.  I fixed the problem with the email
library, and removed the bogus test from the http_cookiejar test suite.

Added file: http://bugs.python.org/file11089/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 23:28:26 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 08 Aug 2008 21:28:26 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218230906.63.0.22070844876.issue3300@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file11064/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Fri Aug  8 23:33:33 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Aug 2008 21:33:33 +0000
Subject: [issue3493] No Backslash (\) in IDLE 1.2.2
In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
Message-ID: <1218231213.81.0.461715581595.issue3493@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

\ works fine for me and I suspect almost everyone else.
Please bring this up on comp.lang.python or python-list or
gmane.comp.python.general to see if any other Macbook users have this
problems or any ideas on what might be wrong with your particular
installation.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3493>
_______________________________________

From report at bugs.python.org  Fri Aug  8 23:44:04 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 08 Aug 2008 21:44:04 +0000
Subject: [issue3489] add rotate{left,right} methods to bytearray
In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za>
Message-ID: <1218231844.2.0.0338218181614.issue3489@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

In order for MemoryView to know what bytes it is pointing to in memory,
it (generally) keeps a pointer with a length.  In order to rotate the
data without any copies, you need a pointer and length for each rotation
plus the original.  For example, the equivalent to a rotate left of 8
characters using slicing is... x[8:] + x[:8].  That is two segments. 
That's a "multi-segment buffer interface".  But typical multi-segment
buffer interfaces require each segment to be exactly the same length
(like numpy), which is not the case with rotations.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________

From report at bugs.python.org  Sat Aug  9 00:00:52 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Aug 2008 22:00:52 +0000
Subject: [issue3489] add rotate{left,right} methods to bytearray
In-Reply-To: <1218231844.2.0.0338218181614.issue3489@psf.upfronthosting.co.za>
Message-ID: <1218232801.18022.3.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 08 ao?t 2008 ? 21:44 +0000, Josiah Carlson a ?crit :
> Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:
> 
> In order for MemoryView to know what bytes it is pointing to in memory,
> it (generally) keeps a pointer with a length.  In order to rotate the
> data without any copies, you need a pointer and length for each rotation
> plus the original.  For example, the equivalent to a rotate left of 8
> characters using slicing is... x[8:] + x[:8].

Hmm, I think it's simpler if the rotate is done in-place rather than
returning a new object. Most uses of memoryviews are going to be with
APIs requiring a single contiguous segment.
(of course for read-only buffers it would raise an error)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3489>
_______________________________________

From report at bugs.python.org  Sat Aug  9 00:06:30 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 08 Aug 2008 22:06:30 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1218233190.45.0.142806983667.issue3436@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Making an existing attribute a property is a nice, API-neutral way to
handle this.  Let's call the inconsistency a bug and this a bug fix
<wink> so that it's fine to add to 2.6 and 3.0 at this point.

----------
nosy: +barry
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Sat Aug  9 00:17:03 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Aug 2008 22:17:03 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1218233823.68.0.468468413193.issue2827@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.0b2, WinXP
I cut and pasted the text above into an empty IDLE edit window, hit F5,
and in the blink of an eye, both IDLE windows disappeared.  No error
message, no Window's error box, just gone.

The pasted text was saved to the file.  When I added input() statements,
and ran with CPython directly, it got to the function call and then
crashed.  Rerunning with Idle with input() at the top, it still crashed,
indicating that it crashed during compilation and never started execution.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Sat Aug  9 00:36:04 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 Aug 2008 22:36:04 +0000
Subject: [issue2983] Ttk support for Tkinter
In-Reply-To: <1211911032.63.0.360625687085.issue2983@psf.upfronthosting.co.za>
Message-ID: <1218234964.22.0.150982479775.issue2983@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I wish I had realized this work was done or else I would have pushed to
get this in for 2.6/3.0. Damn. Setting for 2.7/3.1, although if the
decision was made it was easier to only have it in 3.1 that would be
fine by me.

Regardless, setting this to high since while it is not a bug fix, being
able to make Tk apps that aren't quite so ugly would be REALLY nice and
might re-invigorate use of tkinter.

----------
nosy: +brett.cannon
priority:  -> high
versions: +Python 2.7, Python 3.1 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2983>
_______________________________________

From report at bugs.python.org  Sat Aug  9 00:46:51 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 08 Aug 2008 22:46:51 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1218235611.41.0.14254205748.issue3526@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I cannot quite see why the problem is serious: even though the memory is
not returned to the system, it will be swapped out to the swap file, so
it doesn't consume any real memory (just swap space).

I don't think Python should integrate a separate malloc implementation.
Instead, Python's own memory allocate (obmalloc) should be changed to
directly use the virtual memory interfaces of the operating system (i.e.
mmap), bypassing the malloc of the C library.

So I'm -1 on this patch.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Sat Aug  9 00:53:45 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 08 Aug 2008 22:53:45 +0000
Subject: [issue3436] csv.DictReader inconsistency
In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za>
Message-ID: <1218236025.08.0.393144717967.issue3436@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Committed as revision 65605.

----------
assignee:  -> skip.montanaro
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3436>
_______________________________________

From report at bugs.python.org  Sat Aug  9 03:05:49 2008
From: report at bugs.python.org (Jim Sizelove)
Date: Sat, 09 Aug 2008 01:05:49 +0000
Subject: [issue3529] Remove long integer literals from Python 3.0 tutorial
In-Reply-To: <1218243949.59.0.896920703107.issue3529@psf.upfronthosting.co.za>
Message-ID: <1218243949.59.0.896920703107.issue3529@psf.upfronthosting.co.za>


New submission from Jim Sizelove <jimsize at gmail.com>:

The distinction between integers and long integers has been removed in
Python 3.0.  The attached patch file changes the long literals to Python
3.0 integer literals in the Floating Point Arithmetic section of the
tutorial.

----------
assignee: georg.brandl
components: Documentation
files: floatingpoint.diff
keywords: patch
messages: 70922
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Remove long integer literals from Python 3.0 tutorial
versions: Python 3.0
Added file: http://bugs.python.org/file11090/floatingpoint.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3529>
_______________________________________

From report at bugs.python.org  Sat Aug  9 04:26:15 2008
From: report at bugs.python.org (daishi)
Date: Sat, 09 Aug 2008 02:26:15 +0000
Subject: [issue3530] ast.NodeTransformer bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>


New submission from daishi <python at daishi.fastmail.fm>:

I am testing python 2.6 from SVN version: 40110

I tried the following, based on the documentation
and example in the ast module. I would expect the
second 'compile' to succeed also, instead of
throwing an exception.

Python 2.6b2+ (unknown, Aug  6 2008, 18:05:08) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> a = ast.parse('foo', mode='eval')
>>> x = compile(a, '<unknown>', mode='eval')
>>> class RewriteName(ast.NodeTransformer):
...     def visit_Name(self, node):
...         return ast.copy_location(ast.Subscript(
...             value=ast.Name(id='data', ctx=ast.Load()),
...             slice=ast.Index(value=ast.Str(s=node.id)),
...             ctx=node.ctx
...         ), node)
... 
>>> a2 = RewriteName().visit(a)
>>> x2 = compile(a2, '<unknown>', mode='eval')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: required field "lineno" missing from expr
>>>

----------
components: Library (Lib)
messages: 70923
nosy: daishiharada
severity: normal
status: open
title: ast.NodeTransformer bug
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sat Aug  9 04:29:45 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Sat, 09 Aug 2008 02:29:45 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

I wrote a buggy PNG parser which ended up doing several file.read(large 
value).  It causes a MemoryError, which was strange because the file was 
only a few KB long.

I tracked it down to the implementation of read().  When given a size 
hint it preallocates the return string with that size.  If the hint is 
for 10MB then the string returned will be preallocated fro 10MB, even if 
the actual read is empty.

Here's a reproducible

BLOCKSIZE = 10*1024*1024

f=open("empty.txt", "w")
f.close()

f=open("empty.txt")
data = []
for i in range(10000):
    s = f.read(BLOCKSIZE)
    assert len(s) == 0
    data.append(s)


I wasn't sure if this is properly a bug, but since the MemoryError 
exception I got was quite unexpected and required digging into the 
source code to figure out, I'll say that it is.

----------
components: Interpreter Core
messages: 70924
nosy: dalke
severity: normal
status: open
title: file read preallocs 'size' bytes which can cause memory problems
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Aug  9 11:39:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 09:39:08 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218274748.05.0.476882309663.issue3531@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't reproduce, your code snippet works fine. What Python version is it?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Aug  9 12:00:10 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Sat, 09 Aug 2008 10:00:10 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218276010.4.0.164156880709.issue3531@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

I tested it with Python 2.5 on a Mac, Python 2.5 on FreeBSD, and Python 
2.6b2+ (from SVN as of this morning) on a Mac.

Perhaps the memory allocator on your machine is making a promise it can't 
keep?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Aug  9 12:15:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 10:15:09 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218276909.0.0.538958986734.issue3531@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps. I'm under Linux.

However, at the end of the file_read() implementation in fileobject.c,
you can find the following lines:

if (bytesread != buffersize)
    _PyString_Resize(&v, bytesread);

Which means that the string *is* resized at the end.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Aug  9 12:41:54 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Aug 2008 10:41:54 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218278514.09.0.822862619653.issue3270@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

I confirmed this patch works on my win2000.
And I believe it works on Trent's machine, too.
http://mail.python.org/pipermail/python-dev/2008-June/080525.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Sat Aug  9 12:57:10 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 10:57:10 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218235611.41.0.14254205748.issue3526@psf.upfronthosting.co.za>
Message-ID: <1218279426.5764.2.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 08 ao?t 2008 ? 22:46 +0000, Martin v. L?wis a ?crit :
> Instead, Python's own memory allocate (obmalloc) should be changed to
> directly use the virtual memory interfaces of the operating system (i.e.
> mmap), bypassing the malloc of the C library.

How would that interact with fork()?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Sat Aug  9 13:26:56 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Sat, 09 Aug 2008 11:26:56 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218281216.04.0.602641395217.issue3531@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

You're right.  I mistook the string implementation for the list one 
which does keep a preallocated section in case of growth.  Strings of 
course don't grow so there's no need for that.

I tracked the memory allocation all the way down to 
obmalloc.c:PyObject_Realloc .  The call goes to realloc(p, nbytes) which 
is a C lib call.  It appears that the memory space is not reallocated.

That was enough to be able to find the python-dev thread "Darwin's 
realloc(...) implementation never shrinks allocations" from Jan. 2005, 
Bob Ippolito's post "realloc.. doesn?t?" 
(http://bob.pythonmac.org/archives/2005/01/01/realloc-doesnt/ ) and Issue1092502 .

Mind you, I also get the problem on FreeBSD 2.6 so it isn't Darwin 
specific.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Aug  9 13:31:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 11:31:41 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218281216.04.0.602641395217.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218281498.5764.4.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 09 ao?t 2008 ? 11:26 +0000, Andrew Dalke a ?crit :
> Mind you, I also get the problem on FreeBSD 2.6 so it isn't Darwin 
> specific.

Darwin and the BSD's supposedly share a lot of common stuff.
But FreeBSD 2.6 is a bit old, isn't it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Aug  9 17:27:48 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Aug 2008 15:27:48 +0000
Subject: [issue3501] expm1 missing
In-Reply-To: <1217888447.93.0.520646287679.issue3501@psf.upfronthosting.co.za>
Message-ID: <1218295668.18.0.842230787199.issue3501@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> marketdickinson
components: +Extension Modules -None
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3501>
_______________________________________

From report at bugs.python.org  Sat Aug  9 18:29:54 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 09 Aug 2008 16:29:54 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

I haven't been able to find a way to encode a bytes object in
hexadecimal, where in Python 2.x I'd go "str.encode('hex')".

I recommend adding a bytes.tohex() method (in the same vein as the
existing bytes.fromhex class method).

I've attached a patch which adds this method to the bytes and bytearray
classes (in the C code). Also included documentation and test cases.

Style note: The bytesobject.c and bytearrayobject.c files are all over
the place in terms of tabs/spaces. I used tabs in bytesobject and spaces
in bytearrayobject, since those seemed to be the predominant styles in
either file.

Commit log:

Added "tohex" method to bytes and bytearray objects. Also added
documentation and test cases.

----------
components: Interpreter Core
files: bytes.tohex.patch
keywords: patch
messages: 70932
nosy: mgiuca
severity: normal
status: open
title: bytes.tohex method
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file11091/bytes.tohex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sat Aug  9 18:31:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 16:31:01 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1218299461.22.0.936331776138.issue3492@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Any updates ? The py3k list is also very silent since the
> week-end...Thanks!

Your two patches look good, I suppose either Alexandre or I will commit
them soon. 
You shouldn't to worry when you don't get a reply immediately, people
react simply when they have time to do so. And as for the mailing-list
activity, we are in the beginning of August which I guess implies many
people are on holidays.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Sat Aug  9 18:42:07 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Sat, 09 Aug 2008 16:42:07 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1218300127.47.0.239817618167.issue3531@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

FreeBSD is why my hosting provider uses.  Freebsd.org calls 2.6 "legacy" 
but the latest update was earlier this year.

There is shared history with Macs.  I don't know the details though.  I 
just point out that the problem isn't only on Darwin.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Aug  9 18:46:11 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 09 Aug 2008 16:46:11 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

I wanted to use Py_DEBUG build to help debug a problem
with ref counts in a C++ extension.

I cannot find eprintf in the sources of python
where does this symbol come from? How do I fix the
build to define it?


$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S165

$ ./configure --enable-framework --enable-debug --with-pydebug
$ make
...
/usr/bin/install -c -d -m 755 Python.framework/Versions/3.0
if test ""; then \
        gcc -o Python.framework/Versions/3.0/Python  -dynamiclib \
                -isysroot "" \
                -all_load libpython3.0.a -Wl,-single_module \
                -install_name
/Library/Frameworks/Python.framework/Versions/3.0/Python \
                -compatibility_version 3.0 \
                -current_version 3.0; \
        else \
        /usr/bin/libtool -o Python.framework/Versions/3.0/Python
-dynamic  libpython3.0.a \
                 -lSystem -lSystemStubs -arch_only ppc -install_name
/Library/Frameworks/Python.framework/Versions/3.0/Python
-compatibility_version 3.0 -current_version 3.0 ;\
fi
ld: Undefined symbols:
___eprintf
/usr/bin/libtool: internal link edit command failed
make: *** [Python.framework/Versions/3.0/Python] Error 1

----------
components: Build
messages: 70935
nosy: barry-scott
severity: normal
status: open
title: mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Sat Aug  9 18:46:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 16:46:33 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1218300393.38.0.67653605853.issue3160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi Viktor,

It's complicated for me to test under Windows right now, but your
snippet looks buggy:

            script_data = open(self.pre_install_script, "r").read()
            cfgdata = cfgdata + script_data + b"\n\0"

script_data is an unicode string because the file is opened in text
mode, but you try to concatenate it with bytes objects which will fail.
Please try to fix this and provide a proper patch :-)

PS : I agree it is important to fix this.

----------
keywords: +patch
nosy: +pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Sat Aug  9 18:55:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 16:55:13 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218300913.16.0.887697233035.issue3362@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

locale.getpreferredencoding() should certainly not crash but the
question remains of what should be the outcome. I can see several
possibilities:
(1) return the empty string
(2) return None
(3) return "ascii" (!!)
(4) raise an exception (which one?)

(2) sounds the most logical to me, there is no preferred encoding in the
environment so we just return None to indicate that the application has
to choose its own default.

----------
nosy: +pitrou
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Sat Aug  9 18:55:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 16:55:59 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218300959.09.0.611159673809.issue3362@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:06:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 17:06:31 +0000
Subject: [issue3253] shutil.move bahave unexpected in fat32
In-Reply-To: <1214933709.34.0.0595495782723.issue3253@psf.upfronthosting.co.za>
Message-ID: <1218301591.92.0.741471920487.issue3253@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is already fixed in the trunk (which will become Python 2.6).

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3253>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:23:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 17:23:57 +0000
Subject: [issue3205] bz2 iterator fails silently on MemoryError
In-Reply-To: <1214471301.68.0.267247122126.issue3205@psf.upfronthosting.co.za>
Message-ID: <1218302637.92.0.958519485264.issue3205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65609. Thanks for the report and for the patch!

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3205>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:28:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Aug 2008 17:28:34 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218279426.5764.2.camel@fsol>
Message-ID: <489DD322.6010703@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Instead, Python's own memory allocate (obmalloc) should be changed to
>> directly use the virtual memory interfaces of the operating system (i.e.
>> mmap), bypassing the malloc of the C library.
> 
> How would that interact with fork()?

Nicely, why do you ask? Any anonymous mapping will be copied
(typically COW) to the child process, in fact, malloc itself
uses anonymous mapping (at least on Linux).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:30:20 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Aug 2008 17:30:20 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218303020.68.0.921931119579.issue3362@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No, getpreferredencoding should always produce an encoding name. If the
application had an idea what to use, it wouldn't have to ask. So I favor
(3), or, perhaps given that OSX uses UTF-8 in many places,

(5) return "UTF-8"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:32:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Aug 2008 17:32:04 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218303124.1.0.43435960714.issue3533@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Are you sure you are using the correct compiler (i.e. from the XCode
release relevant for your operating system version)?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:35:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 17:35:58 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1218303358.46.0.474564395925.issue3187@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, I suppose that while the filename is latin1-encoded,
Py_FileSystemDefaultEncoding is "utf-8" and therefore os.listdir fails
decoding the filename and falls back on returning a byte string.
It was acceptable in Python 2.x but is a very annoying problem in py3k
now that unicode and bytes objects can't be mixed together anymore. I'm
bumping this to critical, although there is probably no clean solution.

----------
nosy: +pitrou
priority:  -> critical
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:36:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Aug 2008 17:36:27 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218303387.89.0.161843948501.issue3532@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I recommend to use binascii.hexlify; this works in all Python version
(since 2000 or so).

I'm -1 for this patch.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sat Aug  9 19:54:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 17:54:53 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <489DD322.6010703@v.loewis.de>
Message-ID: <1218304426.5832.6.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 09 ao?t 2008 ? 17:28 +0000, Martin v. L?wis a ?crit :
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> >> Instead, Python's own memory allocate (obmalloc) should be changed to
> >> directly use the virtual memory interfaces of the operating system (i.e.
> >> mmap), bypassing the malloc of the C library.
> > 
> > How would that interact with fork()?
> 
> Nicely, why do you ask?

Because I didn't know :)
But looking at the dlmalloc implementation bundled in the patch, it
seems that using mmap/munmap (or VirtualAlloc/VirtualFree under Windows)
should be ok.

Do you think we should create a separate issue for this improvement? It
could also solve #3531.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Sat Aug  9 20:05:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 18:05:30 +0000
Subject: [issue3134] shutil references undefined WindowsError symbol
In-Reply-To: <1213822190.13.0.727070543552.issue3134@psf.upfronthosting.co.za>
Message-ID: <1218305130.5.0.909341913138.issue3134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Raghuram, your patch looks good to me. I'll try to test it under Windows
soon.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3134>
_______________________________________

From report at bugs.python.org  Sat Aug  9 20:10:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Aug 2008 18:10:58 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1218305458.29.0.734346413092.issue3080@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> critical
type:  -> behavior
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Sat Aug  9 20:17:13 2008
From: report at bugs.python.org (Roger Upole)
Date: Sat, 09 Aug 2008 18:17:13 +0000
Subject: [issue3534] refactor.py can lose indentation for relative imports
In-Reply-To: <1218305833.19.0.0391754178644.issue3534@psf.upfronthosting.co.za>
Message-ID: <1218305833.19.0.0391754178644.issue3534@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

Here's an excerpt from the output when run with --verbose.

@@ -138,7 +136,7 @@

        def _MakeColorizer(self):
                ext = os.path.splitext(self.GetDocument().GetPathName())
-               import formatter
+from . import formatter
                return formatter.BuiltinPythonSourceFormatter(self, ext)

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 70947
nosy: collinwinter, rupole
severity: normal
status: open
title: refactor.py can lose indentation for relative imports
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3534>
_______________________________________

From report at bugs.python.org  Sat Aug  9 20:26:19 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 09 Aug 2008 18:26:19 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218306379.24.0.287240596762.issue3532@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> I recommend to use binascii.hexlify.

Ah, see I did not know about this! Thanks for pointing it out.

* However, it is *very* obscure. I've been using Python for a year and I
didn't know about it.
* And, it requires importing binascii.
* And, it results in a bytes object, not a str. That's weird. (Perhaps
it would be good idea to change the functions in the binascii module to
output strings instead of bytes? Ostensibly it looks like this module
hasn't undergone py3kification).

Would it hurt to have the tohex method of the bytes object to perform
this task as well? It would be much nicer to use since it's a method of
the object rather than having to find out about and import and use some
function.

Also why have a bytes.fromhex method when you could use binascii.unhexlify?

(If it's better from a code standpoint, you could replace the code I
wrote with a call to binascii.unhexlify).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sat Aug  9 20:34:24 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 09 Aug 2008 18:34:24 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218306864.44.0.78350530603.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Bill, I had a look at your patch. I see you've decided to make
quote_as_string the default? In that case, I don't know why you had to
rewrite everything to implement the same basic behaviour as my patch.
(My latest few patches support bytes both ways). Anyway, I have a lot of
issues with your implementation.

* Why did you replace all of the existing machinery? Particularly the
way quote creates Quoter objects and stores them in a cache. I haven't
done any speed tests, but I assume that was all there for performance
reasons.

* The idea of quote_as_bytes is malformed. quote_as_bytes takes a str or
bytes, and outputs a URI as a bytes, while quote_as_string outputs a URI
as a str. This is the first time in the whole discussion we've
represented a URI as bytes, not a str. URIs are not byte sequences, they
are character sequences (see discussion below). I think only
quote_as_string is valid.

* The names unquote_as_* and quote_as_* are confusing. Use unquote_to_*
and quote_from_* to avoid ambiguity.

* Are unquote_as_string and unquote both part of your public interface?
That seems like unnecessary duplication.

* As Antoine pointed out above, it's too limiting for quote to force
UTF-8. Add a 'charset' parameter.

* Add an 'errors' parameter too, to give the caller control over how
strict to be.

* unquote and unquote_plus are missing 'charset' param, which should be
passed along to unquote_as_string.

* I do like the addition of a "plus" argument, as opposed to the
separate unquote_plus and quote_plus functions. I'd swap the arguments
to unquote around so charset is first and then plus, so you can write
unquote(mystring, 'utf-8') without using a keyword argument.

* In unquote: The "raw_unicode_escape" encoding makes no sense. It does
exactly the same thing as Latin-1, except it also looks for b"\\uxxxx"
in the string and converts that into a Unicode character. So your code
behaves like this:

>>> urllib.parse.unquote('%5Cu00fc')
'?'
(Should output "\u00fc")
>>> urllib.parse.unquote('%5Cu')
UnicodeDecodeError: 'rawunicodeescape' codec can't decode bytes in
position 11-12: truncated \uXXXX
(Should output "\u")

I suspect the email package (where you got the inspiration to use
'rawunicodeescape') has this same crazy problem, but that isn't my
concern today!

Aside from this weirdness, you're essentially defaulting unquote to
Latin-1. As I've said countless times, unquote needs to be the inverse
of quote, or you get this behaviour:

>>> urllib.parse.unquote(urllib.parse.quote('?'))
'??'

Once again, I refer you to my favourite web server example.

import http.server
s = http.server.HTTPServer(('',8000),
        http.server.SimpleHTTPRequestHandler)
s.serve_forever()

Run this in a directory with a non-Latin-1 filename (eg. "??"), and
you will get a 404 when you click on the file.

* One issue I worked very hard to solve is how to deal with unescaped
non-ASCII characters in unquote. Technically this is an invalid URI, so
I'm not sure how important it is, but it's nice to be able to assume the
unquote function won't mess with them. For example,
unquote_as_string("\u6f22%C3%BC", charset="latin-1") should give
"\u6f22\u00fc" (or at least it would be nice). Yours raises
"UnicodeEncodeError: 'ascii' codec can't encode character". (I assume
this is a wanted property, given that the existing test suite tests that
unquote can handle ALL unescaped ASCII characters (that's what
escape_string in test_unquoting is for) - I merely extend this concept
to be able to handle all unescaped Unicode characters). Note that it's
impossible to allow such lenience if you implement unquote_as_string as
calling unquote_as_bytes and then decoding.

* Question: How does unquote_bytes deal with unescaped characters?
(Since this is a str->bytes transform, you need to encode them somehow).
I don't have a good answer for you here, which is one reason I think
it's wrong to treat a URI as an octet encoding. I treat them as UTF-8.
You treat them as ASCII. Since URIs are supposed to only contain ASCII,
the answers "ASCII", "Latin-1" and "UTF-8" are all as good as each
other, but as I said above, I prefer to be lenient and allow non-ASCII
URIs as input.

* Needs a lot more test cases, and documentation for your changes. I
suggest you plug my new test cases for urllib in and see if you can make
your code pass all the things I test for (and if not, have a good reason).

In addition, a major problem I have is with this dangerous assumption
that RFC 3986 specifies a byte->str encoding. You keep stating
assumptions like this:

> Remember that the RFC for percent-encoding really takes
> bytes in, and produces bytes out.  The string-in and string-out
> versions are to support naive programming (what a nice way of
> putting it!).

You assume that my patch, the string version of quote/unquote, is a
"hack" in order to satisfy the naive souls who only want to deal with
strings, while your method is the "pure and correct" solution. This is
in no way certain.

It is clear from reading RFC 3986 that URIs are characters, not octets
(that's not debatable - as we see URIs written on billboards, they're
definately characters). What *is* debatable is whether the source data
for a URI is a character or a byte. I'm arguing it can be either.

The process of percent-encoding is taking a character, converting it
into an octet, and percent-encoding that octet into a 3-character
sequence. I quote:

> Percent-encoded octets may be used within a URI to represent
> characters outside the range of the US-ASCII coded character set
> if this representation is allowed by the scheme or by the protocol
> element in which the URI is referenced.  Such a definition should
> specify the character encoding used to map those characters to
> octets prior to being percent-encoded for the URI.

It could not be clearer that the RFC allows us to view percent encoding
as a str->str transform.

I also see later on (in section 2.1) the RFC talking about "data octets"
being percent-encoded, so I assume it's also valid to speak about a
bytes->str transform.

Therefore, I believe my quote and unquote are as correct as can be with
respect to the RFC, and I've also supplied unquote_to_bytes and
quote_from_bytes to satisfy the other (IMHO less clear, and certainly
less useful) reading of the RFC.

You seem to have arrived at the same outcome, but from a very different
standpoint that your unquote_as_bytes is "correct" and unquote_as_string
is a nasty hack.

Bill:
> Barring any other information, I think that the "segments" in the
> path of an "http" URL must also be assumed to be binary; that is,
> any octet is allowed, and no character set can be presumed.

Once again, practicality beats purity. Segments in HTTP URLs usually
refer to file paths. Files (in all modern operating systems) are Unicode
filenames, not byte filenames. So you HAVE to assume the character set
at some point. The best assumption we can make (as shown by all the
major browsers' defaults) is UTF-8.

> So this probably indicates a bug in urllib.parse:
> urllib.parse.urlparse(<snip>)
> should throw an exception somewhere.

No, this is just assuming the behaviour of unquote (which is called by
urlparse) to preserve unescaped characters as-is. So this "bug" is
actually in your own implementation of unquote (and mine too). But I
refute that that's desirable behaviour. I think you SHOULD NOT have
removed that test case. It is indicating a bug in your code (which is
what it's there for).

Look, I'm sorry to be so harsh, but I don't see what this alternative
patch accomplishes. My analysis probably comes off as self-righteous,
but then, I've spent the past month reading documentation and testing
every aspect of this issue rigorously, and all I see is you ignoring all
my work and rewriting it in a less-robust way.

Your point here was to make the str->bytes and bytes->str versions of
unquote and quote, respectively, work, right? Well I've already got
those working too. Please tell me what you think of my implementation so
we can get it approved before the deadline.

Matt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sat Aug  9 20:44:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Aug 2008 18:44:28 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218306379.24.0.287240596762.issue3532@psf.upfronthosting.co.za>
Message-ID: <489DE589.7060209@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> * However, it is *very* obscure. I've been using Python for a year and I
> didn't know about it.

Hmm. There are probably many modules that you haven't used yet.

> * And, it requires importing binascii.

So what? The desire to convert bytes into hex strings is infrequent
enough to leave it out of the realm of a method. Also, Guido has
pronounced that he prefers functions over methods (and in this case,
I agree)

Using functions is more extensible. If you wanted to produce base-85
(say), then you can extend the functionality of bytes by providing a
function that does that, whereas you can't extend the existing bytes
type.

> * And, it results in a bytes object, not a str. That's weird. (Perhaps
> it would be good idea to change the functions in the binascii module to
> output strings instead of bytes? Ostensibly it looks like this module
> hasn't undergone py3kification).

There has been endless debates on this (or, something similar to this),
revolving around the question: "is base-64 text or binary"?

> Would it hurt to have the tohex method of the bytes object to perform
> this task as well?

IMO, yes, it would. It complicates the code, and draws the focus away
from the proper approach to data conversion (namely, functions - not
methods).

> It would be much nicer to use since it's a method of
> the object rather than having to find out about and import and use some
> function.

That's highly debatable.

> Also why have a bytes.fromhex method when you could use binascii.unhexlify?

Good point.

In any case, this is my opion; feel free to discuss this on python-dev.

Very clearly it is too late to add this for 3.0 now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sat Aug  9 20:44:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Aug 2008 18:44:44 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218307484.55.0.705874339742.issue3532@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sat Aug  9 21:02:51 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 09 Aug 2008 19:02:51 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218308571.88.0.435602617562.issue3533@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

As far as I know I'm using the Xcode compiler. Does this match
your expectations?

$ which gcc
/usr/bin/gcc

$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5341.obj~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5341)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Sun Aug 10 02:12:17 2008
From: report at bugs.python.org (Viktor Ferenczi)
Date: Sun, 10 Aug 2008 00:12:17 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1218327137.83.0.826812594767.issue3160@psf.upfronthosting.co.za>


Viktor Ferenczi <python at cx.hu> added the comment:

Thanks. Good point. :-)

I did not find that bug, since pre_install_script is not defined for my
project. Sorry, it is my fault. I did not test my patch deep enough.

I need to know one more thing before providing a better patch:

What is the expected encoding of the pre_install_script file?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Sun Aug 10 02:18:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Aug 2008 00:18:29 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1218327509.16.0.743039650993.issue3187@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Let's make this a release blocker for RCs.

----------
priority: critical -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sun Aug 10 02:26:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Aug 2008 00:26:36 +0000
Subject: [issue3534] refactor.py can lose indentation for relative imports
In-Reply-To: <1218305833.19.0.0391754178644.issue3534@psf.upfronthosting.co.za>
Message-ID: <1218327996.81.0.127194936656.issue3534@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

What version of 2to3 are you using? AFAIK, this has been fixed in the trunk.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3534>
_______________________________________

From report at bugs.python.org  Sun Aug 10 02:35:12 2008
From: report at bugs.python.org (Jim Jewett)
Date: Sun, 10 Aug 2008 00:35:12 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218328512.04.0.38331607788.issue3300@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

Matt,

Bill's main concern is with a policy decision; I doubt he would object to 
using your code once that is resolved.

The purpose of the quoting functions is to turn a string (representing the 
human-readable version) into bytes (that go over the wire).  If everything 
is ASCII, there isn't any disagreement -- but it also isn't obvious that 
they're bytes instead of characters.  So people started (well, continued, 
since it dates to pre-unicode C) treating them as though they were strings.

The fact that ASCII (and therefore most wire protocols) looks the same as 
bytes or as characters was one of the strongest arguments against splitting 
the bytes and string types.  Now that this has been done, Bill feels we 
should be consistent.  (You feel wire-protocol bytes should be treated as 
strings, if only as bytestrings, because the libraries use them that way -- 
but this is a policy decision.)

To quote the final paragraph of 1.2.1
"""
 In local or regional contexts and with improving technology, users
   might benefit from being able to use a wider range of characters;
   such use is not defined by this specification.  Percent-encoded
   octets (Section 2.1) may be used within a URI to represent characters
   outside the range of the US-ASCII coded character set if this
   representation is allowed by the scheme or by the protocol element in
   which the URI is referenced.  Such a definition should specify the
   character encoding used to map those characters to octets prior to
   being percent-encoded for the URI.
"""

So the mapping to bytes (or "octets") for non-ASCII isn't defined (here), 
and if you want to use it, you need to specify charset.  But in practice, 
people do use it without specifying a charset.  Which charset should be 
assumed?  The old code (and test cases) assumed Latin-1.  You want to 
assume UTF-8 (though you took the document charset when available -- which 
might also make sense).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Aug 10 03:45:10 2008
From: report at bugs.python.org (Roger Upole)
Date: Sun, 10 Aug 2008 01:45:10 +0000
Subject: [issue3534] refactor.py can lose indentation for relative imports
In-Reply-To: <1218305833.19.0.0391754178644.issue3534@psf.upfronthosting.co.za>
Message-ID: <1218332710.4.0.18009192898.issue3534@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

I was using 3.0b2.
The output is correct with latest updates,
sorry for the trouble.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3534>
_______________________________________

From report at bugs.python.org  Sun Aug 10 03:45:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Aug 2008 01:45:53 +0000
Subject: [issue3534] refactor.py can lose indentation for relative imports
In-Reply-To: <1218305833.19.0.0391754178644.issue3534@psf.upfronthosting.co.za>
Message-ID: <1218332753.08.0.399687164625.issue3534@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3534>
_______________________________________

From report at bugs.python.org  Sun Aug 10 04:47:52 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 02:47:52 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218336472.04.0.771071251677.issue3532@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

You did the 3.1 thing again! We can accept a new feature like this
before 3.0b3, can we not?

> Hmm. There are probably many modules that you haven't used yet.

Snap :)

Well, I didn't know about the community's preference for functions over
methods. You make a lot of good points.

I think the biggest problem I have is the existence of fromhex. It's
really strange/inconsistent to have a fromhex without a tohex.

Also I think a lot of people (like me, in my relative inexperience) are
going to be at a loss as to why .encode('hex') went away, and they'll
easily be able to find .tohex (by typing help(bytes), or just guessing),
while binascii.hexlify is sufficiently obscure that I had to ask.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 05:09:55 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 03:09:55 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218337795.42.0.906599600861.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> Bill's main concern is with a policy decision; I doubt he would
> object to using your code once that is resolved.

But his patch does the same basic operations as mine, just implemented
differently and with the heap of issues I outlined above. So it doesn't
have anything to do with the policy decision.

> The purpose of the quoting functions is to turn a string
> (representing the human-readable version) into bytes (that go
> over the wire).

Ah hang on, that's a misunderstanding. There is a two-step process involved.

Step 1. Translate <character/byte> string into an ASCII character string
by percent-encoding the <characters/bytes>. (If percent-encoding
characters, use an unspecified encoding).
Step 2. Serialize the ASCII character string into an octet sequence to
send it over the wire, using some unspecified encoding.

Step 1 is explained in detail throughout the RFC, particularly in
Section 1.2.1 Transcription ("Percent-encoded octets may be used within
a URI to represent characters outside the range of the US-ASCII coded
character set") and 2.1 Percent Encoding.

Step 2 is not actually part of the spec (because the spec outlines URIs
as character sequences, not how to send them over a network). It is
briefly described in Section 2 ("This specification does not mandate any
particular character encoding for mapping between URI characters and the
octets used to store or transmit those characters.  When a URI appears
in a protocol element, the character encoding is defined by that protocol").

Section 1.2.1:

> A URI may be represented in a variety of ways; e.g., ink on
> paper, pixels on a screen, or a sequence of character
> encoding octets.  The interpretation of a URI depends only on
> the characters used and not on how those characters are
> represented in a network protocol.

The RFC then goes on to describe a scenario of writing a URI down on a
napkin, before stating:

> A URI is a sequence of characters that is not always represented
> as a sequence of octets.

Right, so there is no debate that a URI (after percent-encoding) is a
character string, not a byte string. The debate is only whether it's a
character or byte string before percent-encoding.

Therefore, the concept of "quote_as_bytes" is flawed.

> You feel wire-protocol bytes should be treated as
> strings, if only as bytestrings, because the libraries use them
> that way.

No I do not. URIs post-encoding are character strings, in the Unicode
sense of the term "character". This entire topic has nothing to do with
the wire.

Note that the "charset" or "encoding" parameter in Bill/My patch
respectively isn't the mapping from URI strings to octets (that's
trivially ASCII). It's the charset used to encode character information
into octets which then get percent-encoded.

> The old code (and test cases) assumed Latin-1.

No, the old code and test cases were written for Python 2.x. They
assumed a byte string was being emitted (back when a byte string was a
string, so that was an acceptable output type). So they weren't assuming
an encoding. In fact the *ONLY* test case for Unicode in test_urllib
used a UTF-8-encoded string.

> r = urllib.parse.unquote('br%C3%BCckner_sapporo_20050930.doc')
> self.assertEqual(r, 'br\xc3\xbcckner_sapporo_20050930.doc')

In Python 2.x, this test case says "unquote('%C3%BC') should give me the
byte sequence '\xc3\xbc'", which is a valid case. In Python 3.0, the
code didn't change but the meaning subtly did. Now it says
"unquote('%C3%BC') should give the string '??'". The name is clearly
supposed to be "br?ckner", not "br??ckner", which means in Python 3.0 we
should EITHER be expecting the BYTE string b'\xc3\xbc' or the character
string '?'.

So the old code and test cases didn't assume any encoding, then they
were accidentally made to assume Latin-1 by the fact that the language
changed underneath them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Aug 10 07:05:09 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 05:05:09 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218344709.3.0.965800855029.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

I've been thinking more about the errors="strict" default. I think this
was Guido's suggestion. I've decided I'd rather stick with errors="replace".

I changed errors="replace" to errors="strict" in patch 8, but now I'm
worried that will cause problems, specifically for unquote. Once again,
all the code in the stdlib which calls unquote doesn't provide an errors
option, so the default will be the only choice when using these other
services.

I'm concerned that there'll be lots of unhandled exceptions flying
around for URLs which aren't encoded with UTF-8, and a conscientious
programmer will not be able to protect against user errors.

Take the cgi module as an example. Typical usage is to write:
> fields = cgi.FieldStorage()
> foo = fields.getFirst("foo")

If the QUERY_STRING is "foo=w%FCt" (Latin-1), with errors='strict', you
get a UnicodeDecodeError when you call cgi.FieldStorage(). With
errors='replace', the variable foo will be "w?t". I think in general I'd
rather have '?'s in my program (representing invalid user input) than
exceptions, since this is usually a user input error, not a programming
error.

(One problem is that all I can do to handle this is catch a
UnicodeDecodeError on the call to FieldStorage; then I can't access any
of the data).

Now maybe something we can think about is propagating the "encoding" and
"errors" argument through to a few other major functions (such as
cgi.parse_qsl, cgi.FieldStorage and urllib.parse.urlencode), but that
should be separately to this patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Aug 10 08:10:26 2008
From: report at bugs.python.org (Senthil)
Date: Sun, 10 Aug 2008 06:10:26 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1218348626.77.0.689326146971.issue2827@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I was NOT able to Reproduce it in IDLE 3.0b2 running on Linux. Would you
like to try with 3.0b2 and also do.

tjreedy: I did not properly get your comment. When you open Idle
instance and create a new Document, cut-paste the code, and Run. The
Execution happens in the IDLE instance which was running. No need of
input() call.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Sun Aug 10 08:49:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Aug 2008 06:49:39 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218336472.04.0.771071251677.issue3532@psf.upfronthosting.co.za>
Message-ID: <489E8F80.2020300@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You did the 3.1 thing again! We can accept a new feature like this
> before 3.0b3, can we not?

Not without explicit approval by the release manager, no (or by BDFL
pronouncement).

The point of the betas is that *only* bugs get fixed, and *no* new
are features added.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 09:05:47 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 07:05:47 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218351947.75.0.785102512508.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Guido suggested that quote's "safe" parameter should allow any
character, not just ASCII range. I've implemented this now. It was a lot
messier than I imagined.

The problem is that in my older patches, both 's' and 'safe' are encoded
to bytes right away, and the rest of the process is just octet encoding
(matching each byte against the safe set to see whether or not to quote it).

The new implementation requires that you delay encoding both of these
till the iteration over the string, so you match each *character*
against the safe set, then encode it if it's not in 'safe'. Now the
problem is some encodings/errors produce bytes which are in the safe
range. For instance quote('\u6f22', encoding='latin-1',
errors='xmlcharrefreplace') should give "%26%2328450%3B" (which is
"&#28450;" encoded). To preserve this behaviour, you then have to check
each *byte* of the encoded character against a 'safe bytes' set. I
believe that will slow down the implementation considerably.

In summary, it requires two levels of encoding: first characters, then
bytes. You can see how messy it made my quote implementation - I've
attached the patch (parse.py.patch8+allsafe).

I don't think it's worth the extra code bloat and performance hit just
to implement a feature whose only use is producing invalid URIs (since
URIs are supposed to only have ASCII characters). Does anyone disagree,
and want this feature in?

Added file: http://bugs.python.org/file11092/parse.py.patch8+allsafe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Aug 10 09:13:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Aug 2008 07:13:06 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218352386.85.0.145324951457.issue3533@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This might be a duplicate of issue 1099. Can you try building with
--enable-universalsdk ?

__eprintf should have been defined in libgcc, or else assert() should
not call it. To investigate this further, you should determine how many
copies of assert.h you have, whether they all refer to __eprintf, how
many copies of libgcc you have, whether they all define __eprintf, and
which header file and which library gets used.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Sun Aug 10 09:17:23 2008
From: report at bugs.python.org (Senthil)
Date: Sun, 10 Aug 2008 07:17:23 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1218352643.1.0.697534056051.issue3160@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

>> What is the expected encoding of the pre_install_script file?
I think, the pre_install_script will be provided by the user.
It would be safe to assume "UTF-8" for the encoding of pre_install_script

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Sun Aug 10 09:45:18 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 07:45:18 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218354318.21.0.312780120674.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Made a bunch of requested changes (I've reverted the "all safe" patch
for now since it caused so much grief; see above).

* quote: Fixed encoding illegal % sequences (and lots of new test cases
to prove it).
* quote now throws a type error if s is bytes, and encoding or errors
supplied.
* A few minor documentation fixes.

Patch 9.
Commit log for patch8 should suffice.

Added file: http://bugs.python.org/file11093/parse.py.patch9

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Aug 10 10:15:17 2008
From: report at bugs.python.org (Senthil)
Date: Sun, 10 Aug 2008 08:15:17 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <20080810081452.GB1142@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

* scriptor Matt Giuca, explico 
> 
> I think the biggest problem I have is the existence of fromhex. It's
> really strange/inconsistent to have a fromhex without a tohex.

Except, when we look at the context. This is bytes class
method returns a bytes or bytearray object, decoding the given string object.

Do we require an opposite in the bytes class method? Where will we use it?
> 
> Also I think a lot of people (like me, in my relative inexperience) are
> going to be at a loss as to why .encode('hex') went away, and they'll

No, it is not going away. str.encode('hex') is available to users when they
seek it. They wont look for it under bytes type.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 10:37:36 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 08:37:36 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218357456.16.0.0408878914182.issue3532@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> Except, when we look at the context. This is bytes class
> method returns a bytes or bytearray object, decoding the given
> string object.

> Do we require an opposite in the bytes class method? Where will
> we use it?
No, tohex is not a class method (unlike fromhex). It's just a regular
method on the bytes object.

> No, it is not going away. str.encode('hex') is available to
> users when they seek it. They wont look for it under bytes type.

>>> 'hello'.encode('hex')
LookupError: unknown encoding: hex

This is deliberate, I'm pretty sure. encode/decode are for converting
to/from unicode strings and bytes. It never made sense to have "hex" in
there, which actually goes the other way. And it makes no sense to
encode a Unicode string as hex (since they aren't bytes). So it's good
that that went away.

I'm just saying it should have something equally accessible to replace it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 11:27:28 2008
From: report at bugs.python.org (alonwas)
Date: Sun, 10 Aug 2008 09:27:28 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>


New submission from alonwas <alon.was at gmail.com>:

zipfile complains about "Bad magic number for central directory" when I
give it files over 2GB. I believe the problem is that the offset for the
central directory should be read as an unsigned long rather than as a
signed long. Modifying structEndArchive from "<4s4H2lH" to "<4s4H2LH"
(note the capital L) should probably fix it. When the offset is >2^31
you get a negative offset and the code fails to find the central
directory. I'll appreciate it if someone more knowledgeable looks at the
problem and the suggested fix, Thanks, Alon

----------
components: Library (Lib)
messages: 70968
nosy: alonwas
severity: normal
status: open
title: zipfile has problem reading zip files over 2GB
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Sun Aug 10 12:50:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Aug 2008 10:50:03 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218351947.75.0.785102512508.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218365389.5894.15.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 10 ao?t 2008 ? 07:05 +0000, Matt Giuca a ?crit :
> I don't think it's worth the extra code bloat and performance hit just
> to implement a feature whose only use is producing invalid URIs (since
> URIs are supposed to only have ASCII characters).

Agreed.

> If the QUERY_STRING is "foo=w%FCt" (Latin-1), with errors='strict', you
> get a UnicodeDecodeError when you call cgi.FieldStorage(). With
> errors='replace', the variable foo will be "w?t". I think in general I'd
> rather have '?'s in my program (representing invalid user input) than
> exceptions, since this is usually a user input error, not a programming
> error.

Invalid user input? What if the query string comes from filling a form?
For example if I search the word "num?ro" in a latin1 Web site, I get
the following URL:
http://www.le-tigre.net/spip.php?page=recherche&recherche=num%E9ro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Aug 10 13:26:26 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 11:26:26 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218367586.43.0.507851434689.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> Invalid user input? What if the query string comes from filling
> a form?
> For example if I search the word "num?ro" in a latin1 Web site,
> I get the following URL:
> http://www.le-tigre.net/spip.php?page=recherche&recherche=num%E9ro

Yes, that is a concern. I suppose the idea should be that as the
programmer _you_ write the website, so you make it UTF-8 and you use our
defaults. Or you make it Latin-1, and you override our defaults (which
is tricky if you use cgi.FieldStorage, for example).

But anyway, how do you propose to handle that (other than the programmer
setting the correct default). With errors='replace', the above query
will result in "num?ro", but with errors='strict', it will result in a
UnicodeDecodeError (which you could handle, if you remembered). As a
programmer I don't really want to handle that error every time I use
unquote or anything that calls unquote. I'd rather accept the
possibility of '?'s in my input.

I'm not going to dig in my heels though, this time :) I just want to
make sure the consequences of this decision are known before we commit.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Sun Aug 10 13:33:07 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Sun, 10 Aug 2008 11:33:07 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1218367987.87.0.19115985445.issue1342811@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Fixed in r65622. Backported to the release25-maint and merged into the
py3k branch.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:06:32 2008
From: report at bugs.python.org (=?utf-8?q?Ozan_=C3=87a=C4=9Flayan?=)
Date: Sun, 10 Aug 2008 12:06:32 +0000
Subject: [issue3536] case conversion problems in Turkish
In-Reply-To: <1218369992.36.0.178922687211.issue3536@psf.upfronthosting.co.za>
Message-ID: <1218369992.36.0.178922687211.issue3536@psf.upfronthosting.co.za>


New submission from Ozan ?a?layan <ozancag at gmail.com>:

>>> sys.getdefaultencoding()
'utf-8'

>>> s = 'i?'
>>> s.upper()
'II' # should be '?I'

>>> t = 'I?'
>>> t.lower()
'ii' # should be '?i'

>>> unicodedata.name('?')      # The small dotless one
'LATIN SMALL LETTER DOTLESS I'
>>> unicodedata.name('I')      # The capital dotless one
'LATIN CAPITAL LETTER I'


>>> unicodedata.name('i')      # The small 'i'
'LATIN SMALL LETTER I'
>>> unicodedata.name('?')      # The corresponding capital one
'LATIN CAPITAL LETTER I WITH DOT ABOVE'

The other non-ascii turkish characters '??????????' are correctly
handled by case conversion methods.

----------
components: Unicode
messages: 70972
nosy: ozan
severity: normal
status: open
title: case conversion problems in Turkish
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3536>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:16:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 12:16:57 +0000
Subject: [issue3529] Remove long integer literals from Python 3.0 tutorial
In-Reply-To: <1218243949.59.0.896920703107.issue3529@psf.upfronthosting.co.za>
Message-ID: <1218370617.95.0.680005866705.issue3529@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r65627.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3529>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:20:31 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 12:20:31 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218370831.46.0.417830125136.issue3532@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is why we will get transform() and untransform() in 3.1.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:22:18 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 12:22:18 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218370938.55.0.262778586802.issue3532@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Oh, where's the information on those?

(A brief search of the peps and bug tracker shows nothing).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:24:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 12:24:41 +0000
Subject: [issue3536] case conversion problems in Turkish
In-Reply-To: <1218369992.36.0.178922687211.issue3536@psf.upfronthosting.co.za>
Message-ID: <1218371081.83.0.0555850418117.issue3536@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Being Unicode strings, Py3k strings use the Unicode database's
lowercase<->uppercase mapping, which is not context sensitive.

See #1528802 for more discussion.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3536>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:24:45 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Aug 2008 12:24:45 +0000
Subject: [issue1288615] Python code.interact() and UTF-8 locale
Message-ID: <1218371085.58.0.361124502322.issue1288615@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

@kmtracey: Great and thanks! Three years later, the bug is finally 
fixed :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288615>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:26:23 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 12:26:23 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218371183.17.0.141448962324.issue3532@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

At the moment, mails on python-dev are the only source of information :)

Look here:
http://mail.python.org/pipermail/python-3000/2008-August/014533.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:31:46 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 12:31:46 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218371506.93.0.317389955405.issue3532@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

OK thanks.

Well I still can't really see what transform/untransform are about. Is
it OK to keep this issue open (and listed as 3.1) until more information
becomes available on those methods?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:42:51 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 12:42:51 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218372171.72.0.196291996368.issue3532@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

They are meant to replace encode/decode for those 2.x codecs that didn't
really encode/decode Unicode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:45:15 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 10 Aug 2008 12:45:15 +0000
Subject: [issue3532] bytes.tohex method
In-Reply-To: <1218299394.34.0.421334599583.issue3532@psf.upfronthosting.co.za>
Message-ID: <1218372315.12.0.197634675498.issue3532@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

So I assumed.

In that case, why is there a "fromhex"? (Was that put in there before
the notion of transform/untransform?) As I've been saying, it's weird to
have a fromhex but not a tohex.

Anyway, assuming we go to 3.1 and add transform/untransform, I suppose
fromhex will remain for backwards, and tohex will not be needed. So I
guess this issue is closed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3532>
_______________________________________

From report at bugs.python.org  Sun Aug 10 14:52:40 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Sun, 10 Aug 2008 12:52:40 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1218372760.3.0.38822203509.issue2578@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

Is there anything that can be done now about this issue? like renaming
the API and leaving the old names as aliases? If so, let me know and
I'll try to work on it.

----------
nosy: +pupeno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
_______________________________________

From report at bugs.python.org  Sun Aug 10 17:54:30 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 10 Aug 2008 15:54:30 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218383670.3.0.154747986463.issue3533@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

I have Xcode 2.3 which is quite old.
Simple program to test assert works with my current setup.

I'm going to update to Xcode 2.5 and see what happens.
I'll report back once I've installed and rebuild python.

Added file: http://bugs.python.org/file11094/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Sun Aug 10 19:20:35 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 10 Aug 2008 17:20:35 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218388835.84.0.836721001751.issue3533@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

Xcode 2.5 solves the build issue.

I suspect you can close the 1099 saying use Xcode 2.5.

I think you can only get 2.5 by login in to the Apple developer site.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Sun Aug 10 19:21:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 17:21:30 +0000
Subject: [issue3097] sphinx: config option for exclude_dirnames
In-Reply-To: <1213307873.74.0.0842689115594.issue3097@psf.upfronthosting.co.za>
Message-ID: <1218388890.79.0.755173856265.issue3097@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added in r65632.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3097>
_______________________________________

From report at bugs.python.org  Sun Aug 10 19:29:45 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Aug 2008 17:29:45 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218389385.83.0.390997116312.issue3533@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> works for me
status: open -> closed
versions: +3rd party -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Sun Aug 10 19:30:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Aug 2008 17:30:39 +0000
Subject: [issue1099] Mac compile fails with pydebug and framework enabled
In-Reply-To: <1188886622.31.0.867109013105.issue1099@psf.upfronthosting.co.za>
Message-ID: <1218389439.47.0.540245497638.issue1099@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please try XCode 2.5? See issue 3533 for a report that says that
upgrading solved the problem.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1099>
_______________________________________

From report at bugs.python.org  Sun Aug 10 19:51:13 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Aug 2008 17:51:13 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1218390673.55.0.494833819608.issue3535@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What Python version exactly are you using? This might have been fixed in
2.5.2, with r60117.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Sun Aug 10 20:04:01 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Aug 2008 18:04:01 +0000
Subject: [issue2841] Windows: "Runtime Error!" crash from pythonw.exe (3.0a5)
In-Reply-To: <1210625724.53.0.096647435573.issue2841@psf.upfronthosting.co.za>
Message-ID: <1218391441.4.0.385149351024.issue2841@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am closing this as 'out of date' because the problem went away in .b1
and is still gone in .b2.  There is still, however, a crash problem if a
file is run with utf-8.  See http://bugs.python.org/issue2827

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2841>
_______________________________________

From report at bugs.python.org  Sun Aug 10 20:05:57 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Aug 2008 18:05:57 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1218391557.1.0.927808133456.issue2827@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

When one runs a file with Python30.exe, it opens a window, runs the
file, and closes the window too fast to see what happened.  The point of
the input() statements is to 'pause' execution.  This is standard
debugging along with print()/write() statements.  With three input()s, I
determined that CPython compiled the file, executed the def statement,
and failed the function call (due, I presume, to the requested disk file
not being present).  IDLE, on the other hand, crashed before getting to
the first input() before the function def.  So it crashed while
compiling the file -- or as a result of trying to execute input().

I just tried cut and paste into the IDLE shell window (without the
encoding cookie) and it runs as expected, giving
IOError: [Errno 2] No such file or directory: 'slovn?k.txt'
Retrying with the cookie gives the same.  I have no idea if it is
recognized in interactive mode or if interactive mode is utf8 by default.

I just tried running from a file without the coding line and IDLE
crashed again.  So the problem is reading from a file on Windows.

IDLE is doing *something* different than bare CPython.  Actually, it
uses pythonw30.exe rather that python.exe, but when I replace the input
statements with file write statements (input raises error with pythonw),
pythonw also executed through to the def statement. But I still suspect
something in the interaction between IDLE and pythonw.  There was a
another problem with IDLE and pythonw in .a5
http://bugs.python.org/issue2841 
which seems to have disappeared without being officially fixed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Sun Aug 10 20:10:24 2008
From: report at bugs.python.org (Roger Upole)
Date: Sun, 10 Aug 2008 18:10:24 +0000
Subject: [issue3537] dict creation failure causes crash
In-Reply-To: <1218391824.09.0.805958642576.issue3537@psf.upfronthosting.co.za>
Message-ID: <1218391824.09.0.805958642576.issue3537@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

If the first item can't be inserted the interpreter will crash 
eventually.

while 1:
	try:
		d = { 'a':a,
		  'b':'b',
		  'c':'c',
		  'd':'d',
		  'e':'e',
		  'f':'f',
		  'g':'g',
		  'h':'h',
		  'i':'i',
		  'j':'j',
		  'k':'k',
		  'l':'l',
		  'm':'m',
		  'n':'n',
		  'o':'o'
		  }
	except:
		pass

As best I can tell, this only happens for the first item.
In a debug build, this assert fails on the second time thru
the loop (dictobject.c, line 247):
		assert (mp->ma_table == mp->ma_smalltable);

Apparently something is leaving one of the entries in the list
of preallocated dict objects in an inconsistent state.

----------
messages: 70990
nosy: rupole
severity: normal
status: open
title: dict creation failure causes crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3537>
_______________________________________

From report at bugs.python.org  Sun Aug 10 20:32:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 18:32:52 +0000
Subject: [issue3537] dict creation failure causes crash
In-Reply-To: <1218391824.09.0.805958642576.issue3537@psf.upfronthosting.co.za>
Message-ID: <1218393172.3.0.724101663612.issue3537@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Also happens in trunk.

----------
nosy: +georg.brandl
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3537>
_______________________________________

From report at bugs.python.org  Sun Aug 10 20:47:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Aug 2008 18:47:25 +0000
Subject: [issue3537] dict creation failure causes crash
In-Reply-To: <1218391824.09.0.805958642576.issue3537@psf.upfronthosting.co.za>
Message-ID: <1218394045.18.0.721925000397.issue3537@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The problem is that PyDict_New doesn't reinitialize the fields of a dict
from the free list when the number of entries is zero. For a
preconstructed dict (like created by BUILD_MAP) of size >=8, however,
there will be an allocated ma_table and ma_mask will be 16-1, not 8-1.

I propose the attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file11095/dictobj.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3537>
_______________________________________

From report at bugs.python.org  Sun Aug 10 20:51:12 2008
From: report at bugs.python.org (Elias Pipping)
Date: Sun, 10 Aug 2008 18:51:12 +0000
Subject: [issue1099] Mac compile fails with pydebug and framework enabled
In-Reply-To: <1188886622.31.0.867109013105.issue1099@psf.upfronthosting.co.za>
Message-ID: <1218394272.93.0.700270724048.issue1099@psf.upfronthosting.co.za>


Elias Pipping <elias at pipping.org> added the comment:

Configuring with '--with-pydebug --enable-framework --enable-universalsdk' 
(and invoking make afterwards) certainly works now for me.

I'm running XCode 3.1 -- or more importantly 'i686-apple-darwin9-gcc-4.0.1 
(GCC) 4.0.1 (Apple Inc. build 5484)' -- on OS X 10.5.4.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1099>
_______________________________________

From report at bugs.python.org  Sun Aug 10 21:23:05 2008
From: report at bugs.python.org (Viktor Ferenczi)
Date: Sun, 10 Aug 2008 19:23:05 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1218396185.04.0.940825690913.issue3160@psf.upfronthosting.co.za>


Viktor Ferenczi <python at cx.hu> added the comment:

Is forcing the encoding as UTF-8 backwards compatible?

It should be at least noted somewhere if this change could render
existing setup scripts incompatible with Python 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Sun Aug 10 21:40:36 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 10 Aug 2008 19:40:36 +0000
Subject: [issue3533] mac 10.4 buld of 3.0 --with-pydebug fails no __eprintf
In-Reply-To: <1218300371.75.0.851068496859.issue3533@psf.upfronthosting.co.za>
Message-ID: <1218397236.73.0.151786660605.issue3533@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

Grr... this problem is a pain... I have the __eprint undefined back...

I tried to get readline going as well and rebuilt. Couldn't get that
working then rebuilt without readline stuff and got the __eprintf.

I'm goint to have to give up on devleoping this on Mac and move to
linux. I don't have the spare time to get to the bottom of this problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3533>
_______________________________________

From report at bugs.python.org  Mon Aug 11 00:16:34 2008
From: report at bugs.python.org (Rambo007)
Date: Sun, 10 Aug 2008 22:16:34 +0000
Subject: [issue3538] Docstring typos
In-Reply-To: <1218406594.2.0.281031629955.issue3538@psf.upfronthosting.co.za>
Message-ID: <1218406594.2.0.281031629955.issue3538@psf.upfronthosting.co.za>


New submission from Rambo007 <wxpythoner at gmail.com>:

Hello. I was pokinf around in the Python 3.0b2 interpreter and I found
some typos in the following doctring:

>>> import sys; print(sys.platform.__doc__)
str(string[, encoding[, errors]]) -> str

Create a new string object from the given encoded string.
encoding defaults to the current default string encoding.
errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'.



Please fix the docstring words 'encoding' and 'errors' to have the
capital initial letter, so that the docstring would look like this:
str(string[, encoding[, errors]]) -> str

Create a new string object from the given encoded string.
Encoding defaults to the current default string encoding.
Errors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'.



Please fix other similar typos if you find them. Thank you.

----------
assignee: georg.brandl
components: Documentation
messages: 70996
nosy: Rambo007, georg.brandl
severity: normal
status: open
title: Docstring typos
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3538>
_______________________________________

From report at bugs.python.org  Mon Aug 11 00:46:33 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 10 Aug 2008 22:46:33 +0000
Subject: [issue3538] Docstring typos
In-Reply-To: <1218406594.2.0.281031629955.issue3538@psf.upfronthosting.co.za>
Message-ID: <1218408393.02.0.970182546806.issue3538@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

'encoding' and 'errors' refers to the names of the arguments accepted by
str, this is not a typo.

----------
nosy: +gpolo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3538>
_______________________________________

From report at bugs.python.org  Mon Aug 11 02:55:55 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 11 Aug 2008 00:55:55 +0000
Subject: [issue3539] Problem with pgen make dependencies in certain
	circumstances
In-Reply-To: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za>
Message-ID: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I usually build Python directly in my source repository (the directory
containing the configure script).  Accordingly, I have .o files scattered
throughout my sandbox.

Today I decided to build --with-pydebug, so I created a debug directory,
then ran ../configure from within that directory, giving the arguments
I wanted.  When I ran make it croaked with a link error linking pgen.
The linker complained that tokenizer_pgen.o and pgenmain.o weren't found.

Messing around with make -d I figured out that when make ran it
concluded that Parser/pgenmain.o didn't need to be rebuilt.  It thought
that ../Parser/pgenmain.o satisfied the dependency for Parser/pgenmain.o.
I don't know if this is a problem with GNU make's VPATH processing or
with the dependency specification in Python's makefile.

I can work around the problem by avoiding builds directly in my sandbox
but it would be nice if this worked.

(I'm experiencing a sense of deja vu.  Perhaps I've reported this problem
sometime in the dim, dark past, but I can't find anything searching for
either "VPATH" or "makefile".)

----------
components: Build
messages: 70998
nosy: skip.montanaro
severity: normal
status: open
title: Problem with pgen make dependencies in certain circumstances
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3539>
_______________________________________

From report at bugs.python.org  Mon Aug 11 03:58:16 2008
From: report at bugs.python.org (Jed Smith)
Date: Mon, 11 Aug 2008 01:58:16 +0000
Subject: [issue3499] Python 2.6 requires pre-installed Python to build
In-Reply-To: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>
Message-ID: <1218419896.76.0.559332499079.issue3499@psf.upfronthosting.co.za>


Jed Smith <jed at jedsmith.org> added the comment:

This happened in my fresh unpack of the 3.0b2 tarball, as well.

Touching merely Include/Python-ast.h satisfied the dependency, and I did
not have to touch Python-ast.c.  Is the particular grammar-rebuild rule
needed for production tarballs anyway?  I can't think the majority of
people downloading the package want to start hacking the grammar right away.

----------
nosy: +jedsmith
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3499>
_______________________________________

From report at bugs.python.org  Mon Aug 11 06:33:02 2008
From: report at bugs.python.org (Tim Wegener)
Date: Mon, 11 Aug 2008 04:33:02 +0000
Subject: [issue1533164] Installed but not listed *.pyo break bdist_rpm
Message-ID: <1218429182.68.0.911229572918.issue1533164@psf.upfronthosting.co.za>


Changes by Tim Wegener <twegener at fastmail.fm>:


----------
nosy: +twegener
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533164>
_______________________________________

From report at bugs.python.org  Mon Aug 11 07:27:19 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 11 Aug 2008 05:27:19 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218432439.55.0.675145350842.issue2389@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I don't see why this cannot be fixed easily. All we need to do is fix
the __reduce__ method of array objects to emit a list--i.e. with
array.tolist()--instead of a memory string. Since the reduce protocol is
just a fancy way to store the constructor arguments, this won't break
unpickling of array objects pickled by previous Python versions.

And here is a patch against the trunk.

----------
keywords: +patch
nosy: +alexandre.vassalotti
Added file: http://bugs.python.org/file11096/fix_array_pickling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Mon Aug 11 07:48:48 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 11 Aug 2008 05:48:48 +0000
Subject: [issue3514] pickle segfault with infinite loop in __getattr__
In-Reply-To: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>
Message-ID: <1218433728.34.0.0938914299848.issue3514@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

This is a bug in the C implementation of pickle (i.e., the _pickle
module). I think you're right about the missing exception check. At
first glance, it looks like the missing else-if case for "setstate ==
NULL", in load_build(), is the cause of the problem:

static int
load_build(UnpicklerObject *self)
{
...
    setstate = PyObject_GetAttrString(inst, "__setstate__");
    if (setstate == NULL && PyErr_ExceptionMatches(PyExc_AttributeError)) {
        PyErr_Clear();
    }
/*---missing else-if case---------
    else if (setstate == NULL) {
        return NULL;
    }
----------------------------------*/
    else {
        PyObject *result;

        /* The explicit __setstate__ is responsible for everything. */
        result = unpickler_call(self, setstate, state);
        Py_DECREF(setstate);
        if (result == NULL)
            return -1;
        Py_DECREF(result);
        return 0;
    }
...

----------
nosy: +alexandre.vassalotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3514>
_______________________________________

From report at bugs.python.org  Mon Aug 11 10:18:17 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 11 Aug 2008 08:18:17 +0000
Subject: [issue3538] Docstring typos
In-Reply-To: <1218406594.2.0.281031629955.issue3538@psf.upfronthosting.co.za>
Message-ID: <1218442697.17.0.477855792992.issue3538@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Chester, please stop changing your user name and wasting our time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3538>
_______________________________________

From report at bugs.python.org  Mon Aug 11 10:41:08 2008
From: report at bugs.python.org (alonwas)
Date: Mon, 11 Aug 2008 08:41:08 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218390673.55.0.494833819608.issue3535@psf.upfronthosting.co.za>
Message-ID: <1218444056.2383.0.camel@alon-lnx.istraresearch.com>


alonwas <alon.was at gmail.com> added the comment:

Hi,
I'm using 2.5.2 (r252:60911),
Thanks,
Alon

On Sun, 2008-08-10 at 17:51 +0000, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> What Python version exactly are you using? This might have been fixed in
> 2.5.2, with r60117.
> 
> ----------
> nosy: +loewis
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3535>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Mon Aug 11 11:08:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 11 Aug 2008 09:08:21 +0000
Subject: [issue3537] dict creation failure causes crash
In-Reply-To: <1218391824.09.0.805958642576.issue3537@psf.upfronthosting.co.za>
Message-ID: <1218445701.31.0.110880386315.issue3537@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied and added test in r65637.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3537>
_______________________________________

From report at bugs.python.org  Mon Aug 11 11:17:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 09:17:08 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1218446228.78.0.592899727523.issue3160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Do you really need to know the encoding of the pre_install_script? Isn't
it sufficient to open it in binary mode instead?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Mon Aug 11 11:44:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 09:44:44 +0000
Subject: [issue3134] shutil references undefined WindowsError symbol
In-Reply-To: <1213822190.13.0.727070543552.issue3134@psf.upfronthosting.co.za>
Message-ID: <1218447884.79.0.436020115408.issue3134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch works under Windows.

----------
assignee:  -> pitrou
priority:  -> high
versions: +Python 2.6, Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3134>
_______________________________________

From report at bugs.python.org  Mon Aug 11 11:59:34 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Mon, 11 Aug 2008 09:59:34 +0000
Subject: [issue3540] NotEmptyErrorError
In-Reply-To: <1218448774.78.0.853237126897.issue3540@psf.upfronthosting.co.za>
Message-ID: <1218448774.78.0.853237126897.issue3540@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

In the library reference of mailbox, 
NotEmptyError appears as NotEmptyErrorError.

For exampe:
http://docs.python.org/dev/3.0/library/mailbox.html#mailbox.NotEmptyErrorError

----------
assignee: georg.brandl
components: Documentation
messages: 71007
nosy: georg.brandl, mft
severity: normal
status: open
title: NotEmptyErrorError
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3540>
_______________________________________

From report at bugs.python.org  Mon Aug 11 12:27:50 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 11 Aug 2008 10:27:50 +0000
Subject: [issue3540] NotEmptyErrorError
In-Reply-To: <1218448774.78.0.853237126897.issue3540@psf.upfronthosting.co.za>
Message-ID: <1218450470.14.0.392533643059.issue3540@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r65639.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3540>
_______________________________________

From report at bugs.python.org  Mon Aug 11 12:29:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 10:29:17 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1218450557.8.0.224169275929.issue3160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, it's a little more complicated than that, because the
pre-install-script must have its newlines converted, otherwise the
installer refuses to run it. Here is a working patch. Viktor, do you
want to give it a try?

----------
assignee:  -> pitrou
Added file: http://bugs.python.org/file11097/wininst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Mon Aug 11 12:40:28 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Aug 2008 10:40:28 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1218451228.63.0.660792326171.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Indeed, that seems to be much faster. In the mean time, do you mind if I
> steal the code? :-)

Not at all!

I guess constant factors could well appear and/or disappear when
recoding in C; it might well be worth trying to implement both
methods to see which is faster.

There are some semi-obvious tricks available that might speed up the
recursive version.  For one thing, all shifts should be in multiples
of 15 bits (because longs are stored in base 2**15).  For another, it
ought to be possible to avoid the single-bit normalization shifts
every time the number of bits ('n') is odd---one can do a single
shift at the beginning of the calculation instead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Aug 11 12:53:34 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Mon, 11 Aug 2008 10:53:34 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1218452014.75.0.629678652637.issue3131@psf.upfronthosting.co.za>


Haoyu Bai <divinekid at gmail.com> added the comment:

I tried the patch and it works well. Thanks Georgij! So, why the patch
havn't merged into SVN?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Mon Aug 11 14:58:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 12:58:03 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218459483.62.0.649416503898.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The last beta is arriving soon. We need to go ahead on this, or retarget
it for 2.7/3.1.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Mon Aug 11 15:07:02 2008
From: report at bugs.python.org (Kuang-che Wu)
Date: Mon, 11 Aug 2008 13:07:02 +0000
Subject: [issue3541] bsddb memory leak on ubuntu
In-Reply-To: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>
Message-ID: <1218460022.22.0.445363609563.issue3541@psf.upfronthosting.co.za>


New submission from Kuang-che Wu <kcwu at csie.org>:

On ubuntu, python 2.5.2.
The memory usage of following program is increasing infinitly. There may
be something leaking.

However, it only consumes constant memory on windows (python 2.5.2).

import bsddb
d = bsddb.hashopen('a.db', 'c')
d.close()
while True:
    d = bsddb.hashopen('a.db')
    d.close()

----------
components: Extension Modules
messages: 71013
nosy: kcwu
severity: normal
status: open
title: bsddb memory leak on ubuntu
type: resource usage
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3541>
_______________________________________

From report at bugs.python.org  Mon Aug 11 15:15:01 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Mon, 11 Aug 2008 13:15:01 +0000
Subject: [issue1034053] unittest.py patch: add skipped test functionality
Message-ID: <1218460501.59.0.885116168466.issue1034053@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

Hello,

The attached patch adds the skip functionality and tests to a very
recent (yesterday) Python 3. It took me a few hours to apply the patch,
change to Python 3 style, merge the tests into the current set of tests
not doing a mess.

I think the whole thing is missing documentation, which I would gladly
write if the code is good to go. Just let me know.

Thanks.

----------
nosy: +pupeno
Added file: http://bugs.python.org/file11098/skip.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1034053>
_______________________________________

From report at bugs.python.org  Mon Aug 11 15:17:10 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Mon, 11 Aug 2008 13:17:10 +0000
Subject: [issue1034053] unittest.py patch: add skipped test functionality
Message-ID: <1218460630.88.0.691544091294.issue1034053@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

Oh, I forgot to upgrade versions to include Python 3.0 and to mention
that I have to fix some other tests to work with the new TestCase. It's
nothing serious, just doctests that where too dependent on the output of
the TextTestRunner. As previously discussed, doing that is not a good
idea anyhow, but it is needed for these doctests and I wouldn't expect
anybody else out there in the while to encounter this problem.

----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1034053>
_______________________________________

From report at bugs.python.org  Mon Aug 11 15:20:43 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Mon, 11 Aug 2008 13:20:43 +0000
Subject: [issue2821] unittest.py sys.exit error
In-Reply-To: <1210532457.78.0.053406582463.issue2821@psf.upfronthosting.co.za>
Message-ID: <1218460843.2.0.922789332116.issue2821@psf.upfronthosting.co.za>


J. Pablo Fern?ndez <pupeno at pupeno.com> added the comment:

Shouldn't this be closed now? or is there anything pending to be solved?

----------
nosy: +pupeno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2821>
_______________________________________

From report at bugs.python.org  Mon Aug 11 15:25:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 13:25:40 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1218461140.87.0.77053636638.issue1179@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1179>
_______________________________________

From report at bugs.python.org  Mon Aug 11 16:29:22 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 11 Aug 2008 14:29:22 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218464962.14.0.571174816318.issue3270@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've removed the fqdn call per the patch as of r65641

Lowering this to an enhancement to consider the removal of the 0.0.0.0 
functionality

----------
priority: high -> normal
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Mon Aug 11 17:30:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 15:30:21 +0000
Subject: [issue3542] Building an MSI installer crashes
In-Reply-To: <1218468621.31.0.60930081544.issue3542@psf.upfronthosting.co.za>
Message-ID: <1218468621.31.0.60930081544.issue3542@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

msilib hasn't been updated for py3k, consequently bdist_msi fails. The
provided patch fixes it, but encoding issues are not worked out (in my
tests, selecting an utf-8 codepage produces unrecognized msi files).

----------
components: Library (Lib)
files: msilib.patch
keywords: patch
messages: 71018
nosy: loewis, pitrou
priority: critical
severity: normal
status: open
title: Building an MSI installer crashes
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11099/msilib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3542>
_______________________________________

From report at bugs.python.org  Mon Aug 11 17:32:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 15:32:59 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1218468779.8.0.678344373571.issue3160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Similar issue but with bdist_msi in #3542.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Mon Aug 11 17:46:53 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 11 Aug 2008 15:46:53 +0000
Subject: [issue3134] shutil references undefined WindowsError symbol
In-Reply-To: <1218447884.79.0.436020115408.issue3134@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0808110846n782be315ye77a2465dc136371@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

> Patch works under Windows.

Thanks. Can you please commit the change?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3134>
_______________________________________

From report at bugs.python.org  Mon Aug 11 17:48:47 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Aug 2008 15:48:47 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1218469727.04.0.344930632757.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Py3k warnings for this have been checked in on the trunk as r65642.

There's an unfortunate problem with having to define a fixed stack level
for the warnings - for classes with a metaclass implemented in Python,
the warning message will point to the __new__ method of the metaclass
instead of to the first line of the offending class definition. I don't
see a way around this problem, but it definitely caused me grief in
tracking down some of the misbehaving classes in the standard library
that use ABCMeta as their metaclass in 2.6 (I actually cheated and
recompiled with the stack level on the warnings set to 2 instead of 1).

The update also eliminates the spurious and not-so-spurious Py3k
warnings that this update triggered in the test suite under the -3 flag.
Most were just test suite classes that happen to become unhashable in
Py3k, but a few were classes in the standard lib itself that defined
__eq__ or __cmp__ methods that were incompatible with the default
__hash__ implementation (collections.Mapping, collections.Set,
unittest.TestSuite, xml.dom.minidom.NamedNodeMap, numbers.Number,
UserList.UserList). Instances of all of the affected classes are now
explicitly unhashable in 2.x as well as 3.x (note that any code which
relied on any of them being hashable was already broken due to the fact
that these classes didn't provide the correct hash and equality invariants).

The numbers.Number change deserves special mention - the actual warning
occurs further down in the number stack (when numbers.Complex defines a
new __eq__ method), but it seemed appropriate to block the inheritance
of object.__hash__ in Number since an id() based hash isn't appropriate
for any numeric type. This particular aspect of the change should
probably be forward ported to Py3k.

In implementing the warnings, I'm also pretty happy with the current
Py3k approach that overriding __cmp__ or __eq__ means that __hash__
isn't inherited *at all*, rather than restricting the block solely to
object.__hash__. The current behaviour is simple to explain, and more
importantly, I think it is more correct - any time you change the
definition of equality for the class, you really do need to think
carefully about what it means for mutability and hashability.

P.S. I should never have said this part of the change was going to be
easy, because that was just begging old Murphy to come slap me upside
the head...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Mon Aug 11 17:53:59 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Aug 2008 15:53:59 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1218470039.94.0.258615835276.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I still intend to do the necessary documentation updates for this, but
they're going to be delayed a bit since getting the warnings right took
much longer than I expected.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Mon Aug 11 19:21:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 17:21:58 +0000
Subject: [issue3134] shutil references undefined WindowsError symbol
In-Reply-To: <1213822190.13.0.727070543552.issue3134@psf.upfronthosting.co.za>
Message-ID: <1218475318.01.0.18170502557.issue3134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65644.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3134>
_______________________________________

From report at bugs.python.org  Mon Aug 11 19:26:48 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 11 Aug 2008 17:26:48 +0000
Subject: [issue1545] shutil fails when copying to NTFS in Linux
In-Reply-To: <1196665730.42.0.657784597912.issue1545@psf.upfronthosting.co.za>
Message-ID: <1218475608.32.0.416007088048.issue1545@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

WindowsError issue is now fixed in r65644.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1545>
_______________________________________

From report at bugs.python.org  Mon Aug 11 19:30:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 17:30:00 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1218475800.79.0.23040131264.issue3535@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Do you have a public URL for such a zip file?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:02:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 11 Aug 2008 18:02:05 +0000
Subject: [issue3530] ast.NodeTransformer bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1218477725.74.0.463305963212.issue3530@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +aronacher, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:02:54 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 11 Aug 2008 18:02:54 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218477774.54.0.672275800414.issue3419@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Hey Mark - I took a look at the mp_nohang patch you added - and you're 
right, the connection refused error numbers are different from platform to 
platform. So rather than use a static list, I switched the code to use the 
errno module.

Can you apply this and confirm it works for you?

Added file: http://bugs.python.org/file11100/mp_nohang_jnoller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:20:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 11 Aug 2008 18:20:26 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218459483.62.0.649416503898.issue3139@psf.upfronthosting.co.za>
Message-ID: <48A082E8.5040904@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The last beta is arriving soon. We need to go ahead on this, or retarget
> it for 2.7/3.1.

I'll look into it tomorrow.

Regards,
Martin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:26:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 11 Aug 2008 18:26:26 +0000
Subject: [issue3542] Building an MSI installer crashes
In-Reply-To: <1218468621.31.0.60930081544.issue3542@psf.upfronthosting.co.za>
Message-ID: <1218479186.14.0.948589306437.issue3542@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3542>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:28:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 18:28:08 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1218479288.96.0.559294304714.issue2394@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:37:58 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 11 Aug 2008 18:37:58 +0000
Subject: [issue3543] ctypes works on Intel OS X, fails on PPC OS X
In-Reply-To: <1218479878.6.0.0482444198059.issue3543@psf.upfronthosting.co.za>
Message-ID: <1218479878.6.0.0482444198059.issue3543@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Hi, I'm having more problems with ctypes.util.find_library.  On my
Intel box, this works fine:

% python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import CDLL, RTLD_GLOBAL
>>> from ctypes.util import find_library
>>> print CDLL(find_library("iconv"), RTLD_GLOBAL)
<CDLL '/usr/lib/libiconv.dylib', handle 311df0 at 8a1b0>
>>> 

But on my PowerPC box, I get this:

% python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:16) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import CDLL, RTLD_GLOBAL
>>> from ctypes.util import find_library
>>> print CDLL(find_library("iconv"), RTLD_GLOBAL)
<CDLL 'None', handle fffffffe at 75af0>
>>> 

Both have /usr/lib/libiconv.dylib, both are running 10.5.4.

----------
components: Library (Lib)
messages: 71028
nosy: janssen
priority: normal
severity: normal
status: open
title: ctypes works on Intel OS X, fails on PPC OS X
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3543>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:39:36 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 11 Aug 2008 18:39:36 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1218479976.49.0.463885187974.issue3383@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Any chance of getting this fixed?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Mon Aug 11 20:53:43 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Aug 2008 18:53:43 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218480823.96.0.844481613246.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> So rather than use a static list, I switched the code to use the 
> errno module.

Yup.  That's definitely a better solution.

Your patch fixed the problem for me.

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Mon Aug 11 21:00:53 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 11 Aug 2008 19:00:53 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218481253.89.0.920323794003.issue3419@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks Mark, I've checked in the connection refused fix in r65645 on trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Mon Aug 11 21:00:58 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 11 Aug 2008 19:00:58 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218481258.23.0.482431589575.issue3419@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file11038/mp_nohang.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Mon Aug 11 21:23:27 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 11 Aug 2008 19:23:27 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1218482607.97.0.450082930254.issue3383@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Well, I have no idea what the standard setup on posix boxes is - should
objdump and ldconfig be on $PATH or not?

Regarding the groups in the regexp:  It is my understanding that the
parens do not matter because .group(0) is returned, which contains the
entire matching string anyway - do I overlook something?

Please note that the find_library() code was not written by myself ;-(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Mon Aug 11 21:58:01 2008
From: report at bugs.python.org (Trent Nelson)
Date: Mon, 11 Aug 2008 19:58:01 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218484681.89.0.995266848869.issue3270@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

I can confirm the patch works in Windows.  Regarding the 0.0.0.0 issue, 
perhaps we can compromise on something like this:

% svn diff connection.py
Index: connection.py
===================================================================
--- connection.py       (revision 65645)
+++ connection.py       (working copy)
@@ -217,6 +217,8 @@
         self._socket.bind(address)
         self._socket.listen(backlog)
         self._address = self._socket.getsockname()
+        if self._address[0] == '0.0.0.0':
+            self._address[0] = '127.0.0.1'
         self._family = family
         self._last_accepted = None


That way, we still support binding on all addresses, and self._address 
will always represent a connectable end-point.  Thoughts?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Mon Aug 11 22:09:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Aug 2008 20:09:09 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1218484681.89.0.995266848869.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218485330.8794.2.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 11 ao?t 2008 ? 19:58 +0000, Trent Nelson a ?crit :
> +        if self._address[0] == '0.0.0.0':
> +            self._address[0] = '127.0.0.1'

Please no. If the user asks for 0.0.0.0, either obey or raise an
exception, but do not silently change the value.

My own humble opinion is that 0.0.0.0 should be allowed and, at worse,
the documentation may carry a warning about it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Tue Aug 12 01:29:56 2008
From: report at bugs.python.org (endolith)
Date: Mon, 11 Aug 2008 23:29:56 +0000
Subject: [issue3544] "expection" typo
In-Reply-To: <1218497396.52.0.0979019785158.issue3544@psf.upfronthosting.co.za>
Message-ID: <1218497396.52.0.0979019785158.issue3544@psf.upfronthosting.co.za>


New submission from endolith <endolith at gmail.com>:

http://docs.python.org/lib/typecontextmanager.html

"if any expection that occurred should be suppressed"

----------
assignee: georg.brandl
components: Documentation
messages: 71035
nosy: endolith, georg.brandl
severity: normal
status: open
title: "expection" typo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3544>
_______________________________________

From report at bugs.python.org  Tue Aug 12 01:39:37 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Aug 2008 23:39:37 +0000
Subject: [issue3514] pickle segfault with infinite loop in __getattr__
In-Reply-To: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>
Message-ID: <1218497977.01.0.458789709874.issue3514@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Good find Alexandre!  Can you work up a patch?  Would be even better if
it had a unittest.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3514>
_______________________________________

From report at bugs.python.org  Tue Aug 12 01:41:17 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Aug 2008 23:41:17 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218498077.82.0.620993674914.issue2389@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Wouldn't that be lots and lots slower?  I believe speed is one of the
reasons why the binary representation is currently dumped.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Aug 12 02:17:48 2008
From: report at bugs.python.org (cfr)
Date: Tue, 12 Aug 2008 00:17:48 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218500268.74.0.399971571504.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

I admit to not understanding the code involved, but I *thought* that the
problem involved cases where there *is* a preferred encoding in the
environment but it is not one of those covered by:
    case kCFStringEncodingMacRoman: return "mac-roman";
    case kCFStringEncodingMacGreek: return "mac-greek";
    case kCFStringEncodingMacCyrillic: return "mac-cyrillic";
    case kCFStringEncodingMacTurkish: return "mac-turkish";
    case kCFStringEncodingMacIcelandic: return "mac-icelandic";
The work around basically ensures the preferred encoding given by the
environment is one of those listed so that the rest of that part of the
code doesn't run. I don't think that my crash, at least, resulted from
no preferred encoding being defined in the environment but maybe
something is going wrong in the locale module because it is not one from
the standard list.

Maybe?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Aug 12 02:18:01 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 12 Aug 2008 00:18:01 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1218500281.88.0.53361325383.issue1432@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Hi Facundo,
I think, we can go ahead and commit the changes. Got a response in
Web-SIG that,previous RFC2396 listed behavior is invalid (in a practical
sense) and the current patch fixes it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Tue Aug 12 02:18:53 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 12 Aug 2008 00:18:53 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1218500333.4.0.596636595798.issue2275@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Facundo, Shall we go ahead with committing these changes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Tue Aug 12 03:53:26 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 01:53:26 +0000
Subject: [issue3543] ctypes works on Intel OS X, fails on PPC OS X
In-Reply-To: <1218479878.6.0.0482444198059.issue3543@psf.upfronthosting.co.za>
Message-ID: <1218506006.2.0.240005567544.issue3543@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Caused by setting DYLD_FALLBACK_LIBRARY_PATH badly on the PPC machine.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3543>
_______________________________________

From report at bugs.python.org  Tue Aug 12 04:30:55 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 02:30:55 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218306864.44.0.78350530603.issue3300@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0808111930m459bbc98sef6934c15a158e65@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

On Sat, Aug 9, 2008 at 11:34 AM, Matt Giuca <report at bugs.python.org> wrote:

>
> Matt Giuca <matt.giuca at gmail.com> added the comment:
>
> Bill, I had a look at your patch. I see you've decided to make
> quote_as_string the default? In that case, I don't know why you had to
> rewrite everything to implement the same basic behaviour as my patch.
>

Just to get things clear in my head.  I don't care what code is used, so
long as it doesn't break the Web.

> (My latest few patches support bytes both ways). Anyway, I have a lot of
> issues with your implementation.
>
> * Why did you replace all of the existing machinery? Particularly the
> way quote creates Quoter objects and stores them in a cache. I haven't
> done any speed tests, but I assume that was all there for performance
> reasons.

I see no real advantage there, except that it has a built-in memory leak.
Just use a function.

> * The idea of quote_as_bytes is malformed. quote_as_bytes takes a str or
> bytes, and outputs a URI as a bytes, while quote_as_string outputs a URI
> as a str. This is the first time in the whole discussion we've
> represented a URI as bytes, not a str. URIs are not byte sequences, they
> are character sequences (see discussion below).

Just there for consistency.  Of course,  URIs are actually strings of
*ASCII* characters, which sort of specifies an encoding right there, so
using ASCII octets isn't all that far-fetched...

> * The names unquote_as_* and quote_as_* are confusing. Use unquote_to_*
> and quote_from_* to avoid ambiguity.

Good point.

> * Are unquote_as_string and unquote both part of your public interface?

Yes.  Good programmers will switch to unquote_as_string or unquote_as_bytes
(or, with your amendment, unquote_to_string and unquote_to_bytes, while
unquote is just there for backwards compatibility for naifs.

* As Antoine pointed out above, it's too limiting for quote to force
> UTF-8. Add a 'charset' parameter.

That's what quote_as_string is for.

> * Add an 'errors' parameter too, to give the caller control over how
> strict to be.

No.  Errors should be seen.  This is data, not whimsey.

>
> * unquote and unquote_plus are missing 'charset' param, which should be
> passed along to unquote_as_string.

No, they're only there for backwards compatibility, and the 2.x versions
don't have a charset param. *

>I do like the addition of a "plus" argument, as opposed to the

> separate unquote_plus and quote_plus functions. I'd swap the arguments
> to unquote around so charset is first and then plus, so you can write
> unquote(mystring, 'utf-8') without using a keyword argument.

Unquote doesn't take a charset (in my design).

>
> * In unquote: The "raw_unicode_escape" encoding makes no sense. It does
> exactly the same thing as Latin-1, except it also looks for b"\\uxxxx"
> in the string and converts that into a Unicode character. So your code
> behaves like this:
>
> >>> urllib.parse.unquote('%5Cu00fc')
> '?'
> (Should output "\u00fc")
> >>> urllib.parse.unquote('%5Cu')
> UnicodeDecodeError: 'rawunicodeescape' codec can't decode bytes in
> position 11-12: truncated \uXXXX
> (Should output "\u")
>
> I suspect the email package (where you got the inspiration to use
> 'rawunicodeescape') has this same crazy problem, but that isn't my
> concern today!
>
> Aside from this weirdness, you're essentially defaulting unquote to
> Latin-1. As I've said countless times, unquote needs to be the inverse
> of quote, or you get this behaviour:

> >>> urllib.parse.unquote(urllib.parse.quote('?'))
> '??'
>
> Once again, I refer you to my favourite web server example.
>
> import http.server
> s = http.server.HTTPServer(('',8000),
>        http.server.SimpleHTTPRequestHandler)
> s.serve_forever()
>
> Run this in a directory with a non-Latin-1 filename (eg. "??"), and
> you will get a 404 when you click on the file.

Using unquote() and expecting a string is basically broken already.  So what
I'm trying to do here is to avoid losing data in the translation.

> * One issue I worked very hard to solve is how to deal with unescaped
> non-ASCII characters in unquote. Technically this is an invalid URI, so
> I'm not sure how important it is, but it's nice to be able to assume the
> unquote function won't mess with them. For example,
> unquote_as_string("\u6f22%C3%BC", charset="latin-1") should give
> "\u6f22\u00fc" (or at least it would be nice). Yours raises
> "UnicodeEncodeError: 'ascii' codec can't encode character". (I assume
> this is a wanted property, given that the existing test suite tests that
> unquote can handle ALL unescaped ASCII characters (that's what
> escape_string in test_unquoting is for) - I merely extend this concept
> to be able to handle all unescaped Unicode characters). Note that it's
> impossible to allow such lenience if you implement unquote_as_string as
> calling unquote_as_bytes and then decoding.

Good thing we don't need to; URIs consist of ASCII characters.

>
> * Question: How does unquote_bytes deal with unescaped characters?

Not sure I understand this question...

>
> * Needs a lot more test cases, and documentation for your changes. I
> suggest you plug my new test cases for urllib in and see if you can make
> your code pass all the things I test for (and if not, have a good reason).

Your test cases probably aren't testing things I feel it's necessary to
test. I'm interested in having the old test cases for urllib pass, as well
as providing the ability to unquote_to_bytes().

> In addition, a major problem I have is with this dangerous assumption
> that RFC 3986 specifies a byte->str encoding. You keep stating
> assumptions like this:
>

> Remember that the RFC for percent-encoding really takes
> > bytes in, and produces bytes out.  The string-in and string-out
> > versions are to support naive programming (what a nice way of
> > putting it!).
>

Those aren't assumptions, they're simple statements of fact.

>
> You assume that my patch, the string version of quote/unquote, is a
> "hack" in order to satisfy the naive souls who only want to deal with
> strings, while your method is the "pure and correct" solution.

Yes.

>
> It is clear from reading RFC 3986 that URIs are characters, not octets
> (that's not debatable - as we see URIs written on billboards, they're
> definately characters). What *is* debatable is whether the source data
> for a URI is a character or a byte. I'm arguing it can be either.
>

I wasn't talking about URIs (you're right, they're clearly sequences of
characters), I was talking about the process of percent-encoding, which
takes a sequence of octets, and produces an ASCII string, and the process of
percent-decoding, which takes that ASCII string, and produces that same
original sequence of octets.  Don't confuse the two issues.

You seem to have arrived at the same outcome, but from a very different
> standpoint that your unquote_as_bytes is "correct" and unquote_as_string
> is a nasty hack

Nasty?  I suppose that's in the eye of the beholder.  No, I think that this
whole situation has come about because Python 1 and Python 2 had this
unfortunate ambiguity about what a "str" was.  urllib.unquote() has always
produced a sequence of bytes, but unfortunately too many careless
programmers have regarded it as a sequence of characters.  Unquote_as_string
simply (and, IMO,  usefully), conflates two operations:  percent-decode, and
string decode.  Non-careless programmers have always written something like:

   s = urllib.unquote(frag).decode("UTF-8", "strict")

That is, they understood what was going on, and handled it correctly.  I'd
suggest removing "unquote" completely, and leaving everyone porting to
Python 3 to make their own choice between unquote_to_bytes and
unquote_to_string.

> Bill:
> > Barring any other information, I think that the "segments" in the
> > path of an "http" URL must also be assumed to be binary; that is,
> > any octet is allowed, and no character set can be presumed.
>
> Once again, practicality beats purity. Segments in HTTP URLs usually
> refer to file paths. Files (in all modern operating systems) are Unicode
> filenames, not byte filenames. So you HAVE to assume the character set
> at some point. The best assumption we can make (as shown by all the
> major browsers' defaults) is UTF-8.
>

You're not suggesting we build something that works for 80% of the cases,
and breaks on the other 20%?  When we don't need to?

> So this probably indicates a bug in urllib.parse:
> > urllib.parse.urlparse(<snip>)
> > should throw an exception somewhere.
>
> No, this is just assuming the behaviour of unquote (which is called by
> urlparse) to preserve unescaped characters as-is. So this "bug" is
> actually in your own implementation of unquote (and mine too). But I
> refute that that's desirable behaviour. I think you SHOULD NOT have
> removed that test case. It is indicating a bug in your code (which is
> what it's there for).

This has nothing to do with unquote().  The octets in question are not
percent-encoded.

> Look, I'm sorry to be so harsh, but I don't see what this alternative
> patch accomplishes. My analysis probably comes off as self-righteous,
> but then, I've spent the past month reading documentation and testing
> every aspect of this issue rigorously, and all I see is you ignoring all
> my work and rewriting it in a less-robust way.

Sorry to be so harsh, but... wow, take some lessons in humility!  It's not
about you or your patch or how long you spend reading stuff, it's about
Python. And, without referring explicitly to your patch, it really doesn't
matter how long someone spends on something, if they get it wrong.  I think
you are conflating things in a way which will break stuff (and not break
other stuff, that's true).  We're arguing about which way of breaking things
is better, I think.

> Your point here was to make the str->bytes and bytes->str versions of
> unquote and quote, respectively, work, right? Well I've already got
> those working too. Please tell me what you think of my implementation so
> we can get it approved before the deadline.

Matt, your patch is not some God-given thing here.  There are lots of
patches waiting to be looked at, and this is a fairly trivial concern.  I'm
guessing there are lots of URIs out there that contain non-UTF-8 octets,
particularly in Japan, which has used ISO-2022-JP for years (though Antoine
advances an example of Latin-1 in URLs right here).  Be nice if someone who
worked at Google (hint!, hint!) looked through their massive collection of
URLs and validated this hypothesis, or not.

Added file: http://bugs.python.org/file11101/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080812/5112dc6a/attachment-0001.txt>

From report at bugs.python.org  Tue Aug 12 05:36:29 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 03:36:29 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218512189.11.0.589217027439.issue3300@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file11101/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 05:43:38 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 03:43:38 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218512618.41.0.823335524111.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Some interesting notes here (from Erik van der Poel at Google; Guido,
you might want to stroll over to his location and talk with him):

http://lists.w3.org/Archives/Public/www-international/2007JanMar/0004.html

and more particularly

http://lists.w3.org/Archives/Public/www-international/2008AprJun/0092.html,
which says, in part,

``Within the context of HTML and HTTP, queries
[that is, the query part of a URL] don't have to say which
charset they are using, because there is already an agreement in
place: the major browsers and servers use the charset of the HTML.''

So, there's still a sizable number of Latin-1 pages out there, and
queries against these pages will use that encoding in the URL's they send.

And then there's this:

http://lists.w3.org/Archives/Public/www-international/2008AprJun/0014.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 07:45:13 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 12 Aug 2008 05:45:13 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218519913.2.0.513203083069.issue2389@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The slowdown depends of the array type. The patch makes array unpickling
a few orders of magnitude slower (i.e. between 4 and 15 times slower
depending of the array type). In general, pickling is about as fast as
with the binary representation (or faster!). 

Although since most 64-bit compilers uses the LP64 model, I think we
could make a compromise and only pickle as a list arrays of long
integers. This would fix the problem without any visible speed penalties.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Aug 12 08:31:34 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 12 Aug 2008 06:31:34 +0000
Subject: [issue3270] test_multiprocessing: test_listener_client flakiness
In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za>
Message-ID: <1218522694.49.0.467486724827.issue3270@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

I was thinking about this on the way home last night and concluded that 
my last suggestion (s/0.0.0.0/127.0.0.1/) is a terrible one as well.  
I'd be happy with a mention in the documentation (for now) stating that 
if you listen on '0.0.0.0', Listener._address won't be a connectable 
end-point (and you'll have to explicitly connect to 127.0.0.1, for 
example).

As for the original issue, Jesse I'm +1 on your connection_v2.patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3270>
_______________________________________

From report at bugs.python.org  Tue Aug 12 09:19:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Aug 2008 07:19:41 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218525581.09.0.797840137148.issue3362@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Lists of possible string encodings are here:

http://developer.apple.com/documentation/CoreFoundation/Reference/CFStringRef/Reference/reference.html#//apple_ref/c/tdef/CFStringBuiltInEncodings

and

http://developer.apple.com/documentation/CoreFoundation/Reference/CFStringRef/Reference/reference.html#//apple_ref/doc/constant_group/External_String_Encodings

So it would be interesting to know what CFStringGetSystemEncoding
returns on your system. Notice the special value
kCFStringEncodingInvalidId, which it might also return.

I think

  printf("Encoding is %x\n", enc);

should do.

I think mac_getscript is fine as it stands: if name is NULL, it tries
CFStringConvertEncodingToIANACharSetName which should perform a lookup
in the Apple database.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Aug 12 09:30:33 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Aug 2008 07:30:33 +0000
Subject: [issue3544] "expection" typo
In-Reply-To: <1218497396.52.0.0979019785158.issue3544@psf.upfronthosting.co.za>
Message-ID: <1218526233.92.0.297659820479.issue3544@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already fixed in SVN.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3544>
_______________________________________

From report at bugs.python.org  Tue Aug 12 10:00:29 2008
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Tue, 12 Aug 2008 08:00:29 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218528029.47.0.184037855532.issue2389@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Unfortunately dumping the internal representation of non-long arrays
won't work, for several reasons.  First, it breaks when porting pickles
between platforms of different endianness such as Intel and SPARC. 
Then, it ignores the considerable work put into correctly pickling
floats, including the support for IEEE 754 special values.  Finally, it
will break when unpickling Unicode character arrays pickled on different
Python versions -- wchar_t is 2 bytes wide on Windows, 4 bytes on Unix.

I believe pickling arrays to compact strings is the right approach on
the grounds of efficiency and I wouldn't change it.  We must only be
careful to pickle to a string with a portable representation of values.
 The straightforward way to do this is to pick a "standard" size for
types (much like the struct module does) and endianness and use it in
the pickled array.  Ints are simple, and the code for handling floats is
already there, for example _PyFloat_Pack8 used by cPickle.

Pickling arrays as lists is probably a decent workaround for the pending
release because it's backward and forward compatible (old pickles will
work as well as before and new pickles will be correctly read by old
Python versions), but for the next release I would prefer to handle this
the right way.  If there is agreement on this, I can start work on a
patch in the following weeks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Aug 12 12:05:31 2008
From: report at bugs.python.org (Anders Bensryd)
Date: Tue, 12 Aug 2008 10:05:31 +0000
Subject: [issue3545] Python turning off assertions (Windows)
In-Reply-To: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>
Message-ID: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>


New submission from Anders Bensryd <anders.bensryd at aveva.com>:

We are using Windows XP SP2, Visual Studio 2005 & Python 2.5.2.
In Objects/exceptions.c the following code turns off all assertions.

#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
    /* Set CRT argument error handler */
    prevCrtHandler = _set_invalid_parameter_handler
(InvalidParameterHandler);
    /* turn off assertions in debug mode */
    prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif

As far as I understand, this is to make sure that no assertion dialogs 
pop up during the internal Python tests. For ordinary users, this is 
not an issue.

However, we are using the Python DLL in our product and when developing 
we always use the debug version of the Python DLL (as recommended). 
When we do Py_Initialize() all assertions are turned off, even our 
assertions, and this is not what we want. The current workaround is as 
follows (this is in our code):

   prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_REPORT_MODE);
   Py_Initialize();
   prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,prevCrtReportMode);

I am not certain if this is a bug or a feature and I really do not have 
a suggested solution since I do not know the real reasons for turning 
off assertions. Perhaps there already is a way to avoid this problem 
that I have not found?

All comments are appreciated.

----------
components: Windows
messages: 71049
nosy: abe
severity: normal
status: open
title: Python turning off assertions (Windows)
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________

From report at bugs.python.org  Tue Aug 12 12:11:11 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Aug 2008 10:11:11 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218535871.88.0.299553867499.issue2389@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I like to challenge the view what "correct" behavior is here. If I
pickle an array of 32-bit integer values on one system, and unpickle it
as an array of 64-bit integer values on a different system, is that
correct, or incorrect?

IMO, correct behavior would preserve the width as much as possible. For
integers, this should be straight-forward, as it should be for floats
and doubles (failing to unpickle them if the target system doesn't
support a certain format). For Unicode, I think the array module should
grow platform-independent width, for both 2-byte and 4-byte Unicode.

When pickling, the pickle should always use network byte order;
alternatively, the pickle should contain a byte order marker (presence
of which could also be used as an indication that the new array pickle
format is used). IOW, <i would indicate little-endian four byte
integers, and so on.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Aug 12 12:29:33 2008
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Tue, 12 Aug 2008 10:29:33 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218536973.63.0.436333195078.issue2389@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

I think preserving integer width is a good idea because it saves us from
having to throw overflow errors when unpickling to machines with
different width of C types.  The cost is that pickling/unpickling the
array might change the array's typecode, which can be a problem for C
code that processes the array's buffer and expects the C type to remain
invariant.

Instead of sticking to network byte order, I propose to include byte
order information in the pickle (for example as '<' or '>' like struct
does), so that pickling/unpickling between the same-endianness
architectures doesn't have to convert at all.  Floats are always pickled
as IEEE754, but the same optimization (not having to convert anything)
would apply when unpickling a float array on an IEEE754 architecture.

Preserving widths and including endianness information would allow
pickling to be as fast as it is now (with the exception of unicode chars
and floats on non-IEEE754 platforms).  It would also allow unpickling to
be as fast between architecture with equal endianness, and correct
between others.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Aug 12 16:51:57 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Aug 2008 14:51:57 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218552717.52.0.607207135906.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now committed the patch to 2.6 as r65654, adding changes for the
bz2module.

I also decided to make the Py_buffer structure own its reference, as I
was running out of arguments why not to. In the process, I removed
PyObject_ReleaseBuffer, as it is redundant and would have an unclear
sematics (what if the object passed directly and the object passed
indirectly were different?).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Tue Aug 12 16:54:30 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 12 Aug 2008 14:54:30 +0000
Subject: [issue3546] Missing linebreak in ext.doctest output
In-Reply-To: <1218552870.92.0.456647494435.issue3546@psf.upfronthosting.co.za>
Message-ID: <1218552870.92.0.456647494435.issue3546@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

There is a linebreak missing in the doctest extension. See attached patch.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: linebreak.patch
keywords: patch
messages: 71053
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: Missing linebreak in ext.doctest output
type: behavior
Added file: http://bugs.python.org/file11102/linebreak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3546>
_______________________________________

From report at bugs.python.org  Tue Aug 12 17:20:29 2008
From: report at bugs.python.org (Matt Giuca)
Date: Tue, 12 Aug 2008 15:20:29 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218554429.43.0.154361702641.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Bill, this debate is getting snipy, and going nowhere. We could argue
about what is the "pure" and "correct" thing to do, but we have a
limited time frame here, so I suggest we just look at the important facts.

1. There is an overwhelming consensus (including from me) that a
str->bytes version is acceptable to have in the library (whether or not
it's the "correct solution").
2. There is an overwhelming consensus (including from you) that a
str->str version is acceptable to have in the library (whether or not
it's the "correct solution").
3. By default, the str->str version breaks much less code, so both of us
decided to use it by default.

To this end, both of our patches:

1. Have a str->bytes version available.
2. Have a str->str version available.
3. Have "quote" and "unquote" functions call the str->str version.

So it seems we have agreed on that. Therefore, there should be no more
arguing about which is "more right".

So all your arguments seem to be essentially saying "the str->bytes
methods work perfectly; I don't care about if the str->str methods are
correct or not". The fact that your string versions quote UTF-8 and
unquote Latin-1 shows just how un-seriously you take the str->str methods.

Well the fact is that a) a great many users do NOT SHARE your ideals and
will default to using "quote" and "unquote" rather than the bytes
functions, and b) all of the rest of the library uses "quote" and
"unquote". So from a practical sense, how these methods behave is of the
utmost importance - they are more important than any new functions we
introduce at this point.

For example, the cgi.FieldStorage and the http.server modules will
implicitly call unquote and quote.

That means whether you, or I, or Guido, or The King Of The Internet
likes it or not, we have to have a "most reasonable" solution to the
problem of quoting and unquoting strings.

> Good thing we don't need to [handle unescaped non-ASCII characters in
> unquote]; URIs consist of ASCII characters.

Once again, practicality beats purity. I'd argue that it's a *good* (not
strictly required) idea to not mangle input unless we have to.

> > * Question: How does unquote_bytes deal with unescaped characters?

> Not sure I understand this question...

I meant unescaped non-ASCII characters, as discussed above (eg.
unquote_bytes('\u0123')).

> Your test cases probably aren't testing things I feel it's necessary
> to test. I'm interested in having the old test cases for urllib
> pass, as well as providing the ability to unquote_to_bytes().

I'm sorry, but you're missing the point of test-driven development. If
you think there is a bug, you don't just fix it and say "look, the old
test cases still pass!" You write new FAILING test cases to demonstrate
the bug. Then you change the code to make the test cases pass. All your
test suite proves is that you're happy with things the way they are.

> Matt, your patch is not some God-given thing here.

No, I am merely suggesting that it's had a great deal more thought put
into it -- not just my thought, but all the other people in the past
month who've suggested different approaches and brought up discussion
points. Including yourself -- it was your suggestion in the first place
to have the str->bytes functions, which I agree are important.

> > <snip> - Quote uses cache

> I see no real advantage there, except that it has a built-in
> memory leak. Just use a function.

Good point. Well the merits of using a cache are completely independent
from the behavioural aspects. I simply changed the existing code as
little as possible. Hence this patch will have the same performance
strengths/weaknesses as all previous versions, and the performance can
be tuned after 3.0 if necessary. (Not urgent).

On statistics about UTF-8 versus other encodings. Yes, I agree, there
are lots of URIs floating around out there, in many different encodings.
Unfortunately, we can't implicitly handle them all (and I'm talking once
more explicitly about the str->str transform here). We need to pick one
as the default. Whether Latin-1 is more popular than UTF-8 *for the time
being* is no good reason to pick Latin-1. It is called a "legacy
encoding" for a reason. It is being phased out and should NOT be
supported from here on in as the default encoding in a major web
programming language.

(Also there is no point in claiming to be "Unicode compliant" then
turning around and supporting a charset with 256 symbols by default).

Because Python's urllib will mostly be used in the context of building
web apps, it is up to the programmer to decide what encoding to use for
h(is|er) web app. For future apps, this should almost certainly be UTF-8
(if it isn't, the website won't be able to accept form input across all
characters, so isn't Unicode compliant anyway).

The problem you mention of browsers submitting URIs encoded based on the
charset is simply something we have to live with. A server will never be
able to deal with that unless the URIs are coming from pages which *it
served*. As this is very often the case, then as I said above, the app
should serve UTF-8 and there'll be no problems. Also note that ALL the
browsers I tested (FF/Saf/IE) use UTF-8 no matter what, if you directly
type Unicode characters into the address bar.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 17:26:57 2008
From: report at bugs.python.org (Matt Giuca)
Date: Tue, 12 Aug 2008 15:26:57 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218554817.69.0.715071509169.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

By the way, what is the current status of this bug? Is anybody waiting
on me to do anything? (Re: Patch 9)

To recap my previous list of outstanding issues raised by the review:

> Should unquote accept a bytes/bytearray as well as a str?
Currently, does not. I think it's meaningless to do so (and how to
handle >127 bytes, if so?)

> Lib/email/utils.py:
> Should encode_rfc2231 with charset=None accept strings with non-ASCII
> characters, and just encode them to UTF-8?
Currently does. Suggestion to restrict to ASCII on the review tracker;
simple fix.

> Should quote raise a TypeError if given a bytes with encoding/errors
> arguments? (Motivation: TypeError is what you usually raise if you
> supply too many args to a function).
Resolved. Raises TypeError.

> Lib/urllib/parse.py:
> (As discussed above) Should quote accept safe characters outside the
> ASCII range (thereby potentially producing invalid URIs)?
Resolved? Implemented, but too messy and not worth it just to produce
invalid URIs, so NOT in patch.

That's only two very minor yes/no issues remaining. Please comment.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 18:05:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Aug 2008 16:05:03 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218554429.43.0.154361702641.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218557076.5539.16.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree that given two similar patches, the one with more tests earns
some bonus points. Also, it seems to me that round-trippability of
quote()/unquote() is a logical and semantic requirement: in particular,
if there is a default encoding, it should be the same for both.

> For future apps, this should almost certainly be UTF-8
> (if it isn't, the website won't be able to accept form input across all
> characters, so isn't Unicode compliant anyway).

Actually, it will be able to accept such form input, as characters not
supported by the charset should be entity-encoded by the browser (e.g.
"&#123;").

I have no strong opinion on the very remaining points you listed, except
that IMHO ?encode_rfc2231 with charset=None should not try to use UTF8
by default. But someone with more mail protocol skills should comment :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 18:05:20 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 16:05:20 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1218557120.58.0.425279307655.issue2054@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I think I'm just going to bring the unwrap already in the _ssl.c code
out to the ssl.py module, that seems to be the simplest fix.  Still not
sure you can do a proper fix to ftplib here, but that seems to be a good
thing to do anyway, rather than having people call directly into the
_ssl module to get at it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Tue Aug 12 18:15:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Aug 2008 16:15:48 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218557748.69.0.763380143047.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I also started working on porting it to 3.0, but couldn't complete that
port yet - the memoryview object doesn't play nicely.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Tue Aug 12 18:20:19 2008
From: report at bugs.python.org (Tim Maxwell)
Date: Tue, 12 Aug 2008 16:20:19 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>


New submission from Tim Maxwell <timmaxw at gmail.com>:

Steps to reproduce:

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *     
>>> fields = [('a', c_short, 4), ('b', c_short, 4), ('c', c_long, 24)]
>>> class Foo(Structure):
...     _fields_ = fields
... 
>>> Foo.a
<Field type=c_short, ofs=0:0, bits=4>
>>> Foo.b
<Field type=c_short, ofs=0:4, bits=4>
>>> Foo.c
<Field type=c_long, ofs=-2:8, bits=24> # Wrong!

More about my machine:
>>> sizeof(c_short)
2
>>> sizeof(c_long)
4

This particular example comes from a 32-bit Mac OS X Intel machine. The 
bug has been reproduced on Linux as well, but could not be reproduced on 
Windows XP.

----------
assignee: theller
components: ctypes
messages: 71060
nosy: theller, tim.maxwell
severity: normal
status: open
title: Ctypes is confused by bitfields of varying integer types
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Tue Aug 12 17:50:53 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 12 Aug 2008 15:50:53 +0000
Subject: [issue2776] urllib2.urlopen() gets confused with path with // in it
In-Reply-To: <1210109415.44.0.221361539235.issue2776@psf.upfronthosting.co.za>
Message-ID: <1218556253.42.0.746117210268.issue2776@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I could reproduce this issue on trunk and p3k branch. The patch attached
by Adrianna Pinska "appropriately" fixes this issue. I agree with the
logic. Attaching the patch for py3k with the same fix.

Thanks,
Senthil

Added file: http://bugs.python.org/file11103/issue2776-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2776>
_______________________________________

From report at bugs.python.org  Tue Aug 12 19:13:52 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 17:13:52 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1218561232.75.0.537625367046.issue2054@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

OK, I think I've done the minimal fix necessary to the SSL module to
allow this work to proceed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Tue Aug 12 19:23:59 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 12 Aug 2008 17:23:59 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

Attached is a patch that add "pipe" command to the "subprocess" module.

pipe(["ls"], ["grep", "test_"]) will return the output of 
"ls | grep test_".

----------
components: Library (Lib)
files: pipe.patch
keywords: patch
messages: 71062
nosy: tebeka
severity: normal
status: open
title: subprocess.pipe function
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11104/pipe.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Tue Aug 12 19:35:22 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 12 Aug 2008 17:35:22 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1218562522.79.0.0773643397645.issue3548@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Not sure about the name, maybe "chain" will be better?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Tue Aug 12 19:38:40 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 17:38:40 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218562720.33.0.227607266543.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Larry Masinter is off on vacation, but I did get a brief message saying
that he will dig up similar discussions that he was involved in when he
gets back.

Out of curiosity, I sent a note off to the www-international mailing
list, and received this:

``For the authority (server name) portion of a URI, RFC 3986 is pretty
clear that UTF-8 must be used for non-ASCII values (assuming, for a
moment, that IDNA addresses are not Punycode encoded already). For the
path portion of URIs, a large-ish proportion of them are, indeed, UTF-8
encoded because that has been the de facto standard in Web browsers for
a number of years now. For the query and fragment parts, however, the
encoding is determined by context and often depends on the encoding of
some page that contains the form from which the data is taken. Thus, a
large number of URIs contain non-UTF-8 percent-encoded octets.''

http://lists.w3.org/Archives/Public/www-international/2008JulSep/0041.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 19:47:35 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 17:47:35 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218563255.63.0.987699803249.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

For Antoine:

I think the problem that Barry is facing with the email package is that
Unicode strings are an ambiguous representation of a sequence of bytes;
that is, there are a number of different byte sequences a Unicode string
may have come from.  His ingenious use of raw-unicode-escape is an
attempt to conform to the requirement of having to produce a string, but
without losing any data, so that an application program can, if it needs
to, still reprocess that string and retrieve the original data.  Naive
application programs that sort of expected the result to be an ASCII
string will be unaffected.  Not sure it's the best idea; this is all
about just where to force unexpected runtime failures.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 20:24:24 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Aug 2008 18:24:24 +0000
Subject: [issue3545] Python turning off assertions (Windows)
In-Reply-To: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>
Message-ID: <1218565464.99.0.880700184741.issue3545@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As you must be building your own Python DLL, anyway, can't you just
simply remove that code if you don't want it?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________

From report at bugs.python.org  Tue Aug 12 20:29:19 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Aug 2008 18:29:19 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1218536973.63.0.436333195078.issue2389@psf.upfronthosting.co.za>
Message-ID: <ca471dc20808121129l180dfdf4jd8142103b20b12e8@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

> Instead of sticking to network byte order, I propose to include byte
> order information in the pickle (for example as '<' or '>' like struct
> does), so that pickling/unpickling between the same-endianness
> architectures doesn't have to convert at all.  Floats are always pickled
> as IEEE754, but the same optimization (not having to convert anything)
> would apply when unpickling a float array on an IEEE754 architecture.
>
> Preserving widths and including endianness information would allow
> pickling to be as fast as it is now (with the exception of unicode chars
> and floats on non-IEEE754 platforms).  It would also allow unpickling to
> be as fast between architecture with equal endianness, and correct
> between others.

This sounds like the best approach yet -- it can be made backwards
compatible (so 2.6 can read 2.5 pickles at least on the same platform)
and can be just as fast when unpickling on the same platform, and only
slightly slower on a different platform.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Tue Aug 12 21:12:38 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 12 Aug 2008 19:12:38 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218568358.81.0.145246025802.issue3419@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

With trunk when running test_multiprocessing in a tight loop I saw 
another problem:

test_multiprocessing
Process Process-61:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 229, in _bootstrap
Process Process-60:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 229, in _bootstrap
Process Process-62:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 229, in _bootstrap
    util._run_after_forkers()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line 
138, in _run_after_forkers
    util._run_after_forkers()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line 
138, in _run_after_forkers
    util._run_after_forkers()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line 
138, in _run_after_forkers
    items = list(_afterfork_registry.items())
    items = list(_afterfork_registry.items())
  File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
  File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
    items = list(_afterfork_registry.items())
  File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
    for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration
    for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration
    for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration

The original problem itself seems to be fixed, so cheers for that!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Tue Aug 12 21:37:41 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 12 Aug 2008 19:37:41 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218569861.3.0.00392322743716.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Here's another thought:

Let's put string_to_bytes and string_from_bytes into the binascii
module, as a2b_percent and b2a_percent, respectively.

Then parse.py would import them as

  from binascii import a2b_percent as percent_decode_as_bytes
  from binascii import b2a_percent as percent_encode_from_bytes

and add two more functions:

  def percent_encode(<string>, encoding="UTF-8", error="strict", plus=False)
  def percent_decode(<string>, encoding="UTF-8", error="strict", plus=False)

and would add backwards-compatible but deprecated functions for quote
and unquote:

  def quote(s):
      warnings.warn("urllib.parse.quote should be replaced by
percent_encode or percent_encode_from_bytes", FutureDeprecationWarning)
      if isinstance(s, str):
          return percent_encode(s)
      else:
          return percent_encode_from_bytes(s)

  def unquote(s):
      warnings.warn("urllib.parse.unquote should be replaced by
percent_decode or percent_decode_to_bytes", FutureDeprecationWarning)
      if isinstance(s, str):
          return percent_decode(s)
      else:
          return percent_decode(str(s, "ASCII", "strict"))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Tue Aug 12 22:57:31 2008
From: report at bugs.python.org (John J Lee)
Date: Tue, 12 Aug 2008 20:57:31 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1218574651.63.0.994749655917.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

The CaseInsensitive dict class fails to preserve its invariants (implied
invariants, since there are no tests for it).  There are also problems
with the documentation in the patch.  I will submit a modified patch, I
hope later this week.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Tue Aug 12 23:11:29 2008
From: report at bugs.python.org (John J Lee)
Date: Tue, 12 Aug 2008 21:11:29 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1218575489.0.0.530469870866.issue2275@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

By the way, this is a feature addition, not a bug fix.  The first beta
releases for 2.6 and 3.0 came out some time ago, so according to PEP
361, this change should not be committed to trunk until after the 2.6 /
3.0 maintenance branches have been created.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Aug 13 00:12:52 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Aug 2008 22:12:52 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218569861.3.0.00392322743716.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218579168.5573.9.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 12 ao?t 2008 ? 19:37 +0000, Bill Janssen a ?crit :
> Let's put string_to_bytes and string_from_bytes into the binascii
> module, as a2b_percent and b2a_percent, respectively.

Well, it's my personal opinion, but I think we should focus on a simple
and straightforward solution for the present issue before beta3 is
released (which is in 8 days now). It has already been difficult to find
a (quasi-)consensus for a simple patch to adapt quote()/unquote() to the
realities of bytes/unicode separation in py3k: witness the length of the
present discussion.

(perhaps a sophisticated solution could still be adopted for 3.1,
especially if it has backwards compatibility in mind)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 01:43:49 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Aug 2008 23:43:49 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218554817.69.0.715071509169.issue3300@psf.upfronthosting.co.za>
Message-ID: <ca471dc20808121643q22abc4e5mb04b416531f28ebe@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

> Matt Giuca <matt.giuca at gmail.com> added the comment:
> By the way, what is the current status of this bug? Is anybody waiting
> on me to do anything? (Re: Patch 9)

I'll be reviewing it today or tomorrow. From looking at it briefly I
worry that the implementation is pretty slow -- a method call for each
character and a map() call sounds pretty bad.

> To recap my previous list of outstanding issues raised by the review:
>
>> Should unquote accept a bytes/bytearray as well as a str?
> Currently, does not. I think it's meaningless to do so (and how to
> handle >127 bytes, if so?)

The bytes > 127 would be translated as themselves; this follows
logically from how stuff is parsed -- %% and %FF are translated,
everything else is not. But I don't really care, I doubt there's a
need.

>> Lib/email/utils.py:
>> Should encode_rfc2231 with charset=None accept strings with non-ASCII
>> characters, and just encode them to UTF-8?
> Currently does. Suggestion to restrict to ASCII on the review tracker;
> simple fix.

I think I agree with that comment; it seems wrong to return UTF8
without setting that in the header. The alternative would be to
default charset to utf8 if there are any non-ASCII chars in the input.
I'd be okay with that too.

>> Should quote raise a TypeError if given a bytes with encoding/errors
>> arguments? (Motivation: TypeError is what you usually raise if you
>> supply too many args to a function).
> Resolved. Raises TypeError.
>
>> Lib/urllib/parse.py:
>> (As discussed above) Should quote accept safe characters outside the
>> ASCII range (thereby potentially producing invalid URIs)?
> Resolved? Implemented, but too messy and not worth it just to produce
> invalid URIs, so NOT in patch.

Agreed, safe should be ASCII chars only.

> That's only two very minor yes/no issues remaining. Please comment.

I believe patch 9 still has errors defaulting to strict for quote().
Weren't you going to change that?

Regarding using UTF-8 as the default encoding, I still think this the
right thing to do -- while the tables shown by Bill indicate that
there's still a lot of Latin-1 out there, UTF-8 is definitely gaining
on it, and I expect that Python apps, especially Py3k apps, are much
more likely to follow (and hopefully reinforce! :-) this trend than to
lag behind.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 02:35:17 2008
From: report at bugs.python.org (cfr)
Date: Wed, 13 Aug 2008 00:35:17 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218587717.86.0.815519887425.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Interesting. At least the "39" makes sense. I don't understand the
documentation well enough to know what the "79" is about.

I'm sorry but I can't work out what I should do with:

  printf("Encoding is %x\n", enc);

Am I meant to use this in python, a standard shell or something else? I
tried in a bash shell and a python interpreter (after undoing my "work
around") and both gave errors - a syntax error in the case of bash; a
complaint about printf being unrecognised in python. I also tried
"import os, sys, locale" first just in case.

  bash: syntax error near unexpected token `"Encoding is %x\n",'

(python)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'printf' is not defined

Sorry for being dumb about this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Aug 13 02:49:37 2008
From: report at bugs.python.org (cfr)
Date: Wed, 13 Aug 2008 00:49:37 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218588577.42.0.979875432037.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Just realised what I'm meant to do with it. Sorry - it is late (early,
actually). Will report back when I get a chance to recompile.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Aug 13 08:15:40 2008
From: report at bugs.python.org (alonwas)
Date: Wed, 13 Aug 2008 06:15:40 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218475800.79.0.23040131264.issue3535@psf.upfronthosting.co.za>
Message-ID: <1218608124.2383.7.camel@alon-lnx.istraresearch.com>


alonwas <alon.was at gmail.com> added the comment:

Hi Antoine,
The problem happens for files between 2GB and 4GB. I can't really send
you a link to such a big file. To reproduce the problem, you can
generate one. I created (and attach) a tiny C program that helps
generate one. If you want to, you can run it, save its output to a file
and then add it to a zip file (it should compress around 12%). The
resulting zip file will fail to open from python using the zipfile
package because of the bug I mentioned. Please let me know whether this
is enough information to reproduce,
Thanks,
Alon

On Mon, 2008-08-11 at 17:30 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Do you have a public URL for such a zip file?
> 
> ----------
> nosy: +pitrou
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3535>
> _______________________________________

Added file: http://bugs.python.org/file11105/large.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: large.c
Type: text/x-csrc
Size: 138 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080813/03268c49/attachment.c>

From report at bugs.python.org  Wed Aug 13 11:03:56 2008
From: report at bugs.python.org (Anders Bensryd)
Date: Wed, 13 Aug 2008 09:03:56 +0000
Subject: [issue3545] Python turning off assertions (Windows)
In-Reply-To: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>
Message-ID: <1218618236.1.0.361974911863.issue3545@psf.upfronthosting.co.za>


Anders Bensryd <anders.bensryd at aveva.com> added the comment:

Yes, we could do that. However, my concerns are:

1) We cannot be the only Python user that experience this issue? I 
would prefer one of these solutions (in this order):
 a) A parameter to Py_Initialize (structure) that controls its 
behaviour.
 b) A #define in pyconfig.h controls whether this should be done or not.
However, since I am not a Python developer myself, I cannot judge how 
much this would affect other things. I also realize that this involves 
some work and that it has very low priority.
2) We have to remember to do this change every time we upgrade to a 
newer version of Python. In earlier releases of Python where 
PyImport_AppendInittab did not exist, we had to do changes to the 
Python code every time we upgraded which was a hazzle. This is why I 
prefer the current workaround we are using where we reset the CRT 
report mode after Py_Initialize().
Your efforts are much appreciated and I realize that the current 
workaround we are using will probably be the final solution.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________

From report at bugs.python.org  Wed Aug 13 11:33:12 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Wed, 13 Aug 2008 09:33:12 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1218619992.02.0.650405181516.issue3492@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Thanks. Will this make into beta3 ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Wed Aug 13 13:24:39 2008
From: report at bugs.python.org (cfr)
Date: Wed, 13 Aug 2008 11:24:39 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218626679.92.0.31561073183.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

It returns 27.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Aug 13 13:51:35 2008
From: report at bugs.python.org (cfr)
Date: Wed, 13 Aug 2008 11:51:35 +0000
Subject: [issue1099] Mac compile fails with pydebug and framework enabled
In-Reply-To: <1188886622.31.0.867109013105.issue1099@psf.upfronthosting.co.za>
Message-ID: <1218628295.82.0.179077870421.issue1099@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Still fails for me on OS X 10.4.11 with latest available xcode (2.5).
This is on PPC with the current stable release of python (2.5.2).

---configure script---
../configure \
        --enable-framework \
        LDFLAGS=-L/usr/local/lib \
        CFLAGS=-I/usr/local/include \
        CPPFLAGS=-I/usr/local/include \
        --with-pydebug \

---error from make---
if test ""; then \
        gcc -o Python.framework/Versions/2.5/Python -arch i386 -arch ppc
-dynamiclib \
                -isysroot "" \
                -all_load libpython2.5.a -Wl,-single_module \
                -install_name
/Library/Frameworks/Python.framework/Versions/2.5/Python \
                -compatibility_version 2.5 \
                -current_version 2.5; \
        else \
        /usr/bin/libtool -o Python.framework/Versions/2.5/Python
-dynamic  libpython2.5.a \
                 -lSystem -lSystemStubs -arch_only ppc -install_name
/Library/Frameworks/Python.framework/Versions/2.5/Python
-compatibility_version 2.5 -current_version 2.5 ;\
fi
ld: Undefined symbols:
___eprintf
/usr/bin/libtool: internal link edit command failed
make: *** [Python.framework/Versions/2.5/Python] Error 1

----------
nosy: +cfr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1099>
_______________________________________

From report at bugs.python.org  Wed Aug 13 14:33:14 2008
From: report at bugs.python.org (cfr)
Date: Wed, 13 Aug 2008 12:33:14 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218630794.59.0.80483887483.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

I noticed there is an issue (http://bugs.python.org/issue1276) with
Japanese Python users on Macs because the relevant codec is removed in
Tools/unicode/Makefile. That file also removes a number of other codecs,
including Mac Celtic. I just wondered if this might be related in some
way because that issue report mentioned problems with getdefaultlocale etc.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Wed Aug 13 16:25:25 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 13 Aug 2008 14:25:25 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218637525.02.0.262767911166.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> I have no strong opinion on the very remaining points you listed,
> except that IMHO ?encode_rfc2231 with charset=None should not try to
> use UTF8 by default. But someone with more mail protocol skills
> should comment :)

OK I've come to the realization that DEMANDING ascii (and erroring on
non-ASCII chars) is better for the short term anyway, because we can
always decide later to relax the restrictions, but it's a lot worse to
add restrictions later. So I agree now, should be ASCII. And no, I don't
have mail protocol skills.

The same goes for unquote accepting bytes. We can decide to make it
accept bytes later, but can't remove that feature later, so it's best
(IMHO) to let it NOT accept bytes (which is the current behaviour).

> The bytes > 127 would be translated as themselves; this follows
> logically from how stuff is parsed -- %% and %FF are translated,
> everything else is not. But I don't really care, I doubt there's a
> need.

Ah but what about unquote (to string)? If it accepted bytes then it
would be a bytes->str operation, and then you need a policy on DEcoding
those bytes. It makes things too complex I think.

> I believe patch 9 still has errors defaulting to strict for quote().
> Weren't you going to change that?

I raised it as a concern, but I thought you overruled on that, so I left
it as errors='strict'. What do you want it to be? 'replace'? Now that
this issue has been fully discussed, I'm happy with whatever you decide.

> From looking at it briefly I
> worry that the implementation is pretty slow -- a method call for each
> character and a map() call sounds pretty bad.

Yes, it does sound pretty bad. However, that's the current way of doing
things in both 2.x and 3.x; I didn't change it (though it looks like I
changed a LOT, I really did try to change as little as possible!)
Assuming it wasn't made _slower_ than before, can we ignore existing
performance issues and treat them as a separate matter (and can be dealt
with after 3.0)?

I'm not putting up a new patch now. The only fix I'd make is to add
Antoine's "or 'ascii'" to email/utils.py, as suggested on the review
tracker. I'll make this change along with any other recommendations
after your review.

(That is Lib/email/utils.py line 222 becomes:
s = urllib.parse.quote(s, safe='', encoding=charset or 'ascii')
)

btw this Rietveld is amazing. I'm assuming I don't have permission to
upload patches there (can't find any button to do so) which is why I
keep posting them here and letting you upload to Rietveld ...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 16:28:56 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Aug 2008 14:28:56 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218637736.26.0.33280374566.issue3300@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
nosy:  -lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 16:50:31 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Aug 2008 14:50:31 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218637525.02.0.262767911166.issue3300@psf.upfronthosting.co.za>
Message-ID: <ca471dc20808130750s66654b18ra03b809cd3339117@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Wed, Aug 13, 2008 at 7:25 AM, Matt Giuca <report at bugs.python.org> wrote:
>> I have no strong opinion on the very remaining points you listed,
>> except that IMHO ?encode_rfc2231 with charset=None should not try to
>> use UTF8 by default. But someone with more mail protocol skills
>> should comment :)
>
> OK I've come to the realization that DEMANDING ascii (and erroring on
> non-ASCII chars) is better for the short term anyway, because we can
> always decide later to relax the restrictions, but it's a lot worse to
> add restrictions later. So I agree now, should be ASCII. And no, I don't
> have mail protocol skills.

OK.

> The same goes for unquote accepting bytes. We can decide to make it
> accept bytes later, but can't remove that feature later, so it's best
> (IMHO) to let it NOT accept bytes (which is the current behaviour).

OK.

>> The bytes > 127 would be translated as themselves; this follows
>> logically from how stuff is parsed -- %% and %FF are translated,
>> everything else is not. But I don't really care, I doubt there's a
>> need.
>
> Ah but what about unquote (to string)? If it accepted bytes then it
> would be a bytes->str operation, and then you need a policy on DEcoding
> those bytes. It makes things too complex I think.

OK.

>> I believe patch 9 still has errors defaulting to strict for quote().
>> Weren't you going to change that?
>
> I raised it as a concern, but I thought you overruled on that, so I left
> it as errors='strict'. What do you want it to be? 'replace'? Now that
> this issue has been fully discussed, I'm happy with whatever you decide.

I'm OK with replace for unquote(), your point that bogus data is
better than an exception is well taken, especially since there are
calls that the app can't control (like in cgi.py).

For quote() I think strict is better -- it can't fail anyway with
UTF8, and if an app passes an explicit conversion it'd be pretty
stupid to pass a string that can't be converted with that encoding
(since it's presumably the app that generates both the string and the
encoding) so it's better to complain there, just like if they made the
encode() call themselves with only an encoding specified. This means
we have a useful analogy: quote(s, e) == quote(s.encode(e)).

>> From looking at it briefly I
>> worry that the implementation is pretty slow -- a method call for each
>> character and a map() call sounds pretty bad.
>
> Yes, it does sound pretty bad. However, that's the current way of doing
> things in both 2.x and 3.x; I didn't change it (though it looks like I
> changed a LOT, I really did try to change as little as possible!)

Actually, while the Quoter class (the immediat subject of my scorn)
was there before your patch in 3.0, it isn't there in 2.x; somebody
must have added it in 3.0 as part of the conversion to Unicode or
perhaps as part of the restructuring of urllib.py. The 2.x code maps
the __getitem__ of a dict over the string, which is much faster. I
think we can do much better than mapping a method call.

> Assuming it wasn't made _slower_ than before, can we ignore existing
> performance issues and treat them as a separate matter (and can be dealt
> with after 3.0)?

Now that you've spent so  much time with this patch, can't you think
of a faster way of doing this? I wonder if mapping a defaultdict
wouldn't work.

> I'm not putting up a new patch now. The only fix I'd make is to add
> Antoine's "or 'ascii'" to email/utils.py, as suggested on the review
> tracker. I'll make this change along with any other recommendations
> after your review.
>
> (That is Lib/email/utils.py line 222 becomes:
> s = urllib.parse.quote(s, safe='', encoding=charset or 'ascii')
> )
>
> btw this Rietveld is amazing. I'm assuming I don't have permission to
> upload patches there (can't find any button to do so) which is why I
> keep posting them here and letting you upload to Rietveld ...

Thanks! You can't upload patches to the issue that *I* created, but a
better way would be to create a new issue and assign it to me for
review. That will work as long as you have a gmail account or a Google
Account. I highly recommend using the upload.py script, which you can
download from codereview.appspot.com/static/upload.py. (There's also a
link to it on the Create Issue page, at the bottom.)

I am hoping that in general we will be able to use Rietveld to review
patches instead of the bug tracker.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 17:09:00 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 13 Aug 2008 15:09:00 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218640140.82.0.343772051654.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> I'm OK with replace for unquote() ...
> For quote() I think strict is better 

There's just an odd inconsistency there, but it's only a tiny "gotcha";
and I agree with all your other arguments. I'll change unquote back to
errors='replace'.

> This means we have a useful analogy:
> quote(s, e) == quote(s.encode(e)).

That's exactly true, yes.

> Now that you've spent so  much time with this patch, can't you think
> of a faster way of doing this?

Well firstly, you could replace Quoter (the class) with a "quoter"
function, which is nested inside quote. Would calling a nested function
be faster than a method call?

> I wonder if mapping a defaultdict wouldn't work.

That is a good idea. Then, the "function" (as I describe above) would be
just the inside of what currently is the except block, and that would be
the default_factory of the defaultdict. I think that should speed things up.

I'm very hazy about what is faster in the bytecode world of Python, and
wary of making a change and proclaiming "this is faster!" without doing
proper speed tests (which is why I think this optimisation could be
delayed until at least after the core interface changes are made). But
I'll have a go at that change tomorrow.

(I won't be able to work on this for up to 24 hours).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 18:02:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2008 16:02:07 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218640140.82.0.343772051654.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218643340.48a3058cd4021@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon Matt Giuca <report at bugs.python.org>:
>
> > Now that you've spent so  much time with this patch, can't you think
> > of a faster way of doing this?
>
> Well firstly, you could replace Quoter (the class) with a "quoter"
> function, which is nested inside quote. Would calling a nested function
> be faster than a method call?

The obvious speedup is to remove the map() call and do the loop inside
Quoter.__call__ instead. That way you don't have any function or method call in
the critical path.

(also, defining a class with a single __call__ method is not a common Python
idiom; usually you'd just have a function returning another (nested) function)

As for the defaultdict, here is how it can look like (this is on 2.5):

...  def __missing__(self, key):
...   print "__missing__", key
...   value = "%%%02X" % key
...   self[key] = value
...   return value
...
>>> d = D()
>>> d[66] = 'B'
>>> d[66]
'B'
>>> d[67]
__missing__ 67
'%43'
>>> d[67]
'%43'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 18:03:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2008 16:03:28 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218643340.48a3058cd4021@imp.free.fr>
Message-ID: <1218643422.48a305de2a897@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon Antoine Pitrou <report at bugs.python.org>:
> As for the defaultdict, here is how it can look like (this is on 2.5):
>

(there should be a line here saying "class D(defaultdict)" :-))

> ...  def __missing__(self, key):
> ...   print "__missing__", key
> ...   value = "%%%02X" % key
> ...   self[key] = value
> ...   return value

cheers

Antoine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 18:26:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2008 16:26:16 +0000
Subject: [issue3383] ctypes.util fails to find libc in some environments
In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za>
Message-ID: <1218644776.36.0.0241610150255.issue3383@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, I have no idea what the standard setup on posix boxes is - should
> objdump and ldconfig be on $PATH or not?

I think it should try first in $PATH and, if not found, try in /usr/sbin
afterwards. /usr/sbin isn't always in $PATH when in non-root mode.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3383>
_______________________________________

From report at bugs.python.org  Wed Aug 13 18:41:44 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Aug 2008 16:41:44 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218640140.82.0.343772051654.issue3300@psf.upfronthosting.co.za>
Message-ID: <ca471dc20808130941n46671892o5dcdd0915780bf7@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

>> Now that you've spent so  much time with this patch, can't you think
>> of a faster way of doing this?
>
> Well firstly, you could replace Quoter (the class) with a "quoter"
> function, which is nested inside quote. Would calling a nested function
> be faster than a method call?

Yes, but barely.

>> I wonder if mapping a defaultdict wouldn't work.
>
> That is a good idea. Then, the "function" (as I describe above) would be
> just the inside of what currently is the except block, and that would be
> the default_factory of the defaultdict. I think that should speed things up.

Yes, it would be tremendously faster, since the method would be called
only once per byte value (for each value of 'safe'), and if that byte
is repeated in the input, further occurrences will use the __getitem__
function of the defaultdict, which is implemented in C.

> I'm very hazy about what is faster in the bytecode world of Python, and
> wary of making a change and proclaiming "this is faster!" without doing
> proper speed tests (which is why I think this optimisation could be
> delayed until at least after the core interface changes are made).

That's very wise. But a first-order approximation of the speed of
something is often "how many functions/methods implemented in Python
(i.e. with def or lambda) does it call?"

> But I'll have a go at that change tomorrow.
>
> (I won't be able to work on this for up to 24 hours).

That's fine, as long as we have closure before beta3, which is next Wednesday.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 18:56:12 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 13 Aug 2008 16:56:12 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <ca471dc20808130941n46671892o5dcdd0915780bf7@mail.gmail.com>
Message-ID: <4b3e516a0808130956l6b551eeai330a83d142f72089@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Feel free to take the function implementation from my patch, if it speeds
things up (and it should).

Bill

On Wed, Aug 13, 2008 at 9:41 AM, Guido van Rossum <report at bugs.python.org>wrote:

>
> Guido van Rossum <guido at python.org> added the comment:
>
> >> Now that you've spent so  much time with this patch, can't you think
> >> of a faster way of doing this?
> >
> > Well firstly, you could replace Quoter (the class) with a "quoter"
> > function, which is nested inside quote. Would calling a nested function
> > be faster than a method call?
>
> Yes, but barely.
>
> >> I wonder if mapping a defaultdict wouldn't work.
> >
> > That is a good idea. Then, the "function" (as I describe above) would be
> > just the inside of what currently is the except block, and that would be
> > the default_factory of the defaultdict. I think that should speed things
> up.
>
> Yes, it would be tremendously faster, since the method would be called
> only once per byte value (for each value of 'safe'), and if that byte
> is repeated in the input, further occurrences will use the __getitem__
> function of the defaultdict, which is implemented in C.
>
> > I'm very hazy about what is faster in the bytecode world of Python, and
> > wary of making a change and proclaiming "this is faster!" without doing
> > proper speed tests (which is why I think this optimisation could be
> > delayed until at least after the core interface changes are made).
>
> That's very wise. But a first-order approximation of the speed of
> something is often "how many functions/methods implemented in Python
> (i.e. with def or lambda) does it call?"
>
> > But I'll have a go at that change tomorrow.
> >
> > (I won't be able to work on this for up to 24 hours).
>
> That's fine, as long as we have closure before beta3, which is next
> Wednesday.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3300>
> _______________________________________
>

Added file: http://bugs.python.org/file11106/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080813/c121667b/attachment.txt>

From report at bugs.python.org  Wed Aug 13 19:05:21 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 13 Aug 2008 17:05:21 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218647121.49.0.344183013642.issue3300@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Erik van der Poel at Google has now chimed in with stats on current URL
usage:

``...the bottom line is that escaped non-utf-8 is still quite prevalent,
enough (in my opinion) to require an implementation in Python, possibly
even allowing for different encodings in the path and query parts (e.g.
utf-8 path and gb2312 query).''

http://lists.w3.org/Archives/Public/www-international/2008JulSep/0042.html

I think it's worth remembering that a very large proportion of the use
of Python's urllib.unquote() is in implementations of Web server
frameworks of one sort or another.  We can't control what the browsers
that talk to such frameworks produce; the IETF doesn't control that,
either.  In this case, "practicality beats purity" is the clarion call
of the browser designers, and we'd better be able to support them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 19:17:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Aug 2008 17:17:20 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218647121.49.0.344183013642.issue3300@psf.upfronthosting.co.za>
Message-ID: <ca471dc20808131017t2176cdbfwc70439529887feb6@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

> Bill Janssen <bill.janssen at gmail.com> added the comment:
>
> Erik van der Poel at Google has now chimed in with stats on current URL
> usage:
>
> ``...the bottom line is that escaped non-utf-8 is still quite prevalent,
> enough (in my opinion) to require an implementation in Python, possibly
> even allowing for different encodings in the path and query parts (e.g.
> utf-8 path and gb2312 query).''
>
> http://lists.w3.org/Archives/Public/www-international/2008JulSep/0042.html
>
> I think it's worth remembering that a very large proportion of the use
> of Python's urllib.unquote() is in implementations of Web server
> frameworks of one sort or another.  We can't control what the browsers
> that talk to such frameworks produce; the IETF doesn't control that,
> either.  In this case, "practicality beats purity" is the clarion call
> of the browser designers, and we'd better be able to support them.

I think we're supporting these sufficiently by allowing developers to
override the encoding and errors value. I see no argument here against
having a default encoding of UTF-8.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 19:51:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2008 17:51:36 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218647121.49.0.344183013642.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218649889.5646.13.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 13 ao?t 2008 ? 17:05 +0000, Bill Janssen a ?crit :
> I think it's worth remembering that a very large proportion of the use
> of Python's urllib.unquote() is in implementations of Web server
> frameworks of one sort or another.  We can't control what the browsers
> that talk to such frameworks produce;

Yes, we do. Browsers will use whatever charset is specified in the HTML
for the query part; and, as for the path part, they should't produce it
themselves, they just follow a link which should already be
percent-quoted in the HTML.

(URL rewriting at the HTTP server level can make this more complicated,
since it can turn a query fragment into a path fragment or vice-versa;
however, most modern frameworks alleviate the need for such rewriting,
since they allow to specify flexible mapping rules at the framework
level)

The situation in which we can't control the encoding is when getting the
URLs from third-part content (e.g. some Web page which we didn't produce
ourselves, or some link in an e-email). But in those cases there's less
use cases for unquoting the URL rather than use it as-is. The only time
I've wanted to unquote such an URL was to do some processing of HTTP
referrers in order to extract which search queries had led people to
visit a Web site.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 20:07:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2008 18:07:36 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218557748.69.0.763380143047.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218650852.5646.26.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 12 ao?t 2008 ? 16:15 +0000, Martin v. L?wis a ?crit :
> I also started working on porting it to 3.0, but couldn't complete that
> port yet - the memoryview object doesn't play nicely.

I've seen your recent merge and I don't know if you have finished with
it.

I think we should drop the "base" member in PyMemoryViewObject, it has
become redundant and confusing. There are some places in memoryobject.c
where base seems mistakingly used instead of view.obj, e.g.
PyMemoryView_FromMemory INCREFs view.obj, but memory_dealloc DECREFs
base.
Also, I don't understand why memory_getbuf INCREFs view.obj, there is no
corresponding DECREF in memory_releasebuf and view.obj should already
have been INCREFed anyway.

(if people want to get easily at the base object, we could provide be a
macro e.g. PyMemory_GET_BASE())

By the way, perhaps PyBuffer_Release should set view->obj and view->buf
to NULL (and view->len to -1?), it would be a simple way to signal that
the buffer can't be used anymore.

What do you think?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Wed Aug 13 20:09:22 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Aug 2008 18:09:22 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1218650962.27.0.203893298982.issue3473@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Another use case: upon reading A.Baxter's Porting to 3 talk, I realized,
slightly generalizing from his example, that
print(s.join(map(str,it))) == print(*it,sep=s) -- or would, except that
it currently has to be written non-intuitively as print(sep=s,*it),
which I might not have tried except for knowing about this issue.

Given that many have problems with .join and that most uses are to
produce immediate output not otherwise processed, I think having the
replacement work in the way many would expect would be a win.
So I hope this makes the next beta.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Wed Aug 13 21:49:35 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 13 Aug 2008 19:49:35 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1218656975.86.0.667836320722.issue2548@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

FWIW, rev58032 introduced this:
    tstate = PyThreadState_GET();
    if (++tstate->recursion_depth > Py_GetRecursionLimit()) {
        --tstate->recursion_depth;
        PyErr_SetObject(PyExc_RuntimeError, PyExc_RecursionErrorInst);
        return;
    }
above this line: 
    PyErr_NormalizeException(exc, val, tb);

Contrary to (what I understand from) Amaury's analysis, ISTM that the
call to PyErr_SetObject is the problem, as after the recursion limit is
hit PyErr_NormalizeException isn't called again.

Commenting off the PyErr_SetObject line suppresses the "undetected
errors" and passes the unittests (including the infinite recursion
crashers removed in that rev). I have no idea about the problems it may
cause, though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Wed Aug 13 21:49:52 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 13 Aug 2008 19:49:52 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218649889.5646.13.camel@fsol>
Message-ID: <4b3e516a0808131249g465e9312m9c7fe85b858867d6@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

On Wed, Aug 13, 2008 at 10:51 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le mercredi 13 ao?t 2008 ? 17:05 +0000, Bill Janssen a ?crit :
> > I think it's worth remembering that a very large proportion of the use
> > of Python's urllib.unquote() is in implementations of Web server
> > frameworks of one sort or another.  We can't control what the browsers
> > that talk to such frameworks produce;
>
> Yes, we do. Browsers will use whatever charset is specified in the HTML
> for the query part; and, as for the path part, they should't produce it
> themselves, they just follow a link which should already be
> percent-quoted in the HTML.

Sure.  What I meant was that we don't control what the browsers do, we just
go along with what they do, that is, we try to play with the default
understanding that's developed between the "consenting pairs" of
Apache/Firefox or ASP/IE.

Added file: http://bugs.python.org/file11107/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080813/23979c3b/attachment.txt>

From report at bugs.python.org  Wed Aug 13 22:11:53 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Aug 2008 20:11:53 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218658313.57.0.658234077723.issue3300@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file11107/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 22:12:00 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Aug 2008 20:12:00 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218658320.22.0.587656759782.issue3300@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file11106/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 13 22:23:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 13 Aug 2008 20:23:10 +0000
Subject: [issue3545] Python turning off assertions (Windows)
In-Reply-To: <1218618236.1.0.361974911863.issue3545@psf.upfronthosting.co.za>
Message-ID: <48A342A9.1060700@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 2) We have to remember to do this change every time we upgrade to a 
> newer version of Python. 

Every new MSVC release brings new problems, as far back as I remember.
Did you actually try to turn it off? Did it work? What if you do
'open("foo","bar")'? IIRC, turning this CRT checking code back on,
regular Python code can now crash Python, by triggering a CRT
assertion (these assertions are stupid, in the sense that they ban
behavior that is completely conforming to the ISO C standard, and
consider it incorrect). Turning off the assertions is the only
supported way to override the CRT behavior to crash the application.

I don't quite understand why this all affects your code. Are you
using ASSERT() by any chance? If so, why are you not using assert()
instead? That doesn't go through CrtDebugReport, AFAICT.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________

From report at bugs.python.org  Wed Aug 13 23:03:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 13 Aug 2008 21:03:48 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218650852.5646.26.camel@fsol>
Message-ID: <48A34C30.5030208@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I've seen your recent merge and I don't know if you have finished with
> it.

Indeed, I'm done, r65654. Unless there are actual bugs in these patches
(in the sense that they don't fix the reported problem, or introduce new
bugs), I'd like to close this issue.

> I think we should drop the "base" member in PyMemoryViewObject, it has
> become redundant and confusing.

I tried, and failed; feel free to submit a patch (as a new issue).
The tricky part is that base is sometimes used as a tuple.

> Also, I don't understand why memory_getbuf INCREFs view.obj, there is no
> corresponding DECREF in memory_releasebuf and view.obj should already
> have been INCREFed anyway.

Ok, that's an open issue. Is the caller of FromMemory supposed to do
Buffer_Release afterwards, or is ownership of the buffer transferred
in the FromMemory call? (the issue didn't exist when the embedded
reference was borrowed)

To put it another way: view.obj has *not* been INCREFed. *view holds
a reference, but that reference belongs to the caller, not to the memory
object. Every time you initialize a PyObject* (such as view.obj), you
need to INCREF, unless it's a borrowed reference.

In any case, the corresponding DECREF *does* exist: in memory_dealloc,
PyBuffer_Release is invoked, which releases the reference.

> By the way, perhaps PyBuffer_Release should set view->obj and view->buf
> to NULL (and view->len to -1?), it would be a simple way to signal that
> the buffer can't be used anymore.

That can be done; it's again a separate patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Wed Aug 13 23:12:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2008 21:12:31 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218661951.33.0.447411702856.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In any case, the corresponding DECREF *does* exist: in memory_dealloc,
> PyBuffer_Release is invoked, which releases the reference.

I'm a bit confused. In the PyBuffer_Release implementation you
committed, there is no DECREF at all.

> > By the way, perhaps PyBuffer_Release should set view->obj and view->buf
> > to NULL (and view->len to -1?), it would be a simple way to signal that
> > the buffer can't be used anymore.
> 
> That can be done; it's again a separate patch.

Ok.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Wed Aug 13 23:29:14 2008
From: report at bugs.python.org (Paul Chew)
Date: Wed, 13 Aug 2008 21:29:14 +0000
Subject: [issue3549] Missing IDLE Preferences on Mac
In-Reply-To: <1218662954.17.0.753425221317.issue3549@psf.upfronthosting.co.za>
Message-ID: <1218662954.17.0.753425221317.issue3549@psf.upfronthosting.co.za>


New submission from Paul Chew <chew at cs.cornell.edu>:

When the latest Mac installer (Python 2.5.2 for Macintosh OS X) is used on 
a new Mac (10.5.4) the resulting IDLE does not have a Preferences... entry 
in its File menu.  The only fix that I've found is to use the previous Mac 
installer (python-2.5.1-macosx.dmg).

----------
components: IDLE, Installation, Macintosh
messages: 71100
nosy: pchew
severity: normal
status: open
title: Missing IDLE Preferences on Mac
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3549>
_______________________________________

From report at bugs.python.org  Thu Aug 14 00:11:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Aug 2008 22:11:14 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218608124.2383.7.camel@alon-lnx.istraresearch.com>
Message-ID: <1218665470.22748.9.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The problem happens for files between 2GB and 4GB. I can't really send
> you a link to such a big file. To reproduce the problem, you can
> generate one.

The problem is that the "zip" command fails to create a zip file larger
than 2GB (I get "zip I/O error: Invalid argument"). And even if it
didn't fail the internal structure of the zip file might not be exactly
the same as with other compression tools. That's why I was asking you
for an existing file.

If I give you an ssh/sftp access somewhere, would you be able to upload
such a file?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Thu Aug 14 02:30:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 00:30:26 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218673826.13.0.894533555944.issue3362@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, now that we have established that the user's encoding is supposed to
be mac-celtic, I think I understand the problem: there simply isn't any
IANA charset name for the mac-celtic encoding, so
CFStringConvertEncodingToIANACharSetName doesn't return any.

If we want to support these systems, I think we need to add another
switch case for mac-celtic. That alone won't be sufficient, as we then
also need an implementation of the encoding, i.e. change Tools/unicode
to preserve mac-celtic.

To better detect that case in the future, it might be useful to return
mac-unsupported as the script name if it isn't in the switch statement
and doesn't have a IANA name, and then alias mac-unknown to ASCII.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Thu Aug 14 03:50:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 Aug 2008 01:50:46 +0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1218678646.78.0.589816007929.issue2065@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I have committed remaining VC6 patch. (I postponed _multiprocessing
module support addition because I sometimes experiences nasty error
message "pipe was closed" or "resource is not enough" in
test_multiprocessing. I cannot reproduce it by simply running only
test_multiprocessing, it occurs in regrtest. :-(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
_______________________________________

From report at bugs.python.org  Thu Aug 14 03:56:29 2008
From: report at bugs.python.org (cfr)
Date: Thu, 14 Aug 2008 01:56:29 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218678989.31.0.267211029563.issue3362@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Do you happen to know why it is returning 27? Is that correct or should
it be returning something else (e.g. 39)?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Thu Aug 14 04:24:20 2008
From: report at bugs.python.org (Andrew R.)
Date: Thu, 14 Aug 2008 02:24:20 +0000
Subject: [issue3550] Socket Python 3k Documentation failure OR Unicode string
	is not supported with socket.send
In-Reply-To: <1218680660.59.0.981908565171.issue3550@psf.upfronthosting.co.za>
Message-ID: <1218680660.59.0.981908565171.issue3550@psf.upfronthosting.co.za>


New submission from Andrew R. <ajr1991 at comcast.net>:

I am confused by the socket docs for Python 3000. It says to pass a
string through socket.send or socket.sendall, however, it does not seem
to account for the ASCII to Unicode transition. Trying to send an
ordinary Python 3k string through socket.send fails with a TypeError
stating that the first arg must be bytes or buffers but not a str.

Besides the misdocumented sockets, I would think it would be easier to
translate a Unicode string to ASCII, however, I fear this might violate
the "Explicit is better than implicit" rule and RFC tables.

----------
assignee: georg.brandl
components: Documentation
messages: 71105
nosy: georg.brandl, st33med
severity: normal
status: open
title: Socket Python 3k Documentation failure OR Unicode string is not supported with socket.send
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3550>
_______________________________________

From report at bugs.python.org  Thu Aug 14 04:32:50 2008
From: report at bugs.python.org (Andrew R.)
Date: Thu, 14 Aug 2008 02:32:50 +0000
Subject: [issue3550] Socket Python 3k Documentation mistake OR Unicode string
	is not supported with socket.send
In-Reply-To: <1218680660.59.0.981908565171.issue3550@psf.upfronthosting.co.za>
Message-ID: <1218681170.01.0.436274453334.issue3550@psf.upfronthosting.co.za>


Andrew R. <ajr1991 at comcast.net> added the comment:

http://docs.python.org/dev/3.0/library/socket.html

The examples at the bottom also add to the confusion.
Also, changed title to be friendlier (failure? Mistake, more likely) and
changed type to no selection.

----------
title: Socket Python 3k Documentation failure OR Unicode string is not supported with socket.send -> Socket Python 3k Documentation mistake OR Unicode string is not supported with socket.send
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3550>
_______________________________________

From report at bugs.python.org  Thu Aug 14 04:36:44 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Aug 2008 02:36:44 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1218656975.86.0.667836320722.issue2548@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808131936y58107e9em4299a3d4f9fbe3d6@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Aug 13, 2008 at 12:49 PM, Daniel Diniz <report at bugs.python.org> wrote:
>
> Daniel Diniz <ajaksu at gmail.com> added the comment:
>
> FWIW, rev58032 introduced this:
>    tstate = PyThreadState_GET();
>    if (++tstate->recursion_depth > Py_GetRecursionLimit()) {
>        --tstate->recursion_depth;
>        PyErr_SetObject(PyExc_RuntimeError, PyExc_RecursionErrorInst);
>        return;
>    }
> above this line:
>    PyErr_NormalizeException(exc, val, tb);
>
> Contrary to (what I understand from) Amaury's analysis, ISTM that the
> call to PyErr_SetObject is the problem, as after the recursion limit is
> hit PyErr_NormalizeException isn't called again.
>
> Commenting off the PyErr_SetObject line suppresses the "undetected
> errors" and passes the unittests (including the infinite recursion
> crashers removed in that rev). I have no idea about the problems it may
> cause, though.
>

If I remember correctly, that is on purpose as normalizing the
exception could lead to the stack being blown again. But this totally
off of memory, so I could be wrong.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Thu Aug 14 04:40:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Aug 2008 02:40:06 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1218681606.94.0.103024214518.issue2394@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Thu Aug 14 06:25:56 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 14 Aug 2008 04:25:56 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1218687955.91.0.887910168406.issue3488@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3488>
_______________________________________

From report at bugs.python.org  Thu Aug 14 07:50:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 05:50:09 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1218693009.96.0.514668320099.issue3362@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

0x27==39. It's all fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Thu Aug 14 08:21:53 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 14 Aug 2008 06:21:53 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218694913.55.0.0621802710444.issue2389@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I'm all in for a standardized representation of array's pickles (with
width and endianness preserved). However to happen, we will either need
to change array's constructor to support at least the byte-order
specification (like struct) or add built-in support for array in the
pickle module (which could be done without modifying the pickle protocol).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Thu Aug 14 09:18:45 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 07:18:45 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1218698325.95.0.470407425672.issue2389@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think changing the array constructor is fairly easy: just pick a set
of codes that are defined to be platform-neutral (i.e. for each size two
codes, one for each endianness). For example, the control characters
(\0..\x1F) could be used in the following way:

char, signed-byte, unsigned byte: c, b, B
(big/little)
sint16: 1,2 uint16: 3,4
sint32: 5,6 uint32: 7,8
sint64: 9,10 uint64: 11,12
float:  13,14 double: 15,16
UCS-2:  17,18 UCS-4: 19,20

In above scheme, even codes are little-endian, odd codes are big endian.
Converting the codes to "native" codes could be table-driven.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Thu Aug 14 09:29:55 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 14 Aug 2008 07:29:55 +0000
Subject: [issue2756] urllib2 add_header fails with existing unredirected_header
In-Reply-To: <1209913898.38.0.175541514636.issue2756@psf.upfronthosting.co.za>
Message-ID: <1218698995.26.0.974357871044.issue2756@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

The submitted patch has problems. It does not correctly solve this issue
(which I want to confirm, if there is issue at all after understanding
the logic behind unredirected_headers). My explanation of this issue and
comments on the patch is here:
http://urllib-gsoc.blogspot.com/2008/08/issue2756-urllib2-addheader-fails-with.html

Now, coming back to the current issue. We see that addition of
unredirected_hdrs takes place in the do_request_ call of
AbstractHTTPHandler and it adds the unredirected_hdrs based on certain
conditions, like when Content-Type is not there in header add the
unredirected header ('Content-Type','application/x-www-form-urlencoded')
The value of Content-Type is hardcoded here, but other header values are
not hardcoded and got from header request only.

Question here is: When the request contains the Content-Type header and
has a updated value, why is it not supposed to change the
unredirected_header to the updated value?  (Same for other request
header items).

John J Lee, can perhaps help us understand more.

If it is supposed to change, then the following snippet (rough) at
do_request_
for key, value in request.headers:
      request.add_unredirected_header(key,request.get_header(key))
should update it, there is no need to change the add_header and
add_unredirected_header method as proposed by the patch.

On our conclusion, I shall provide the updated patch (if required).

Thanks,
Senthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2756>
_______________________________________

From report at bugs.python.org  Thu Aug 14 09:35:44 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 14 Aug 2008 07:35:44 +0000
Subject: [issue2756] urllib2 add_header fails with existing unredirected_header
In-Reply-To: <1209913898.38.0.175541514636.issue2756@psf.upfronthosting.co.za>
Message-ID: <1218699344.98.0.14379723302.issue2756@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

The problem with the patch was:

The attached patch modifies the add_header() and
add_unredirected_header() method to remove the existing headers of the
same name alternately in the headers and unredirected_hdrs.

What we observe is unredirected_hdrs item is removed during add_header()
calland it is never added back/updated in teh undirected_hdrs.

Let us discuss on the points mentioned in my previous post.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2756>
_______________________________________

From report at bugs.python.org  Thu Aug 14 09:47:28 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 Aug 2008 07:47:28 +0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1218700048.69.0.527152303662.issue2065@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Can I close this entry?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
_______________________________________

From report at bugs.python.org  Thu Aug 14 10:32:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 08:32:09 +0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1218702729.27.0.115772579765.issue2065@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Sure. Feel free to commit any further changes to these build files directly.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
_______________________________________

From report at bugs.python.org  Thu Aug 14 11:22:50 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Aug 2008 09:22:50 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1218705770.99.0.974276521649.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

With the patch, the following code causes a
non-keyboard-interruptible interpreter hang.

>>> from sys import maxint
>>> (-maxint-1).numbits()

[... interpreter hang ...]

The culprit is, of course, the statement

if (n < 0)
    n = -n;

in int_numbits: LONG_MIN is negated to itself (this may
even be undefined behaviour according to the C standards).

The patch also needs documentation, and that documentation
should clearly spell out what happens for zero and for
negative numbers.  It's not at all clear that everyone
will expect (0).numbits() to be 0, though I agree that this
is probably the most useful definition in practice.

One could make a case for (0).numbits() raising ValueError:
for some algorithms, what one wants is an integer k such
that 2**(k-1) <= abs(n) < 2**k; when n == 0 no such
integer exists.

Other than those two things, I think the patch looks fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Thu Aug 14 11:47:11 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Aug 2008 09:47:11 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1218707231.58.0.459715716283.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One possible fix would be to compute the absolute value
of n as an unsigned long. I *think* the following is
portable and avoids any undefined behaviour coming
from signed arithmetic overflow.

unsigned long absn;
if (n < 0)
	absn = 1 + (unsigned long)(-1-n);
else
	absn = (unsigned long)n;

Might this work?

Perhaps it would also be worth changing the tests
in test_int from e.g.

self.assertEqual((-a).numbits(), i+1)

to

self.assertEqual(int(-a).numbits(), i+1)

This would have caught the -LONG_MAX error.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Thu Aug 14 11:48:18 2008
From: report at bugs.python.org (Anders Bensryd)
Date: Thu, 14 Aug 2008 09:48:18 +0000
Subject: [issue3545] Python turning off assertions (Windows)
In-Reply-To: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>
Message-ID: <1218707298.0.0.670382826814.issue3545@psf.upfronthosting.co.za>


Anders Bensryd <anders.bensryd at aveva.com> added the comment:

We started using Python 2.5.2 recently and a few developers have 
complained that they do not get any assertions anymore so yes, we do 
use _ASSERT() and _ASSERTE(), but after a brief look it seems as if we 
mainly use assert(). The developer using _ASSERT() cannot remember why 
this was necessary and the tests I have made today shows that we could 
probably move to assert() everywhere.

A more interesting aspect is that we have recently moved the the more 
secure CRT routines (strcpy_s etc) and tests have shown issues with 
these if we turn off assertions:

 int prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,0);
 char str[8];
 strcpy_s(str,"123456789");

With assertions turned on, I get an assertion dialog saying "Buffer is 
too small" which is what I expect and want. With assertions turned off 
(as in the example above), I get a dialog saying "Microsoft Visual 
Studio C Runtime Library has detected a fatal error in crt.exe.".

The stack is still useful and we can find the cause of the error so it 
is not a serious problem for us since we will continue to turn on 
assertions after Py_Initialize().

I have not yet seen any examples where the are erroneous assertions.

Anyway, you have made your point and I really do not want to take up 
anymore of your time. I respect your opinion and at least I have forced 
you to think about this. We have a workaround that works for us so I am 
OK with closing this issue.

Many thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:10:15 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Aug 2008 11:10:15 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1218712215.3.0.105759119655.issue2819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch, in final form, that replaces fsum with an lsum-based
implementation.  In brief, the accumulated sum-so-far is represented in
the form

  huge_integer * 2**(smallest_possible_exponent)

and the huge_integer is stored in base 2**30, with a signed-digit representation (digits 
in the range [-2**29, 2**29).

What are the chances of getting this in before next week's beta?

I did toy with a base 2**52 version, with digits stored as doubles.  It's attractive for 
a couple of reasons: (1) each 53-bit double straddles exactly two digits, which makes 
the inner loop more predictable and removes some branches, and (2) one can make some 
optimizations (e.g. being sloppy about transferring single-bit carries to the next digit 
up) based on the assumption that the input is unlikely to have more than 2**51 summands.  The result was slightly faster on OS X, and slower on Linux;  the final rounding code 
also became a little more complicated (as a result of not being able to do bit 
operations on a double easily), and making sure that things work for non IEEE doubles is 
a bit of a pain.  So in the end I abandoned this approach.

Added file: http://bugs.python.org/file11108/fsum11.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:11:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 Aug 2008 11:11:21 +0000
Subject: [issue3551] multiprocessing.Pipe terminates with
	ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
In-Reply-To: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
Message-ID: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed sometimes regrtest.py fails in test_multiprocessing.py
(test_connection) on win2000.

I could not reproduce error by invoking test_multiprocessing alone, but
finally I could do it by incresing 'really_big_msg' to 32MB or more.

I attached reproducable code. I don't know why this happens yet.

----------
components: Library (Lib), Windows
files: reproduce.py
messages: 71119
nosy: ocean-city
severity: normal
status: open
title: multiprocessing.Pipe terminates with ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
versions: Python 2.6
Added file: http://bugs.python.org/file11109/reproduce.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3551>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:15:41 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 Aug 2008 11:15:41 +0000
Subject: [issue3551] multiprocessing.Pipe terminates with
	ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
In-Reply-To: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
Message-ID: <1218712541.93.0.882333872164.issue3551@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This is traceback when run reproducable.py.

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "e:\python-dev\trunk\lib\multiprocessing\forking.py", line 341,
in main
    prepare(preparation_data)
  File "e:\python-dev\trunk\lib\multiprocessing\forking.py", line 456,
in prepar
e
    '__parents_main__', file, path_name, etc
  File "reproducable.py", line 20, in <module>
    conn.send_bytes(really_big_msg)
IOError: [Errno 1450] Insufficient system resources complete the
requested service to exist.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3551>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:18:27 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Aug 2008 11:18:27 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1218712707.78.0.851424320814.issue2819@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file10988/fsum7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:18:40 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Aug 2008 11:18:40 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1218712720.05.0.445638707302.issue2819@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file11008/fsum8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:18:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Aug 2008 11:18:57 +0000
Subject: [issue2819] Full precision summation
In-Reply-To: <1210522613.21.0.870124531367.issue2819@psf.upfronthosting.co.za>
Message-ID: <1218712737.19.0.343456160478.issue2819@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file11014/fsum10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2819>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:35:13 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 14 Aug 2008 11:35:13 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218713713.37.0.697053999532.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Ah cheers Antoine, for the tip on using defaultdict (I was confused as
to how I could access the key just by passing defaultfactory, as the
manual suggests).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:50:47 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Aug 2008 11:50:47 +0000
Subject: [issue3550] Socket Python 3k Documentation mistake OR Unicode string
	is not supported with socket.send
In-Reply-To: <1218680660.59.0.981908565171.issue3550@psf.upfronthosting.co.za>
Message-ID: <1218714647.77.0.21526183987.issue3550@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed the docs to refer to bytes objects in r65674.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3550>
_______________________________________

From report at bugs.python.org  Thu Aug 14 13:53:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Aug 2008 11:53:09 +0000
Subject: [issue3546] Missing linebreak in ext.doctest output
In-Reply-To: <1218552870.92.0.456647494435.issue3546@psf.upfronthosting.co.za>
Message-ID: <1218714789.91.0.21882279858.issue3546@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r65675.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3546>
_______________________________________

From report at bugs.python.org  Thu Aug 14 14:18:51 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 14 Aug 2008 12:18:51 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218716331.89.0.261736879306.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

OK I implemented the defaultdict solution. I got curious so ran some
rough speed tests, using the following code.

import random, urllib.parse
for i in range(0, 100000):
    str = ''.join(chr(random.randint(0, 0x10ffff)) for _ in range(50))
    quoted = urllib.parse.quote(str)

Time to quote 100,000 random strings of 50 characters.
(Ran each test twice, worst case printed)

HEAD, chars in range(0,0x110000): 1m44.80
HEAD, chars in range(0,256): 25.0s
patch9, chars in range(0,0x110000): 35.3s
patch9, chars in range(0,256): 27.4s
New, chars in range(0,0x110000): 31.4s
New, chars in range(0,256): 25.3s

Head is the current Py3k head. Patch 9 is my previous patch (before
implementing defaultdict), and New is after implementing defaultdict.

Interesting. Defaultdict didn't really make much of an improvement. You
can see the big help the cache itself makes, though (my code caches all
chars, whereas the HEAD just caches ASCII chars, which is why HEAD is so
slow on the full repertoire test). Other than that, differences are
fairly negligible.

However, I'll keep the defaultdict code, I quite like it, speedy or not
(it is slightly faster).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug 14 14:26:36 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 14 Aug 2008 12:26:36 +0000
Subject: [issue3551] multiprocessing.Pipe terminates with
	ERROR_NO_SYSTEM_RESOURCES if large data is sent (win2000)
In-Reply-To: <1218712281.34.0.473878484861.issue3551@psf.upfronthosting.co.za>
Message-ID: <1218716796.11.0.322696031691.issue3551@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

After googling, ERROR_NO_SYSTEM_RESOURCES seems to happen
when one I/O size is too large.

And in Modules/_multiprocessing/pipe_connection.c, conn_send_string is
implemented with one call WriteFile(). Maybe this should be devided into
some reasonable sized chunks for several WriteFile() calls?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3551>
_______________________________________

From report at bugs.python.org  Thu Aug 14 15:07:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 13:07:24 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1218716331.89.0.261736879306.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218719260.48a42e1c58d2c@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello Matt,

> OK I implemented the defaultdict solution. I got curious so ran some
> rough speed tests, using the following code.
>
> import random, urllib.parse
> for i in range(0, 100000):
>     str = ''.join(chr(random.randint(0, 0x10ffff)) for _ in range(50))
>     quoted = urllib.parse.quote(str)

I think if you move the line defining "str" out of the loop, relative timings
should change quite a bit. Chances are that the random functions are not very
fast, since they are written in pure Python.
Or you can create an inner loop around the call to quote(), for example to
repeat it 100 times.

cheers

Antoine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug 14 15:15:24 2008
From: report at bugs.python.org (Ross Burton)
Date: Thu, 14 Aug 2008 13:15:24 +0000
Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't
	have permission to see
In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
Message-ID: <1218719724.08.0.0538665710494.issue2466@psf.upfronthosting.co.za>


Changes by Ross Burton <ross at burtonini.com>:


----------
title: os.path.ismount doesn't work for NTFS mounts -> os.path.ismount doesn't work for mounts the user doesn't have permission to see
versions: +Python 2.5 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2466>
_______________________________________

From report at bugs.python.org  Thu Aug 14 15:37:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 13:37:29 +0000
Subject: [issue3545] Python turning off assertions (Windows)
In-Reply-To: <1218707298.0.0.670382826814.issue3545@psf.upfronthosting.co.za>
Message-ID: <48A43514.5090709@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I have not yet seen any examples where the are erroneous assertions.

Please take a look at the code in signalmodule.c. The MS CRT asserts
that the signal number is supported (i.e. among a fixed list of signal
numbers), even though C 99, 7.14.1.1p8 says that the library shall
return SIG_ERR, and set errno to a positive value, if the request cannot
be honored.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________

From report at bugs.python.org  Thu Aug 14 15:38:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 13:38:12 +0000
Subject: [issue3545] Python turning off assertions (Windows)
In-Reply-To: <1218535531.94.0.182570624972.issue3545@psf.upfronthosting.co.za>
Message-ID: <1218721092.18.0.829202591494.issue3545@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3545>
_______________________________________

From report at bugs.python.org  Thu Aug 14 16:00:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 14:00:04 +0000
Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't
	have permission to see
In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
Message-ID: <1218722404.17.0.00769538841093.issue2466@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If ismount() used os.path.dirname() instead of appending "..", then this
> wouldn't happen.

But it may change the function result if the argument is a symlink to
something (directory or mount point) on another filesystem. It should be
verified before making a decision.

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 2.6, Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2466>
_______________________________________

From report at bugs.python.org  Thu Aug 14 16:50:28 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 14 Aug 2008 14:50:28 +0000
Subject: [issue3552] uuid - exception on uuid3/uuid5
In-Reply-To: <1218725428.36.0.572136195282.issue3552@psf.upfronthosting.co.za>
Message-ID: <1218725428.36.0.572136195282.issue3552@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

The test suite breaks on the Lib/test/test_uuid.py, as of r65661. This
is because uuid3 and uuid5 now raise exceptions.

TypeError: new() argument 1 must be bytes or read-only buffer, not bytearray

The problem is due to the changes in the way "s#" now expects a
read-only buffer in PyArg_ParseTupleAndKeywords. (Which was changed in
r65661).

A rundown of the problem:

Lib/uuid.py:553 (in uuid.uuid3):
    hash = md5(namespace.bytes + bytes(name, "utf-8")).digest()

namespace.bytes is a bytearray, so the argument to md5 is a bytearray.

Modules/md5module.c:517 (in _md5.md5.new):
    if (!PyArg_ParseTupleAndKeywords(args, kwdict, "|s#:new", kwlist,

Using s# now requires a read-only buffer, so this raises a TypeError.

The same goes for uuid5 (which calls _sha1.sha1, and has exactly the
same problem).

The commit log for r65561 suggests changing some s# into s* (which
allows readable buffers). I don't understand the ramifications here
(some problem with threading), and when I made that change, it seg
faulted, so I'll leave well enough alone. But for someone who knows more
what they're doing, that may be a more "root-of-the-problem" fix.

In the meantime, I propose this simple patch to fix uuid: I think
namespace.bytes should actually return a bytes, not a bytearray, so I'm
modifying it to return a bytes.

Related issue:
http://bugs.python.org/issue3139

Patch for r65675.
Commit log:

Fixed TypeError raised by uuid.uuid3 and uuid.uuid5, by passing a
bytearray to hash functions. Now namespace.bytes returns a bytes instead
of a bytearray.

----------
components: Library (Lib)
files: uuid.patch
keywords: patch
messages: 71129
nosy: mgiuca
severity: normal
status: open
title: uuid - exception on uuid3/uuid5
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file11110/uuid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3552>
_______________________________________

From report at bugs.python.org  Thu Aug 14 17:27:28 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 14 Aug 2008 15:27:28 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218727648.28.0.988658298824.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

New patch (patch10). Details on Rietveld review tracker
(http://codereview.appspot.com/2827).

Another update on the remaining "outstanding issues":

Resolved issues since last time:

> Should unquote accept a bytes/bytearray as well as a str?
No. But see below.

> Lib/email/utils.py:
> Should encode_rfc2231 with charset=None accept strings with non-ASCII
> characters, and just encode them to UTF-8?
Implemented Antoine's fix ("or 'ascii'").

> Should quote accept safe characters outside the
> ASCII range (thereby potentially producing invalid URIs)?
No.

New issues:

unquote_to_bytes doesn't cope well with non-ASCII characters (currently
encodes as UTF-8 - not a lot we can do since this is a str->bytes
operation). However, we can allow it to accept a bytes as input (while
unquote does not), and it preserves the bytes precisely.
Discussion at http://codereview.appspot.com/2827/diff/82/84, line 265.

I have *implemented* that suggestion - so unquote_to_bytes now accepts
either a bytes or str, while unquote accepts only a str. No changes need
to be made unless there is disagreement on that decision.

I also emailed Barry Warsaw about the email/utils.py patch (because we
weren't sure exactly what that code was doing). However, I'm sure that
this patch isn't breaking anything there, because I call unquote with
encoding="latin-1", which is the same behaviour as the current head.

That's all the issues I have left over in this patch.

Attaching patch 10 (for revision 65675).

Commit log for patch 10:

Fix for issue 3300.

urllib.parse.unquote:
  Added "encoding" and "errors" optional arguments, allowing the caller
  to determine the decoding of percent-encoded octets.
  As per RFC 3986, default is "utf-8" (previously implicitly decoded
  as ISO-8859-1).
  Fixed a bug in which mixed-case hex digits (such as "%aF") weren't
  being decoded at all.

urllib.parse.quote:
  Added "encoding" and "errors" optional arguments, allowing the
  caller to determine the encoding of non-ASCII characters
  before being percent-encoded.
  Default is "utf-8" (previously characters in range(128, 256)
  were encoded as ISO-8859-1, and characters above that as UTF-8).
  Characters/bytes above 128 are no longer allowed to be "safe".
  Now allows either bytes or strings.
  Optimised "Quoter"; now inherits defaultdict.

Added functions urllib.parse.quote_from_bytes,
urllib.parse.unquote_to_bytes.
All quote/unquote functions now exported from the module.

Doc/library/urllib.parse.rst: Updated docs on quote and unquote to
reflect new interface, added quote_from_bytes and unquote_to_bytes.

Lib/test/test_urllib.py: Added many new test cases testing encoding
and decoding Unicode strings with various encodings, as well as testing
the new functions.

Lib/test/test_http_cookiejar.py, Lib/test/test_cgi.py,
Lib/test/test_wsgiref.py: Updated and added test cases to deal with
UTF-8-encoded URIs.

Lib/email/utils.py: Calls urllib.parse.quote and urllib.parse.unquote
with encoding="latin-1", to preserve existing behaviour (which the email
module is dependent upon).

Added file: http://bugs.python.org/file11111/parse.py.patch10

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug 14 17:31:40 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 14 Aug 2008 15:31:40 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1218727900.59.0.385481256799.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Antoine:
> I think if you move the line defining "str" out of the loop, relative
> timings should change quite a bit. Chances are that the random
> functions are not very fast, since they are written in pure Python.

Well I wanted to test throwing lots of different URIs to test the
caching behaviour. You're right though, probably a small % of the time
is spent on calling quote.

Oh well, the defaultdict implementation is in patch10 anyway :) It
cleans Quoter up somewhat, so it's a good thing anyway. Thanks for your
help.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Thu Aug 14 17:44:57 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Aug 2008 15:44:57 +0000
Subject: [issue3553] "2to3 -l" doesn't work when installed in /opt
In-Reply-To: <1218728696.82.0.307782254741.issue3553@psf.upfronthosting.co.za>
Message-ID: <1218728696.82.0.307782254741.issue3553@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

I just installed Python 3.0b2 in /opt/py3k and tried 2to3 tool:

$ /opt/py3k/bin/2to3 -l
Available transformations for the -f/--fix option:
Traceback (most recent call last):
  File "/opt/py3k/bin/2to3", line 5, in <module>
    sys.exit(refactor.main("lib2to3/fixes"))
  File "/opt/py3k/lib/python3.0/lib2to3/refactor.py", line 69, in main
    for fixname in get_all_fix_names(fixer_dir):
  File "/opt/py3k/lib/python3.0/lib2to3/refactor.py", line 102, in 
get_all_fix_names
    names = os.listdir(fixer_dir)
OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'

fixer_dir is the relative directory name "lib2to3/fixes", it should be 
an absolute directory. Example (ugly code copied from 
RefactoringTool.get_fixers()) to get the full path in refactor.py 
(main function):

    if not os.path.isabs(fixer_dir):
        fixer_pkg = fixer_dir.replace(os.path.sep, ".")
        if os.path.altsep:
            fixer_pkg = fixer_pkg.replace(os.path.altsep, ".")
        mod = __import__(fixer_pkg, {}, {}, ["*"])
        fixer_dir = os.path.dirname(mod.__file__)

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 71132
nosy: collinwinter, haypo
severity: normal
status: open
title: "2to3 -l" doesn't work when installed in /opt
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3553>
_______________________________________

From report at bugs.python.org  Thu Aug 14 17:53:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 15:53:01 +0000
Subject: [issue3552] uuid - exception on uuid3/uuid5
In-Reply-To: <1218725428.36.0.572136195282.issue3552@psf.upfronthosting.co.za>
Message-ID: <1218729181.7.0.551894172262.issue3552@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I couldn't reproduce the problem (and apparently, many of the buildbots
can't, either). It depends on whether you have openssl available, i.e.
whether hashlib can be built. I explicitly disabled use of OpenSSL on my
system, and have now committed a fix as r65676.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3552>
_______________________________________

From report at bugs.python.org  Thu Aug 14 17:54:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Aug 2008 15:54:50 +0000
Subject: [issue3553] "2to3 -l" doesn't work when installed in /opt
In-Reply-To: <1218728696.82.0.307782254741.issue3553@psf.upfronthosting.co.za>
Message-ID: <1218729290.86.0.987939172194.issue3553@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file11112/2to3_fixer_dir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3553>
_______________________________________

From report at bugs.python.org  Thu Aug 14 18:13:58 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 16:13:58 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218661951.33.0.447411702856.issue3139@psf.upfronthosting.co.za>
Message-ID: <48A459C2.70905@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm a bit confused. In the PyBuffer_Release implementation you
> committed, there is no DECREF at all.

Oops, I meant to make the reference own by Py_buffer, but actually
forgot to implement that. Fixed in r65677, r65678.

Now, when I try to merge that into the 3k branch, test_unicode terribly
leaks memory :-( It's really frustrating.

Regards,
Martin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 18:39:52 2008
From: report at bugs.python.org (Kevin Watters)
Date: Thu, 14 Aug 2008 16:39:52 +0000
Subject: [issue3554] ctypes.wstring_at and string_at call Python API without
	the GIL
In-Reply-To: <1218731992.24.0.0258351695719.issue3554@psf.upfronthosting.co.za>
Message-ID: <1218731992.24.0.0258351695719.issue3554@psf.upfronthosting.co.za>


New submission from Kevin Watters <kevinwatters at gmail.com>:

in Lib/ctypes/__init__.py the wstring_at and string_at functions are
declared with CFUNCTYPE.

This means that in Modules/_ctypes/callproc.c when the functions are
invoked, Py_UNBLOCK_THREADS and Py_BLOCK_THREADS surround the call. But
string_at and wstring_at call PyString_FromString and
PyUnicode_FromWideChar, respectively.

The solution (I think) is to declare the functions with PYFUNCTYPE
instead, so that callproc.c doesn't release the GIL when calling them.

----------
assignee: theller
components: ctypes
messages: 71135
nosy: kevinwatters, theller
severity: normal
status: open
title: ctypes.wstring_at and string_at call Python API without the GIL
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3554>
_______________________________________

From report at bugs.python.org  Thu Aug 14 19:28:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 17:28:40 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <48A459C2.70905@v.loewis.de>
Message-ID: <1218734908.5572.4.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 14 ao?t 2008 ? 16:13 +0000, Martin v. L?wis a ?crit :
> Now, when I try to merge that into the 3k branch, test_unicode terribly
> leaks memory :-( It's really frustrating.

If you don't have the time to work on it anymore, you can post the
current patch here and I'll take a try.

Regards

Antoine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 20:23:12 2008
From: report at bugs.python.org (Andrew Trick)
Date: Thu, 14 Aug 2008 18:23:12 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1218738192.99.0.2257465093.issue1424152@psf.upfronthosting.co.za>


Andrew Trick <andrew.trick at gmail.com> added the comment:

Mercurial will not work for anyone in a large company without this
fix. I appreciate the patch, but hope its released soon. I did try the
patch with Mercurial, but now I'm getting different error. I'm not
sure if its related to the same bug:

abort: error: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol

----------
nosy: +AndrewTrick

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Aug 14 20:23:20 2008
From: report at bugs.python.org (Martin Wilck)
Date: Thu, 14 Aug 2008 18:23:20 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <9ED873FF2263454A995F57CE14906D879CB331737D@ABGEX71E.FSC.NET>


Martin Wilck <martin.wilck at fujitsu-siemens.com> added the comment:

I am not in my office. I'll be back on August 25, 2008.
In urgent cases, please contact:
   Peter Pols <peter.pols at fujitsu-siemens.com> or
   Gerhard Wichert <gerhard.wichert at fujitsu-siemens.com>

Best regards
Martin Wilck

Added file: http://bugs.python.org/file11113/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080814/29c19a24/attachment.txt>

From report at bugs.python.org  Thu Aug 14 20:35:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 18:35:38 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1218738938.24.0.891735842229.issue1424152@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Aug 14 20:35:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 18:35:58 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1218738958.92.0.631991216525.issue1424152@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11113/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Aug 14 20:52:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 18:52:34 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218739954.56.0.0790785488803.issue3139@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is really trivial, and attached.

Added file: http://bugs.python.org/file11114/refcount.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 20:55:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 18:55:34 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218739954.56.0.0790785488803.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218740131.5572.13.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 14 ao?t 2008 ? 18:52 +0000, Martin v. L?wis a ?crit :
> The patch is really trivial, and attached.
> 
> Added file: http://bugs.python.org/file11114/refcount.diff

By the way, even without that patch, there is a memory leak:

Python 3.0b2+ (py3k, Aug 14 2008, 20:49:19) 
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, codecs
>>> b = bytearray()
>>> sys.getrefcount(b)
2
>>> codecs.ascii_decode(memoryview(b))
('', 0)
>>> sys.getrefcount(b)
3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:03:35 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 14 Aug 2008 19:03:35 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

The following code works[1] on trunk and 2.5.1, but crashes with "Fatal
Python error: Cannot recover from stack overflow," on py3k as of rev65676:

######
# Python 3.0b2+ (py3k:65676, Aug 14 2008, 14:37:38)
# [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

import sys

def overflower():
    try:
        return overflower()
    except:
        return sys.exc_info()


def f():
      try:
          return f()
      except:
          return overflower()

f()
######

Catching RuntimeError crashes, letting it be raised avoids the crash.
Adding "finally: return overflower()" along with a non
RuntimeError-catching except also gives a Fatal Python error.

A smaller test case for hitting the overflow in py3k would be "def f():
[...] except: return f()", but that hangs in an (desirable?) infinite
loop in 2.5 and trunk. 


[1] "Works" as in "doesn't crash", but both the code above and the
infinite loop hit issue2548 when run on a debug build of trunk. Calling
overflower() alone in trunk hits the "undetected error" discussed in
that issue, but works fine in py3k.

----------
components: Interpreter Core
messages: 71141
nosy: ajaksu2
severity: normal
status: open
title: Regression: nested exceptions crash (Cannot recover from stack overflow)
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:06:23 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 19:06:23 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218740131.5572.13.camel@fsol>
Message-ID: <48A4822D.3060005@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> By the way, even without that patch, there is a memory leak:

With the patch, this memory leak goes away.

Regards,
Martin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:06:46 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 14 Aug 2008 19:06:46 +0000
Subject: [issue3554] ctypes.wstring_at and string_at call Python API without
	the GIL
In-Reply-To: <1218731992.24.0.0258351695719.issue3554@psf.upfronthosting.co.za>
Message-ID: <1218740806.22.0.24453974584.issue3554@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Good catch!  Indeed, when PyString_FromString or PyUnicode_FromWideChar
fail, Python crashes with
  Fatal Python error: PyThreadState_Get: no current thread
in a debug build, and an access violation in a release build (tested on
Windows).

Also, your patch suggestion is absolutely correct and fixes the problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3554>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:23:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 19:23:17 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1218741797.45.0.691209040751.issue3476@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch which simply wraps the current BufferedWriter
methods with a lock. It has a test case, and Amaury's example works fine
too.

Martin, do you think it's fine?

(as for BufferedReader, I don't see the use cases for multithreaded reading)

----------
assignee:  -> pitrou
Added file: http://bugs.python.org/file11115/bufferedwriter3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:30:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 19:30:55 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <48A4822D.3060005@v.loewis.de>
Message-ID: <1218742251.5572.15.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 14 ao?t 2008 ? 19:06 +0000, Martin v. L?wis a ?crit :
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> > By the way, even without that patch, there is a memory leak:
> 
> With the patch, this memory leak goes away.

But now:

30
>>> m = memoryview(b)
>>> sys.getrefcount(b)
32
>>> del m
>>> sys.getrefcount(b)
31

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:33:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 19:33:53 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218742433.69.0.60120834408.issue3139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, the roundup e-mail interface ate some lines of code:

>>> b = b''
>>> sys.getrefcount(b)
30
>>> m = memoryview(b)
>>> sys.getrefcount(b)
32
>>> del m
>>> sys.getrefcount(b)
31

It doesn't happen with bytearrays, so I suspect it's that you only
DECREF when releasebuffer method exists:

>>> b = bytearray()
>>> sys.getrefcount(b)
2
>>> m = memoryview(b)
>>> sys.getrefcount(b)
4
>>> del m
>>> sys.getrefcount(b)
2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:43:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Aug 2008 19:43:16 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1218742996.16.0.506068540645.issue3555@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________

From report at bugs.python.org  Thu Aug 14 21:50:56 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 14 Aug 2008 19:50:56 +0000
Subject: [issue1432] Strange behavior of urlparse.urljoin
In-Reply-To: <1194916709.09.0.956868163288.issue1432@psf.upfronthosting.co.za>
Message-ID: <1218743456.49.0.891872320898.issue1432@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Commited in revs 65679 and 65680.

Thank you all!!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1432>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:07:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 20:07:13 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1218744433.5.0.965522746317.issue3555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm no expert in recursion checking inside the Python interpreter, but
looking at the code for _Py_CheckRecursiveCall(), I don't think it is a
bug but a feature.

Here how I understand it. When the recursion level exceeds the normal
recursion limit (let's call the latter N), a RuntimeError is raised and
the normal recursion check is temporarily disabled (by setting
tstate->overflowed) so that Python can run some recovery code (e.g. an
except statement with a function call to log the problem), and another
recursion check is put in place that is triggered at N+50. When the
latter check triggers, the interpreter prints the aforementioned
Py_FatalError and bails out.

This is actually what happens in your example: when the normal recursion
limit is hit and a RuntimeError is raised, you immediately catch the
exception and run into a second infinite loop while the normal recursion
check is temporarily disabled: the N+50 check then does its job.

Here is a simpler way to showcase this behaviour, without any nested
exceptions:

def f():
    try:
        return f()
    except:
        pass
    f()

f()


Can someone else comment on this?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:08:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 20:08:29 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1218744509.03.0.845959818982.issue3476@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine (as far as it goes).

I do think the same should be done to the reader: IO libraries typically
provide a promise that concurrent threads can read, and will get the
complete stream in an overlapped manner (i.e. each input byte goes to
exactly one thread - no input byte gets lost, and no input byte is
delivered to multiple threads). I don't think this is currently the
case: two threads reading simultaneously may very well read the same
bytes twice, and then, subsequently, skip bytes (i.e. when both
increment _read_pos, but both see the original value of pos)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:21:19 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 20:21:19 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

It appears that test_unicode::test_raiseMemError was meant to produce a
MemoryError. Unfortunately, on my machine (Linux 2.6.25, 32-bit
processor, 1GiB main memory, plenty swap), allocation *succeed*, and
then brings the machine to a near halt, trying to fill that memory with
data.

IMO, the patch should be rewritten to either reliably produce a
MemoryError (why not allocate sys.maxsize characters, or sys.maxsize//2?),
or else it should be removed.

----------
assignee: amaury.forgeotdarc
messages: 71150
nosy: amaury.forgeotdarc, loewis
severity: normal
status: open
title: test_raiseMemError consumes an insane amount of memory
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:26:05 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 14 Aug 2008 20:26:05 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1218745565.83.0.353862691937.issue600362@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Hi Facundo,
This issue/comments somehow escaped from my noticed, initially. I have
addressed your comments in the new set of patches.

1) Previous patch Docs had issues. Updated the Docs patch.
2) Included message in cgi.py about parse_qs, parse_qsl being present
for backward compatiblity.
3) The reason, py26 version of patch has quote function from urllib is
to avoid circular reference. urllib import urlparse for urljoin method.
So only way for us use quote is to have that portion of code in the
patch as well.

Please have a look the patches. 
As this request has been present from a long time ( 2002-08-26 !), is it
possible to include this change in b3?

Thanks,
Senthil

Added file: http://bugs.python.org/file11116/issue600362-py26-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue600362>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:26:30 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 14 Aug 2008 20:26:30 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1218745590.9.0.683380104284.issue600362@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file11117/issue600362-py3k-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue600362>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:26:49 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 14 Aug 2008 20:26:49 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1218745609.83.0.683236126988.issue600362@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file10771/issue600362-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue600362>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:26:56 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 14 Aug 2008 20:26:56 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1218745616.19.0.0400664429119.issue600362@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file10772/issue600362-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue600362>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:36:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 20:36:06 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218742433.69.0.60120834408.issue3139@psf.upfronthosting.co.za>
Message-ID: <48A49733.10106@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It doesn't happen with bytearrays, so I suspect it's that you only
> DECREF when releasebuffer method exists:

Thanks, that was indeed the problem; this is now fixed in r65683 and r65685.

My initial observation that test_unicode leaks a lot of memory was
incorrect - it's rather that test_raiseMemError consumes all my
memory (probably without leaking).

test_unicode still leaks 6 references each time; one reference is leaked
whenever a SyntaxError is raised. I'm not sure though whether this was
caused by this patch, so I'll close this issue as fixed. Any further
improvements should be done through separate patches (without my
involvement, most likely).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 22:36:30 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Aug 2008 20:36:30 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218746190.52.0.0879646724222.issue3139@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Thu Aug 14 23:07:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 21:07:07 +0000
Subject: [issue3476] BufferedWriter not thread-safe
In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za>
Message-ID: <1218748027.48.0.217782075209.issue3476@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Both BufferedReader and BufferedWriter are now fixed in r65686.
Perhaps someone wants to open a separate issue for TextIOWrapper...

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3476>
_______________________________________

From report at bugs.python.org  Thu Aug 14 23:17:29 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 14 Aug 2008 21:17:29 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1218748649.72.0.404186663086.issue3555@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Antoine,

Thanks for your analysis. I still believe this is a regression for the
case described, but take my opinion with a grain of salt :)

>> looking at the code for _Py_CheckRecursiveCall(), I don't think it 
>> is a bug but a feature.

It does seem to be working as designed, if that is a desirable behavior
then this issue should be closed.

> This is actually what happens in your example: when the normal
> recursion limit is hit and a RuntimeError is raised, you 
> immediately catch the exception and run into a second infinite
> loop while the normal recursion check is temporarily disabled:
> the N+50 check then does its job.

Except that it wasn't an infinite loop in 2.5 and isn't in trunk: it
terminates on overflower's except. That's why I think this is a
regression. Besides being different behavior, it seems weird to bail out
on a recursion issue instead of dealing with it.

Your showcase is a better way of getting an infinite loop in trunk than
the one I mentioned, but AFAIK we are more comfortable with infinite
loops than with fatal errors.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________

From report at bugs.python.org  Thu Aug 14 23:29:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Aug 2008 21:29:13 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1218749353.26.0.714392097383.issue3555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Except that it wasn't an infinite loop in 2.5 and isn't in trunk: it
> terminates on overflower's except.

That's because the stated behaviour is only implemented in 3.0 and not
in 2.x. I'm not sure what motivated it, but you are the first one to
complain about it. If you think it is a regression, I think you should
open a thread on the python-dev mailing-list about it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________

From report at bugs.python.org  Fri Aug 15 04:24:07 2008
From: report at bugs.python.org (Matt Giuca)
Date: Fri, 15 Aug 2008 02:24:07 +0000
Subject: [issue3552] uuid - exception on uuid3/uuid5
In-Reply-To: <1218725428.36.0.572136195282.issue3552@psf.upfronthosting.co.za>
Message-ID: <1218767047.44.0.100394154568.issue3552@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

So are you saying that if I had libopenssl (or whatever the name is)
installed and linked with Python, it would bypass the use of _md5 and
_sha1, and call the hash functions in libopenssl instead? And all the
buildbots _do_ have it linked?

That would indicate that the bots _aren't_ testing the code in _md5 and
_sha1 at all. Perhaps one should be made to?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3552>
_______________________________________

From report at bugs.python.org  Fri Aug 15 04:39:35 2008
From: report at bugs.python.org (Matt Giuca)
Date: Fri, 15 Aug 2008 02:39:35 +0000
Subject: [issue3557] Segfault in sha1
In-Reply-To: <1218767975.42.0.656822559371.issue3557@psf.upfronthosting.co.za>
Message-ID: <1218767975.42.0.656822559371.issue3557@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

Continuing the discussion from Issue 3552
(http://bugs.python.org/issue3552).

r65676 makes changes to Modules/md5module.c and Modules/sha1module.c, to
allow them to read mutable buffers.

There's a segfault in sha1module if given 0 arguments. eg:

>>> import _sha1
>>> _sha1.sha1()
Segmentation fault

Docs here suggest this should be OK:
http://docs.python.org/dev/3.0/library/hashlib.html

This crashes on the Lib/test/test_hmac.py test case, but apparently
(according to Margin on issue 3552) none of the build bots see it
because they use libopenssl and completely bypass the _md5 and _sha1
modules. Also there are no direct test cases for either of these modules.

This is because new code in r65676 doesn't initialise a pointer to NULL.
Fixed in patch (as well as replaced tab with spaces for consistency, in
both modules).

I strongly recommend that a) A "build bot" be made to use _md5 and _sha1
instead of OpenSSL (or they aren't running that code at all), AND/OR b)
Direct test cases be written for _md5 and _sha1.

Commit log:

Fixed crash on _sha1.sha1(), with no arguments, due to not initialising
pointer.

Normalised indentation in md5module.c and sha1module.c.

----------
components: Interpreter Core
files: sha1.patch
keywords: patch
messages: 71157
nosy: mgiuca
severity: normal
status: open
title: Segfault in sha1
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11118/sha1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3557>
_______________________________________

From report at bugs.python.org  Fri Aug 15 05:08:22 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 15 Aug 2008 03:08:22 +0000
Subject: [issue3514] pickle segfault with infinite loop in __getattr__
In-Reply-To: <1218094884.25.0.929413492042.issue3514@psf.upfronthosting.co.za>
Message-ID: <1218769702.31.0.617092327672.issue3514@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed fix in r65689. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3514>
_______________________________________

From report at bugs.python.org  Fri Aug 15 06:09:39 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 15 Aug 2008 04:09:39 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1218773379.16.0.303666881343.issue3385@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I ran into a few problems while trying to fix this issue. First, does
someone know how to add class attributes on extension types? It sounds
like I will need either some tp_dict hacking or a Pickler subclass.

Second, which methods of Pickler should be made public? I know
save_reduce() is needed, but would it be worthwhile to expose more? In
the recipe Amaury linked (which abuses Pickler IMHO), save_global(),
save_dict(), write() and memoize() are used. Exposing all save_* methods
is out of question for now as none were written to be used standalone.

Third, should Pickler allows pickling support for built-in types (e.g.,
int, dict, tuple, etc) to be overridden? Currently, pickle.py allows it.
However, I am not sure if it is a good idea to copy this "feature" in
_pickle.c.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Fri Aug 15 06:46:01 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Aug 2008 04:46:01 +0000
Subject: [issue3558] Operator precedence misdocumented
In-Reply-To: <1218775561.6.0.243287416094.issue3558@psf.upfronthosting.co.za>
Message-ID: <1218775561.6.0.243287416094.issue3558@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Reference/Expressions/Primaries: "Primaries represent the most tightly
bound operations of the language. Their syntax is:
primary ::=  atom | attributeref | subscription | slicing | call"

This (along with the fact that all sections after 'call' doc follow in
order of decreasing precedence) implies to me that atom is highest and
call is lowest of this group.  Certainly, attributeref seems higher than
those that follow, as ob.attr[x] and ob.attr(x) are executed as
(ob.attr)[x] and (ob.attr)(x), not as ob.(attr[x]) or ob.(attr(x)) (both
taken literally are syntax errors). (Michael Tobis gave an example today
on c.l.p showing this.)

But the Summary of precedence at the chapter end lists attriburef to
call as low to high.  I think these should be reversed.

----------
assignee: georg.brandl
components: Documentation
messages: 71160
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Operator precedence misdocumented
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3558>
_______________________________________

From report at bugs.python.org  Fri Aug 15 07:34:50 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Aug 2008 05:34:50 +0000
Subject: [issue3559] Pasted \n not same as typed \n
In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za>
Message-ID: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Winxp, 3.0b2, but I suspect earlier as well, since reported on c.l.p.

If I paste '1+2\n' into the command window interpreter, it responds with
'3' and a new prompt.  In IDLE, the pasted \n is ignored and a typed \n
is required to trigger execution.  As a consequence, pasting multiple
statements does not work; anything after the first is ignored.

If this cannot be changed, following
	Paste            -- Insert system-wide clipboard into window
with                        (The shell will only recognize one statement)
would at least document the limitation.

----------
components: IDLE
messages: 71161
nosy: tjreedy
severity: normal
status: open
title: Pasted \n not same as typed \n
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3559>
_______________________________________

From report at bugs.python.org  Fri Aug 15 08:24:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 06:24:02 +0000
Subject: [issue3552] uuid - exception on uuid3/uuid5
In-Reply-To: <1218767047.44.0.100394154568.issue3552@psf.upfronthosting.co.za>
Message-ID: <48A520FE.9050405@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So are you saying that if I had libopenssl (or whatever the name is)
> installed and linked with Python, it would bypass the use of _md5 and
> _sha1, and call the hash functions in libopenssl instead?

Correct. Those modules aren't even built then. See openssl_ver in setup.py.

> And all the buildbots _do_ have it linked?

Most of them, yes, to be able to test openssl. You would have to check
each one individually to really know.

> That would indicate that the bots _aren't_ testing the code in _md5 and
> _sha1 at all. Perhaps one should be made to?

Perhaps. However, the buildbots can't test all combinations, anyway.
People will report problems in other combinations quickly. Hopefully,
they don't panic when they encounter a bug that only shows up on their
system.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3552>
_______________________________________

From report at bugs.python.org  Fri Aug 15 08:29:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 06:29:16 +0000
Subject: [issue3557] Segfault in sha1
In-Reply-To: <1218767975.42.0.656822559371.issue3557@psf.upfronthosting.co.za>
Message-ID: <1218781756.32.0.643306876461.issue3557@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report. Fixed in r65690.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3557>
_______________________________________

From report at bugs.python.org  Fri Aug 15 11:37:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 09:37:07 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

PyMemoryViewObject has a "base" field which points to the originator of
the buffer. However, this field has become redundant now that the
Py_buffer struct has received an "obj" field which also points to the
originator of the buffer (this has been done as part of the fix to #3139).

Not removing "base" would make for a confusing and error-prone API.
However, removing it is complicated by the fact that "base" is sometimes
abused to contain a tuple (for PyBUF_SHADOW type buffers, which are
neither mentioned in the PEP nor used anywhere in py3k).

----------
components: Interpreter Core
messages: 71164
nosy: pitrou, teoliphant
priority: critical
severity: normal
status: open
title: redundant "base" field in memoryview objects
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 11:38:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 09:38:44 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1218793124.09.0.773673193396.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See also #3560.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Fri Aug 15 12:13:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 10:13:03 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1218795183.63.0.787945571579.issue2271@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Fri Aug 15 12:14:25 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 10:14:25 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1218795265.8.0.743327971333.issue3392@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
type:  -> behavior
versions: +Python 2.6, Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Fri Aug 15 12:16:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 10:16:47 +0000
Subject: [issue3482] re.split, re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1218795407.71.0.182749487675.issue3482@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please note that the flags can be inlined in the pattern instead. That
is, you can begin the pattern with "(?i)" instead of passing re.I in the
flags parameter.

----------
nosy: +pitrou
priority:  -> normal
type: behavior -> feature request
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________

From report at bugs.python.org  Fri Aug 15 12:25:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 10:25:57 +0000
Subject: [issue3006] subprocess.Popen causes socket to remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1218795957.15.0.0434772700008.issue3006@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It's not perfect--another thread could still spawn a subprocess in
> between

Then it could be done in socketmodule.c, when still holding the GIL.
Python code can change back the socket to inheritable afterwards if it
wants to.

> We probably need some kind of API for setting socket inheritance.

Right.

----------
nosy: +pitrou
priority:  -> high
versions: +Python 2.6, Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________

From report at bugs.python.org  Fri Aug 15 12:30:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 10:30:53 +0000
Subject: [issue2676] email/message.py [Message.get_content_type]: Trivial
	regex hangs on pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1218796253.51.0.571128526204.issue2676@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This should really be fixed. Hanging on a rather normal email message
(not a theoretical example) is not right.

----------
nosy: +pitrou
priority:  -> high
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2676>
_______________________________________

From report at bugs.python.org  Fri Aug 15 13:38:28 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Fri, 15 Aug 2008 11:38:28 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1218800308.75.0.0474954710435.issue2271@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

I also have this problem.  (2.5 msi installer under Win2K with a non-
admin account granted admin privs).  Python installs just fine under 
C:\ (instead of C:\Python25) but then I run into problems installing 
the win32 extensions.

Searching the web I found this posting from 2005
  http://mail.python.org/pipermail/python-list/2005-
September/341874.html

That poster created an SF bug report which is now issue1298962.  He 
linked to http://tinyurl.com/82dt2 which states:

    Windows Installler has no recognition of power
    users, so these users fall into the category of 
    "non admin" when running an install. 

That describes exactly my situation.  The solution is, apparently:

    To mark certain properties as safe for configuration,
    you can add them to the SecureCustomProperties list
    in the property table of the MSI file. 

which Martin reported here.  Martin suggested using orca, but I have no 
idea of what that is (unix/mac dweeb that I am), and it doesn't exist 
on this machine.

I know this is pretty much a "me too" report.  I'm doing so to say that 
it has been an ongoing problem here at my client's site.  They are not 
software developers here, and rather than trying to track down the 
right person with full admin rights to come to each person's desktop, 
they've been installing an old pre-msi version of Python.

I would like to see this fixed before 2.6 is released.  All I can do to 
help though is to test an installer, which I will do gladly.

----------
nosy: +dalke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Fri Aug 15 14:58:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Aug 2008 12:58:47 +0000
Subject: [issue3553] "2to3 -l" doesn't work when installed in /opt
In-Reply-To: <1218728696.82.0.307782254741.issue3553@psf.upfronthosting.co.za>
Message-ID: <1218805127.36.0.711711179076.issue3553@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is a duplicate of #3131.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3553>
_______________________________________

From report at bugs.python.org  Fri Aug 15 17:16:51 2008
From: report at bugs.python.org (Nicolas Grilly)
Date: Fri, 15 Aug 2008 15:16:51 +0000
Subject: [issue1398] Can't pickle partial functions
In-Reply-To: <1194449250.48.0.936565568427.issue1398@psf.upfronthosting.co.za>
Message-ID: <1218813411.22.0.464783810802.issue1398@psf.upfronthosting.co.za>


Nicolas Grilly <nicolas.grilly at garden-paris.com> added the comment:

It seems using protocol version 2 is not enough:

>>> s = pickle.dumps(partial_f, 2)
>>> f = pickle.loads(s)
Traceback (most recent call last):
...
TypeError: type 'partial' takes at least one argument

Am I missing something?

----------
nosy: +ngrilly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1398>
_______________________________________

From report at bugs.python.org  Fri Aug 15 19:17:23 2008
From: report at bugs.python.org (Jason Spiro)
Date: Fri, 15 Aug 2008 17:17:23 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>


New submission from Jason Spiro <jasonspiro4 at gmail.com>:

The Python Windows installer[1] should automatically add the Python and 
Scripts directories to the PATH environment variable.  (If you like, 
you can also provide a checkbox in the installer GUI that users can 
uncheck if they don't want this behavior.)

This issue was discussed at http://nabble.com/Why-does-Python-never-add-
itself-to-the-Windows-path--td8044465.html and the majority consensus 
was that this is a good idea, but nobody has volunteered to implement 
it.

^ [1].  The installer is generated by the code at 
http://svn.python.org/view/python/trunk/Tools/msi/

----------
components: Installation, Windows
messages: 71172
nosy: christian.heimes, jasonspiro, loewis
severity: normal
status: open
title: Windows installer should add Python and Scripts directories to the PATH environment variable
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Fri Aug 15 19:49:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 17:49:40 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1218822580.27.0.0633186671487.issue3560@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why is this a "critical" bug?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 20:03:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 18:03:40 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1218823420.25.0.830942564205.issue3561@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still don't think such a change should be made, hence I reject this
report as "won't fix". Discussion shouldn't start again on this matter
until there is an actual patch to review.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Fri Aug 15 20:08:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Aug 2008 18:08:14 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1218823694.73.0.394409773867.issue3560@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Because it should be fixed before 3.0 final?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 20:25:17 2008
From: report at bugs.python.org (Paul Molodowitch)
Date: Fri, 15 Aug 2008 18:25:17 +0000
Subject: [issue2642] MSVCRT packing in Windows Installer (3.0a4)
In-Reply-To: <1208307954.26.0.976441320091.issue2642@psf.upfronthosting.co.za>
Message-ID: <1218824717.25.0.581142279696.issue2642@psf.upfronthosting.co.za>


Paul Molodowitch <python.calin79 at neverbox.com> added the comment:

To do a private, SxS install, see:

http://msdn.microsoft.com/en-us/library/ms997620.aspx

I once made a private SxS installation of a MSVC-reliant app (that you
could install with non-admin privileges), and if recall correctly, it
required disabling the generation / embedding of the manifest file in
MSVC++, and then include the MSVC dlls and hand-edited manifest files in
the installation.  (Or perhaps you could somehow edit the options for
the embedded manifest's generation? never tried this myself...).  (Or,
if you don't like .manifest files littering the install directory, turn
off the auto-generation of the manifest, but embed your own hand-edited
manifest as a resource.  I'm sure this is possible, but figuring out the
exact steps to do it may be more headache then it's worth...)

I don't remember exactly, but I think in order to make a manifest that
worked for non-Admin install, I think all I had to do was remove the
'publicKeyToken' property from the assemblyIdentity... if it's present,
I believe it tries to find a registered, "signed" version of the dlls -
and registering signed SxS dlls requires admin privileges.  What I don't
remember is, if 'publicKeyToken' is present, if it just gives up if it
doesn't find a signed version, or it simply means that it will use a
signed version preferentially to a 'local' copy if both are present...

----------
nosy: +barnabas79

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2642>
_______________________________________

From report at bugs.python.org  Fri Aug 15 20:33:38 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 15 Aug 2008 18:33:38 +0000
Subject: [issue1398] Can't pickle partial functions
In-Reply-To: <1194449250.48.0.936565568427.issue1398@psf.upfronthosting.co.za>
Message-ID: <1218825218.58.0.659289393089.issue1398@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I agree that this a bug. However, the liberal functools.partial
constructor makes it hard to pickle partial instances correctly.
Ideally, we would add the __getnewargs__ special method and be done with
it. But, this won't work in this case due to the *args and **kwargs
arguments of partial. Since pickle supports neither, we would need to
use apply(), which going to be removed in Python 3.0, as follow:

>>> import pickletools
>>>
pickletools.dis("c__builtin__\napply\n(cfunctools\npartial\n(c__main__\nf\nt(S'b'\nK\x01dtR.")
    0: c    GLOBAL     '__builtin__ apply'
   19: (    MARK
   20: c        GLOBAL     'functools partial'
   39: (        MARK
   40: c            GLOBAL     '__main__ f'
   52: t            TUPLE      (MARK at 39)
   53: (        MARK
   54: S            STRING     'b'
   59: K            BININT1    1
   61: d            DICT       (MARK at 53)
   62: t        TUPLE      (MARK at 19)
   63: R    REDUCE
   64: .    STOP

Unfortunately, pickle.Pickler cannot generate a such pickle stream. So
this bug is symptom of the bigger issue that classes with *args and/or
**kwargs argument cannot be made picklable.

----------
nosy: +alexandre.vassalotti
priority:  -> normal
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1398>
_______________________________________

From report at bugs.python.org  Fri Aug 15 20:35:36 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Aug 2008 18:35:36 +0000
Subject: [issue3558] Operator precedence misdocumented
In-Reply-To: <1218775561.6.0.243287416094.issue3558@psf.upfronthosting.co.za>
Message-ID: <1218825336.85.0.00690307954812.issue3558@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, moved attribute reference to the appropriate place in r65693.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3558>
_______________________________________

From report at bugs.python.org  Fri Aug 15 21:10:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 19:10:37 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218823694.73.0.394409773867.issue3560@psf.upfronthosting.co.za>
Message-ID: <48A5D4A9.1020704@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Because it should be fixed before 3.0 final?

And why should that be done? IMO, this can still
be fixed in 3.1, or not a fixed at all - I fail to
see the true bug (apart from the minor redundancy).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 21:24:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 19:24:22 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <48A5D4A9.1020704@v.loewis.de>
Message-ID: <1218828259.5682.5.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 15 ao?t 2008 ? 19:10 +0000, Martin v. L?wis a ?crit :
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> > Because it should be fixed before 3.0 final?
> 
> And why should that be done? IMO, this can still
> be fixed in 3.1, or not a fixed at all - I fail to
> see the true bug (apart from the minor redundancy).

I've filed this as critical because it is a new API and, if we change
it, we'd better change it before 3.0 is released.

It is a minor redundancy but could easily lead to subtle problems
(crashes, memory leaks...) if for whatever reason, "base" and "view.obj"
start pointing to different objects.

Of course, if other people disagree, it can be bumped down to "normal".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 21:45:05 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 19:45:05 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218828259.5682.5.camel@fsol>
Message-ID: <48A5DCBE.80304@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I've filed this as critical because it is a new API and, if we change
> it, we'd better change it before 3.0 is released.

I don't think it is API. The structure may be defined in a public
header, but it is not intended to be used directly. Instead,
only the functions around it should be used.

To make that clear, the structure could be moved into the C file,
and PyMemoryView should become a function (or also be moved into
the C file). This should be done before the next beta, indeed
(but I won't have the time to do it)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 21:58:10 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 19:58:10 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1218830290.26.0.307744670156.issue3560@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 22:19:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 20:19:54 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1218831594.01.0.816841363166.issue3560@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is a simple patch. It:
- moves the struct definition at the end of memoryobject.h with a
comment that the definition should not be considered public
- adds two macros for accessing the underlying Py_buffer* and PyObject*,
respectively
- removes the ill-named PyMemoryView() macro (PyMemoryView_GET_BUFFER()
can be used instead)
- renames PyMemory_Check() to PyMemoryView_Check()
- renames PyMemoryView_FromMemory() to PyMemoryView_FromBuffer()

I didn't try to clean up the existing documentation comments, although I
find them difficult to follow. I also didn't change anything in the
semantics and implementation of the memoryview object.

Let me know what you think.

----------
keywords: +patch
Added file: http://bugs.python.org/file11119/memapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:03:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 21:03:58 +0000
Subject: [issue2676] email/message.py [Message.get_content_type]: Trivial
	regex hangs on pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1218834238.1.0.152217161235.issue2676@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65700. Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2676>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:08:56 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 21:08:56 +0000
Subject: [issue3562] Intermitent failure in
	test_multiprocessing.test_number_of_objects
In-Reply-To: <1218834536.55.0.521559442827.issue3562@psf.upfronthosting.co.za>
Message-ID: <1218834536.55.0.521559442827.issue3562@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Just got the following on trunk:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/memapi/Lib/test/test_multiprocessing.py",
line 1040, in test_number_of_objects
    print(self.manager._debug_info())
  File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
555, in _debug_info
    return dispatch(conn, None, 'debug_info')
  File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
85, in dispatch
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
187, in handle_request
    result = func(c, *args, **kwds)
  File "/home/antoine/py3k/memapi/Lib/multiprocessing/managers.py", line
305, in debug_info
    keys.sort()
TypeError: unorderable types: str() < int()
---------------------------------------------------------------------------

----------
assignee: jnoller
components: Library (Lib), Tests
messages: 71184
nosy: jnoller, pitrou
priority: high
severity: normal
status: open
title: Intermitent failure in test_multiprocessing.test_number_of_objects
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3562>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:09:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 21:09:16 +0000
Subject: [issue3562] Intermitent failure in
	test_multiprocessing.test_number_of_objects
In-Reply-To: <1218834536.55.0.521559442827.issue3562@psf.upfronthosting.co.za>
Message-ID: <1218834556.16.0.67744360174.issue3562@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.0 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3562>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:22:05 2008
From: report at bugs.python.org (Jason Spiro)
Date: Fri, 15 Aug 2008 21:22:05 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1218835325.62.0.471571056897.issue3561@psf.upfronthosting.co.za>


Jason Spiro <jasonspiro4 at gmail.com> added the comment:

Martin, at the time I read the python-list thread, I didn't pay any 
attention to the posts' authors.  Only now did I realize you were one 
of the posters.  Oops.

I already know the basic ideas about creating MSIs with Wise from a 
past job.  So now I researched and thought about this particular 
problem for several hours.  I've learned that Windows Installer is able 
to add ...\python and ...\python\scripts to the PATH during 
installation.  It cannot[1] remove them at uninstallation.  [ WiX, and 
its superior competitor MAKEMSI, each provide slightly higher-level 
abstractions[2][3] on top of what Windows Installer provides[4] to make 
this slightly easier, but not by that much.  But I will assume you 
don't plan to spend days or weeks of your spare time on migrating away 
from msilib. :-) ]

Here are the rough notes I've made up so far on how to do this:

-  make a new method add_environment.  In it:
    -  call start_component to create components "modify_path_per_user" 
and "modify_path_per_machine"
    -  call add_data to create an Environment table.  It should have 
two rows[5]:
        -  Name:"=PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]" 
Component:"modify_path_per_user"
        -  Name:"=*PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]" 
Component:"modify_path_per_machine"

Another difficult part is the UI.  Then there's the issue of switching 
which of the two components are installed based on whether it's per-
user or per-machine and also based on whether the user specifies via 
the UI that they want their PATH changed.  I have to think more about 
that, and I'm already tired of researching.

Remember that Windows Installer cannot undo its PATH changes at 
uninstall time.  So, before I consider proceeding further, let me 
verify a few things with you.

1.  [TARGETDIR] will stay on the path.  I think that is fine, since the 
python.exe will be gone, so will never be executed.  Do you agree?

2.  [TARGETDIR]\scripts will also stay on the path.  And it may still 
contain scripts installed by the user or by third-party installers like 
the SCons installer.  I don't know enough about how Python works to 
know if that's a problem.  Is it a problem?

P.S.  Would you prefer to discuss this by something more synchronous 
like telephone (I will pay the tolls) or instant messaging?

P.P.S.  Now that I have realized how complicated Python installation 
actually is, and how hard it is to design the tables of and write 
raw .MSI files, I have a new appreciation for the work you've done on 
making a Python MSI installer.  Thank you very much for having done 
so.  Also, now that I have started researching how much work is 
necessary to get this done, I realize why you don't want to code it 
yourself.  :-)

I don't know if I will end up actually managing to come up with a patch.

^ [1].  I have inferred this fact based on 
http://www.isg.ee.ethz.ch/tools/realmen/det/msi.en.html -- scroll down 
to the "Setting the PATH" section
^ [2].  http://blogs.technet.com/alexshev/archive/2008/03/28/from-msi-
to-wix-part-13-installable-items-environment-variable.aspx
^ [3].  http://makemsi-manual.dennisbareis.com/path.htm
^ [4].  http://msdn.microsoft.com/en-us/library/aa368369(printer).aspx
^ [5].  Search inside the page http://msdn.microsoft.com/en-
us/library/aa368369(printer).aspx for "If the package can be installed 
per-user or per-machine" to see why you need two rows.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:31:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Aug 2008 21:31:12 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1218835872.26.0.658600903023.issue2834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Barry?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:40:36 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 21:40:36 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1218836436.01.0.829908951158.issue2271@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please try out the file at

https://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6.14106.msi

and report whether it fixes the issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:42:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 21:42:06 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1218836526.74.0.702582465296.issue2271@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please try out the file at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6.14106.msi

and report whether it fixes the issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Fri Aug 15 23:42:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 21:42:17 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1218836537.14.0.766649943493.issue2271@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Sat Aug 16 00:36:54 2008
From: report at bugs.python.org (jess)
Date: Fri, 15 Aug 2008 22:36:54 +0000
Subject: [issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1,
	Linux 64bit
In-Reply-To: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>
Message-ID: <1218839814.89.0.995230951175.issue3107@psf.upfronthosting.co.za>


jess <jess at boulder.com> added the comment:

This appears to be the same issue as in:
3055  	2 months ago  	 test_list on 64-bit platforms

The failing test appears to be test_bigrepeat:

    def test_bigrepeat(self):
        x = self.type2test([0])
        x *= 2**16
        self.assertRaises(MemoryError, x.__mul__, 2**16)
        if hasattr(x, '__imul__'):
            self.assertRaises(MemoryError, x.__imul__, 2**16)

I am experiencing the same symptoms with 64-bit builds on Solaris10 on
an 8gb sparc machine with lots of virtual memory.  The test is
attempting to allocate a list with 4gb elements.  This requires more
space than there is physical memory so the machine starts swapping like
crazy but does not throw an error in 64 bit mode.  In 32 bit, it would
presumabley throw the error because the test has requested more than 4gb
of memory.

In other words Python appears to be working as it should.  In my case I
am not sure that Solaris10 is scanning for virtual memory properly but
that is an entirely different problem.

----------
nosy: +jess

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3107>
_______________________________________

From report at bugs.python.org  Sat Aug 16 01:01:13 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Aug 2008 23:01:13 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218835325.62.0.471571056897.issue3561@psf.upfronthosting.co.za>
Message-ID: <48A60AB5.4030709@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 1.  [TARGETDIR] will stay on the path.  I think that is fine, since the 
> python.exe will be gone, so will never be executed.  Do you agree?

Completely disagree. Adding something to PATH is nearly unacceptable
clutter even during installation, and completely unacceptable (to me)
after uninstallation. If you install Python several times, will the path
get longer and longer?

In principal, uninstallation should completely undo installation. There
should be only plausible exceptions, e.g. when the user still has files
in a directory, deleting the directory is unacceptable as it would also
delete the files. The big problem where the Python installer (and MSI
in general) fails is uninstallation of file associations, which doesn't
restore the file assocations to what they were (of course, that software
might be gone)

> 2.  [TARGETDIR]\scripts will also stay on the path.  And it may still 
> contain scripts installed by the user or by third-party installers like 
> the SCons installer.  I don't know enough about how Python works to 
> know if that's a problem.  Is it a problem?

To me, any change to PATH is a problem... (I really think that software
installation should never ever touch it - this aspect of the operating
system completely belongs to the user resp. the system administrator)

> P.S.  Would you prefer to discuss this by something more synchronous 
> like telephone (I will pay the tolls) or instant messaging?

I don't think this can be done for 2.6, so there is no need for
synchrony - there is plenty of time to come up with a solution
for 2.7/3.1. In any case, I'll be away for the next three weeks.

> It cannot[1] remove them at uninstallation.
> ^ [1].  I have inferred this fact based on 
> http://www.isg.ee.ethz.ch/tools/realmen/det/msi.en.html -- scroll down 
> to the "Setting the PATH" section

I think this is incorrect. You cannot uninstall the path through
unsetting the PATH variable, sure. So perhaps using the Environment
table is the wrong approach in the first place. You can do nearly
anything in a custom action, so it should be possible to remove the
path entry on uninstallation by means of a custom action.

If such a solution was designed, there would still be many questions,
such as:
- what is the actual problem being solved? Is it real? Could there
  be other solutions to that problem (such as installing things into
  system32, or somewhere else that is on the PATH already)?
- if the path is modified, should the Python directory be added to
  the beginning or the end?
- IMO, this feature needs to be customizable, and IMO, it must be
  turned off by default. So how should such customization be offered?
These questions can partially be discussed in the tracker item proposing
the patch. The very end-user related aspects of it need to be discussed
on python-dev (perhaps taking a poll whether this is desirable, whether
it should be optional, and if so, what the default should be)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3561>
_______________________________________

From report at bugs.python.org  Sat Aug 16 01:59:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Aug 2008 23:59:09 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1218844749.72.0.189028075011.issue3131@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I don't like the patch because it constricts possible fixer dirs. IMO,
refactor.py needs some refactoring its self in order to separate command
line logic from application logic.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Sat Aug 16 03:26:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 01:26:41 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1218850001.95.0.350761049863.issue1179@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1179>
_______________________________________

From report at bugs.python.org  Sat Aug 16 03:41:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 01:41:23 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1218850883.92.0.332367192431.issue3474@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a patch that actually imports reduce from functools to stop
repetition.

----------
keywords: +patch
priority: release blocker -> high
Added file: http://bugs.python.org/file11120/import_from_functools.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Sat Aug 16 04:52:44 2008
From: report at bugs.python.org (Jack Diederich)
Date: Sat, 16 Aug 2008 02:52:44 +0000
Subject: [issue2676] email/message.py [Message.get_content_type]: Trivial
	regex hangs on pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1218855164.91.0.597618587969.issue2676@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Antoine, I looked at your patch and I'm not sure why you applied it
instead of applying mine (or saying +1 on me applying my patch).

Yours uses str.partition which I pointed out is sub-optimal (same big-Oh
but with a larger constant factor) and also adds a function that returns
two things, one of which is thrown away after having a str.strip
performed on it.

If my patch was deficient please let me know.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2676>
_______________________________________

From report at bugs.python.org  Sat Aug 16 05:25:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 03:25:30 +0000
Subject: [issue3499] Python 2.6 requires pre-installed Python to build
In-Reply-To: <1217867777.22.0.746958377378.issue3499@psf.upfronthosting.co.za>
Message-ID: <1218857130.8.0.0613023000038.issue3499@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I've updated release.py to do the dirty work in 65708.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3499>
_______________________________________

From report at bugs.python.org  Sat Aug 16 07:50:16 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 16 Aug 2008 05:50:16 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1218865816.59.0.265900877081.issue3139@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

This seems to break test_unicode on MacOSX 10.5.4,

test_unicode
python(80320,0xa0659fa0) malloc: *** mmap(size=2147483648) failed (error 
code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python(80320,0xa0659fa0) malloc: *** mmap(size=2147483648) failed (error 
code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sat Aug 16 07:56:41 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 05:56:41 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1218866201.77.0.912368200713.issue3547@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Confirmed in HEAD for Python 2.6 and 3.0, on Linux.

Python 2.6b2+ (trunk:65708, Aug 16 2008, 15:04:13) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2

Python 3.0b2+ (py3k:65708, Aug 16 2008, 15:09:19) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2

I was also able to simplify the test case. I get this issue just using
one c_short and one c_long, with nonstandard bit lengths. eg:

fields = [('a', c_short, 16), ('b', c_long, 16)]

(sizeof(c_short) == 2 and sizeof(c_long) == 4).

But it's somewhat sporadic under which conditions it happens and which
it doesn't.

One might imagine this was a simple calculation. But the _ctypes module
is so big (5000 lines of C); at an initial glance I can't find the code
responsible! Any hints? (Modules/_ctypes/ctypes.c presumably is where
this takes place).

----------
nosy: +mgiuca
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Sat Aug 16 08:20:11 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 16 Aug 2008 06:20:11 +0000
Subject: [issue3107] test_list uses unreasonable amounts of memory on 64-bit
	Linux
In-Reply-To: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>
Message-ID: <1218867611.21.0.20547850131.issue3107@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, so it seems there is no memory leak. Changing the title accordingly.

----------
title: memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit -> test_list uses unreasonable amounts of memory on 64-bit Linux

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3107>
_______________________________________

From report at bugs.python.org  Sat Aug 16 08:39:17 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Aug 2008 06:39:17 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1218868757.4.0.0318026034179.issue3473@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ping!

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Sat Aug 16 09:03:08 2008
From: report at bugs.python.org (Ali Polatel)
Date: Sat, 16 Aug 2008 07:03:08 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>


New submission from Ali Polatel <hawking at gentoo.org>:

fix_idioms.py generates bad code for conversions in try/except blocks.
Example:
s=(1, 2, 3)
try:
    t = list(s)
    t.sort()
except TypeError:
    pass

fix_idioms.py generates this diff:
--- test.py (original)
+++ test.py (refactored)
@@ -7,8 +7,7 @@
 
 s=(1, 2, 3)
 try:
-    t = list(s)
-    t.sort()
-except TypeError:
+    t = sorted(s)
+    except TypeError:
     pass
 
except TypeError is indented wrongly.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 71199
nosy: collinwinter, hawking
severity: normal
status: open
title: fix_idioms.py generates bad code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3563>
_______________________________________

From report at bugs.python.org  Sat Aug 16 09:05:11 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 16 Aug 2008 07:05:11 +0000
Subject: [issue3564] making partial functions comparable
In-Reply-To: <1218870311.31.0.296416489838.issue3564@psf.upfronthosting.co.za>
Message-ID: <1218870311.31.0.296416489838.issue3564@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

functools.partial functions are not comparable, in both python 2.5 and 
3.0:

>>> def foo(): pass
>>> functools.partial(foo) == functools.partial(foo)
False

It can be worked around by comparing the func, args, and keywords, but 
this means that if a partial function is stored in some structure, such 
as:

>>> def foo(): pass
>>> f1=functools.partial(foo)
>>> f2=functools.partial(foo)
>>> (1,'a',f1) == (1,'a',f2)
False

Which complicates things when I'm comparing things in a function that 
works with generic data structures. Would it be possible to extend 
partial to support comparisons?

----------
components: Library (Lib)
messages: 71200
nosy: erickt
severity: normal
status: open
title: making partial functions comparable
type: feature request
versions: Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3564>
_______________________________________

From report at bugs.python.org  Sat Aug 16 11:14:13 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 09:14:13 +0000
Subject: [issue3565] array documentation, method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

A few weeks ago I fixed the struct module's documentation which wasn't
3.0 compliant (basically renaming "strings" to "bytes" and "unicode" to
"string"). Now I've had a look at the array module, and it's got similar
problems.

http://docs.python.org/dev/3.0/library/array.html

Unfortunately, the method names are wrong as far as Py3K is concerned.
"tostring" returns what is now called a "bytes", and "tounicode" returns
what is now called a "string".

There are a few other errors in the documentation too, like the 'c' type
code (which no longer exists, but is still documented), and examples
using Python 2 syntax. Those are trivial to fix.

I suggest a 3-step process for fixing this:
1. Update the documentation to describe the 3.0 behaviour using 3.0
terminology, even though the method names are wrong (I've done this
already).
2. Rename "tostring" and "fromstring" methods to "tobytes" and
"frombytes". I think this is quite important as the value being returned
can no longer be described as a "string".
3. Rename "tounicode" and "fromunicode" methods to "tostring" and
"fromstring". I think this is less important, as the name "unicode"
isn't ambiguous, and potentially undesirable, as we'd be re-using method
names which previously did something else.

I'm aware we've got the final beta in 4 days, and there's no way my
phase 2-3 can be done after that. I think we should aim to do phase 2,
but probably not phase 3.

I've fixed the documentation to accurately describe the current
behaviour, using Python 3 terminology. This doesn't change any behaviour
at all, so it should be able to be committed immediately.

I'll have a go at a "phase 2" patch shortly. Is it feasible to even
think about renaming a method at this stage?

Commit log:

Doc/library/array.rst, Modules/arrayobject.c:

Updated array module documentation to be Python 3.0 compliant.

* Removed references to 'c' type code (no longer valid).
* References to "string" changed to "bytes".
* References to "unicode" changed to "string".
* Updated examples to use Python 3.0 syntax (and show the output of
evaluating them).

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
files: doc-only.patch
keywords: patch
messages: 71201
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: array documentation, method names not 3.0 compliant
versions: Python 3.0
Added file: http://bugs.python.org/file11121/doc-only.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Sat Aug 16 11:22:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 16 Aug 2008 09:22:35 +0000
Subject: =?utf-8?q?[issue3565]_array_documentation,
	=09method_names_not_3.0_compliant?=
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <48A69C57.1050402@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> 2. Rename "tostring" and "fromstring" methods to "tobytes" and
> "frombytes". I think this is quite important as the value being returned
> can no longer be described as a "string".

I'm not a native speaker (of English), but my understanding is that the
noun "string", in itself, can very well be used to describe this type:
the result is a "byte string", as opposed to a "character string".
Merriam-Webster's seems to agree; meaning 5b(2) is "a sequence of like
items (as bits, characters, or words)"

----------
nosy: +loewis
title: array documentation, method names not 3.0 compliant -> array documentation,	method names not 3.0 compliant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Sat Aug 16 11:59:16 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 09:59:16 +0000
Subject: =?utf-8?q?[issue3565]_array_documentation,
	=09method_names_not_3.0_compliant?=
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1218880756.53.0.654958057792.issue3565@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> I'm not a native speaker (of English), but my understanding is that the
> noun "string", in itself, can very well be used to describe this type:
> the result is a "byte string", as opposed to a "character string".
> Merriam-Webster's seems to agree; meaning 5b(2) is "a sequence of like
> items (as bits, characters, or words)"

Ah yes, that's quite right (and computer science literature will
strongly support that claim as well).

However the word "string", unqualified, and in Python 3.0 terminology
(as described in PEP 358) now refers only to the "str" type (formerly
known as "unicode"), so it is very confusing to have a method "tostring"
which returns a bytes object.

For array to become a good Py3k citizen, I'd strongly argue that
tostring/fromstring should be renamed to tobytes/frombytes. I'm
currently writing a patch for that - it looks like there's very minimal
damage.

However as a separate issue, I think the documentation update should be
approved first.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Sat Aug 16 12:00:19 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 10:00:19 +0000
Subject: [issue3565] array documentation, method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1218880819.26.0.590096652057.issue3565@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

(Fixed issue title)

----------
title: array documentation,	method names not 3.0 compliant -> array documentation, method names not 3.0 compliant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Sat Aug 16 12:26:09 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 10:26:09 +0000
Subject: [issue3565] array documentation, method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1218882369.59.0.170513169056.issue3565@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

I renamed tostring/fromstring to tobytes/frombytes in the array module,
as described above. I then grepped the entire py3k tree for "tostring"
and "fromstring", and carefully replaced all references which pertain to
array objects.

The relatively minor number of these references suggests this won't be a
big problem. All the test cases pass.

I haven't (yet) renamed tounicode/fromunicode to tostring/fromstring.
The more I think about it, the more that sounds like a bad idea (and
could create confusion as to whether this is a character string or byte
string, as Martin pointed out).

The patch (doc+bytesmethods.patch) does both the original
doc-only.patch, plus the renaming and updating of all usages. Use the
above commit log, plus:

Renamed array.tostring to array.tobytes, and array.fromstring to
array.frombytes, to reflect the Python 3.0 terminology.

Updated all references to these methods in Lib to the new names.

Added file: http://bugs.python.org/file11122/doc+bytesmethods.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Sat Aug 16 12:29:05 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 10:29:05 +0000
Subject: [issue3565] array documentation, method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1218882545.67.0.279281607702.issue3565@psf.upfronthosting.co.za>


Changes by Matt Giuca <matt.giuca at gmail.com>:


Removed file: http://bugs.python.org/file11122/doc+bytesmethods.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Sat Aug 16 12:30:38 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 10:30:38 +0000
Subject: [issue3565] array documentation, method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1218882638.49.0.530686143646.issue3565@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Oops .. forgot to update the array.rst docs with the new method names.
Replaced doc+bytesmethods.patch with a fixed version.

Added file: http://bugs.python.org/file11123/doc+bytesmethods.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Sat Aug 16 12:31:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 10:31:53 +0000
Subject: [issue2676] email/message.py [Message.get_content_type]: Trivial
	regex hangs on pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1218882713.93.0.451820211561.issue2676@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi Jack,

> Antoine, I looked at your patch and I'm not sure why you applied it
> instead of applying mine (or saying +1 on me applying my patch).
> 
> Yours uses str.partition which I pointed out is sub-optimal (same big-Oh
> but with a larger constant factor) and also adds a function that returns
> two things, one of which is thrown away after having a str.strip
> performed on it.

I added that function so that the header splitting facility is
explicitly exposed as an internal API, as was the case with the regular
expression. I tried to mimick the behaviour of the regex as closely as
possible, which meant returning two things as well :-)

I think the point of the issue is to remove the pathological
(exponential) behaviour when parsing some headers, not to try to squeeze
out the last microseconds out of content-type parsing (which shouldn't
be, IMO, the limiting factor in email handling performance as soon as
it's not super-linear).

That said, I've timed the function against the regular expression and
the former is always faster, even for tiny strings (e.g. "a;b").

Your patch was keeping the regular expression as a module-level constant
while replacing all uses of it with a function, which I found a bit
strange (I don't think people are using paramre from the outside since
it's not documented, it's an internal not public API IMO). I also found
it strange to devote a docstring to the discussion of a performance
detail. But I don't have any strong feeling against it either, so you
can still apply it if you think it's important performance-wise.

Regards

Antoine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2676>
_______________________________________

From report at bugs.python.org  Sat Aug 16 12:59:02 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 16 Aug 2008 10:59:02 +0000
Subject: [issue3564] making partial functions comparable
In-Reply-To: <1218870311.31.0.296416489838.issue3564@psf.upfronthosting.co.za>
Message-ID: <1218884342.08.0.77112069093.issue3564@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

It's highly debatable whether these should compare true. (Note: saying
"they aren't comparable" is a misnomer -- they are comparable, they just
don't compare equal).

>From a mathematical standpoint, they *are* equal, but it's impossible
(undecidable) to get pure equality of higher order values (functions) in
a programming language (because strictly, any two functions which give
the same results for the same input are equal, but it's undecidable
whether any two functions will give the same results for all inputs). So
we have to be conservative (false negatives, but no false positives).

In other words, should these compare equal?

>>> (lambda x: x + 1) == (lambda x: x + 1)
False (even though technically they describe the same function)

I would argue that if you call functools.partial twice, separately, then
you are creating two function objects which are not equal.

I would also argue that functools.partial(f, arg1, ..., argn) should be
equivalent to lambda *rest: f(arg1, ..., argn, *rest). Hence your example:
>>> def foo(): pass
>>> f1=functools.partial(foo)
>>> f2=functools.partial(foo)

Is basically equivalent to doing this:

>>> def foo(): pass
>>> f1 = lambda: foo()
>>> f2 = lambda: foo()

Now f1 and f2 are not equal, because they are two separately defined
functions.

I think you should raise this on Python-ideas, instead of as a bug report:
http://mail.python.org/pipermail/python-ideas/

But with two identical functions comparing INEQUAL if they were created
separately, I see no reason for partial functions to behave differently.

----------
nosy: +mgiuca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3564>
_______________________________________

From report at bugs.python.org  Sat Aug 16 14:21:29 2008
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 16 Aug 2008 12:21:29 +0000
Subject: [issue3530] ast.NodeTransformer bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1218889289.0.0.3348723151.issue3530@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

This is actually not a bug.  copy_location does not work recursively. 
For this example it's more useful to use the "fix_missing_locations"
function which traverses the tree and copies the locations from the
parent node to the child nodes:

import ast
a = ast.parse('foo', mode='eval')
x = compile(a, '<unknown>', mode='eval')

class RewriteName(ast.NodeTransformer):
    def visit_Name(self, node):
        return ast.Subscript(
            value=ast.Name(id='data', ctx=ast.Load()),
            slice=ast.Index(value=ast.Str(s=node.id)),
            ctx=node.ctx
        )

a2 = ast.fix_missing_locations(RewriteName().visit(a))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sat Aug 16 15:06:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 13:06:24 +0000
Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file
In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za>
Message-ID: <1218891984.62.0.123942662336.issue2310@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm a little confused on what needs to happen here. It's "incomplete"
because it gets skipped in merges, but "2.6 ports don't need to be in 3.0".

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2310>
_______________________________________

From report at bugs.python.org  Sat Aug 16 15:06:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 16 Aug 2008 13:06:59 +0000
Subject: [issue3542] Building an MSI installer crashes
In-Reply-To: <1218468621.31.0.60930081544.issue3542@psf.upfronthosting.co.za>
Message-ID: <1218892019.54.0.564506218547.issue3542@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report. This is now fixed in r65709.

The right approach is to use the MS "wide string" API whereever
possible, e.g. invoke MsiSummarySetPropertyInfoW (instead of
MsiSummarySetPropertyInfo, as that defaults to MsiSummarySetPropertyInfoA).

If you ever find that you need to encode a Unicode string to a byte
string so that some "ANSI" API can accept it, use the "mbcs" encoding.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3542>
_______________________________________

From report at bugs.python.org  Sat Aug 16 15:07:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 16 Aug 2008 13:07:07 +0000
Subject: [issue3542] Building an MSI installer crashes
In-Reply-To: <1218468621.31.0.60930081544.issue3542@psf.upfronthosting.co.za>
Message-ID: <1218892027.83.0.770735687774.issue3542@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3542>
_______________________________________

From report at bugs.python.org  Sat Aug 16 15:28:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 13:28:41 +0000
Subject: [issue3055] test_list on 64-bit platforms
In-Reply-To: <1212788254.95.0.00817873629987.issue3055@psf.upfronthosting.co.za>
Message-ID: <1218893321.71.0.673710235186.issue3055@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently this has been fixed as part of r65335 ("Security patches from
Apple:  prevent int overflow when allocating memory"), although it uses
sys.maxint where sys.maxsize may be more appropriate. Can you check?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3055>
_______________________________________

From report at bugs.python.org  Sat Aug 16 15:29:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 13:29:54 +0000
Subject: [issue3107] test_list uses unreasonable amounts of memory on 64-bit
	Linux
In-Reply-To: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>
Message-ID: <1218893394.07.0.39596969412.issue3107@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently this has been fixed as part of r65335 ("Security patches from
Apple:  prevent int overflow when allocating memory"), although it uses
sys.maxint where sys.maxsize may be more appropriate. Can you check?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3107>
_______________________________________

From report at bugs.python.org  Sat Aug 16 16:06:50 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Aug 2008 14:06:50 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1218895610.54.0.67712310371.issue600362@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

This is ok, maybe with some small changes in the docs.

I asked in python-dev if this should go now or wait until 2.7/3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue600362>
_______________________________________

From report at bugs.python.org  Sat Aug 16 16:45:44 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Aug 2008 14:45:44 +0000
Subject: [issue2776] urllib2.urlopen() gets confused with path with // in it
In-Reply-To: <1210109415.44.0.221361539235.issue2776@psf.upfronthosting.co.za>
Message-ID: <1218897944.71.0.971775966338.issue2776@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Commited in revs 65710 and 65711.

Thank you all!!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2776>
_______________________________________

From report at bugs.python.org  Sat Aug 16 16:45:57 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Aug 2008 14:45:57 +0000
Subject: [issue2776] urllib2.urlopen() gets confused with path with // in it
In-Reply-To: <1210109415.44.0.221361539235.issue2776@psf.upfronthosting.co.za>
Message-ID: <1218897957.7.0.534712910073.issue2776@psf.upfronthosting.co.za>


Changes by Facundo Batista <facundo at taniquetil.com.ar>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2776>
_______________________________________

From report at bugs.python.org  Sat Aug 16 17:02:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 15:02:46 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218898966.37.0.463204939637.issue3556@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I wonder if it might be most effective to make a _testcapi interface to
PyErr_NoMemory.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 17:06:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 15:06:25 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1218899185.41.0.710971420945.issue3563@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It's due to these lines in fix_idioms:

if next_stmt:
     next_stmt[0].set_prefix(sort_stmt.get_prefix())

I'm not sure what the correct way to deal with this is. Anyway I'm
attaching a test case.

----------
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file11124/indentation_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3563>
_______________________________________

From report at bugs.python.org  Sat Aug 16 17:07:46 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 16 Aug 2008 15:07:46 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218898966.37.0.463204939637.issue3556@psf.upfronthosting.co.za>
Message-ID: <48A6ED3F.9020300@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I wonder if it might be most effective to make a _testcapi interface to
> PyErr_NoMemory.

How would that work in this case? (I actually don't know what the test
purpose of this test is.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 17:10:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 15:10:17 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218899417.99.0.366566985564.issue3556@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

You're right; this test would be pointless with that. However, I'm
looking at test_exceptions' test_MemoryError that is failing for me
because it gives a OverflowError instead of a MemoryError.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 17:35:03 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Aug 2008 15:35:03 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1218900903.11.0.98756658808.issue3131@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Sat Aug 16 17:36:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Aug 2008 15:36:17 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1218900977.53.0.444297739431.issue3131@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

I reported the same bug with another patch: #3553. I used __import__ 
and module.__file__ attribute (and not realpath).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Sat Aug 16 17:41:19 2008
From: report at bugs.python.org (C. Scott Ananian)
Date: Sat, 16 Aug 2008 15:41:19 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>


New submission from C. Scott Ananian <cscott at cscott.net>:

Although HTTP/1.1 says that servers SHOULD send a Connection: close
header if they intend to close a persistent connection (sec 8.1.2.1),
clients (like httplib) "MUST be able to recover from asynchronous close
events. Client software SHOULD reopen the transport connection and
retransmit the aborted sequence of requests without user interaction so
long as the request sequence is idempotent" (sec 8.1.4) since servers
MAY close a persistent connection after a request due to a timeout or
other reason.  Further, "Clients and servers SHOULD both constantly
watch for the other side of the transport close, and respond to it as
appropriate." (sec 8.1.4).

httplib currently does not detect when the server closes its side of the
connection, until the following bit of HTTPResponse in httplib.py
(python2.5.2):

    def _read_status(self):
        # Initialize with Simple-Response defaults
        line = self.fp.readline()
        ...
        if not line:
            # Presumably, the server closed the connection before
            # sending a valid response.
            raise BadStatusLine(line)
        ...

So we end up raising a BadStatusLine exception for a completely
permissible case: the server closed a persistent connection.  This
causes persistent connections to fail for users of httplib in mysterious
ways, especially if they are behind proxies: Squid, for example, seems
to limit persistent connections to a maximum of 3 requests, and then
closes the connection, causing future requests to raise the BadStatusLine.

There appears to be code attempting to fix this problem in
HTTPConnection.request(), but it doesn't always work.  RFC793 says, "If
an unsolicited FIN arrives from the network, the receiving TCP can ACK
it and tell the user that the connection is closing.  The user will
respond with a CLOSE, upon which the TCP can send a FIN to the other TCP
after sending any remaining data." (sec 3.5 case 2)  Key phrase here is
"after sending any remaining data": python is usually allowed to put the
request on the network without raising a socket.error; the close is not
signaled to python until HTTPResponse.begin() invokes
HTTPResponse._read_status.

It would be best to extend the retry logic in request() to cover this
case as well (store away the previous parameters to request() and if
_read_status() fails invoke HTTPConnection.close(),
HTTPConnection.connect(), HTTPConnection.request(stored_params), and
retry the HTTPConnection.getresponse().  But at the very least python
should document and raise a EAGAIN exception of some kind so that the
caller can distinguish this case from an actual bad status line and
retry the request.

----------
components: Library (Lib)
messages: 71221
nosy: cananian
severity: normal
status: open
title: httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Sat Aug 16 18:16:06 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 16 Aug 2008 16:16:06 +0000
Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file
In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za>
Message-ID: <1218903366.01.0.406957757216.issue2310@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I worry that many things were not recoded in Misc/NEWS at all,
especially in the early days of 3.0 development (e.g. in the p3yk branch
:-).

I'm not sure if it's possible to fix this retroactively, however.  As
long as we keep the changes between the betas complete, and as long as
somebody updates the "what's new" document (I have volunteered for that
though I'm not sure I'll get to it :-( ) I'm okay.

So let's close this.  We don't need more busy-work.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2310>
_______________________________________

From report at bugs.python.org  Sat Aug 16 18:23:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 16:23:58 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1218903838.8.0.145260405375.issue2235@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Let's lower the priority a little then.

----------
nosy: +benjamin.peterson
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Sat Aug 16 18:29:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 16:29:29 +0000
Subject: [issue3424] imghdr test order makes it slow
In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za>
Message-ID: <1218904169.34.0.199881368617.issue3424@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Done in r65713.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3424>
_______________________________________

From report at bugs.python.org  Sat Aug 16 18:31:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 16:31:07 +0000
Subject: [issue3530] ast.NodeTransformer bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1218904267.66.0.728016799686.issue3530@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sat Aug 16 18:32:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 16:32:54 +0000
Subject: [issue3564] making partial functions comparable
In-Reply-To: <1218870311.31.0.296416489838.issue3564@psf.upfronthosting.co.za>
Message-ID: <1218904374.05.0.978202588434.issue3564@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would add that making the comparison "right" for partial would be
trickier than it seems:

>>> from functools import partial
>>> type == type
True
>>> 1 == 1.0
True
>>> partial(type, 1)() == partial(type, 1.0)()
False

If partial(type, 1) and partial(type, 1.0) were to compare equal, it
would break the expectation, stated by Matt, that two equal function
objects produce the same results when given the same inputs.


PS: 
>>> partial(type, 1)()
<type 'int'>
>>> partial(type, 1.0)()
<type 'float'>

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3564>
_______________________________________

From report at bugs.python.org  Sat Aug 16 18:46:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 16:46:58 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218905218.6.0.508965513946.issue3556@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you test with that patch?

----------
components: +Tests
keywords: +patch
nosy: +pitrou
type:  -> resource usage
Added file: http://bugs.python.org/file11125/memerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 18:47:18 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Aug 2008 16:47:18 +0000
Subject: [issue2756] urllib2 add_header fails with existing unredirected_header
In-Reply-To: <1209913898.38.0.175541514636.issue2756@psf.upfronthosting.co.za>
Message-ID: <1218905238.61.0.13929794889.issue2756@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

What I think is that the AbstractHTTPHandler is grabbing the headers, in
the do_open() method, in an incorrect way.

Check the get_header() method from Request:

def get_header(self, header_name, default=None):
    return self.headers.get(
        header_name,
        self.unredirected_hdrs.get(header_name, default))

What it's doing there is to grab the header from self.header, and if not
there use the one in self.unredirected_hdrs, and if not there return the
default.

So, to emulate this behaviour, in do_open() I just grabbed first the
unredirected headers, and then updated it with the normal ones.

See my simple patch I attach here, which solves the issue, and passes
all the tests also.

Added file: http://bugs.python.org/file11126/issue2756-facundo.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2756>
_______________________________________

From report at bugs.python.org  Sat Aug 16 20:00:59 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Aug 2008 18:00:59 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218909659.31.0.253364499758.issue3556@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Antoine, it works great, both in 2.6 and in 3.0 (with the obvious small
modification).

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 20:32:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 18:32:48 +0000
Subject: [issue3567] test_ossaudiodev fails when run with -bb
In-Reply-To: <1218911568.33.0.627988957615.issue3567@psf.upfronthosting.co.za>
Message-ID: <1218911568.33.0.627988957615.issue3567@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I suppose the sunau module hasn't received a lot ot love lately :-)

test test_ossaudiodev failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_ossaudiodev.py", line
146, in test_playback
    sound_info = read_sound_file(findfile('audiotest.au'))
  File "/home/antoine/py3k/__svn__/Lib/test/test_ossaudiodev.py", line
27, in read_sound_file
    au = sunau.open(fp)
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 469, in open
    return Au_read(f)
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 158, in __init__
    self.initfp(f)
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 167, in initfp
    magic = int(_read_u32(file))
  File "/home/antoine/py3k/__svn__/Lib/sunau.py", line 138, in _read_u32
    if byte == '':
BytesWarning: Comparison between bytes and string

----------
components: Library (Lib)
messages: 71229
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_ossaudiodev fails when run with -bb
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3567>
_______________________________________

From report at bugs.python.org  Sat Aug 16 21:29:17 2008
From: report at bugs.python.org (Jacek)
Date: Sat, 16 Aug 2008 19:29:17 +0000
Subject: [issue3568] list enumeration corrupt when remove()
In-Reply-To: <1218914957.69.0.531370039263.issue3568@psf.upfronthosting.co.za>
Message-ID: <1218914957.69.0.531370039263.issue3568@psf.upfronthosting.co.za>


New submission from Jacek <jaworski at autograf.pl>:

Hi

I wrote my first program in python, and I found bug in it.
I explain it in example (I do it under Windows XP):

1. At the begining create some directories:
>mkdir .\test\
>mkdir .\test\.svn
>mkdir .\test\cvs
>mkdir .\test\pdk

2. Next create file ".\bug.py" with content:
import re
import os

print 'example1:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk(r'.\\test\\'):
   ldirIndex = 0
   for ldirName in ldirs:
      if lpatternDirSkip.search(ldirName):
         ldirs.remove(ldirName)
   print ldirs

print 'example2:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk('.\\test\\'):
   ldirIndex = 0
   while ldirIndex < len(ldirs):
      if lpatternDirSkip.search(ldirs[ldirIndex]):
         ldirs.remove(ldirs[ldirIndex])
         ldirIndex -= 1
      ldirIndex += 1
   print ldirs

3. Next run cmd.exe (in the same directory) and type "bug.py". Result is:
example1:
['cvs', 'pdk']
[]
[]
example2:
['pdk']
[]

5. Comment:
In this example I want to remove from list of directories (ldirs) every
hiden directories (like ".svn") and directory "CVS". 
Example1 is the comfortable way, but it products wrong result (the "cvs"
directory is not remove). This is only happen when I remove some
directories from the list. I don't care that there was deleted one
element from the list. It should be special case, and enumeration on the
rest elements should be correct.
Example2 works correcty (it's work around of this problem).

Jacek Jaworski

----------
components: Build
messages: 71230
nosy: jacek
severity: normal
status: open
title: list enumeration corrupt when remove()
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3568>
_______________________________________

From report at bugs.python.org  Sat Aug 16 21:30:09 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Aug 2008 19:30:09 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1218915009.29.0.81060005455.issue2464@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Senthil:

Look at that URL that the server returned in the second redirect:

http://www.wikispaces.com?responseToken=ee3fca88a9b0dc865152d8a9e5b6138d

See that the "?" appears without a path between the host and it.

Check the item 3.2.2 in the RFC 2616, it says that a HTTP URL should be:

  http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

So, we should fix that URL that the server returned. Guess what: if we
put a "/" (as obligates the RFC), everything works ok.

The patch I attach here does that. All tests pass ok.

What do you think?

----------
keywords: +patch
Added file: http://bugs.python.org/file11127/issue2464-facundo.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Sat Aug 16 21:31:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 19:31:20 +0000
Subject: [issue3568] list enumeration corrupt when remove()
In-Reply-To: <1218914957.69.0.531370039263.issue3568@psf.upfronthosting.co.za>
Message-ID: <1218915080.73.0.459083342282.issue3568@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It's a known fact that mutating a list during iteration will cause
problems. You should mutate a copy of the list.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3568>
_______________________________________

From report at bugs.python.org  Sat Aug 16 21:50:13 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Aug 2008 19:50:13 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218916213.3.0.439186786472.issue3556@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With sys.maxint gone in 3.0, test_raisexxx() is also gone in 3.0b2

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 21:53:17 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Aug 2008 19:53:17 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218916397.81.0.793176453602.issue3556@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Terry, I don't get to understand your comment. Could you please explain
in more detail? Thank you!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 22:39:47 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Aug 2008 20:39:47 +0000
Subject: [issue3569] Glitch in eval() doc
In-Reply-To: <1218919187.91.0.149398237755.issue3569@psf.upfronthosting.co.za>
Message-ID: <1218919187.91.0.149398237755.issue3569@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

LibRef/built-in functions/eval() has this section

This function can also be used to execute arbitrary code objects (such
as those created by compile()).
In this case pass a code object instead of a string.
The code object must have been compiled passing 'eval' as the kind argument.

As pointed out by Patrick Maupin on py-dev today, the first and third
statements are contradictory: 'arbitrary' != 'limited to kind "eval"'
and the third is wrong in 2.5.  It is still wrong in 3.0b2:

>>> eval(compile('1+2', '', 'eval'))
3
>>> eval(compile('1+2', '', 'exec')) # runs and returns None

Because of the first line, I assume this is intended.

Patrick suggests that the third line be expanded to

In order to return a result other than None to eval's caller,  the code
object must have been compiled passing 'eval' as the kind argument.

I prefer the slightly more compact

In order for eval to return a result other than None, the code object
must have been compiled passing 'eval' as the kind argument.

or even

However eval will return None unless the code object was compiled with
'eval' as the kind argument.

----------
assignee: georg.brandl
components: Documentation
messages: 71235
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Glitch in eval() doc
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3569>
_______________________________________

From report at bugs.python.org  Sat Aug 16 22:45:41 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Aug 2008 20:45:41 +0000
Subject: [issue3568] list enumeration corrupt when remove()
In-Reply-To: <1218914957.69.0.531370039263.issue3568@psf.upfronthosting.co.za>
Message-ID: <1218919541.69.0.0958114624038.issue3568@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since you are just beginning Python, I suggest you report questionable
program behavior on newsgroups comp.lang.python,
gmane.comp.python.general at news.gmane.org, or the python.org mailing
list python-list (all three are equivalent).

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3568>
_______________________________________

From report at bugs.python.org  Sat Aug 16 22:48:03 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 16 Aug 2008 20:48:03 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218905218.6.0.508965513946.issue3556@psf.upfronthosting.co.za>
Message-ID: <48A73D01.3000708@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Can you test with that patch?

I personally can't test it for the next three weeks, sorry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sat Aug 16 22:59:30 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Aug 2008 20:59:30 +0000
Subject: [issue3567] test_ossaudiodev fails when run with -bb
In-Reply-To: <1218911568.33.0.627988957615.issue3567@psf.upfronthosting.co.za>
Message-ID: <1218920370.97.0.0510991133158.issue3567@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Systems that don't run this test (Windows, ??) cannot catch such problems.
Does adding 'b' fix sunau and the test?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3567>
_______________________________________

From report at bugs.python.org  Sat Aug 16 23:05:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 21:05:19 +0000
Subject: [issue896052] symtable module not documented
Message-ID: <1218920719.92.0.793736102845.issue896052@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I wrote up some documentation for it in r65715.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue896052>
_______________________________________

From report at bugs.python.org  Sat Aug 16 23:22:24 2008
From: report at bugs.python.org (Andy Harrington)
Date: Sat, 16 Aug 2008 21:22:24 +0000
Subject: [issue3570] str.find docstring typo
In-Reply-To: <1218921744.88.0.490515931091.issue3570@psf.upfronthosting.co.za>
Message-ID: <1218921744.88.0.490515931091.issue3570@psf.upfronthosting.co.za>


New submission from Andy Harrington <aharrin at luc.edu>:

When you enter help("".find)
you get
...
such that sub is contained within s[start,end]
...

s[start, end] makes no sense.  It should be s[start:end].

----------
assignee: georg.brandl
components: Documentation
messages: 71240
nosy: andyharrington, georg.brandl
severity: normal
status: open
title: str.find docstring typo
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3570>
_______________________________________

From report at bugs.python.org  Sat Aug 16 23:37:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 21:37:38 +0000
Subject: [issue3571] test_closerange in test_os can crash the test suite
In-Reply-To: <1218922658.18.0.0206081400424.issue3571@psf.upfronthosting.co.za>
Message-ID: <1218922658.18.0.0206081400424.issue3571@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I've been trying to track down the following failure which very recently
has started to plague the py3k buildbots:

[...]
test_os
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1197, in <module>
    main()
  File "./Lib/test/regrtest.py", line 400, in main
    print(test)
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1490, in write
    self.flush()
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1455, in flush
    self.buffer.flush()
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1071, in flush
    self._flush_unlocked()
  File
"/home/buildbot/slave/py-build/3.0.norwitz-amd64/build/Lib/io.py", line
1079, in _flush_unlocked
    n = self.raw.write(self._write_buf)
IOError: [Errno 9] Bad file descriptor


I've determined that the failure in writing to the raw stream underlying
stdout is caused by the fact that the file descriptor 0 has been closed
in test_os.test_closerange:

    def test_closerange(self):
        f = os.open(support.TESTFN, os.O_CREAT|os.O_RDWR)
        # close a fd that is open, and one that isn't
        os.closerange(f, f+2)

The problem arises when the call to os.open above returns 0. Normally 0
is the file descriptor underlying stdin, I don't know why it ends up
available for other uses, this would deserve investigation.

In the meantime, a way of circumventing this problem would be to rewrite
test_closerange in a saner way, such that closerange() doesn't try to
close important file descriptors.

----------
components: Tests
messages: 71241
nosy: pitrou
priority: critical
severity: normal
status: open
title: test_closerange in test_os can crash the test suite
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3571>
_______________________________________

From report at bugs.python.org  Sat Aug 16 23:57:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 21:57:18 +0000
Subject: [issue3571] test_closerange in test_os can crash the test suite
In-Reply-To: <1218922658.18.0.0206081400424.issue3571@psf.upfronthosting.co.za>
Message-ID: <1218923838.76.0.221826455558.issue3571@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a temptative patch. It should fix the problems with test_closerange.

----------
keywords: +patch
Added file: http://bugs.python.org/file11128/test_closerange.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3571>
_______________________________________

From report at bugs.python.org  Sun Aug 17 00:04:06 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 16 Aug 2008 22:04:06 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1218924246.08.0.445557775544.issue1342811@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uhm, this patch can cause trouble if not adapted a bit. The index method
may return None for either index1 or index2, which will cause a
TypeError in that for loop.

If code is needed to confirm this, try the following:
menu = Tkinter.Menu(tearoff=False)
menu.delete(0)

----------
nosy: +gpolo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Sun Aug 17 00:20:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 22:20:57 +0000
Subject: [issue3572] with closed file descriptor #2 (stderr),
	py3k hangs when trying to print an exception
In-Reply-To: <1218925257.81.0.638124043012.issue3572@psf.upfronthosting.co.za>
Message-ID: <1218925257.81.0.638124043012.issue3572@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Reproducing this bug is simple:

./python -c "import os; os.close(2); 1/0"

----------
components: Interpreter Core
messages: 71244
nosy: pitrou
priority: high
severity: normal
status: open
title: with closed file descriptor #2 (stderr), py3k hangs when trying to print an exception
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3572>
_______________________________________

From report at bugs.python.org  Sun Aug 17 00:26:11 2008
From: report at bugs.python.org (cfr)
Date: Sat, 16 Aug 2008 22:26:11 +0000
Subject: [issue3549] Missing IDLE Preferences on Mac
In-Reply-To: <1218662954.17.0.753425221317.issue3549@psf.upfronthosting.co.za>
Message-ID: <1218925571.58.0.61445611221.issue3549@psf.upfronthosting.co.za>


cfr <margali at imapmail.org> added the comment:

Also with Python 2.5.2 on OS X 10.4.11 (PPC but it is the universal
installer): there is no Preferences... menu.

The help mentions an Options menu. I don't know if that is the
equivalent, but I cannot find that either.

----------
nosy: +cfr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3549>
_______________________________________

From report at bugs.python.org  Sun Aug 17 00:42:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 22:42:17 +0000
Subject: [issue1397] mysteriously failing test_bsddb3 threading test in other
	threads
In-Reply-To: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za>
Message-ID: <1218926537.27.0.647828658465.issue1397@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This still happens regularly on buildbots. Just today:
http://www.python.org/dev/buildbot/3.0.stable/amd64%20gentoo%203.0/builds/925/step-test/0

The bsddb tests must be fixed so that exception raised in other threads
(especially when produced by assert* methods) cause the test to fail.
The exceptions do indicate a failure, which should be corrected rather
than ignored.

----------
nosy: +pitrou
priority: normal -> high
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397>
_______________________________________

From report at bugs.python.org  Sun Aug 17 00:57:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 16 Aug 2008 22:57:16 +0000
Subject: [issue3572] with closed file descriptor #2 (stderr),
	py3k hangs when trying to print an exception
In-Reply-To: <1218925257.81.0.638124043012.issue3572@psf.upfronthosting.co.za>
Message-ID: <1218927436.77.0.766091312402.issue3572@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3572>
_______________________________________

From report at bugs.python.org  Sun Aug 17 01:11:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Aug 2008 23:11:36 +0000
Subject: [issue3572] with closed file descriptor #2 (stderr),
	py3k hangs when trying to print an exception
In-Reply-To: <1218925257.81.0.638124043012.issue3572@psf.upfronthosting.co.za>
Message-ID: <1218928296.94.0.478934066638.issue3572@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Curious. I wonder if this is platform specific because this does not
hang for me on MacOS.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3572>
_______________________________________

From report at bugs.python.org  Sun Aug 17 01:29:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 23:29:42 +0000
Subject: [issue3571] test_closerange in test_os can crash the test suite
In-Reply-To: <1218922658.18.0.0206081400424.issue3571@psf.upfronthosting.co.za>
Message-ID: <1218929382.16.0.141631037711.issue3571@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've finally diagnosed the problem. test_buffer_is_readonly was opening
stdin's file descriptor again in raw mode, and closing it implicitly by
using "with". 

It should be fixed in r65731.

There's a justice: the test had been checked in by me.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3571>
_______________________________________

From report at bugs.python.org  Sun Aug 17 01:32:26 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 16 Aug 2008 23:32:26 +0000
Subject: [issue3573] IDLE hangs when passing invalid command line args
	(directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Passing a single directory as a command line argument can make IDLE hang.
To achieve this the user needs to configure IDLE to open an editor
window by default.

The attached patch discards filenames that failed to load, so in the end
it may open an empty editor window instead of hanging.

----------
components: Library (Lib)
files: fix_idle_startup_hang.diff
keywords: patch
messages: 71249
nosy: gpolo
severity: normal
status: open
title: IDLE hangs when passing invalid command line args (directory(ies) instead of file(s))
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11129/fix_idle_startup_hang.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________

From report at bugs.python.org  Sun Aug 17 01:52:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Aug 2008 23:52:22 +0000
Subject: [issue3572] with closed file descriptor #2 (stderr),
	py3k hangs when trying to print an exception
In-Reply-To: <1218925257.81.0.638124043012.issue3572@psf.upfronthosting.co.za>
Message-ID: <1218930742.53.0.496213145943.issue3572@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, sorry, false alarm. This was due to some debugging code I had added
in my working copy.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3572>
_______________________________________

From report at bugs.python.org  Sun Aug 17 02:39:40 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 00:39:40 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The following leads to a SyntaxError in 3.0:

  compile(b'# coding: latin-1\nu = "\xC7"\n', '<dummy>', 'exec')

That is not the case in Python 2.6.

----------
messages: 71251
nosy: brett.cannon
severity: normal
status: open
title: compile() cannot decode Latin-1 source encodings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 17 02:40:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 00:40:00 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1218933600.35.0.325803025635.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Looks like Parser/tokenizer.c:check_coding_spec() considered Latin-1 a
raw encoding just like UTF-8. Patch is in the works.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 17 02:43:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 00:43:35 +0000
Subject: [issue3567] test_ossaudiodev fails when run with -bb
In-Reply-To: <1218911568.33.0.627988957615.issue3567@psf.upfronthosting.co.za>
Message-ID: <1218933815.22.0.518184049577.issue3567@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65734. I can't guarantee that the whole sunau module is ok,
just that it works enough for the test to pass (and emit the expected
sound...).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3567>
_______________________________________

From report at bugs.python.org  Sun Aug 17 02:50:51 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 17 Aug 2008 00:50:51 +0000
Subject: [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>
Message-ID: <1218934251.71.0.355826066971.issue2693@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Hi there,

The revisions you are after are r59653 and r59654.
I really don't see a reason to not patch release25-maint with those ones.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
_______________________________________

From report at bugs.python.org  Sun Aug 17 03:20:48 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Aug 2008 01:20:48 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1218936048.33.0.35890207572.issue2464@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

looks good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Sun Aug 17 03:28:15 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Aug 2008 01:28:15 +0000
Subject: [issue1397] mysteriously failing test_bsddb3 threading test in other
	threads
In-Reply-To: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za>
Message-ID: <1218936495.71.0.272867151539.issue1397@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

agreed, that should be made to cause the test to fail.  a
failureException method that sets a flag that the main thread will
detect and fail on when exiting should do the trick.

side note:
...sadly that failure appears to be a test issue, not really a bsddb
wrapper issue...

(There are many tests in the Lib/bsddb/test/ full test suite that appear
to go overboard as far as testing a python wrapper is concerned and are
effectively tests of BerkeleyDB features themselves.  That doesn't help
our test reliability.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397>
_______________________________________

From report at bugs.python.org  Sun Aug 17 03:56:37 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 01:56:37 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1218938197.01.0.299080592151.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a potential fix. It broke test_imp because it assumed that
Latin-1 source files would be encoded at Latin-1 instead of UTF-8 when
returned by imp.new_module(). Doesn't seem like a critical change as the
file is still properly decoded.

----------
keywords: +patch
Added file: http://bugs.python.org/file11130/fix_latin.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 17 03:58:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 01:58:00 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1218938280.34.0.200730306292.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a test for test_pep3120 (since that is what most likely
introduced the breakage). It's a separate patch since the source file is
marked as binary and thus can't be diffed by ``svn diff``.

----------
components: +Interpreter Core
priority:  -> critical
versions: +Python 3.0
Added file: http://bugs.python.org/file11131/pep3120_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 17 03:58:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 01:58:08 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1218938288.37.0.120194293773.issue3574@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 17 04:42:19 2008
From: report at bugs.python.org (Senthil)
Date: Sun, 17 Aug 2008 02:42:19 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1218940939.94.0.382839140202.issue2464@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Ah, I that was a simple fix. :) I very much overlooked the problem after
being so much given the hints at the web-sig.

I have some comments on the patch, Facundo.
1) I don't think is a good idea to include that portion in the
http_error_302 method. That makes the fix "very" specific to "this"
issue only. 
Another point is, fixing broken url's should not be under urllib2,
urlparse would be a better place.
So, I came up with the approach wherein urllib2 does unparse(parse) of
the url and parse methods will fix the url if it is broken. ( See
attached   issue2464-PATCH1.diff)

But if we handle it in the urlparse methods, then we are much
susceptible to breaking RFC conformance, breaking a lot of tests, Which
is not a  good idea.

So,I introduced fix_broken() method in urlparse and called it to solve
the issue, using the same logic as yours (issue2464-py26-FINAL.diff)
With fix_broken() method in urlparse, we will have better control
whenever we want to implement a behavior which is RFC non-confirming but
implemented widely by browsers and clients.

All tests pass with issue2464-py26-FINAL.diff

Comments,please?

Added file: http://bugs.python.org/file11132/issue2464-py26-FINAL.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Sun Aug 17 04:42:36 2008
From: report at bugs.python.org (Senthil)
Date: Sun, 17 Aug 2008 02:42:36 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1218940956.44.0.477023154394.issue2464@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file11133/issue2464-PATCH1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Sun Aug 17 04:56:27 2008
From: report at bugs.python.org (Senthil)
Date: Sun, 17 Aug 2008 02:56:27 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1218941787.68.0.757462584388.issue2464@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Patch for py3k, but please test this before applying.

Added file: http://bugs.python.org/file11134/issue2463-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Sun Aug 17 05:39:09 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 17 Aug 2008 03:39:09 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1218944349.77.0.0480056070149.issue2464@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Senthil: I don't like that.

Creating a public method called "fix_broken", introducing new behaviours
now in beta, and actually not fixing the url in any broken possibility
(just the path if it's not there), it's way too much for this fix.

I commited the change I proposed. Maybe in the future will have a
"generic url fixing" function, now is not the moment.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Sun Aug 17 11:13:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 09:13:55 +0000
Subject: [issue3575] [py3k] tell() fails in some situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. I noticed test_mailbox (test_add) fails on my win2k machine.
It's something like this.

======================================================================
ERROR: test_add (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_mailbox.py", line 60, in tearDown
    self._box.close()
  File "e:\python-dev\py3k\lib\mailbox.py", line 642, in close
    self.flush()
  File "e:\python-dev\py3k\lib\mailbox.py", line 600, in flush
    stop - self._file.tell()))
  File "e:\python-dev\py3k\lib\io.py", line 1625, in tell
    chars_decoded += len(decoder.decode(next_byte))
  File "e:\python-dev\py3k\lib\io.py", line 1295, in decode
    output = self.decoder.decode(input, final=final)
TypeError: decode() argument 1 must be string or pinned buffer, not
bytearray

And this is simple reproducable code. ("a.txt" contains some text)

f = open("a.txt")
f.read(1)
f.tell() # boom

I searched the place where raises this error in C code,
and I found mbidecoder_decode() is.

    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "t#|i:decode",
    		incrementalkwarglist, &data, &size, &final))
	return NULL;

This uses "t#", so cannot accept bytearray, probably.
I hope attached file solves this issue. Thank you.

----------
files: fix_mbidecoder_decode.patch
keywords: patch
messages: 71262
nosy: ocean-city
severity: normal
status: open
title: [py3k] tell() fails in some situation
versions: Python 3.0
Added file: http://bugs.python.org/file11135/fix_mbidecoder_decode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________

From report at bugs.python.org  Sun Aug 17 11:32:30 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 09:32:30 +0000
Subject: [issue2222] Memory leak in os.rename?
In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za>
Message-ID: <1218965550.73.0.780893258076.issue2222@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Fixed in r65745. Will be backported to py3k and release25-maint.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2222>
_______________________________________

From report at bugs.python.org  Sun Aug 17 12:36:28 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 17 Aug 2008 10:36:28 +0000
Subject: [issue3576] Demo/embed builds against old version
In-Reply-To: <1218969387.96.0.461430360814.issue3576@psf.upfronthosting.co.za>
Message-ID: <1218969387.96.0.461430360814.issue3576@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

The Python 2.6 version of Demo/embed/Makefile builds against
libpython2.5.a, which doesn't exist in this version.

Quick patch to let it build against libpython2.6.a.

Commit log:

Fixed Demo/embed/Makefile to build against libpython2.6.a.

----------
components: Build
files: embed.makefile.patch
keywords: patch
messages: 71264
nosy: mgiuca
severity: normal
status: open
title: Demo/embed builds against old version
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file11136/embed.makefile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3576>
_______________________________________

From report at bugs.python.org  Sun Aug 17 12:48:21 2008
From: report at bugs.python.org (alonwas)
Date: Sun, 17 Aug 2008 10:48:21 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218665470.22748.9.camel@fsol>
Message-ID: <1218970095.19984.5.camel@alon-lnx.istraresearch.com>


alonwas <alon.was at gmail.com> added the comment:

Antoine,
I had a similar problem with zip version 2.32, but this is fixed in
version 3.0 (or on 64-bit architectures). Would you be able to give it a
try with the newer version (which can be obtained from info-zip.org)?
Unfortunately, my upload bandwidth will not allow me to upload such a
big file.
Thanks,
Alon

On Wed, 2008-08-13 at 22:11 +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> > The problem happens for files between 2GB and 4GB. I can't really send
> > you a link to such a big file. To reproduce the problem, you can
> > generate one.
> 
> The problem is that the "zip" command fails to create a zip file larger
> than 2GB (I get "zip I/O error: Invalid argument"). And even if it
> didn't fail the internal structure of the zip file might not be exactly
> the same as with other compression tools. That's why I was asking you
> for an existing file.
> 
> If I give you an ssh/sftp access somewhere, would you be able to upload
> such a file?
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3535>
> _______________________________________

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Sun Aug 17 13:30:52 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 11:30:52 +0000
Subject: [issue3575] [py3k] tell() fails in some situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218972652.78.0.568561447777.issue3575@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your patch looks right to me. It should also be backported to 2.6.

----------
components: +Library (Lib)
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________

From report at bugs.python.org  Sun Aug 17 13:44:36 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 11:44:36 +0000
Subject: [issue3575] [py3k] tell() fails in some situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218973476.68.0.511765958515.issue3575@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, MultibyteCodec_Decode() also uses Py_buffer in py3k but not in
trunk. Is this also backported?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________

From report at bugs.python.org  Sun Aug 17 14:15:29 2008
From: report at bugs.python.org (John J Lee)
Date: Sun, 17 Aug 2008 12:15:29 +0000
Subject: [issue3577] Interpreter name: python vs. python-3.0
In-Reply-To: <1218975329.44.0.7329421423.issue3577@psf.upfronthosting.co.za>
Message-ID: <1218975329.44.0.7329421423.issue3577@psf.upfronthosting.co.za>


New submission from John J Lee <jjlee at users.sourceforge.net>:

The tutorial says:

"The Python interpreter is usually installed as /usr/local/bin/python on
those machines where it is available"

Shouldn't that be "python3" or "python-3.0"?  And the same throughout
the rest of the tutorial?

make install seems to think that Python 3 should not be installed as
"python", and should be installed as "python-3.0".

----------
assignee: georg.brandl
components: Documentation
messages: 71268
nosy: georg.brandl, jjlee
severity: normal
status: open
title: Interpreter name: python vs. python-3.0
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3577>
_______________________________________

From report at bugs.python.org  Sun Aug 17 14:19:15 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 12:19:15 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1218975555.83.0.102941280127.issue3535@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Alon, can you try with the following patch? It seems to fix it here.

----------
keywords: +patch
priority:  -> normal
versions: +Python 2.6, Python 3.0 -Python 2.5
Added file: http://bugs.python.org/file11137/largezip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Sun Aug 17 14:19:32 2008
From: report at bugs.python.org (John J Lee)
Date: Sun, 17 Aug 2008 12:19:32 +0000
Subject: [issue3577] Interpreter name: python vs. python-3.0
In-Reply-To: <1218975329.44.0.7329421423.issue3577@psf.upfronthosting.co.za>
Message-ID: <1218975572.43.0.319019723859.issue3577@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

"make install" actually installs as "python3.0" (and not as
"python-3.0", nor "python3", nor "python").

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3577>
_______________________________________

From report at bugs.python.org  Sun Aug 17 14:26:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 12:26:12 +0000
Subject: [issue3575] [py3k] tell() fails in some situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218975972.68.0.0806901496243.issue3575@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 17 ao?t 2008 ? 11:44 +0000, Hirokazu Yamamoto a ?crit :
> Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:
> 
> Well, MultibyteCodec_Decode() also uses Py_buffer in py3k but not in
> trunk. Is this also backported?

It should be :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________

From report at bugs.python.org  Sun Aug 17 15:11:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 13:11:33 +0000
Subject: [issue3575] [py3k] tell() fails in some situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218978693.42.0.108654686326.issue3575@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

OK, done.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________

From report at bugs.python.org  Sun Aug 17 15:29:26 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Aug 2008 13:29:26 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218979766.84.0.0749638339208.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that fixes the incref problem for me.  This *definitely* 
needs review from someone more familiar with the multiprocessing module 
than I am;  I'm not at all confident that it won't break something else.

The original problem:  the Server.create method creates shared objects 
with an effective reference count of 0, making them vulnerable to 
premature garbage collection.

The solution in the patch: create shared objects with a reference count 
of 1, and make it the responsibility of the caller of Server.create() to 
do a decref later (once a ProxyObject for the created shared object has 
been initialized).   In effect, Server.create creates and returns a 
reference, and the caller then owns that reference and is responsible 
for disposing of it.

Added file: http://bugs.python.org/file11138/issue3419.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sun Aug 17 15:42:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Aug 2008 13:42:07 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's a report from Ismail Donmez (cartman), extracted from the
issue 3419 discussion in an effort to avoid putting multiple
problems under one tracker issue.

[cartman]

With trunk when running test_multiprocessing in a tight loop I saw 
another problem:

test_multiprocessing
Process Process-61:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 229, in _bootstrap
Process Process-60:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 229, in _bootstrap
Process Process-62:
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", 
line 229, in _bootstrap
    util._run_after_forkers()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line 
138, in _run_after_forkers
    util._run_after_forkers()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line 
138, in _run_after_forkers
    util._run_after_forkers()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/util.py", line 
138, in _run_after_forkers
    items = list(_afterfork_registry.items())
    items = list(_afterfork_registry.items())
  File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
  File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
    items = list(_afterfork_registry.items())
  File "/Users/cartman/Sources/py3k/Lib/weakref.py", line 103, in items
    for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration
    for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration
    for key, wr in self.data.items():
RuntimeError: dictionary changed size during iteration

----------
assignee: jnoller
components: Extension Modules
messages: 71274
nosy: cartman, jnoller, marketdickinson
severity: normal
status: open
title: 'dictionary changed size' error in test_multiprocessing
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Sun Aug 17 15:42:42 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Aug 2008 13:42:42 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1218980562.86.0.366829744314.issue3419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[jnoller]
> As for if this should block the release, it should be resolved before  
> final, but should not block the next beta.

So the priority should be 'deferred blocker', no?

[cartman]
> With trunk when running test_multiprocessing in a tight loop I saw 
> another problem:

I think this really belongs in a separate issue.  See issue 3578.

----------
priority:  -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Sun Aug 17 16:20:42 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Aug 2008 14:20:42 +0000
Subject: [issue3575] [py3k] tell() fails in some situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218982842.94.0.718412890751.issue3575@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please state the revision numbers when closing an issue due to a commit;
this makes it easier to find the change later.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________

From report at bugs.python.org  Sun Aug 17 17:04:44 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 15:04:44 +0000
Subject: [issue3575] [py3k] tell() fails in some situation
In-Reply-To: <1218964435.67.0.36705888367.issue3575@psf.upfronthosting.co.za>
Message-ID: <1218985484.65.0.262873230635.issue3575@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, fixed in r65760 and r65762.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3575>
_______________________________________

From report at bugs.python.org  Sun Aug 17 17:09:20 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 15:09:20 +0000
Subject: [issue2222] Memory leak in os.rename?
In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za>
Message-ID: <1218985760.41.0.373075588876.issue2222@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Backported to py3k(r65746) release25-maint(r65747)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2222>
_______________________________________

From report at bugs.python.org  Sun Aug 17 17:30:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Aug 2008 15:30:22 +0000
Subject: [issue1869] Builtin round function is sometimes inaccurate for floats
In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
Message-ID: <1218987022.75.0.160840529397.issue1869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch, George!

This patch fixes the problem in some, but not all cases.  I'd like to take 
this a little further.

As far as I can see, getting correctly rounded results in all cases is out 
of reach without either writing lots of multi-precision code (which would 
make the round code unnecessarily complicated and difficult to maintain) 
or using Python's arbitrary-precision integers (which would be slow).

But it would be reasonable to aim for correctly rounded results

----------
versions: +Python 2.7, Python 3.1 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1869>
_______________________________________

From report at bugs.python.org  Sun Aug 17 17:35:36 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Aug 2008 15:35:36 +0000
Subject: [issue1869] Builtin round function is sometimes inaccurate for floats
In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
Message-ID: <1218987336.41.0.842242365605.issue1869@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hit submit too soon; sorry...

But it would be reasonable to aim for correctly rounded results when the 
second argument to round is not too large (less than 22 in absolute 
value, for example), so that 10**abs(n) is exactly representable as a 
double.  I think this should be easy when n is negative (use fmod to 
compute the remainder, and subtract the remainder from the original 
number to round down, or add (10**-n - remainder) to round up, and a 
little bit more involved when n is positive.

Note that the 3.x version will need to be slightly different, so that it 
does round-half-to-even instead of round-half-away-from-zero.

I think that while these changes could be considered bugfixes they're 
not essential, so should be put off until 2.7/3.1.

----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1869>
_______________________________________

From report at bugs.python.org  Sun Aug 17 17:51:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 Aug 2008 15:51:53 +0000
Subject: [issue3579] Faites Attention en Utilisant Cette Merveille!
In-Reply-To: <01c9008f$995b7180$550be758@etlhifeld>
Message-ID: <1218988313.03.0.663322258708.issue3579@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3579>
_______________________________________

From report at bugs.python.org  Sun Aug 17 18:51:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 16:51:44 +0000
Subject: [issue3580] failures test_os
In-Reply-To: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
Message-ID: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get failures under test_os when launched under Windows XP. More
precisely, it's a Windows XP image inside qemu with the Python build dir
in a Samba mount.


======================================================================
FAIL: test_1565150 (__main__.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 291, in test_1565150
    self.assertEquals(os.stat(self.fname).st_mtime, t1)
AssertionError: 1159195039.0 != 1159195039.25

======================================================================
FAIL: test_1686475 (__main__.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 300, in test_1686475
    self.fail("Could not stat pagefile.sys")
AssertionError: Could not stat pagefile.sys

----------------------------------------------------------------------

----------
assignee: pitrou
components: Tests
messages: 71282
nosy: pitrou
priority: normal
severity: normal
status: open
title: failures test_os
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Sun Aug 17 18:52:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 16:52:38 +0000
Subject: [issue3580] failures in test_os
In-Reply-To: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
Message-ID: <1218991958.33.0.149454912597.issue3580@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: failures test_os -> failures in test_os

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Sun Aug 17 18:53:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 16:53:17 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get failures in test_uuid when run inside a qemu virtual machine. It
is related to the fake MAC address used by qemu.


======================================================================
FAIL: test_ipconfig_getnode (__main__.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_uuid.py", line 326, in test_ipconfig_getnode
    self.check_node(node, 'ipconfig')
  File "Lib\test\test_uuid.py", line 288, in check_node
    self.assertEqual(universal_local_bit, 0, message)
AssertionError: 525400123456 doesn't look like a real MAC address

======================================================================
FAIL: test_windll_getnode (__main__.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_uuid.py", line 351, in test_windll_getnode
    self.check_node(uuid._windll_getnode(), 'windll')
  File "Lib\test\test_uuid.py", line 288, in check_node
    self.assertEqual(universal_local_bit, 0, message)
AssertionError: 525400123456 doesn't look like a real MAC address

----------------------------------------------------------------------

----------
messages: 71283
nosy: pitrou
severity: normal
status: open
title: failures in test_uuid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Sun Aug 17 18:53:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 16:53:40 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1218992020.53.0.476630014706.issue3581@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
components: +Tests
priority:  -> normal
type:  -> behavior
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Sun Aug 17 19:08:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 17:08:24 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218992904.64.0.753513884006.issue3556@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sun Aug 17 19:08:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 17:08:17 +0000
Subject: [issue3556] test_raiseMemError consumes an insane amount of memory
In-Reply-To: <1218745279.31.0.475449103672.issue3556@psf.upfronthosting.co.za>
Message-ID: <1218992897.42.0.897828648384.issue3556@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After testing under Windows, fixed in r65773.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3556>
_______________________________________

From report at bugs.python.org  Sun Aug 17 19:22:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 Aug 2008 17:22:13 +0000
Subject: [issue3570] str.find docstring typo
In-Reply-To: <1218921744.88.0.490515931091.issue3570@psf.upfronthosting.co.za>
Message-ID: <1218993733.15.0.127317079303.issue3570@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This has been fixed in the trunk.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3570>
_______________________________________

From report at bugs.python.org  Sun Aug 17 20:05:21 2008
From: report at bugs.python.org (George Boutsioukis)
Date: Sun, 17 Aug 2008 18:05:21 +0000
Subject: [issue1869] Builtin round function is sometimes inaccurate for floats
In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
Message-ID: <1218996321.07.0.95474271548.issue1869@psf.upfronthosting.co.za>


George Boutsioukis <gboutsioukis at gmail.com> added the comment:

Hi Mark,

Yes, I see where you are going with this and I agree. I think the py3k
round function is a bit more accurate, any chance this can be backported
to 2.7(after modifying the half-rounding)?

Anyway, I was just playing around with the code when I wrote this patch.
Anything beyond math.h(and only the really portable functions) is
obviously out of the question, so there's little here to work with. 

Despite the (rare) unpredictable results, I think this issue is probably
too minor to spend any more time on;IMO nobody really relies on round()
for accuracy anyway. Perhaps this should be just ignored.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1869>
_______________________________________

From report at bugs.python.org  Sun Aug 17 20:18:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 17 Aug 2008 18:18:46 +0000
Subject: [issue3580] failures in test_os
In-Reply-To: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
Message-ID: <1218997126.67.0.253612592056.issue3580@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Maybe will first test failure be fixed by attached patch?
Sorry, this is my bug in issue1709599. :-(

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file11140/fix_test_1565150.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Sun Aug 17 22:16:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 20:16:05 +0000
Subject: [issue3580] failures in test_os
In-Reply-To: <1218997126.67.0.253612592056.issue3580@psf.upfronthosting.co.za>
Message-ID: <1219004161.5542.7.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

No, it doesn't fix it.
But I've just tried manually, and GetVolumeInformation() returns "NTFS"
for the Samba share. Apparently this is a Samba "feature" to work with
Windows NT. :-)
See http://lists.samba.org/archive/samba/2003-April/065027.html

The other failure is trivial, I've fixed it in r65780.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Sun Aug 17 23:00:19 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 17 Aug 2008 21:00:19 +0000
Subject: [issue3582] thread_nt.c update
In-Reply-To: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>
Message-ID: <1219006819.0.0.701658895964.issue3582@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Here is a suggested update to thread_nt.c.  It has two significant 
changes:
1) it uses the new and safer _beginthreadex API to start a thread
2) it implements native TLS functions on NT, which are certain to be as 
fast as possible.

----------
files: thread_nt.patch
keywords: patch, patch
messages: 71289
nosy: krisvale
severity: normal
status: open
title: thread_nt.c update
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file11141/thread_nt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3582>
_______________________________________

From report at bugs.python.org  Sun Aug 17 23:06:26 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 17 Aug 2008 21:06:26 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1219007186.73.0.201949078687.issue3402@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Let's disable it and add it to the release notes.  If nobody steps
forward to fix it, we'll just leave it turned off for the final release.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Sun Aug 17 23:18:58 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 17 Aug 2008 21:18:58 +0000
Subject: [issue3444] add warnings for intra-package imports
In-Reply-To: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>
Message-ID: <1219007938.05.0.6802895547.issue3444@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Has there been any progress on this?  We can fix this after beta 3 if
necessary.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3444>
_______________________________________

From report at bugs.python.org  Sun Aug 17 23:21:01 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Aug 2008 21:21:01 +0000
Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS
In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>
Message-ID: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

OpenDNS has a "feature" where if you enter an address that doesn't
exist, you get a 404 and a Google-looking search page. Problem is that
urllib.urlopen() does not raise any exception on a 404.

Probably should just change the test such that if no exception is
raised, check if a 404 was returned and still consider the test passed.

----------
components: Library (Lib)
messages: 71292
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: test_urllibnet.test_bad_address() fails when using OpenDNS
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________

From report at bugs.python.org  Mon Aug 18 00:10:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 17 Aug 2008 22:10:13 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1219011013.39.0.81546078448.issue3473@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Barry, is it still time for this to be included in 2.6b3?
Guido already approved the idea:
http://mail.python.org/pipermail/python-3000/2008-July/014506.html

----------
assignee: rhettinger -> amaury.forgeotdarc
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Mon Aug 18 00:19:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Aug 2008 22:19:39 +0000
Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't
	have permission to see
In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
Message-ID: <1219011579.12.0.00845112030712.issue2466@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another problem of using os.path.dirname is that for /A/B, it will
return /A, and if /A is itself a symlink to a mount point itself, /A and
/A/B will have different st_dev values... which will be wrongly
interpreted as meaning that /A/B is a mount point.

So here is a possible course of action for ismount:
1- first test if the arg is a symlink and if so, return False (as it
already does today)
2- then use os.path.realname(os.path.dirname(arg)) instead of joining
with ".."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2466>
_______________________________________

From report at bugs.python.org  Mon Aug 18 00:38:07 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Aug 2008 22:38:07 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1219012687.41.0.694958213589.issue2464@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i was pondering if it should go in urlparse instead.  if it did, i think
it should be part of urlparse.urlunparse to ensure that there is always
a trailing slash after the host:port regardless of what the inputs are.

anyways, agreed, this fixes this specific bug.  should it be backported
to release25-maint?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Mon Aug 18 00:56:21 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 17 Aug 2008 22:56:21 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1219013781.57.0.840337896332.issue3402@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Does this affect 2.6 as well?  It's hard to tell from the buildbot output.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Mon Aug 18 01:01:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Aug 2008 23:01:47 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1219014107.19.0.833151621123.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

backported to release25-maint in r65789.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Mon Aug 18 01:04:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 Aug 2008 23:04:09 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1219014249.92.0.554097093576.issue874900@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

One of tests is hanging in 3.0.

----------
resolution: fixed -> 
status: closed -> open
versions: +Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Mon Aug 18 01:06:43 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Aug 2008 23:06:43 +0000
Subject: [issue3309] missing lock release in BZ2File_iternext()
In-Reply-To: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za>
Message-ID: <1219014403.7.0.874643310902.issue3309@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

backported to release25-maint in r65790

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3309>
_______________________________________

From report at bugs.python.org  Mon Aug 18 01:34:29 2008
From: report at bugs.python.org (Jim Hermann)
Date: Sun, 17 Aug 2008 23:34:29 +0000
Subject: [issue3584] Exception for test_urllib2_localnet
In-Reply-To: <1219016069.28.0.247374147192.issue3584@psf.upfronthosting.co.za>
Message-ID: <1219016069.28.0.247374147192.issue3584@psf.upfronthosting.co.za>


New submission from Jim Hermann <python at jimhermann.com>:

When I installed Python 2.5.2 on my Fedora Core 4 system, I ran 'make
test" and the process stopped at this point:

test_urllib2_localnet
Exception in thread Thread-1067:
Traceback (most recent call last):
  File "/usr/local/src/Python-2.5.2/Lib/threading.py", line 486, in
__bootstrap_inner
    self.run()
  File "/usr/local/src/Python-2.5.2/Lib/test/test_urllib2_localnet.py",
line 64, in run
    self._RequestHandlerClass)
  File "/usr/local/src/Python-2.5.2/Lib/test/test_urllib2_localnet.py",
line 22, in __init__
    RequestHandlerClass)
  File "/usr/local/src/Python-2.5.2/Lib/SocketServer.py", line 330, in
__init__
    self.server_bind()
  File "/usr/local/src/Python-2.5.2/Lib/BaseHTTPServer.py", line 101, in
server_bind
    SocketServer.TCPServer.server_bind(self)
  File "/usr/local/src/Python-2.5.2/Lib/SocketServer.py", line 341, in
server_bind
    self.socket.bind(self.server_address)
  File "<string>", line 1, in bind
error: (98, 'Address already in use')

Thanks.

Jim

----------
components: Tests
messages: 71300
nosy: jimhermann
severity: normal
status: open
title: Exception for test_urllib2_localnet
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3584>
_______________________________________

From report at bugs.python.org  Mon Aug 18 01:34:56 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Aug 2008 23:34:56 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1219016096.64.0.120872848914.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

specifically, test_3_join_in_forked_from_thread hangs in py3k and is
currently disabled.

----------
assignee: gregory.p.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Mon Aug 18 01:50:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 17 Aug 2008 23:50:44 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1219017044.42.0.218703323561.issue3385@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Maybe I missed something, but the (subclassable) python implementation
of Pickler is still available with another name:

from pickle import _Pickler as Pickler
class ForkingPickler(Pickler):
    dispatch = Pickler.dispatch.copy()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Mon Aug 18 02:08:54 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 18 Aug 2008 00:08:54 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1219018134.53.0.928404009905.issue2464@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Maybe we can put it in urlunparse... do you all agree with this test cases?

def test_alwayspath(self):
    u = urlparse.urlparse("http://netloc/path;params?query#fragment")
    self.assertEqual(urlparse.urlunparse(u),
"http://netloc/path;params?query#fragment")

    u = urlparse.urlparse("http://netloc?query#fragment")
    self.assertEqual(urlparse.urlunparse(u),
"http://netloc/?query#fragment")

    u = urlparse.urlparse("http://netloc#fragment")
    self.assertEqual(urlparse.urlunparse(u), "http://netloc/#fragment")



Maybe we could backport this more general fix...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Mon Aug 18 02:51:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Aug 2008 00:51:47 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1219020707.58.0.940677402513.issue2464@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

That test case looks good to me for 2.6 and 3.0.  Also add a note to the
documentation with a versionchanged 2.6 about urlunparse always ensuring
there is a / between the netloc and the rest of the url.

I would not back port the more general urlunparse behavior change to 2.5.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Mon Aug 18 03:03:29 2008
From: report at bugs.python.org (Clinton Roy)
Date: Mon, 18 Aug 2008 01:03:29 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>


New submission from Clinton Roy <clinton.roy at gmail.com>:

This patch adds pkg-config support to the python build, a python.pc file
is installed in the pkgconfig directory such that autoconf buildsystems
can trivially link against the python library.

Diff made against revision 65796

----------
components: Build
files: pkgconfig.diff
keywords: patch
messages: 71305
nosy: ClintonRoy
severity: normal
status: open
title: pkg-config support
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file11142/pkgconfig.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Mon Aug 18 03:15:45 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Aug 2008 01:15:45 +0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1219022145.78.0.64259642604.issue2013@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

preventing this right now is that when i apply this to py3k today, it
fails miserably in a debug build.

first, my patch has an invalid assert(size > 0) in it in _PyLong_New as
0 size is used when the value is 0.  get rid of that line.

then things at least run but you'll end up in an infinite loop when the
interpreter exits at best if you've compiled in debug mode.

things work great in a non-pydebug build.

i believe the reason is this change is not properly looking at the
structure allocation sizes.  debug builds add extra structure fields.

i'm investigating.  the free_list code in floatobject.c does not have
this problem so at least there's a good example to go from.

and yet another reason why a more general free list library for various
internals to use would be useful...

----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
_______________________________________

From report at bugs.python.org  Mon Aug 18 03:28:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 01:28:39 +0000
Subject: [issue3576] Demo/embed builds against old version
In-Reply-To: <1218969387.96.0.461430360814.issue3576@psf.upfronthosting.co.za>
Message-ID: <1219022919.24.0.900725948711.issue3576@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r65798.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3576>
_______________________________________

From report at bugs.python.org  Mon Aug 18 03:29:36 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 18 Aug 2008 01:29:36 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1219022976.22.0.0584862332512.issue2384@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

While this is a bug, it's not serious enough to hold up the release.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Mon Aug 18 03:52:53 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 01:52:53 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1219024373.41.0.456810876328.issue3474@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Reviewing the patch at http://codereview.appspot.com/2968 .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Mon Aug 18 03:57:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 01:57:32 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1219024652.29.0.525687604142.issue3474@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Reviewed in Rietveld. Only a minor change is suggested. Otherwise I
think the patch is ready to be committed, Benjamin.

----------
assignee: brett.cannon -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Mon Aug 18 04:01:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 02:01:37 +0000
Subject: [issue3474] Using functools.reduce() does not stop DeprecationWarning
	when using -3
In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za>
Message-ID: <1219024897.34.0.305737233296.issue3474@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the review! Committed in r65802.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3474>
_______________________________________

From report at bugs.python.org  Mon Aug 18 04:59:49 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 18 Aug 2008 02:59:49 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1219028389.06.0.342522502191.issue2919@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Can you get this done before beta 3?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Mon Aug 18 05:00:58 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 18 Aug 2008 03:00:58 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1219028458.26.0.855829110436.issue3132@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

It's looking pessimistic that this is going to make it by beta 3.  If
they can't get in by then, it's too late.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Mon Aug 18 06:56:18 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Aug 2008 04:56:18 +0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1219035378.39.0.680464959275.issue2013@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

attached is an updated patch that also works in debug mode.  to do this
i had to exclude all zero length (value = 0) PyLongObjects from the free
list.  i'm still not sure why, they all have the same underlying
allocation size.

simplifying it to only freelist one digit longs the only useful
differences are in the microbenchmark of -32767..32768.  otherwise
things are slightly slower.  pybench is identical and pystone drops a bit.

i'm closing this as not worth it as things are written.  if someone
wants to pick up the idea and play with freelists go ahead but this
doesn't need to be an open tracker issue.  there is room for improvement
but these patches aren't it.

----------
resolution:  -> rejected
status: open -> closed
Added file: http://bugs.python.org/file11143/py3k_longfreelist2_gps03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
_______________________________________

From report at bugs.python.org  Mon Aug 18 06:56:57 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Aug 2008 04:56:57 +0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1219035417.13.0.503941596057.issue2013@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Added file: http://bugs.python.org/file11144/py3k_longfreelist2_gps04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
_______________________________________

From report at bugs.python.org  Mon Aug 18 11:33:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 09:33:05 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1219051985.65.0.228226076875.issue874900@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If you remove the print() call from joining_func(), does it stop
hanging? It may be due to differences between the io library in py3k and
the builtin file objects in 2.x.
(looking at the date of the commit disabling the test, it is not related
to the thread-safety changes to BufferedWriter, though)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Mon Aug 18 11:36:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 09:36:18 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1219052178.04.0.0490347318158.issue3132@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Let's retarget it to 3.1 then. It's a new feature, not a behaviour
change or a deprecation, so adding it to 3.0 isn't a necessity.

----------
components: +Library (Lib)
nosy: +pitrou
priority: release blocker -> critical
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Mon Aug 18 11:59:51 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Mon, 18 Aug 2008 09:59:51 +0000
Subject: [issue2982] more tests for pyexpat
In-Reply-To: <1211905628.44.0.670797216201.issue2982@psf.upfronthosting.co.za>
Message-ID: <1219053591.77.0.351090598939.issue2982@psf.upfronthosting.co.za>


Maciek Fijalkowski <fijal at genesilico.pl> added the comment:

Next wave of tests - error handling. More specifically all errors that
might happen during parsing XML and reported by parser itself.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2982>
_______________________________________

From report at bugs.python.org  Mon Aug 18 12:22:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Aug 2008 10:22:44 +0000
Subject: [issue3586] pwd.getpwnam('nobody') produces incorrect results if
	sizeof(uid_t) < sizeof(long)
In-Reply-To: <1219054964.79.0.647831105855.issue3586@psf.upfronthosting.co.za>
Message-ID: <1219054964.79.0.647831105855.issue3586@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

On a 64-bit OS X build of Python, built with:

./configure --with-universal-archs=64-bit --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 && 
make

I get the following result:

Python 2.6b2+ (trunk:65805M, Aug 18 2008, 10:59:08) 
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('nobody')
pwd.struct_passwd(pw_name='nobody', pw_passwd='*', pw_uid=4294967294, pw_gid=4294967294, 
pw_gecos='Unprivileged User', pw_dir='/var/empty', pw_shell='/usr/bin/false')

Here the pw_uid and pw_gid should presumably be -2, not 4294967294.  I haven't had time to 
investigate properly, but the problem is almost certainly something to do with the fact that 
sizeof(uid_t) is 4 and sizeof(long) is 8 for this build.  (Though interestingly, the configure 
script detects sizeof(long) as 4, which may not be helping matters.)

This problem is causing test_httpservers to fail on 64-bit OS X.

System info: it's a MacBook Pro;  uname -a gives:
Darwin Macintosh-3.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53 PDT 2008; root:xnu-
1228.5.20~1/RELEASE_I386 i386

----------
components: Extension Modules
messages: 71318
nosy: marketdickinson
severity: normal
status: open
title: pwd.getpwnam('nobody') produces incorrect results if sizeof(uid_t) < sizeof(long)
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3586>
_______________________________________

From report at bugs.python.org  Mon Aug 18 12:24:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 10:24:17 +0000
Subject: [issue2982] more tests for pyexpat
In-Reply-To: <1211905628.44.0.670797216201.issue2982@psf.upfronthosting.co.za>
Message-ID: <1219055057.76.0.318083114904.issue2982@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
priority:  -> normal
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2982>
_______________________________________

From report at bugs.python.org  Mon Aug 18 12:52:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 10:52:24 +0000
Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS
In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>
Message-ID: <1219056744.26.0.193325695352.issue3583@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Are many people using OpenDNS? Is there a way to detect that OpenDNS is
being used and trigger a separate path in the test?
I say that because returning a 404 when the domain lookup has failed is
wrong. Perhaps the test should check for a 404 and still raise an
exception, but with an appropriate message indicating that it may be due
to a "featureful" DNS service.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________

From report at bugs.python.org  Mon Aug 18 13:50:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Aug 2008 11:50:17 +0000
Subject: [issue3586] pwd.getpwnam('nobody') produces incorrect results if
	sizeof(uid_t) < sizeof(long)
In-Reply-To: <1219054964.79.0.647831105855.issue3586@psf.upfronthosting.co.za>
Message-ID: <1219060217.74.0.144135043794.issue3586@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It turns out that uid_t (and gid_t) actually *is* an unsigned 32-bit 
integer type on OS X 10.5, so perhaps the pw_uid and pw_gid values are 
correct.  So to rephrase: one or both of the following facts might be 
considered bugs:

(1) On a single machine, the value of pwd.getpwnam('nobody') gives 
different results for 32-bit and 64-bit builds of Python (pw_uid is -2 on 
32-bit, 2**32-2 on 64-bit).

(2) On a 64-bit OS X build, pwd.getpwnam can produce uids and gids >= 
2**31, but os.setuid and friends don't accept values larger than 2**31-1.
There's an inconsistency between pwdmodule.c and posixmodule.c:  pwdmodule 
casts uids to C longs before returning them, while the posixmodule.c 
functions parse an input uid/gid using the "i" format in PyArg_Parse*.

It's the latter problem that's causing test_httpservers to fail on 64-bit 
OS X.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3586>
_______________________________________

From report at bugs.python.org  Mon Aug 18 13:54:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 11:54:20 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1219060460.0.0.334141643627.issue3585@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I cannot discuss about the feature itself, but the patch should
certainly use some macro ($(VERSION) ?) instead of the hardcoded "2.6".
Likewise, source files should not contain version number in their names,
or they cannot be merged between branches.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Mon Aug 18 14:01:09 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 18 Aug 2008 12:01:09 +0000
Subject: [issue2271] msi installs to the incorrect location (C drive)
In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za>
Message-ID: <1219060869.29.0.893723080334.issue2271@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

Yes, that installed Python 2.6 into the correct location (C:\Python26 
instead of into the root directory).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2271>
_______________________________________

From report at bugs.python.org  Mon Aug 18 14:02:23 2008
From: report at bugs.python.org (Misha Seltzer)
Date: Mon, 18 Aug 2008 12:02:23 +0000
Subject: [issue3587] Bad parsing of compiling regex with re.MULTILINE
In-Reply-To: <1219060943.01.0.111673832239.issue3587@psf.upfronthosting.co.za>
Message-ID: <1219060943.01.0.111673832239.issue3587@psf.upfronthosting.co.za>


New submission from Misha Seltzer <misha at seltzer.com>:

import re
regex = r"[\w]+"

# Normal behaviour:
>>> re.findall(regex, "hello world", re.M)
['hello', 'world']
>>> re.compile(regex).findall("hello world")
['hello', 'world']

# Bug behaviour:
>>> re.compile(regex).findall("hello world", re.M)
['rld']

----------
components: Regular Expressions
messages: 71323
nosy: misha
severity: normal
status: open
title: Bad parsing of compiling regex with re.MULTILINE
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3587>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:01:36 2008
From: report at bugs.python.org (Konrad Hinsen)
Date: Mon, 18 Aug 2008 13:01:36 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>


New submission from Konrad Hinsen <konrad.hinsen at laposte.net>:

On a MacOS X framework build, the LINKFORSHARED variable obtained from 
distutils.sysconfig.get_config_vars() has the value

  -u _PyMac_Error Python.framework/Versions/2.5/Python

The last item is incomplete, it needs to be prefixed with the path in 
which the Python framework is installed.

Looking at config/Makefile (from which Distutils takes the variables), I 
find

LINKFORSHARED=	-u _PyMac_Error 
$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)

and

PYTHONFRAMEWORKDIR=	Python.framework

One fix would be to use PYTHONFRAMEWORKINSTALLDIR instead of PYTHONFRAMEWORKDIR in the definition of LINKFORSHARED, but I don't know 
if this could have undesirable effects on the build process.

----------
components: Distutils
messages: 71324
nosy: khinsen
severity: normal
status: open
title: sysconfig variable LINKFORSHARED has wrong value for MacOS X framework build
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:21:15 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Aug 2008 13:21:15 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1219065675.82.0.988640995029.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

numbers.Number change forward ported to Py3k in r65808

Docs updated for 2.6 and 3.0 in r65810 and r65811 respectively.

Which means I can finally close this one :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:25:10 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 13:25:10 +0000
Subject: [issue3587] Bad parsing of compiling regex with re.MULTILINE
In-Reply-To: <1219060943.01.0.111673832239.issue3587@psf.upfronthosting.co.za>
Message-ID: <1219065910.59.0.886490234706.issue3587@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The re.M flag is an attribute of the compiled pattern, and as such it
must be passed to compile(), not to findall(). 

These all work:

>>> re.compile(r"[a-z]+").findall("hello world")
['hello', 'world']
>>> re.compile(r"[a-z]+", re.M).findall("hello world")
['hello', 'world']
>>> re.compile(r"(?m)[a-z]+").findall("hello world")
['hello', 'world']

The second argument to the findall() method of compile objects is the
start position to match from (see
http://docs.python.org/lib/re-objects.html). This explains the behaviour
you are witnessing:

>>> re.M
8
>>> re.compile(r"[a-z]+").findall("hello world", 8)
['rld']

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3587>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:27:25 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Aug 2008 13:27:25 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The package level imports from the new multiprocessing package exhibit
some very strange behaviour because they are actually functions
pretending to be classes:

Python 2.6b1+ (trunk:64945, Jul 14 2008, 20:00:46)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing as mp
>>> isinstance(mp.Lock(), mp.Lock)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes
and types
>>> mp.Lock.__name__
'Lock'
>>> mp.Lock.__module__
'multiprocessing'
>>> mp.Lock().__class__.__name__
'Lock'
>>> mp.Lock().__class__.__module__
'multiprocessing.synchronize'

The delayed import functions in multiprocessing.__init__ look like a
serious misfeature to me. I'd be inclined to replace them with "from
.synchronize import *" and "from .process import *" (leaving anything
which isn't covered by those two imports to be retrieved directly from
the relevant mp submodule)

----------
assignee: jnoller
components: Library (Lib)
messages: 71327
nosy: jnoller, ncoghlan
priority: critical
severity: normal
status: open
title: Misleading names for multiprocessing "convenience" functions
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3589>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:28:30 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Aug 2008 13:28:30 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1219066110.75.0.72974133.issue3589@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Setting to deferred blocker, since this really needs to be dealt with
for RC1 (probably too close to b3 to get it discussed and dealt with for
that).

----------
priority: critical -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3589>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:30:27 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Aug 2008 13:30:27 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219066227.59.0.395318899837.issue3352@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I created issue 3589 to cover the problem I mentioned above with the
very misleading names for the package level functions in multiprocessing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:36:30 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 13:36:30 +0000
Subject: [issue3494] "[Errno 11] Resource temporarily unavailable" while using
	tracing facility/threads (in linux listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1219066590.39.0.136567424153.issue3494@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I do not reproduce the problem, but in your example, the trace function
is called only when the script has finished, i.e during interpreter
shutdown. Creating a thread from there is not recommended...

Can you provide the complete traceback of your error?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________

From report at bugs.python.org  Mon Aug 18 15:43:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 13:43:04 +0000
Subject: [issue3496] distutils fails with mingw binutils 2.18.50.20080109
In-Reply-To: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>
Message-ID: <1219066984.97.0.734869834151.issue3496@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3496>
_______________________________________

From report at bugs.python.org  Mon Aug 18 16:13:44 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 18 Aug 2008 14:13:44 +0000
Subject: [issue3580] failures in test_os
In-Reply-To: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
Message-ID: <1219068824.12.0.621389293535.issue3580@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

> The other failure is trivial, I've fixed it in r65780.

#1709112 has been reported earlier in relation to pagefile.sys. Your
patch addresses at least part of the problem there. I wonder if that
issue can be closed.

----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Mon Aug 18 16:27:51 2008
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 18 Aug 2008 14:27:51 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1219069671.1.0.633996326287.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Hi,

Sorry to bump this, but you (Guido) said you wanted this closed by
Wednesday. Is this patch committable yet? (There are no more unresolved
issues that I am aware of).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Mon Aug 18 16:28:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 14:28:16 +0000
Subject: [issue3580] failures in test_os
In-Reply-To: <1218991904.92.0.339312182303.issue3580@psf.upfronthosting.co.za>
Message-ID: <1219069696.51.0.644575091632.issue3580@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

According to the aforementioned bug report, we should also add a test
for e.winerror == 5. Chances are that other cases will arise one day or
another...

Since the purpose of the test is, allegedly, to "Verify that an open
file can be stat'ed", it may be simpler to create and open a file
ourselves (test_support.TESTFN being an obvious candidate :-)), and
check that it can be stat'ed. Expecting to be able to access
C:\pagefile.sys sounds as "right" as doing the same with, say,
/etc/passwd under Linux.

(and, incidentally, creating the file ourselves means the test will stop
being Windows-specific)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Mon Aug 18 16:30:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 14:30:42 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1219069842.63.0.367857924974.issue3589@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The delayed import functions in multiprocessing.__init__ look like a
> serious misfeature to me. I'd be inclined to replace them with "from
> .synchronize import *" and "from .process import *"

+1
(or, even better, qualified than wildcard imports)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3589>
_______________________________________

From report at bugs.python.org  Mon Aug 18 16:36:24 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 18 Aug 2008 14:36:24 +0000
Subject: [issue3580] failures in test_os
In-Reply-To: <1219069696.51.0.644575091632.issue3580@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0808180736x5fb76103q521deed3499efdc5@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Mon, Aug 18, 2008 at 10:28 AM, Antoine Pitrou <report at bugs.python.org> wrote:
> Since the purpose of the test is, allegedly, to "Verify that an open
> file can be stat'ed", it may be simpler to create and open a file
> ourselves (test_support.TESTFN being an obvious candidate :-)), and

No. Any open file does not do. There has been a discussion on
python-dev some time back about replacing the use of pagefile.sys with
a temporarily created open file. But the problem that spawned this
test case does not occur with just any open file.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3580>
_______________________________________

From report at bugs.python.org  Mon Aug 18 16:51:08 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Mon, 18 Aug 2008 14:51:08 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1219071068.68.0.168654367901.issue2384@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

Py3.0b2. This bug seems to be quite annoying. Especially when one works
with a main module importing modules which are importing modules and so
on, all modules having an encoding declaration. The Traceback (and the
user) is (are) a little bit lost.

---------
# -*- coding: cp1252 -*-
# modb.py

def fb():
    i = 1
    j = 0
    r =  i / j    
-----------
# -*- coding: cp1252 -*-
# moda.py

import modb

def fa():
    modb.fb()
-----------
# -*- coding: cp1252 -*-
# main.py

import moda

def main():
    moda.fa()

if __name__ == '__main__':
    main()
-----------

Running main.py leads to an

>c:\python30\pythonw -u "main.py"
(Traceback (most recent call last):
  File "main.py", line 11, in <module>
    
  File "main.py", line 8, in main
    
  File "C:\jm\jmpy3\moda.py", line 8, in fa
    
  File "C:\jm\jmpy3\modb.py", line 8, in fb
    
ZeroDivisionError: int division or modulo by zero
>Exit code: 1

----------
nosy: +jmfauth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Mon Aug 18 16:52:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 14:52:26 +0000
Subject: [issue3496] distutils fails with mingw binutils 2.18.50.20080109
In-Reply-To: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>
Message-ID: <1219071146.44.0.471980917451.issue3496@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Amaury, if you are going to look at this you might want to see #2234.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3496>
_______________________________________

From report at bugs.python.org  Mon Aug 18 17:02:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 15:02:33 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1219071753.24.0.310490108375.issue3132@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Actually, this may be a requirement of #2394; PEP 3118 states that
memoryview.tolist would use the struct module to do the unpacking.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Mon Aug 18 17:06:15 2008
From: report at bugs.python.org (Edward K Ream)
Date: Mon, 18 Aug 2008 15:06:15 +0000
Subject: [issue3590] sax.parser hangs on byte streams
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>


New submission from Edward K Ream <edreamleo at gmail.com>:

While porting Leo to Python 3.0, I found that passing any byte stream to
xml.sax.parser.parse will hang the parser.  My quick fix was to change:

    while buffer != "":

to:

    while buffer != "" and buffer != b"":

at line 123 of xmlreader.py

Here is the entire function:

def parse(self, source):
        from . import saxutils
        source = saxutils.prepare_input_source(source)

        self.prepareParser(source)
        file = source.getByteStream()
        buffer = file.read(self._bufsize)
        ### while buffer != "":
        while buffer != "" and buffer != b"": ### EKR
            self.feed(buffer)
            buffer = file.read(self._bufsize)
        self.close()

For reference, here is the code in Leo that was hanging::

  parser = xml.sax.make_parser()
  parser.setFeature(xml.sax.handler.feature_external_ges,1)
  handler = saxContentHandler(c,inputFileName,silent,inClipboard)
  parser.setContentHandler(handler)
  parser.parse(theFile)

Looking at the test_expat_file function in test_sax.py, it appears that
the essential difference between the code that hangs and the successful
unit test is that that Leo opens the file in 'rb' mode. (code not shown)
It's doubtful that 'rb' mode is correct--from the unit test I deduce
that the default 'r' mode would be better.  Anyway, it would be nice if
parser.parse didn't hang on dubious streams.

HTH.

Edward

----------
components: Library (Lib)
messages: 71339
nosy: edreamleo
severity: normal
status: open
title: sax.parser hangs on byte streams
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Mon Aug 18 17:09:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 15:09:19 +0000
Subject: [issue3590] sax.parser hangs on byte streams
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219072159.05.0.905939697943.issue3590@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It should probably be changed to just while buffer != b"" since it
requests a byte stream.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Mon Aug 18 17:39:39 2008
From: report at bugs.python.org (Edward K Ream)
Date: Mon, 18 Aug 2008 15:39:39 +0000
Subject: [issue3590] sax.parser hangs on byte streams
In-Reply-To: <1219072159.05.0.905939697943.issue3590@psf.upfronthosting.co.za>
Message-ID: <ffb592890808180839y2aab3dfbo96d79ec33946b37e@mail.gmail.com>


Edward K Ream <edreamleo at gmail.com> added the comment:

On Mon, Aug 18, 2008 at 10:09 AM, Benjamin Peterson
<report at bugs.python.org>wrote:

>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> It should probably be changed to just while buffer != b"" since it
> requests a byte stream.

That was my guess as well.  I added the extra test so as not to remove a
test that might, under some circumstance be important.

Just to be clear, I am at present totally confused about io streams :-)
Especially as used by the sax parsers.  In particular, opening a file in 'r'
mode, that is, passing a *non*-byte stream to parser.parse, works, while
opening a file in 'rb' mode, that is, passing a *byte* stream to
parser.parse, hangs.

Anyway, opening the file passed to parser.parse with 'r' mode looks like the
(only) way to go when using Python 3.0.  In Python 2.5, opening files passed
to parser.parse in 'rb' mode works.  I don't recall whether I had any reason
for 'rb' mode: it may have been an historical accident, or just a lucky
accident :-)

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

Added file: http://bugs.python.org/file11145/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080818/554b378b/attachment.txt>

From report at bugs.python.org  Mon Aug 18 17:51:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 15:51:23 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1219074683.35.0.254120341281.issue3132@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Actually, this may be a requirement of #2394; PEP 3118 states that
> memoryview.tolist would use the struct module to do the unpacking.

:-(
However, we don't have any examples of the buffer API / memoryview
object working with something else than 1-dimensional contiguous char
arrays (e.g. bytearray). Therefore, I suggest that Python 3.0 provide
official support only for 1-dimensional contiguous char arrays. Then
tolist() will be easy to implement even without using the struct module
(just a list of integers, if I understand the functionality).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Mon Aug 18 17:52:01 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 18 Aug 2008 15:52:01 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1219074721.08.0.278310776765.issue3578@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

I don't know if this is reproducible in 2.6 but I can reproduce on py3k 
branch, and also thanks for creating the bug!

----------
versions: +Python 3.0 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Mon Aug 18 17:58:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 15:58:13 +0000
Subject: [issue3444] add warnings for intra-package imports
In-Reply-To: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>
Message-ID: <1219075093.42.0.899748079271.issue3444@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I've been trying to do this for a little, but I can't actually figure
out how to implement the warnings. If anyone has any advice on this I'd
be very thankful! Anyway, you're right in that this doesn't need to
block betas.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3444>
_______________________________________

From report at bugs.python.org  Mon Aug 18 18:00:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 16:00:57 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219075257.86.0.56360168489.issue3590@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Just to be clear, I am at present totally confused about io streams :-)

Python 3.0 distincts more clearly between unicode strings (called "str"
in 3.0) and bytes strings (called "bytes" in 3.0). The most important
point being that there is no more any implicit conversion between the
two: you must explicitly use .encode() or .decode().

Files opened in binary ("rb") mode returns byte strings, but files
opened in text ("r") mode return unicode strings, which means you can't
give a text file to 3.0 library expecting a binary file, or vice-versa.

What is more worrying is that XML, until decoded, should be considered a
byte stream, so sax.parser should accept binary files rather than text
files. I took a look at test_sax and indeed it considers XML as text
rather than bytes :-(

Bumping this as critical because it needs a decision very soon (ideally
before beta3).

----------
nosy: +pitrou
priority:  -> critical
title: sax.parser hangs on byte streams -> sax.parser considers XML as text rather than bytes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Mon Aug 18 18:12:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 16:12:33 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1219075953.43.0.537362383743.issue3578@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mmmh, the problem with the list(X.items()) idiom is that it's
thread-safe only if X.items() is implemented in C. Otherwise X can be
mutated if there is a thread-switch while executing bytecode in X.items().

In weakref.py (line 103), by replacing:
    for key, wr in self.data.items():
with:
    for key, wr in list(self.data.items()):

This particular error should disappear.

But this doesn't say why the dictionary is mutated at all. Does
multiprocessing (or at least that particular test) launch several
threads in a given process? Otherwise there may be something fishy going on.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Mon Aug 18 18:16:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 16:16:02 +0000
Subject: [issue2827] IDLE 3.0a5 cannot handle UTF-8
In-Reply-To: <1210546189.14.0.555715055472.issue2827@psf.upfronthosting.co.za>
Message-ID: <1219076162.06.0.494791750327.issue2827@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I managed to get a proper traceback:

Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\afa\python\py3k\lib\tkinter\__init__.py", line 1405, in __call__
    return self.func(*args)
  File "c:\afa\python\py3k\lib\idlelib\MultiCall.py", line 165, in handler
    r = l[i](event)
  File "c:\afa\python\py3k\lib\idlelib\ScriptBinding.py", line 124, in
run_module_event
    code = self.checksyntax(filename)
  File "c:\afa\python\py3k\lib\idlelib\ScriptBinding.py", line 86, in
checksyntax
    source = f.read()
  File "C:\afa\python\py3k\lib\io.py", line 1692, in read
    decoder.decode(self.buffer.read(), final=True))
  File "C:\afa\python\py3k\lib\io.py", line 1267, in decode
    output = self.decoder.decode(input, final=final)
  File "C:\afa\python\py3k\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position
34: character maps to <undefined>

This is because the file is opened in text mode, using the default
encoding (cp1252). It should instead open it in binary mode, and look
for a -*-coding-*- directive.
There is an attempt for this in linecache.py, but the logic there is wrong.

Is there already a function to properly open a python source file?
tokenize.detect_encoding could be used, but is there a way to open a
file in binary & universal mode?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2827>
_______________________________________

From report at bugs.python.org  Mon Aug 18 18:29:59 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 18 Aug 2008 16:29:59 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219076999.75.0.189239665077.issue1342811@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

You are right. How about the attached patch, do you see any problems
here? Tkinter seems to ignore any delete calls when either of the
indices is None, so the deletion of commands may be ignored as well. But
I couldn't find a description making this API behavior official.

And does anybody know about a test suite for the Tkinter library where
issues like these are tested?

Added file: http://bugs.python.org/file11146/tkinter_menu-error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Mon Aug 18 18:40:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 16:40:36 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219077636.01.0.399615206875.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think I can get this done before the release now. For starters I
changed thread.get_ident() to a property in r65818.

----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Aug 18 18:49:12 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Aug 2008 16:49:12 +0000
Subject: [issue3586] pwd.getpwnam('nobody') produces incorrect results if
	sizeof(uid_t) < sizeof(long)
In-Reply-To: <1219054964.79.0.647831105855.issue3586@psf.upfronthosting.co.za>
Message-ID: <1219078152.9.0.433088125247.issue3586@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Issue 1747858 looks closely related.  I propose extending the simple fix 
used there, parsing all uids and gids as longs rather than ints.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3586>
_______________________________________

From report at bugs.python.org  Mon Aug 18 18:57:49 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 16:57:49 +0000
Subject: [issue3591] elementtree tests do not include bytes handling
In-Reply-To: <1219078669.04.0.473516144349.issue3591@psf.upfronthosting.co.za>
Message-ID: <1219078669.04.0.473516144349.issue3591@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In py3k, there should be explicit tests for byte string input (in
addition to unicode input) to elementtree's parser, including non-UTF8
encodings and non-ASCII chars.

----------
components: Tests, XML
messages: 71351
nosy: effbot, pitrou
priority: normal
severity: normal
status: open
title: elementtree tests do not include bytes handling
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3591>
_______________________________________

From report at bugs.python.org  Mon Aug 18 19:19:18 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 17:19:18 +0000
Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS
In-Reply-To: <1219056744.26.0.193325695352.issue3583@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808181019h61d0b97fkfd1a17c5ec5019dd@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Aug 18, 2008 at 3:52 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Are many people using OpenDNS? Is there a way to detect that OpenDNS is
> being used and trigger a separate path in the test?
> I say that because returning a 404 when the domain lookup has failed is
> wrong. Perhaps the test should check for a 404 and still raise an
> exception, but with an appropriate message indicating that it may be due
> to a "featureful" DNS service.
>

That's also a possibility.

Out of curiosity, what HTTP response should be received?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________

From report at bugs.python.org  Mon Aug 18 19:50:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 17:50:19 +0000
Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS
In-Reply-To: <bbaeab100808181019h61d0b97fkfd1a17c5ec5019dd@mail.gmail.com>
Message-ID: <1219081810.5624.3.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 18 ao?t 2008 ? 17:19 +0000, Brett Cannon a ?crit :
> That's also a possibility.
> 
> Out of curiosity, what HTTP response should be received?

There shouldn't be an HTTP response at all. If DNS lookup fails,
connecting to the server simply fails.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________

From report at bugs.python.org  Mon Aug 18 19:59:26 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 18 Aug 2008 17:59:26 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1219082366.79.0.519552647148.issue2876@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

What's the current status of this? If nobody is working on it, I would
be willing to give it a shot. Can somebody just confirm that I have a
correct understanding of the problem.
UserDict.UserDict needs a deprecation warning, UserDict.IterableUserDict
becomes collections.UserDict, and UserDict.Mixin becomes
collections.MutableMapping. Then for keys(), items(), and values(), I
want to replace something like d.keys() to list(d.keys()). 
One added question: based on what I gathered from PEP 3106, this last
part is only needed in a situation such as a = d.keys(), but not a
situation like for key in keys:, so because in the later case wrapping
the call to keys() in list() would presumably be suboptimal, is this
something I should try and avoid? I'm not sure exactly how it could be
done, but I have some idea of how it to do it.

----------
nosy: +nedds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:07:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 18:07:32 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1219082366.79.0.519552647148.issue2876@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808181107j2510ca80s13864de363d6dea1@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Aug 18, 2008 at 10:59 AM, Nick Edds <report at bugs.python.org> wrote:
>
> Nick Edds <nedds at uchicago.edu> added the comment:
>
> What's the current status of this?

I think it is waiting for someone to work on it.

> If nobody is working on it, I would
> be willing to give it a shot.

Great!

> Can somebody just confirm that I have a
> correct understanding of the problem.
> UserDict.UserDict needs a deprecation warning, UserDict.IterableUserDict
> becomes collections.UserDict, and UserDict.Mixin becomes
> collections.MutableMapping.

In theory, yes, but the superclasses have changed, so I don't know if
having a fixer is really the best option in this case since it is not
a simple renaming. Perhaps deprecation warnings stating that the
classes have been moved and given different superclasses would make
more sense?

> Then for keys(), items(), and values(), I
> want to replace something like d.keys() to list(d.keys()).

Sure, but how the heck are you going to get 2to3 to do this properly
just for UserDict instances? Doesn't the keys()/values()/items() fixer
already do this blindly anyway?

> One added question: based on what I gathered from PEP 3106, this last
> part is only needed in a situation such as a = d.keys(), but not a
> situation like for key in keys:, so because in the later case wrapping
> the call to keys() in list() would presumably be suboptimal, is this
> something I should try and avoid? I'm not sure exactly how it could be
> done, but I have some idea of how it to do it.
>

Yes, you are right that wrapping the call in a for loop is not needed
since code will never come across it. But as I said above, doesn't the
fixer for dicts already handle all of this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:32:38 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Aug 2008 18:32:38 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1219084358.9.0.36229153494.issue3300@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Looking into this now.  Will make sure it's included in beta3.

----------
assignee:  -> gvanrossum
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:44:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 18:44:09 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219085049.71.0.133780725958.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I've done the threading API and patched up multiprocessing so it
actually works. Jesse, can you do multiprocessing?

Also, can we decide about is_alive as a property?

----------
assignee: benjamin.peterson -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:45:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 18:45:49 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219085149.54.0.898051895388.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Oh, and by the way, I would start working on multiprocessing by
reverting r65828.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:46:55 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 18 Aug 2008 18:46:55 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1219085049.71.0.133780725958.issue3352@psf.upfronthosting.co.za>
Message-ID: <4222a8490808181146w48342816lf5af173d1adde613@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Mon, Aug 18, 2008 at 2:44 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Ok. I've done the threading API and patched up multiprocessing so it
> actually works. Jesse, can you do multiprocessing?
>
> Also, can we decide about is_alive as a property?
>

Yup, I can do the MP part.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:47:45 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 18 Aug 2008 18:47:45 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1219085149.54.0.898051895388.issue3352@psf.upfronthosting.co.za>
Message-ID: <4222a8490808181147n4d086308y145109117e40d6aa@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Mon, Aug 18, 2008 at 2:45 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Oh, and by the way, I would start working on multiprocessing by
> reverting r65828.
>

Makes sense.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:51:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 18:51:08 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219085468.74.0.841290241444.issue3590@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>From the discussion on the python-3000, it looks like it would be nice
if sax.parser handled both bytes and unicode streams.

Edward, does your simple fix make sax.parser work entirely well with
byte streams?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Mon Aug 18 20:55:21 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 18 Aug 2008 18:55:21 +0000
Subject: [issue3494] "[Errno 11] Resource temporarily unavailable" while using
	tracing facility/threads (in linux listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1219085721.51.0.871838610856.issue3494@psf.upfronthosting.co.za>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

I've pasted the output below... also, the trace function is called for
each function call after the settrace (not only in interpreter shutdown)
-- and the error happens in the listdir -- which is in the main thread,
so, it must happen before the interpreter shutdown.

Also, one thing: it works if you read an empty folder... And putting:
"print frame.f_code.co_filename, frame.f_lineno" in the 'func', it'll go
on and print
/usr/lib/python2.4/encodings/utf_8.py 15
/usr/lib/python2.4/encodings/utf_8.py 16
/usr/lib/python2.4/encodings/utf_8.py 16

For each file/dir available (so, it seems it's actually able to go on
and get all the contents, but before returning, that exception is thrown)

Output from running it:

-----------------------------------------


/usr/bin/python
Traceback (most recent call last):
  File "/home/fabioz/test workspace with spaces/test
project/src/mod1/mod2/listdir_problem.py", line 23, in ?
    print listdir(dir)
OSError: [Errno 11] Resource temporarily unavailable: '/home/fabioz/jython'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:26:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 19:26:43 +0000
Subject: [issue3496] distutils fails with mingw binutils 2.18.50.20080109
In-Reply-To: <1217779977.05.0.102107142392.issue3496@psf.upfronthosting.co.za>
Message-ID: <1219087603.43.0.097036808404.issue3496@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, this problem is a duplicate of #2234, for which I had a very
similar fix.
Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3496>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:26:50 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 19:26:50 +0000
Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases.
In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
Message-ID: <1219087610.72.0.275389493158.issue2234@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed by r65834, thanks to the patch provided in issue3496.
Will backport.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2234>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:34:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 19:34:27 +0000
Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases.
In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
Message-ID: <1219088067.32.0.0607355232907.issue2234@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

committed r65835 in the release25-maint branch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2234>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:37:52 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 18 Aug 2008 19:37:52 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1219088272.48.0.0462666411144.issue3578@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

py3k branch gives another error now, when running test_multiprocessing 
in a tight loop:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py", 
line 1163, in test_remote
    queue = manager2.get_queue()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 641, in temp
    authkey=self._authkey, exposed=exp
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 893, in AutoProxy
    incref=incref)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 702, in __init__
    self._incref()
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 749, in _incref
    dispatch(conn, None, 'incref', (self._id,))
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 85, in dispatch
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
------------------------------------------------------------------------
---
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 187, in handle_request
    result = func(c, *args, **kwds)
  File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", 
line 403, in incref
    self.id_to_refcount[ident] += 1
KeyError: '7389d0'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:40:50 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 18 Aug 2008 19:40:50 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1219088450.82.0.89779038215.issue3578@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Ismail, that's the incref bug in issue 3419

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:42:23 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 18 Aug 2008 19:42:23 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1218980527.78.0.883807944764.issue3578@psf.upfronthosting.co.za>
Message-ID: <1219088543.86.0.0652188855417.issue3578@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Ah cool, we might be at the end of multiprocessing problems then I guess 
:-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:43:12 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 18 Aug 2008 19:43:12 +0000
Subject: [issue3109] test_multiprocessing seems fragile
In-Reply-To: <1213402075.28.0.267049888199.issue3109@psf.upfronthosting.co.za>
Message-ID: <1219088592.79.0.882813904467.issue3109@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

the "socket.error: [Errno 111] Connection refused" is fixed/resolved with 
the fix for issue 3270

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3109>
_______________________________________

From report at bugs.python.org  Mon Aug 18 21:50:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 19:50:35 +0000
Subject: [issue3578] 'dictionary changed size' error in test_multiprocessing
In-Reply-To: <1219088543.86.0.0652188855417.issue3578@psf.upfronthosting.co.za>
Message-ID: <1219089032.5624.18.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 18 ao?t 2008 ? 19:42 +0000, Ismail Donmez a ?crit :
> Ismail Donmez <ismail at namtrac.org> added the comment:
> 
> Ah cool, we might be at the end of multiprocessing problems then I guess 
> :-)

Well, not really, it should be diagnosed why the dictionary mutates in
the first place. This dictionary is apparently processed in a child
process just after a fork() occurred, so logically there shouldn't be
several threads running.
Unless processing the dictionary itself can create some new threads?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3578>
_______________________________________

From report at bugs.python.org  Mon Aug 18 22:08:12 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 18 Aug 2008 20:08:12 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219090092.9.0.461899348702.issue1342811@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

You could return if in that new if statement.

As you noted, the None argument is ignored there, that is because
_tkinter checks for a None parameter, and if it happens to be a None, it
then stops processing new arguments, so this is not directly related to
the delete command of the Menu widget.

Regarding a test suite.. it would be very nice to get one for Tkinter.
Some weeks ago I did some googling but found no attempts for my surprise.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Mon Aug 18 22:09:17 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 18 Aug 2008 20:09:17 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219090157.39.0.121146561223.issue1342811@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

change this:

"You could return if in that new if statement."

to:

"You could return in that new if statement.", please.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Mon Aug 18 22:16:09 2008
From: report at bugs.python.org (Edward K Ream)
Date: Mon, 18 Aug 2008 20:16:09 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219085468.74.0.841290241444.issue3590@psf.upfronthosting.co.za>
Message-ID: <ffb592890808181316g7e3e9c2qfdb103a071dd73ba@mail.gmail.com>


Edward K Ream <edreamleo at gmail.com> added the comment:

On Mon, Aug 18, 2008 at 1:51 PM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> From the discussion on the python-3000, it looks like it would be nice
> if sax.parser handled both bytes and unicode streams.
>

> Edward, does your simple fix make sax.parser work entirely well with
> byte streams?

No. The sax.parser seems to have other problems.  Here is what I *think* I
know ;-)

1. A smallish .leo file (an xml file) containing a single non-ascii (utf-8)
encoded character appears to have been read correctly with Python 3.0.

2. A larger .leo file fails as follows (it's possible that the duplicate
error messages are a Leo problem):

Traceback (most recent call last):
Traceback (most recent call last):

  File "C:\leo.repo\leo-30\leo\core\leoFileCommands.py", line 1283, in
parse_leo_file
    parser.parse(theFile) # expat does not support parseString
  File "C:\leo.repo\leo-30\leo\core\leoFileCommands.py", line 1283, in
parse_leo_file
    parser.parse(theFile) # expat does not support parseString

  File "c:\python30\lib\xml\sax\expatreader.py", line 107, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "c:\python30\lib\xml\sax\expatreader.py", line 107, in parse
    xmlreader.IncrementalParser.parse(self, source)

  File "c:\python30\lib\xml\sax\xmlreader.py", line 121, in parse
    buffer = file.read(self._bufsize)
  File "c:\python30\lib\xml\sax\xmlreader.py", line 121, in parse
    buffer = file.read(self._bufsize)

  File "C:\Python30\lib\io.py", line 1670, in read
    eof = not self._read_chunk()
  File "C:\Python30\lib\io.py", line 1670, in read
    eof = not self._read_chunk()

  File "C:\Python30\lib\io.py", line 1499, in _read_chunk
    self._set_decoded_chars(self._decoder.decode(input_chunk, eof))
  File "C:\Python30\lib\io.py", line 1499, in _read_chunk
    self._set_decoded_chars(self._decoder.decode(input_chunk, eof))

  File "C:\Python30\lib\io.py", line 1236, in decode
    output = self.decoder.decode(input, final=final)
  File "C:\Python30\lib\io.py", line 1236, in decode
    output = self.decoder.decode(input, final=final)

  File "C:\Python30\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
  File "C:\Python30\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]

UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 74:
character maps to <undefined>
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 74:
character maps to <undefined>

The same calls to sax read the file correctly on Python 2.5.

It would be nice to have a message pinpoint the line and character offset of
the problem.

My vote would be for the code to work on both kinds of input streams. This
would save the users considerable confusion if sax does the (tricky)
conversions automatically.

Imo, now would be the most convenient time to attempt this--there is a
certain freedom in having everything be partially broken :-)

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

Added file: http://bugs.python.org/file11147/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080818/16735195/attachment-0001.txt>

From report at bugs.python.org  Mon Aug 18 22:17:50 2008
From: report at bugs.python.org (Jason Tishler)
Date: Mon, 18 Aug 2008 20:17:50 +0000
Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases.
In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
Message-ID: <1219090670.08.0.461622647621.issue2234@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2234>
_______________________________________

From report at bugs.python.org  Mon Aug 18 22:21:44 2008
From: report at bugs.python.org (Edward K Ream)
Date: Mon, 18 Aug 2008 20:21:44 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219075257.86.0.56360168489.issue3590@psf.upfronthosting.co.za>
Message-ID: <ffb592890808181321peb5f36cjb93d30aae9e0d8f1@mail.gmail.com>


Edward K Ream <edreamleo at gmail.com> added the comment:

On Mon, Aug 18, 2008 at 11:00 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > Just to be clear, I am at present totally confused about io streams :-)
>
> Python 3.0 distincts more clearly between unicode strings (called "str"
> in 3.0) and bytes strings (called "bytes" in 3.0). The most important
> point being that there is no more any implicit conversion between the
> two: you must explicitly use .encode() or .decode().
>
> Files opened in binary ("rb") mode returns byte strings, but files
> opened in text ("r") mode return unicode strings, which means you can't
> give a text file to 3.0 library expecting a binary file, or vice-versa.
>
> What is more worrying is that XML, until decoded, should be considered a
> byte stream, so sax.parser should accept binary files rather than text
> files. I took a look at test_sax and indeed it considers XML as text
> rather than bytes :-(

Thanks for these remarks.  They confirm what I suspected, but was unsure of,
namely that it seems strange to be passing something other than a byte
stream to parser.parse.

>
> Bumping this as critical because it needs a decision very soon (ideally
> before beta3).

Thanks for taking this seriously.

Edward

P.S.  I love the new unicode plans.  They are going to cause some pain at
first for everyone (Python team and developers), but in the long run they
are going to be a big plus for Python.

EKR
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

Added file: http://bugs.python.org/file11148/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080818/ab368a8c/attachment.txt>

From report at bugs.python.org  Mon Aug 18 22:41:41 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Mon, 18 Aug 2008 20:41:41 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1219092101.9.0.319610045805.issue3439@psf.upfronthosting.co.za>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

Wow, newbie error. Thanks for spotting!

In every case I can think of, I've wanted (0).numbits() to be 0. The
explanation in the docstring can probably be improved. What other
documentation is needed (where)?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:06:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 21:06:39 +0000
Subject: [issue3494] "[Errno 11] Resource temporarily unavailable" while using
	tracing facility/threads (in linux listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1219093599.61.0.315263869623.issue3494@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I could reproduce the problem, and it appears that it is the same as
#1608818, corrected by r65037:

on posix platforms, listdir() used to check for errno only at the end of
the list; the problem is that the trace function creates a thread, and
this sets errno (harmlessly) somewhere when playing with locks.

In the python codebase, every function that checks errno should set it
to zero before the system call.
The above fix could be backported.

As a workaround, I suggest to put a line like 
   int('0')
near the end of the trace funtion (at least after the creation of the
thread) because it has the nice side-effect to reset errno.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:08:01 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 18 Aug 2008 21:08:01 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1219093681.67.0.127117981942.issue2876@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Ahh right. I totally forgot that there was already a fix_dict.py that
took care of that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:13:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 21:13:52 +0000
Subject: [issue3592] Patch to add imp.get_codingspec()
In-Reply-To: <1219094032.27.0.00275483545794.issue3592@psf.upfronthosting.co.za>
Message-ID: <1219094032.27.0.00275483545794.issue3592@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Attached is a patch to add imp.get_codingspec(); a function that returns
the encoding of a source file.

The motivation is to remove the import of the re module in linecache to
speed up interpreter startup.

----------
components: Library (Lib)
files: reviewed_get_encodingspec.diff
keywords: patch, patch
messages: 71379
nosy: brett.cannon, christian.heimes
priority: low
severity: normal
status: open
title: Patch to add imp.get_codingspec()
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file11149/reviewed_get_encodingspec.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3592>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:14:48 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Aug 2008 21:14:48 +0000
Subject: [issue3592] Patch to add imp.get_codingspec()
In-Reply-To: <1219094032.27.0.00275483545794.issue3592@psf.upfronthosting.co.za>
Message-ID: <1219094088.87.0.899166408351.issue3592@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It should be noted the original patch by Christian had a check for bad
tokenizing. Turns out that if you have that in several tests fail,
including test_modulefinder. This might mean there is a deeper problem
in the parser.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3592>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:15:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 21:15:29 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219094129.46.0.0453613607899.issue3590@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The same calls to sax read the file correctly on Python 2.5.

What are those calls exactly?
Why is "cp1252" used as an encoding? Is it what is specified in the XML
file? Or do you somehow feed stdin to the SAX parser? (if the latter,
you aren't testing bytes handling since stdin/stdout/stderr are text
streams in py3k)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:25:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 21:25:18 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219094718.14.0.884131521682.issue3590@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I guess that the file is simply opened in text mode ("r"). This uses the
"preferred encoding", which is cp1252 on (western) Windows machines.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:26:27 2008
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 18 Aug 2008 21:26:27 +0000
Subject: [issue3494] "[Errno 11] Resource temporarily unavailable" while using
	tracing facility/threads (in linux listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1219094787.46.0.0574815313969.issue3494@psf.upfronthosting.co.za>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

Thanks for looking into this... 

Unfortunately, I'm not sure I can use the workaround of the int('0'), as
this could fix the debugger, but if the code that's being debugged
spawned other threads (which is pretty common), it would be pointless,
but at least clients that really want this can get that fix and apply it
to their python versions...

And I think that setting the errno to 0 in the debugger every time would
make other things misbehave, as in each python call it'd clear it (or
not? I'm not really aware of the implications of doing so -- but if no
one used it, it wouldn't be there, right?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:28:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Aug 2008 21:28:47 +0000
Subject: [issue3439] math.frexp and obtaining the bit size of a large integer
In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za>
Message-ID: <1219094927.84.0.457443911676.issue3439@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> In every case I can think of, I've wanted (0).numbits() to be 0.

Me too, in most cases, though I've encountered the occasional case where 
raising ValueError would be more appropriate and would catch some bugs 
that might otherwise pass silently.

So I agree that (0).numbits() should be 0, but I think there's enough 
potential ambiguity that there should be a sentence in the documentation  
making this explicit.  Two of the most obvious (wrong) formulas for 
numbits are: (1) numbits(n) = ceiling(log_2(n)), and (2) numbits(n) = 
len(bin(n))-2, but neither of these formulas gives the right result for 
0, or for negative numbers for that matter.

> The explanation in the docstring can probably be improved. What other 
documentation is needed (where)?

The docstring looked okay to me.  There should be more comprehensive 
ReST documentation in the Doc/ directory somewhere, probably in 
Doc/library/stdtypes.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3439>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:30:29 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Mon, 18 Aug 2008 21:30:29 +0000
Subject: [issue3593] subprocess + stdout redirection + wait + svn= hang
In-Reply-To: <1219095028.86.0.31629994109.issue3593@psf.upfronthosting.co.za>
Message-ID: <1219095028.86.0.31629994109.issue3593@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

The attached script hangs on Ubuntu + Python 2.5.2.
When make the limit smaller (like 10) or not redirecting stdout, it works.

Running the svn command from shell took about 4sec, I gave up on the
script after a minute.

I tried it both with svn 1.4.6 and 1.5.1 - no change.

----------
components: Library (Lib)
files: svnout.py
messages: 71385
nosy: tebeka
severity: normal
status: open
title: subprocess + stdout redirection + wait + svn= hang
versions: Python 2.6
Added file: http://bugs.python.org/file11150/svnout.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3593>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:43:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Aug 2008 21:43:33 +0000
Subject: [issue3494] "[Errno 11] Resource temporarily unavailable" while using
	tracing facility/threads (in linux listdir with unicode path)
In-Reply-To: <1217704277.74.0.0700671746724.issue3494@psf.upfronthosting.co.za>
Message-ID: <1219095813.86.0.54885960003.issue3494@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> but if the code that's being debugged
> spawned other threads (which is pretty common), it would be pointless,

No, the problem specifically lies in the implementation of listdir().
This function is not supposed to commonly spawn threads... this can only
happen with a sys.settrace function (or a very special
Py_FileSystemDefaultEncoding)

> And I think that setting the errno to 0 in the debugger every time would
> make other things misbehave, as in each python call it'd clear it

I don't think so. errno is (should be) only used shortly after the C
system call which modified it. There is no room for the trace function
to run.
Remember that the python stack is often displayed on every debugging
step, and this modifies errno more than once (to get the source file
content)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3494>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:45:17 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Aug 2008 21:45:17 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1219095917.21.0.887828171551.issue3300@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Checked in patch 10 with minor style changes as r65838.

Thanks Matt for persevering!  Thanks everyone else for contributing;
this has been quite educational.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:48:44 2008
From: report at bugs.python.org (Kevin Watters)
Date: Mon, 18 Aug 2008 21:48:44 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1219096124.69.0.714525751619.issue815646@psf.upfronthosting.co.za>


Kevin Watters <kevinwatters at gmail.com> added the comment:

I know this is long closed, but no one on the nosy list happens to have
this fix backported to 2.5, do they? :) If not, I'll attach one here
eventually...

----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue815646>
_______________________________________

From report at bugs.python.org  Mon Aug 18 23:52:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 21:52:48 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1219096368.43.0.337365923993.issue815646@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I know this is long closed, but no one on the nosy list happens to have
> this fix backported to 2.5, do they? :)

I think that at the time no one was sure the patch was 100% harmless. It
also subtly changes the behaviour of close() when called while another
IO operation is in progress in another thread, which is arguably a bug
fix but can still raise an exception it wouldn't have raised in 2.5.

So all in all I'm not sure this should be backported, although it would
probably be an improvement in most cases. I'll let someone else take the
decision.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue815646>
_______________________________________

From report at bugs.python.org  Tue Aug 19 00:04:01 2008
From: report at bugs.python.org (Edward K Ream)
Date: Mon, 18 Aug 2008 22:04:01 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219094129.46.0.0453613607899.issue3590@psf.upfronthosting.co.za>
Message-ID: <ffb592890808181503j278851f8ie9927d9b02631570@mail.gmail.com>


Edward K Ream <edreamleo at gmail.com> added the comment:

On Mon, Aug 18, 2008 at 4:15 PM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > The same calls to sax read the file correctly on Python 2.5.
>
> What are those calls exactly?

  parser = xml.sax.make_parser()
  parser.setFeature(xml.sax.handler.feature_external_ges,1)
  handler = saxContentHandler(c,inputFileName,silent,inClipboard)
  parser.setContentHandler(handler)
  parser.parse(theFile)

As discussed in http://bugs.python.org/issue3590

theFile is a file opened with 'rb' attributes

Edward

--------------------------------------------------------------------
Edward K. Ream email: edreamleo at gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

Added file: http://bugs.python.org/file11151/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080818/62eb917d/attachment.txt>

From report at bugs.python.org  Tue Aug 19 00:05:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 22:05:31 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219097131.87.0.522728240279.issue3590@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11145/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Tue Aug 19 00:05:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 22:05:34 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219097134.72.0.0335720388454.issue3590@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11147/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Tue Aug 19 00:05:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 22:05:37 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219097137.77.0.462015268797.issue3590@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11148/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Tue Aug 19 00:05:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 22:05:40 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219097140.68.0.581160799492.issue3590@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11151/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Tue Aug 19 00:07:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Aug 2008 22:07:04 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <ffb592890808181503j278851f8ie9927d9b02631570@mail.gmail.com>
Message-ID: <1219097212.5624.24.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, then xml.sax looks rather broken.

(by the way, can you avoid sending HTML emails? each time you send one,
the bug tracker attaches a file names "unnamed". I've removed all 4 of
them now.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Tue Aug 19 01:26:08 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 18 Aug 2008 23:26:08 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1219101968.75.0.175926794889.issue2919@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Sorry, I can't. I would love to get this done, but I am just too busy
this week (and next week doesn't look any better). Furthermore, the
amount of work that the profile/cProfile merge will require is quite
considerable. So, I don't expect someone else could get this done before
the beta.

----------
keywords: +patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Tue Aug 19 01:27:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Aug 2008 23:27:40 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1219102060.93.0.0977765576074.issue2919@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Let's retarget 3.1 then.

----------
nosy: +benjamin.peterson
priority: release blocker -> critical
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Tue Aug 19 01:29:57 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 18 Aug 2008 23:29:57 +0000
Subject: [issue3385] cPickle to pickle conversion in py3k missing methods
In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za>
Message-ID: <1219102197.2.0.849202830359.issue3385@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Yeah, the old Pickler and Unpickler classes are available by design (to
allow testing both implementation). You could subclass _Pickler as a
temporary fix for this issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3385>
_______________________________________

From report at bugs.python.org  Tue Aug 19 02:20:49 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 19 Aug 2008 00:20:49 +0000
Subject: [issue3558] Operator precedence misdocumented
In-Reply-To: <1218775561.6.0.243287416094.issue3558@psf.upfronthosting.co.za>
Message-ID: <1219105248.98.0.763229265579.issue3558@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am reopening because my suggested fix was wrong. As pointed out by
Fredrik Lundh on PyDev the next day, quoting from the grammar,
attributes, subscriptions, slicing, and call have the *same* precedence.
 I thought I posted his comment and an correct fix, but it is not here,
so here it is again, with additional needed fixes revealed by another
post in c.l.p.  The problem is that the table has three (not just one)
groups of equal precedence entries on multiple lines.  And power has
mixed precedence.

Suggestions (low to high as in the table):

Comparisons section
"all comparison operations in Python have the same priority, which is
lower than that of any arithmetic, shifting or bitwise operation."

In the table, before the "in" line, add
"[Next 3 lines indicate same precedence]            Comparisons"
Then indent both the operator and description entries on the next three
lines, and for the third, change "Comparisons" to "Order and equality
tests". Inclusion and identity tests are comparisons also.

Retitle section "Unary arithmetic operations" to "Unary arithmetic and
bitwise operations" and change the following sentence
"All unary arithmetic (and bitwise) operations have the same priority:"
to 
"All unary arithmetic and bitwise operations have the same priority:"
The parentheses could lead one to not understand that 'unary' applies to
bitwise as well as arithmetic.  (Which is to say, I was initially
confused ;-).

Then combine the corresponding lines in the table to make
+x, -x, ~x                  Positive, negative,  bitwise not

Primaries section:
"Primaries represent the most tightly bound operations of the language.
Their syntax is:
primary ::=  atom | attributeref | subscription | slicing | call"

Fredrik quoted the following from the grammar
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME

and this from the TEX version of the docs:
"  \hline
    \lineii{\code{+\var{x}}, \code{-\var{x}}}    {Positive, negative}
    \lineii{\code{\~\var{x}}}            {Bitwise not}
  \hline
    \lineii{\code{**}}                {Exponentiation}
  \hline
    \lineii{\code{\var{x}.\var{attribute}}}    {Attribute reference}
    \lineii{\code{\var{x}[\var{index}]}}    {Subscription}
    \lineii{\code{\var{x}[\var{index}:\var{index}]}}    {Slicing}
    \lineii{\code{\var{f}(\var{arguments}...)}}    {Function call}
  \hline
  ...
which indicates that the author intended "." and "[" to appear in the
same box, but got overruled by the Tex->HTML conversion tool. " 

The overruling happened at least back to the 2.4 docs.
 
So I suggest
"[Next 4 lines indicate same precedence]                  Trailers" 
with indents as before.

An alternative to the added line and indent fix would be to remove the
lines between things of equal precedence.  The suggested text changes,
including the one to 'Comparisons' in the table, would still remain.

Since the last three entries in the table are all atoms, it is possible
that they also have the same precedence with respect to each other
(Fredrik did not quote any more of the TEX source), though it is a moot
point I think because of the required nesting.

Last issue (I hope): "The power operator binds more tightly than unary
operators on its left; it binds less tightly than unary operators on its
right."

To be exactly correct, 'arithmetic and binary' should modify 'unary'
since there is also unary logical operator not, and ** does *not* bind
less tightly that 'not' on its right.  An expression like "2 ** not 1"
has been parsed as "2 (** not) 1",  a syntax error, probably forever and
certainly in 2.2 before bools up to 3.0, and not as "2 ** (not 1)",
which is 1 even in 3.0.

Also, the table really needs two ** lines:
** [followed by +,-,~]            Exponentiation
** [othewise]                     Exponentiation
before and after the unary +,-,~ line or lines, in that order.

I will review the patch if you post it.  I will otherwise try to take a
look when it comes out.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3558>
_______________________________________

From report at bugs.python.org  Tue Aug 19 02:21:27 2008
From: report at bugs.python.org (Clinton Roy)
Date: Tue, 19 Aug 2008 00:21:27 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1219105287.47.0.0826523254365.issue3585@psf.upfronthosting.co.za>


Clinton Roy <clinton.roy at gmail.com> added the comment:

Thanks for the comments Amaury, this patch uses ${VERSION} throughout so
that it can be applied across branches.

cheers,

Added file: http://bugs.python.org/file11152/pkgconfig.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3585>
_______________________________________

From report at bugs.python.org  Tue Aug 19 03:19:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 01:19:39 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Turns out that PyTokenizer_FindEncoding() never properly succeeds
because the tok_state used by it does not have tok->filename set, which
is an error condition in the tokenizer. This error has been masked by
the one place the function is used, imp.find_module() because a NULL
return is never checked for an error, but instead just assumes the
default source encoding suffices.

----------
components: Extension Modules
messages: 71397
nosy: brett.cannon, christian.heimes
priority: critical
severity: normal
status: open
title: PyTokenizer_FindEncoding() never succeeds
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3594>
_______________________________________

From report at bugs.python.org  Tue Aug 19 03:20:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 01:20:06 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1219108806.61.0.847115697516.issue3594@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have not bothered to check if this exists in 2.6, but I don't see why
it would be any different.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3594>
_______________________________________

From report at bugs.python.org  Tue Aug 19 03:44:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 01:44:32 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1219110272.34.0.183498241034.issue3594@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Turns out that the NULL return value can signal an error that manifests
itself as SyntaxError("encoding problem: with BOM") thanks to the lack
of tok->filename being set in Parser/tokenizer.c:fp_setreadl() which is
called by check_coding_spec() and assumes that since tok->encoding was
never set (because fp_setreadl() returned an error value) that it had
something to do with the BOM.

The only reason this was found is because my bootstrapping of importlib
into Py3K, at some point, triggers a PyErr_Occurred() which finally
notices the error.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3594>
_______________________________________

From report at bugs.python.org  Tue Aug 19 04:24:45 2008
From: report at bugs.python.org (Ahir Reddy)
Date: Tue, 19 Aug 2008 02:24:45 +0000
Subject: [issue3595] Windows base64 Decode
In-Reply-To: <1219112685.57.0.506715853146.issue3595@psf.upfronthosting.co.za>
Message-ID: <1219112685.57.0.506715853146.issue3595@psf.upfronthosting.co.za>


New submission from Ahir Reddy <ahirreddy at gmail.com>:

I'm new to this and not quite sure how to go about posting an issue, but
I will do the best I can. In Python 2.5.2, both from python.org and
active state, all methods of decoding in base64 under Windows produce
different output than base64 decoding under UNIX (I've tested it both on
OS X and Linux, which produce the same results). I ran into this while
writing a script that downloads email and parses mime attachments which
are base64 encoded by a similar upload script. UNIX systems are able to
download the attachments and decode the base64 back to the original
attachments correctly, which I've verified with md5sum hashes. The same
script under windows produces an incorrect file. At first I was not sure
what the issue was, and I eventually wrote the raw base64 attachment to
a file. I then used a windows command line tool to decode the file and
it produced the correct output (again checked by md5sum). This leads me
to believe that something is strange with base64 under Windows. I hope
my explanation has helped some. If need be I'll upload the script so
others can replicate my results.

Ahir

----------
components: Library (Lib)
messages: 71400
nosy: ahirreddy
severity: normal
status: open
title: Windows base64 Decode
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3595>
_______________________________________

From report at bugs.python.org  Tue Aug 19 04:34:24 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 02:34:24 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219113264.97.0.0298821923582.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Can someone double-check this patch for me? I don't have much experience
with the parser so I want to make sure I am not doing anything wrong.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Tue Aug 19 04:37:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 02:37:06 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219113426.48.0.989802360819.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

There is a potential dependency on issue3594 as it would change how
imp.find_module() acts and thus make test_imp no longer fail in the way
it has.

----------
dependencies: +PyTokenizer_FindEncoding() never succeeds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Tue Aug 19 04:54:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 02:54:04 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219114444.21.0.307465296854.issue3574@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

That line dates back to the PEP 263 implementation. Martin?

----------
nosy: +benjamin.peterson, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Tue Aug 19 05:06:17 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Tue, 19 Aug 2008 03:06:17 +0000
Subject: [issue3596] Provide a way to disable SSLv2 (or better yet,
	disable by default)
In-Reply-To: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
Message-ID: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>


New submission from Heikki Toivonen <hjtoi-bugzilla at comcast.net>:

There should be a way to disable SSLv2 since it is insecure. It would be
even better if SSLv2 was disabled out of the box, but maybe there could
be a way to re-enable it.

I made the default to disable SSLv2 in M2Crypto, but those that want it
can explicitly request unsecure connection. You can take a look at
http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Context.py to
see how I did it.

Modern web browsers are also removing SSLv2 support from them, so it
should be really rare to actually need v2 anywhere.

----------
components: Library (Lib)
messages: 71404
nosy: heikki
severity: normal
status: open
title: Provide a way to disable SSLv2 (or better yet, disable by default)
type: security
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3596>
_______________________________________

From report at bugs.python.org  Tue Aug 19 05:21:11 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Tue, 19 Aug 2008 03:21:11 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1219116071.75.0.716016382895.issue1589@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

I would definitely recommend providing as strict as possible hostname
verification in the stdlib, but provide application developers a way to
override that.

M2Crypto (and TLS Lite, from which I copied the approach to M2Crypto),
provide a default post connection checker. See
http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Connection.py
and the set_post_connection_check_callback() as well as
http://svn.osafoundation.org/m2crypto/trunk/M2Crypto/SSL/Checker.py.

----------
nosy: +heikki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Tue Aug 19 05:38:11 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Tue, 19 Aug 2008 03:38:11 +0000
Subject: [issue3597] Allow application developers to select ciphers,
	and default to strong in ssl lib
In-Reply-To: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>
Message-ID: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>


New submission from Heikki Toivonen <hjtoi-bugzilla at comcast.net>:

The 2.6 documentation states selecting the most compatible SSLv23 mode
may mean low quality ciphers, which does not really help the application
developers. It would be better to provide a way to set the allowed
ciphers. Even better, IMO, would be if the ssl module would default to
the stronger ciphers. I use the following default in M2Crypto:
set_cipher_list('ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH').

----------
components: Library (Lib)
messages: 71406
nosy: heikki
severity: normal
status: open
title: Allow application developers to select ciphers, and default to strong in ssl lib
type: security
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3597>
_______________________________________

From report at bugs.python.org  Tue Aug 19 07:25:16 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 05:25:16 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1219123516.44.0.446145822174.issue3594@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached is a patch that fixes where the error occurs. By opening the
file by either file name or file descriptor, the problem goes away. Once
this patch is accepted then PyErr_Occurred() should be added to all uses
of PyTokenizer_FindEncoding().

----------
keywords: +patch
Added file: http://bugs.python.org/file11153/fix_findencoding.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3594>
_______________________________________

From report at bugs.python.org  Tue Aug 19 08:50:57 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 19 Aug 2008 06:50:57 +0000
Subject: [issue3598] multiprocessing.Pool windows/linux behaviour difference
In-Reply-To: <1219128657.72.0.0468830015115.issue3598@psf.upfronthosting.co.za>
Message-ID: <1219128657.72.0.0468830015115.issue3598@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

When the attached program is run on Linux it runs "instantly" and
outputs one line, e.g.:

$ python3 mtest.py
100 files, 1702627142 bytes

(The number of bytes will vary depending on the system.)

When run on Windows XP there is no output at all; many processes seem to
be created but nothing seems to actually get done.

In both cases I'm using Py30b2.

----------
components: Library (Lib)
files: mtest.py
messages: 71408
nosy: mark
severity: normal
status: open
title: multiprocessing.Pool windows/linux behaviour difference
versions: Python 3.0
Added file: http://bugs.python.org/file11154/mtest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3598>
_______________________________________

From report at bugs.python.org  Tue Aug 19 10:49:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 19 Aug 2008 08:49:40 +0000
Subject: [issue3598] multiprocessing.Pool windows/linux behaviour difference
In-Reply-To: <1219128657.72.0.0468830015115.issue3598@psf.upfronthosting.co.za>
Message-ID: <1219135780.08.0.239742015302.issue3598@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There is a problem in your script.

On Windows, the remote processes have to import the mtest module, in
order to execute the get_size() function.
This in turn calls the main() function, which creates a new pool of
processes, etc... exponential explosion.
Linux forks and does not have this problem.

The solution of course is

if __name__ == '__main__':
    main()

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3598>
_______________________________________

From report at bugs.python.org  Tue Aug 19 11:06:10 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 09:06:10 +0000
Subject: [issue3598] multiprocessing.Pool windows/linux behaviour difference
In-Reply-To: <1219128657.72.0.0468830015115.issue3598@psf.upfronthosting.co.za>
Message-ID: <1219136770.31.0.524100003624.issue3598@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For what it's worth, this is documented in
http://docs.python.org/dev/library/multiprocessing.html#windows

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3598>
_______________________________________

From report at bugs.python.org  Tue Aug 19 11:09:59 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 19 Aug 2008 09:09:59 +0000
Subject: [issue3598] multiprocessing.Pool windows/linux behaviour difference
In-Reply-To: <1219136770.31.0.524100003624.issue3598@psf.upfronthosting.co.za>
Message-ID: <200808191009.53180.mark@qtrac.eu>


Mark Summerfield <mark at qtrac.eu> added the comment:

On 2008-08-19, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> For what it's worth, this is documented in
> http://docs.python.org/dev/library/multiprocessing.html#windows

Ah yes, sorry I missed that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3598>
_______________________________________

From report at bugs.python.org  Tue Aug 19 14:39:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 12:39:57 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219149597.88.0.455553295252.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a preliminary patch implementing slices with getitem, adding a
bunch of tests, and fixing a few problems.

As stated elsewhere I only bother to test with simple byte buffers. The
semantics of other types of buffers are too fuzzy for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file11155/mem1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 14:57:42 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Aug 2008 12:57:42 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1219150662.34.0.322227226814.issue2834@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I haven't looked at the specific patch, but based on the description of
the behavior, I'm +1 on committing this before beta 3.  I'm fine with
leaving the re.ASCII flags in there -- it will be a marker to indicate
perhaps the code needs a closer examination (eventually).

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Tue Aug 19 14:58:08 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Aug 2008 12:58:08 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1219150688.25.0.630048484591.issue2834@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Make sure of course that the documentation is updated and a NEWS file
entry is added.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Tue Aug 19 15:08:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 13:08:07 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219151287.93.0.495807107048.issue2394@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Antoine, if this is a "cleanup", perhaps you could fix #3101 while
you're at it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 15:12:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 13:12:15 +0000
Subject: [issue896061] symtable.Symbol.is_global() is strange
Message-ID: <1219151535.75.0.240929588755.issue896061@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This has finally been fixed.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue896061>
_______________________________________

From report at bugs.python.org  Tue Aug 19 15:17:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 13:17:01 +0000
Subject: [issue898271] symtable module crashes w/ coding declaration
Message-ID: <1219151821.43.0.47988113979.issue898271@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm pleased to say this is not an issue in 2.6.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue898271>
_______________________________________

From report at bugs.python.org  Tue Aug 19 15:18:30 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Aug 2008 13:18:30 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1219151910.87.0.701958665686.issue3560@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I don't have time to review the patch, but based on the description, I'm
+1 on landing this before beta 3.  I'd like to get the API right for 3.0
and it will be too late to land it after the release candidates start.

----------
nosy: +barry
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Tue Aug 19 16:24:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 14:24:03 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219155843.33.0.922095601119.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is another patch with setitem too (integers and slices supported),
and further tests.

Added file: http://bugs.python.org/file11156/mem2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 16:34:06 2008
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 19 Aug 2008 14:34:06 +0000
Subject: [issue648658] xmlrpc can't do proxied HTTP
Message-ID: <1219156446.07.0.45143365272.issue648658@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Somebody else here in desperate need of this bug being fixed, both to
talk to bazaar and bugzilla...

----------
nosy: +gjb1002

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue648658>
_______________________________________

From report at bugs.python.org  Tue Aug 19 16:42:52 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Tue, 19 Aug 2008 14:42:52 +0000
Subject: [issue648658] xmlrpc can't do proxied HTTP
Message-ID: <1219156972.73.0.709189103069.issue648658@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

It's a missing feature, not a bug in the existing code.  But if you're
desperate, why not just use the transport implementation that's attached
to this issue?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue648658>
_______________________________________

From report at bugs.python.org  Tue Aug 19 16:48:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 14:48:35 +0000
Subject: [issue3599] test_pydoc after test_urllib2 causes exception in
	Popen.__del__
In-Reply-To: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
Message-ID: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

./python.exe Lib/test/regrtest.py -uall -f ../trunk/tests.txt
test_urllib2
test_pydoc
All 2 tests OK.
Exception TypeError: TypeError("'NoneType' object is not callable",) in
<bound method Popen.__del__ of <subprocess.Popen object at 0x15ffd10>>
ignored

----------
components: Tests
messages: 71422
nosy: benjamin.peterson
priority: high
severity: normal
status: open
title: test_pydoc after test_urllib2 causes exception in Popen.__del__
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3599>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:16:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 15:16:07 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219158967.94.0.0721680126885.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch fixes a crash in the codecs module.
However, memoryview should also support comparisons (just == and !=)
with bytes/bytearray objects (or any buffer-enabled objects), otherwise
utf-8-sig produces wrong values (and there are no tests for it).

Added file: http://bugs.python.org/file11157/mem3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:34:56 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Aug 2008 15:34:56 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219160096.2.0.499511557815.issue3352@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

is_alive appears to be a potentially expensive check for the
multiprocessing side of things, which is why I'm inclined to leave it as
a method. "if t.is_alive():" actually reads better to me than "if
t.alive:" anyway.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:36:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 15:36:11 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1219160096.2.0.499511557815.issue3352@psf.upfronthosting.co.za>
Message-ID: <1afaf6160808190836u5055e89eqa24bf3277657e8c0@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Tue, Aug 19, 2008 at 10:34 AM, Nick Coghlan <report at bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> is_alive appears to be a potentially expensive check for the
> multiprocessing side of things, which is why I'm inclined to leave it as
> a method. "if t.is_alive():" actually reads better to me than "if
> t.alive:" anyway.

So be it. I don't really want to do any renaming anyway. :)
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3352>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:36:30 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 15:36:30 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1219160096.2.0.499511557815.issue3352@psf.upfronthosting.co.za>
Message-ID: <4222a8490808190836ib5f1eefj45b1014742ad9091@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Tue, Aug 19, 2008 at 11:34 AM, Nick Coghlan <report at bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> is_alive appears to be a potentially expensive check for the
> multiprocessing side of things, which is why I'm inclined to leave it as
> a method. "if t.is_alive():" actually reads better to me than "if
> t.alive:" anyway.

Dang, I already cut that one over.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:37:28 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 19 Aug 2008 15:37:28 +0000
Subject: [issue3600] Include Tcl/Tk 8.5.4 in the windows binary for the
	upcoming beta3
In-Reply-To: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>
Message-ID: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

May I suggest the inclusion of Tcl/Tk 8.5.4 in the windows binary for
the upcoming beta3 ? beta2 included 8.5.3, but now the 8.5.4 bugfix
release arrived.

----------
components: Windows
messages: 71427
nosy: gpolo
severity: normal
status: open
title: Include Tcl/Tk 8.5.4 in the windows binary for the upcoming beta3
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3600>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:38:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 15:38:58 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219160338.81.0.933307910347.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch to support comparisons of memoryview objects with other
objects offering the buffer interface. Two objects are equal if their
buffers have the same characteristics and compare equal bytewise.
It also improves the test in test_codecs.py, ensuring the problem has
been fixed.

Added file: http://bugs.python.org/file11158/mem4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:42:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 15:42:05 +0000
Subject: [issue3601] test_unicode.test_raiseMemError fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

======================================================================
ERROR: test_raiseMemError (test.test_unicode.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/trunk/Lib/test/test_unicode.py", line 1122, in
test_raiseMemError
    self.assertRaises(MemoryError, alloc)
  File "/temp/python/trunk/Lib/unittest.py", line 336, in failUnlessRaises
    callableObj(*args, **kwargs)
  File "/temp/python/trunk/Lib/test/test_unicode.py", line 1121, in <lambda>
    alloc = lambda: u"a" * (sys.maxsize - 100)
OverflowError: repeated string is too long

----------------------------------------------------------------------

----------
assignee: pitrou
messages: 71429
nosy: benjamin.peterson, pitrou
priority: critical
severity: normal
status: open
title: test_unicode.test_raiseMemError fails in UCS4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:45:10 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 15:45:10 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219160710.55.0.993619159305.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Adding some comparison tests.

Added file: http://bugs.python.org/file11159/mem5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:51:51 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Aug 2008 15:51:51 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219161111.07.0.801871079585.issue3352@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

My preference actually isn't particularly strong either way, so I
suggest asking Barry for a casting vote.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 17:52:43 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 15:52:43 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219161163.23.0.180252625346.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Nick/Ben - here's a rough draft patch for the attribute changes for mp - 
could you both take a look and let me know what you think?

----------
keywords: +patch
Added file: http://bugs.python.org/file11160/mp_api_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:02:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 16:02:36 +0000
Subject: [issue3601] test_unicode.test_raiseMemError fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1219161756.4.0.490274582206.issue3601@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, please disable the test for now, I have more important things to do
for the beta :)

----------
components: +Tests
priority: critical -> high
type:  -> behavior
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:03:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 16:03:57 +0000
Subject: [issue3601] test_unicode.test_raiseMemError fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1219161837.32.0.649348836363.issue3601@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Oh. Sorry, I didn't mean to assign it to you anyway.

----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:05:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 16:05:44 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219161944.7.0.90961400814.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patch looks pretty good. In a few places, you replaced x.set_x(True)
with x.x(True). The docs also will need a few tweaks. Otherwise, if the
tests pass, I say go ahead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:07:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 16:07:59 +0000
Subject: [issue3601] test_unicode.test_raiseMemError fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1219162103.48aaeff749828@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

(the fix is probably trivial, it involves dividing sys.maxsize by the number of
bytes of an unicode character, something like:

    width = sys.getsizeof("a") - sys.getsizeof("")
    alloc = lambda: u"a" * (sys.maxsize // width)
    self.assertRaises(MemoryError, alloc)
    self.assertRaises(MemoryError, alloc)

you can give it a try if you want ;-))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:09:18 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Aug 2008 16:09:18 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219162158.93.0.60870209826.issue3352@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just saw a couple of docs checkins go by suggesting that the camelCase
names will be unavailable in 3.x. Remember that the intent *isn't* to
remove the old names from threading.py - we're just adding the PEP 8
names so that multiprocessing can have a PEP 8 compliant API while still
being close to a drop-in replacement for the 2.6 version of the
threading module.

This means that all of the DeprecationWarnings and so forth can be left
out completely.

Regarding your patch Jesse:
- if I remember rightly, get_exitcode() can block waiting for the other
process to finish, which makes turning it into a property a fairly
questionable idea (p.get_exitcode() blocking is a lot less surprising
than "p.exitcode" doing so)
- the get/set documentation for the new properties can probably be
consolidated, but that isn't a major problem as far as this week's beta
is concerned.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:09:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 16:09:46 +0000
Subject: [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1219162186.75.0.165687028885.issue3131@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r65853. Hopefully we can do the real refactoring fix after the
betas.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3131>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:10:46 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Aug 2008 16:10:46 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219162246.31.0.262038607589.issue3352@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note regarding those comments - only the exitcode one is something we
should try to get sorted for the beta. Backing out the deprecation
warnings and cleaning up the documentation can wait for the first
release candidate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:12:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 16:12:31 +0000
Subject: [issue3046] Locking should be removed from the new buffer protocol
In-Reply-To: <1212734828.53.0.490072473192.issue3046@psf.upfronthosting.co.za>
Message-ID: <1219162351.64.0.107533392164.issue3046@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems to me that the patch has been applied. Can this be closed?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3046>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:13:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 19 Aug 2008 16:13:38 +0000
Subject: [issue3600] Include Tcl/Tk 8.5.4 in the windows binary for the
	upcoming beta3
In-Reply-To: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>
Message-ID: <1219162418.23.0.654026123543.issue3600@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Also, I was bitten by a runtime error because of an uninitialized variable.
It seems that the Microsoft compiler is able to detect uninitialized
values, in debug mode this causes a dialog to appear and IDLE crashes
when opening the "Save file" dialog.

In generic/tkFileFilter.c, the line 341
    if (ostypeCount > 0 && ostypeList != NULL)
should be replaced by
    if (ostypeList != NULL && ostypeCount > 0)

The problem still exists with 8.5.4.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3600>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:16:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 16:16:37 +0000
Subject: [issue2629] _Py_ForgetReference crash when called from _PyUnicode_New
	on MemoryError
In-Reply-To: <1208141769.9.0.601794636636.issue2629@psf.upfronthosting.co.za>
Message-ID: <1219162597.3.0.0264256360198.issue2629@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This should has been fixed by Amaury as part of another patch (the one
which is tested for in test_raiseMemError).
Could you try again?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2629>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:45:21 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 19 Aug 2008 16:45:21 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1219164321.85.0.215784623662.issue1589@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Nope.  Hostname verification was never a good idea -- the "hostname" is
just a vague notion, at best -- lots of hostnames can map to one or more
IP addresses of the server.  It's exposed to the application code, so if
a client application wants to do it, it can.  But I recommend against
it.  It's a complication that doesn't belong in the basic support, that
is, the SSL module.  I'll add a note to this effect in the documentation.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:52:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 16:52:34 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219164754.36.0.943235377038.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Barry said that is_alive should remain a method following in Guido's
footsteps.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:53:20 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 19 Aug 2008 16:53:20 +0000
Subject: [issue3600] Include Tcl/Tk 8.5.4 in the windows binary for the
	upcoming beta3
In-Reply-To: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>
Message-ID: <1219164800.84.0.0191871764539.issue3600@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I don't know what this Microsoft compiler is doing but both ostypeCount
and ostypeList are properly set at Tcl_ListObjGetElements, and if that
call fails it skips to the bottom of this function you looked at.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3600>
_______________________________________

From report at bugs.python.org  Tue Aug 19 18:58:56 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 19 Aug 2008 16:58:56 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219165136.83.0.365500155644.issue1342811@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

I was thinking about returning in that new if statement, too, but
decided not too. The reason is that I didn't want to anticipate _tkinter
implementations, which may change (although not likely, still possible).

Also, with the third beta tomorrow, I am not sure if somebody will find
the time to approve the patch in time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:05:43 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 19 Aug 2008 17:05:43 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219165543.99.0.221785380187.issue1342811@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

If this needs approval of someone else, and such thing doesn't happen in
time then the earlier patch should be reverted.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:17:05 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 19 Aug 2008 17:17:05 +0000
Subject: [issue3600] Include Tcl/Tk 8.5.4 in the windows binary for the
	upcoming beta3
In-Reply-To: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>
Message-ID: <1219166225.32.0.756098933144.issue3600@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

or not ? the indentation in this tkFileFilter.c is fooling me, the
Tcl_ListObjGetElements call is done in another block which is outside
that check, so the compiler seems to be right after all. It would be
good to report this problem at tk's bug tracker
(http://sourceforge.net/projects/tktoolkit).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3600>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:18:32 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 17:18:32 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <001636163c89d091040454d34695@google.com>


Guido van Rossum <guido at python.org> added the comment:

Reviewers: GvR,

Message:
Looks good. Go ahead and submit, assuming you've run full tests.

Description:
http://bugs.python.org/issue3560

Please review this at http://codereview.appspot.com/3003

Affected files:
   Include/memoryobject.h
   Modules/_json.c
   Objects/memoryobject.c
   Objects/unicodeobject.c

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:18:47 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 17:18:47 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <0016e6470d70c1bfec0454d3477d@google.com>


Guido van Rossum <guido at python.org> added the comment:

PS. The PEP probably needs an update. And the docs.

http://codereview.appspot.com/3003

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:21:01 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 17:21:01 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <001636af022db706c10454d34f25@google.com>


Guido van Rossum <guido at python.org> added the comment:

On 2008/08/19 17:18:45, GvR wrote:
> PS. The PEP probably needs an update. And the docs.

And Misc/NEWS

http://codereview.appspot.com/3003

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:23:38 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 19 Aug 2008 17:23:38 +0000
Subject: [issue3554] ctypes.wstring_at and string_at call Python API without
	the GIL
In-Reply-To: <1218731992.24.0.0258351695719.issue3554@psf.upfronthosting.co.za>
Message-ID: <1219166618.36.0.980192274908.issue3554@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

This is fixed now in SVN, in trunk, branches/py3k, and
branches/release25-maint.  Thanks again.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3554>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:46:33 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 19 Aug 2008 17:46:33 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1219167993.49.0.991423137098.issue3265@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Here is a patch for Modules/_ctypes/malloc_closure.c that may work
(totally untested).  The code snippet is copied from Modules/mmapmodule.c.

----------
keywords: +patch
Added file: http://bugs.python.org/file11161/malloc_closure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:48:25 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 19 Aug 2008 17:48:25 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1219168105.18.0.374079184706.issue3265@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


Removed file: http://bugs.python.org/file11161/malloc_closure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:49:08 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 19 Aug 2008 17:49:08 +0000
Subject: [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error:
	`MAP_ANONYMOUS' undeclared
In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za>
Message-ID: <1219168148.82.0.840206720362.issue3265@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Corrected the patch.

Added file: http://bugs.python.org/file11162/malloc_closure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3265>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:20:54 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 18:20:54 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1219162246.31.0.262038607589.issue3352@psf.upfronthosting.co.za>
Message-ID: <4222a8490808191120l1e50b507r3e63f370f0a60562@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Note regarding those comments - only the exitcode one is something we
> should try to get sorted for the beta. Backing out the deprecation
> warnings and cleaning up the documentation can wait for the first
> release candidate.
>

Would it be acceptable to add a doc note mentioning .exitcode() may
block rather than changing it back to the get_exitcode method? It's
not that it's hard - but I do like the consistency of the
property-style interface.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:23:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 18:23:41 +0000
Subject: [issue2619] Document PEP 3118
In-Reply-To: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>
Message-ID: <1219170221.1.0.84142133763.issue2619@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As a reminder, I want to mention that PEP 3118 itself needs to be
updated (see #3560).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2619>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:23:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 18:23:48 +0000
Subject: [issue3560] redundant "base" field in memoryview objects
In-Reply-To: <1218793027.62.0.312203864665.issue3560@psf.upfronthosting.co.za>
Message-ID: <1219170228.0.0.0739066815389.issue3560@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the PEP needs some love generally speaking; many things are un- or
under-specified (and I don't understand better than anyone else). As for
docs, there aren't any ("grep -ri memoryview Doc/" yields only the two
lines referencing the "memoryview" builtin): see #2619.

The patch is committed in r65862.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3560>
_______________________________________

From report at bugs.python.org  Tue Aug 19 19:59:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 17:59:30 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1219168770.58.0.854601079897.issue2834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r65860. Someone should check the docs though (at least try to
generate them, and review my changes a bit since English isn't my mother
tongue).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:35:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Aug 2008 18:35:47 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Since most UNIX distros don't ship Python's test directory,
test.test_support.catch_warning() needs to be moved to the 'warnings'
directory so it can be used to suppress warnings in modules outside the
'test' package.

The default for 'record' will change to False so it is less
test-oriented. The name might change as well since it is more about
saving the state of 'warnings' then actually catching an exception,
although having it return an object representation of a warning makes
the current name make sense.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 71459
nosy: brett.cannon
priority: critical
severity: normal
status: open
title: Move test.test_suport.catch_warning() to the 'warnings' module
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:43:23 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 18:43:23 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1219162246.31.0.262038607589.issue3352@psf.upfronthosting.co.za>
Message-ID: <4222a8490808191143s4e7de8a7jbf38d7bf2dc576f5@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Note regarding those comments - only the exitcode one is something we
> should try to get sorted for the beta. Backing out the deprecation
> warnings and cleaning up the documentation can wait for the first
> release candidate.
>

Actually, re-examining .exitcode - it wraps the custom forking.Popen
class .poll() method, this method should not block (forking.py, line
104) - the WNOHANG call passed to os.waitpid means it should also not
hang.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:45:23 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 18:45:23 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219171523.02.0.832761201762.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Here is a cleaned up patch (ben was right, I typo'ed a few spots) - I did 
not clean up the docs from the original patch except to correct the 
x.x(Foo) accidents.

Added file: http://bugs.python.org/file11163/mp_nohang_jnoller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:45:28 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 18:45:28 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219171528.69.0.119632768832.issue3352@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file11160/mp_api_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:45:35 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 18:45:35 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219171535.23.0.861579979401.issue3352@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file11163/mp_nohang_jnoller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:46:26 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 18:46:26 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219171586.18.0.769964106511.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I attached the wrong patch, here is v2

Added file: http://bugs.python.org/file11164/mp_api_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 20:57:12 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 18:57:12 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219172232.32.0.623310253706.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

And here is v3 - I fixed all of the Docs/include/mp* scripts to reflect 
the new API

Added file: http://bugs.python.org/file11165/mp_api_cleanup-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:07:29 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 19 Aug 2008 19:07:29 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219172849.15.0.392739273046.issue3352@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

committed the v3 patch as-is in r65864 - moving from release blocker to 
deferred blocker pending the Docs cleanup, and outstanding debate points.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:11:05 2008
From: report at bugs.python.org (Santiago Gala)
Date: Tue, 19 Aug 2008 19:11:05 +0000
Subject: [issue3603] trivial typo in Include/pymath.h
In-Reply-To: <1219173065.49.0.835954949015.issue3603@psf.upfronthosting.co.za>
Message-ID: <1219173065.49.0.835954949015.issue3603@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

file Include/pymath.h has the typo s/doube/double/, hidden by the fact
that any sane OS defines copysign:


diff --git a/Include/pymath.h b/Include/pymath.h
index a3735c2..7cea9ae 100644
--- a/Include/pymath.h
+++ b/Include/pymath.h
@@ -19,7 +19,7 @@ functions and constants
  *Note: PC/pyconfig.h defines copysign as _copysign
  */
 #ifndef HAVE_COPYSIGN
-extern double copysign(doube, double);
+extern double copysign(double, double);
 #endif
 
 #ifndef HAVE_ACOSH


It is both in trunk and py3k

----------
messages: 71465
nosy: sgala
severity: normal
status: open
title: trivial typo in Include/pymath.h
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3603>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:16:55 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 19:16:55 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1219173415.16.0.321605574682.issue1878@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I like Armin's latest proposal: have Py_TPFLAGS_DEFAULT include
Py_TPFLAGS_HAVE_VERSION_TAG when compiling the core only.  ISTR there's
a way to do this, but I can't find it right now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:22:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 19:22:27 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219173747.42.0.27105142616.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch changes all bytearray results (in indexing, tobytes()) to
bytes, and adds the implementation the tolist().

Note: the tolist() implementation only handles one-dimensional byte
buffers. It will have to be re-written using the struct module!
But at least once that patch applied, I think we may drop down this bug
to critical.

Added file: http://bugs.python.org/file11166/mem6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:25:51 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 19:25:51 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1219173951.42.0.589714042953.issue1878@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Please review the patch here: http://codereview.appspot.com/3005

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:26:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 19:26:33 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219173993.16.0.964458580103.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please review at http://codereview.appspot.com/3004

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:29:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 19:29:54 +0000
Subject: [issue3603] trivial typo in Include/pymath.h
In-Reply-To: <1219173065.49.0.835954949015.issue3603@psf.upfronthosting.co.za>
Message-ID: <1219174194.39.0.738381609342.issue3603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r65869.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3603>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:31:36 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Aug 2008 19:31:36 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1219174296.59.0.71312573338.issue3473@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Guido's approved it, so please go ahead and add it before beta 3.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:46:18 2008
From: report at bugs.python.org (Matt Beaumont-Gay)
Date: Tue, 19 Aug 2008 19:46:18 +0000
Subject: [issue3604] broken link in curses module docs
In-Reply-To: <1219175178.82.0.559397561246.issue3604@psf.upfronthosting.co.za>
Message-ID: <1219175178.82.0.559397561246.issue3604@psf.upfronthosting.co.za>


New submission from Matt Beaumont-Gay <mattb at cs.ucla.edu>:

The link to the "Curses Programming with Python" page on the curses
module doc page (http://www.python.org/doc/lib/module-curses.html) is
broken; the correct link is apparently
'http://docs.python.org/dev/howto/curses.html'.

----------
assignee: georg.brandl
components: Documentation
messages: 71472
nosy: georg.brandl, mattb
severity: normal
status: open
title: broken link in curses module docs
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3604>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:53:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 19:53:04 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1219175583.97.0.393988894355.issue3473@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Applied for 2.6 in r65872.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Tue Aug 19 21:57:27 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Aug 2008 19:57:27 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1219175847.92.0.912139566216.issue815646@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The fix can not be committed to Python 2.5 because it breaks
compatibility by adding another field to the PyFileObject struct and
adding two new C API functions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue815646>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:12:12 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Aug 2008 20:12:12 +0000
Subject: [issue2629] _Py_ForgetReference crash when called from _PyUnicode_New
	on MemoryError
In-Reply-To: <1208141769.9.0.601794636636.issue2629@psf.upfronthosting.co.za>
Message-ID: <1219176732.36.0.957846019758.issue2629@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Verified fixed.

Python 2.6b2+ (trunk:65871, Aug 19 2008, 13:10:07)
>>> msg = 'A'*2000111222
[12389 refs]
>>> x = msg.decode('utf8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/google/home/gps/python/trunk/Lib/encodings/utf_8.py",
line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
MemoryError
[12431 refs]

----------
assignee:  -> gregory.p.smith
priority:  -> normal
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2629>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:14:29 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 20:14:29 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1219176869.64.0.733065107803.issue1878@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Submitted as r65874.

I will block this for 3.0; 3.0 extensions that want to mess with tp_dict
must explicitly disable this flag.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:26:19 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 20:26:19 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1219177579.34.0.75318387846.issue1179@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Looking into this now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1179>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:42:18 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 20:42:18 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

Py_FatalError calls PyErr_Occurred() which requires a current thread
state.  This mean that if the original error was a thread state error
Py_FatalError is triggered again, ad infinitum.

----------
components: Interpreter Core
messages: 71478
nosy: rupole
severity: normal
status: open
title: Py_FatalError causes infinite loop
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:44:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 20:44:17 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1219178657.46.0.587320658681.issue1878@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Do we want a test?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:44:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 20:44:59 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1218865816.59.0.265900877081.issue3139@psf.upfronthosting.co.za>
Message-ID: <1219178696.5550.6.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 16 ao?t 2008 ? 05:50 +0000, Ismail Donmez a ?crit :
> This seems to break test_unicode on MacOSX 10.5.4,
> 
> test_unicode
> python(80320,0xa0659fa0) malloc: *** mmap(size=2147483648) failed (error 
> code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> python(80320,0xa0659fa0) malloc: *** mmap(size=2147483648) failed (error 
> code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug

Can you run Lib/test/test_unicode.py directly to know which test
precisely crashes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:57:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 20:57:30 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1219179450.62.0.922251502669.issue3473@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Done for py3k in r65877.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Tue Aug 19 22:58:05 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 20:58:05 +0000
Subject: [issue3453] PyType_Ready doesn't ensure that all bases are ready
In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za>
Message-ID: <1219179485.33.0.324551767865.issue3453@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

This doesn't address the discrepancy between tp_base and tp_bases.
If multiple bases are used, it's no longer 'good practice', it's an
absolute requirement.  IMO, it should call PyType_Ready for all bases, 
or none of them.

Since the code assumes that all bases have been
initialized, it could at least ASSERT so, rather than crashing deep
within the mro calculations.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3453>
_______________________________________

From report at bugs.python.org  Tue Aug 19 23:02:23 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 21:02:23 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1219179743.14.0.58182939582.issue1179@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Latest patches applied to 2.5 branch: r65878.
And to 2.6 trunk: r65880.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1179>
_______________________________________

From report at bugs.python.org  Tue Aug 19 23:06:14 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Aug 2008 21:06:14 +0000
Subject: [issue1878] class attribute cache failure (regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1219179974.88.0.518875622922.issue1878@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Sure, go right ahead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
_______________________________________

From report at bugs.python.org  Tue Aug 19 23:08:05 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 21:08:05 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1219180085.06.0.768568066195.issue3605@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Do you have a simple code sample to showcase that?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Tue Aug 19 23:26:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 21:26:13 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1219181173.19.0.0517132261391.issue3473@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Now test_compiler is breaking for us because the compiler package can't
handle the change.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3473>
_______________________________________

From report at bugs.python.org  Tue Aug 19 23:28:33 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 21:28:33 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1219181313.78.0.622226888203.issue3605@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

Py_BEGIN_ALLOW_THREADS
	PyErr_SetString(PyExc_SystemError, "bork bork bork");
	Py_END_ALLOW_THREADS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Tue Aug 19 23:30:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 21:30:31 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219181313.78.0.622226888203.issue3605@psf.upfronthosting.co.za>
Message-ID: <1219181426.5550.13.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Roger Upole <rupole at hotmail.com> added the comment:
> 
> Py_BEGIN_ALLOW_THREADS
> 	PyErr_SetString(PyExc_SystemError, "bork bork bork");
> 	Py_END_ALLOW_THREADS

Well, if you start using all kinds of internal APIs without holding the
GIL, you should expect much worse than just a Py_FatalError ;-)

Of course, it would still be better if the infinite loop could be
avoided.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Tue Aug 19 23:43:34 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 21:43:34 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1219182214.65.0.0841016797817.issue3605@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

Well, you asked for a simple case.  In practice, I'm dealing with
much more complicated code that contains callbacks which may need
to acquire or release the theadlock.  This problem makes it very 
difficult to debug such code.

Also, the PyErr_Occurred is not present in 2.5.2, probably
for this very same reason.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:02:03 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 19 Aug 2008 22:02:03 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1219183323.04.0.709418439606.issue3605@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:05:41 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Aug 2008 22:05:41 +0000
Subject: [issue3606] 2to3: commands varible replaced by subprocess
In-Reply-To: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>
Message-ID: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

I tried 2to3 on my python-ptrace project and with minor changes, it 
works fine. One of the minor changes is to replace 
subprocess.split(";") by commands.split(";"). The original code was:

   commands = command
   ok = True
   for command in commands.split(";"):
      command = command.strip()
      ok &= self.execute(command)

I don't import subprocess and I don't use this module in my code. It 
is possible to reproduce the bug only with two lines:

   commands = "a;b;c"
   x = commands.split(";")

So 2to3 doesn't care if commands is a module or variable, it just 
replaced the text pattern... It looks like the change is done 
by "fixes/fix_imports.py", maybe this pattern:

   # Find usages of module members in code e.g. urllib.foo(bar)
   yield """power< (%s)
            trailer<'.' any > any* >
         """ % mod_name_list

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 71490
nosy: collinwinter, haypo
severity: normal
status: open
title: 2to3: commands varible replaced by subprocess

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3606>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:07:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 22:07:22 +0000
Subject: [issue3606] 2to3: commands varible replaced by subprocess
In-Reply-To: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>
Message-ID: <1219183642.01.0.565818458174.issue3606@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Yes, this is because some of the commands module's functions have moved
to subprocess in py3k. This is probably a won't fix.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3606>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:08:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 22:08:00 +0000
Subject: [issue3607] test_multiprocessing failure (Unserializable message)
In-Reply-To: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
Message-ID: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I have the following deterministic failure on py3k:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 932, in test_dict
    self.assertEqual(sorted(d.keys()), indices)
  File "<string>", line 2, in keys
  File "/home/antoine/py3k/__svn__/Lib/multiprocessing/managers.py",
line 738, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------------
Unserializable message: ('#RETURN', <dict_keys object at 0x956ddb0>)
---------------------------------------------------------------------------

----------
assignee: jnoller
components: Library (Lib), Tests
messages: 71492
nosy: jnoller, pitrou
priority: critical
severity: normal
status: open
title: test_multiprocessing failure (Unserializable message)
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3607>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:11:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Aug 2008 22:11:43 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219183903.18.0.191392507796.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r65886 after review from Benjamin and some small fixes.

I'm downgrading this to critical for the remains of the memoryview API
(support for more format types, multi-dimensional objects...). Perhaps
those remainings will have to wait for 3.1.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:46:13 2008
From: report at bugs.python.org (Collin Winter)
Date: Tue, 19 Aug 2008 22:46:13 +0000
Subject: [issue3606] 2to3: commands varible replaced by subprocess
In-Reply-To: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>
Message-ID: <1219185973.38.0.186479871957.issue3606@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Victor: that's a common problem in most fixers. The analysis needed to
statically determine whether a given identifier is a module or not is
expensive and heuristic.

One of our Summer of Code students has been working on adding a new
feature to 2to3 whereby fixers can apply confidence estimates to the
changes they make, allowing you to say "if 2to3 is 95+% confident, apply
the fix, otherwise, let me see a diff first". This could be
theoretically extended to allow other annotations, such as "changing an
identifier", which you could filter on.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3606>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:50:39 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 22:50:39 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

When using PyMemoryView_FromMemory to create a new object, you have to
pass in a preallocated buffer.  However, there's no way to specify a
routine to free the memory, and it leaks when the object is destroyed.

----------
components: Interpreter Core
messages: 71495
nosy: rupole
severity: normal
status: open
title: memoryview constructor has no deallocator
type: resource usage
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 00:54:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 22:54:16 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219186456.54.0.0964457999921.issue3608@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

PyMemoryView_FromMemory doesn't exist. Do you mean
PyMemoryView_FromBuffer or PyMemoryView_FromObject?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 01:02:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 23:02:55 +0000
Subject: [issue3402] test_nis is hanging on Solaris
In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za>
Message-ID: <1219186975.51.0.919150784772.issue3402@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I've disabled it in r65888.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3402>
_______________________________________

From report at bugs.python.org  Wed Aug 20 01:03:12 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 19 Aug 2008 23:03:12 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219186992.3.0.696095545762.issue3608@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

Well it existed up until a couple hours ago ;).
Looks like it was recently changed to PyMemoryView_FromBuffer.
However, it still has the same issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 01:12:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Aug 2008 23:12:18 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219187538.46.0.911250788296.issue3608@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> teoliphant
nosy: +pitrou, teoliphant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 01:14:47 2008
From: report at bugs.python.org (unutbu)
Date: Tue, 19 Aug 2008 23:14:47 +0000
Subject: [issue3318] Documentation: timeit: "lower bound" should read "upper
	bound"
In-Reply-To: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za>
Message-ID: <247949.19541.qm@web39605.mail.mud.yahoo.com>


unutbu <driabslg at yahoo.com> added the comment:

Dear Georg,
     Would you please reconsider this issue (http://bugs.python.org/issue3318) for a moment?

The term "lower bound" as it is used in the timeit documentation is either misleading or mathematically incorrect. A lower bound is a number which is less than or equal to every member of a set. What set is the timeit documentation referring to? Here are two possibilities:

A = the set of times recorded from three runs
B = the set of all possible times a particular machine could return

The term "lower bound" is technically correct if the documentation means "lower bound of set A", but I think it would be misleading to use the term "lower bound" in this way, since the documentation would then be asserting: "the minimum time of three runs is the lower bound of three runs". It's not very exciting, and moreover, it's obvious. 

The term "lower bound" is simply incorrect if the documentation meant "lower bound of set B". I explained the reason why in my first post.

I appreciate your point when you said, "An ideal machine is not useful in practice". 
However, the documentation opens up this can of worms by its own use of the term lower bound. If ideal machines is not what it wants to discuss, then maybe the documentation needs to be changed in some other way to avoid the mathematically charged term, "lower bound".

I think you would agree that good documentation needs to use language accurately. The documentation as it stands is either fallacious (if it is talking about set B), trivial (if it is talking about set A), or possibly correct if it is talking about some set C which I have not imagined.

If it is the latter case, please update the documentation to make clear what set C is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3318>
_______________________________________

From report at bugs.python.org  Wed Aug 20 02:51:17 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 20 Aug 2008 00:51:17 +0000
Subject: [issue3609] does parse_header really belong in CGI module?
In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>
Message-ID: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Not sure how to class this, but shouldn't the "parse_header" function in
cgi really be in email.header?  And what about parse_multipart?

----------
components: Library (Lib)
messages: 71500
nosy: janssen
priority: normal
severity: normal
status: open
title: does parse_header really belong in CGI module?
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3609>
_______________________________________

From report at bugs.python.org  Wed Aug 20 03:08:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 01:08:18 +0000
Subject: [issue3610] Fix gdbinit for Python 3.0
In-Reply-To: <1219194498.13.0.487280154525.issue3610@psf.upfronthosting.co.za>
Message-ID: <1219194498.13.0.487280154525.issue3610@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

I'm trying to track down a bug in Python 3.0 (or my program?). I fixed 
some functions of gdbinit:
 - pystack and pylocals: use the new function py_printstr
 - lineno: call CPython "PyCode_Addr2Line" instead of ugly gdb 
reimplementation

New functions:
 - py_decref: decrement the reference counter and *always* call 
_Py_Dealloc(obj)
 - py_printstr: display a string as UTF-8 using printf "%s" and 
PyUnicodeUCS2_AsUTF8String()

Problem: PyUnicode_AsUTF8String() is unknown, so I have to use 
PyUnicodeUCS2_AsUTF8String... (but it can be UCS4)

I'm unable to test pylocals, I don't know the good context to test it. 
In PyEval_EvalFrameEx if fails because "f" is unknown but pystack 
works and pystack calls lineno which uses "f" !?

----------
components: None
files: gdbinit.patch
keywords: patch
messages: 71501
nosy: haypo
severity: normal
status: open
title: Fix gdbinit for Python 3.0
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file11167/gdbinit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3610>
_______________________________________

From report at bugs.python.org  Wed Aug 20 03:51:06 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 20 Aug 2008 01:51:06 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1219197066.2.0.204234895272.issue3139@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

> Can you run Lib/test/test_unicode.py directly to know which test
> precisely crashes?

The latest py3k branch is fine now and the test passes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Wed Aug 20 04:33:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 02:33:20 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

After few seconds (30 sec to 5 minutes), my program (Fusil) crashs at:

PyEval_EvalFrameEx (f=0x85b4324, throwflag=0) at Python/ceval.c:2459
    Py_CLEAR(tstate->exc_traceback);

It crashs because tstate->exc_traceback points to a zombi object:
{_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348326, 
ob_type = 0xdbdbdbdb}

(refcnt is 0xdbdbdbdb-1)

I'm using py3k rev 65882 compiled with CFLAGS "-O0 -ggdb" 
and --with-pydebug. Sorry, I don't have more informations yet and I 
can't explain how to reproduce the bug :-/

----------
components: Interpreter Core
messages: 71503
nosy: haypo
severity: normal
status: open
title: invalid exception context
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 04:37:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 02:37:19 +0000
Subject: [issue3607] test_multiprocessing failure (Unserializable message)
In-Reply-To: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
Message-ID: <1219199839.48.0.235048043829.issue3607@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a buildbot example:
http://python.org/dev/buildbot/stable/amd64%20gentoo%203.0/builds/980/step-test/0

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3607>
_______________________________________

From report at bugs.python.org  Wed Aug 20 04:38:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 02:38:21 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219199901.39.0.0167623023104.issue3611@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

The crash is on ProcError exception raising (line 21):

    20      except IOError as err:
    21          raise ProcError("Unable to open %r: %s" % (filename, 

---

(gdb) where
#0  0x0805bcc7 in PyObject_Hash (v=0x8691034) at Objects/object.c:796
#1  0x08062125 in set_contains_key (so=0x856ec6c, key=0x8691034) at 
Objects/setobject.c:682
#2  0x0806659f in PySet_Contains (anyset=0x856ec6c, key=0x8691034) at 
Objects/setobject.c:2263
#3  0x080def3a in print_exception_recursive (f=0xb7bea654, 
value=0x8656814, seen=0x856ec6c) at Python/pythonrun.c:1432
#4  0x080df0ea in PyErr_Display (exception=0x84542ac, value=0x8656814, 
tb=0x865bc34) at Python/pythonrun.c:1470
#5  0x080e68f6 in sys_excepthook (self=0xb7e013b4, args=0x865b334) at 
Python/sysmodule.c:119
#6  0x08161d29 in PyCFunction_Call (func=0xb7e016c4, arg=0x865b334, 
kw=0x0) at Objects/methodobject.c:81
#7  0x08118cc5 in PyObject_Call (func=0xb7e016c4, arg=0x865b334, 
kw=0x0) at Objects/abstract.c:2181
#8  0x080b2ea8 in PyEval_CallObjectWithKeywords (func=0xb7e016c4, 
arg=0x865b334, kw=0x0) at Python/ceval.c:3283
#9  0x080de463 in PyErr_PrintEx (set_sys_last_vars=1) at 
Python/pythonrun.c:1258
#10 0x080de06f in PyErr_Print () at Python/pythonrun.c:1150
#11 0x080e0007 in Py_FatalError (msg=0xbf9a1498 "Python/ceval.c:2459 
object at 0x865b6b4 has negative ref count -606348326")
    at Python/pythonrun.c:1863
#12 0x0805a821 in _Py_NegativeRefcount 
(fname=0x8197098 "Python/ceval.c", lineno=2459, op=0x865b6b4) at 
Objects/object.c:194
#13 0x080b004f in PyEval_EvalFrameEx (f=0x85b4324, throwflag=0) at 
Python/ceval.c:2459
(...)

(gdb) frame 13
#13 0x080b004f in PyEval_EvalFrameEx (f=0x85c9794, throwflag=0) at 
Python/ceval.c:2459
2459                                            
Py_CLEAR(tstate->exc_traceback);

(gdb) pystack
/home/haypo/ptrace/ptrace/linux_proc.py (21): openProc
/home/haypo/ptrace/ptrace/linux_proc.py (24): readProc
/home/haypo/ptrace/ptrace/linux_proc.py (31): readProcessProc
/home/haypo/ptrace/ptrace/linux_proc.py (74): readProcessStat
(...)

---

linux_proc.py code near line 21:
    (...)
     7  class ProcError(Exception):
     8      pass
    (...)
    16  def openProc(path):
    17      try:
    18          filename = procFilename(path)
    19          return open(filename)
    20      except IOError as err:
    21          raise ProcError("Unable to open %r: %s" % (filename, 
err))
    (...)
    29  def readProcessProc(pid, key):
    30      try:
    31          return readProc(path_join(str(pid), str(key)))
    32      except ProcError as error:
    33          raise ProcError("Process %s doesn't exist: %s" % (
    34              pid, error))
    (...)
    73  def readProcessStat(pid):
    74      stat = readProcessProc(pid, 'stat')
    75      return ProcessState(stat)
    76

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 04:45:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 02:45:52 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219200352.15.0.533081432151.issue3611@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

I also noticed a crash in PyErr_SetObject(): in block <line 68..86>, 
tstate->exc_value value may changes and so it's possible that 
tstate->exc_value becomes NULL. I added a test to avoid this crash:

Index: Python/errors.c
===================================================================
--- Python/errors.c     (r?vision 65899)
+++ Python/errors.c     (copie de travail)
@@ -88,7 +88,7 @@
                   This is O(chain length) but context chains are
                   usually very short. Sensitive readers may try
                   to inline the call to PyException_GetContext. */
-               if (tstate->exc_value != value) {
+               if (tstate->exc_value != value && tstate->exc_value != 
NULL) {
                        PyObject *o = tstate->exc_value, *context;
                        while ((context = PyException_GetContext(o))) 
{
                                Py_DECREF(context);

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 04:50:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 02:50:49 +0000
Subject: [issue658693] cPickle does relative import
Message-ID: <1219200649.66.0.0493851922647.issue658693@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Is this still an issue?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue658693>
_______________________________________

From report at bugs.python.org  Wed Aug 20 04:52:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 02:52:34 +0000
Subject: [issue515073] subtypable weak references
Message-ID: <1219200754.83.0.265538315152.issue515073@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Does anyone still care about this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue515073>
_______________________________________

From report at bugs.python.org  Wed Aug 20 04:56:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 02:56:54 +0000
Subject: [issue843385] help(obj) should use __doc__ when available
Message-ID: <1219201014.03.0.40735507924.issue843385@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I believe this has been implemented now.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue843385>
_______________________________________

From report at bugs.python.org  Wed Aug 20 06:50:21 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Wed, 20 Aug 2008 04:50:21 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1219207821.18.0.80800070317.issue3119@psf.upfronthosting.co.za>


Aaron Gallagher <habnabit at gmail.com> added the comment:

Alright, sorry this took so long. Hopefully this can still be included in 
3.0.
Included is a patch that no longer uses collections.deque and also adds a 
test case to test/test_pickle.py. The test catches RuntimeError and fails 
the unittest. I didn't see anything that would behave like the opposite of 
assertRaises except letting the exception propagate.

Added file: http://bugs.python.org/file11168/pickle2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Wed Aug 20 07:03:52 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Aug 2008 05:03:52 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

This patch adds some basic mssing types in ctypes.wintypes.
I think pointer type like LPDWORD would be usuful too, but maybe you
cannot ignore the overhead of POINTER object creation.

----------
assignee: theller
components: ctypes
files: add_some_missing_types.patch
keywords: patch
messages: 71511
nosy: ocean-city, theller
severity: normal
status: open
title: Add some basic mssing types in ctypes.wintypes
versions: Python 2.6
Added file: http://bugs.python.org/file11169/add_some_missing_types.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Wed Aug 20 07:08:05 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 20 Aug 2008 05:08:05 +0000
Subject: [issue3609] does parse_header really belong in CGI module?
In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>
Message-ID: <1219208885.82.0.600283420695.issue3609@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

These functions are for generic MIME headers and bodies, so are
applicable to CGI, HTTP, Email, and any other protocols based on MIME.
So I think having them in email.header makes about as much sense as
having them in cgi.

Isn't mimetools a better package for this?

Also I think there's an exodus of functions from cgi -- there's talk
about parse_qs/parse_qsl being moved to urllib (I thought that was
almost finalised). Traditionally the cgi module has had way too much
stuff in it which only superficially applies to cgi.

I'm also thinking of cgi.escape, which I'd rather see in htmllib than
cgi (except that htmllib is described as "A parser for HTML documents").

But I'm worried that these functions are too ingrained in people's
memories (I type "cgi.escape" several times a day and I'd get confused
if it moved). So perhaps these moves are too late.

I imagine if they were moved (at least for a few versions) the old ones
would still work, with a deprecation warning?

----------
nosy: +mgiuca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3609>
_______________________________________

From report at bugs.python.org  Wed Aug 20 08:00:34 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Wed, 20 Aug 2008 06:00:34 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov <dmitry at targeted.org>:

This quote from base64.py:

---
bytes_types = (bytes, bytearray)  # Types acceptable as binary data
...
def encodestring(s):
    """Encode a string into multiple lines of base-64 data.

    Argument and return value are bytes.
    """
    if not isinstance(s, bytes_types):
        raise TypeError("expected bytes, not %s" % s.__class__.__name__)
    ...
---

shows that encodestring method won't accept str for an argument, only
bytes. Perhaps this is by design, but then wouldn't it make sense to
change the name of the method ?

Anyway, this behavior clashes in (the least I know) xmlrpc.client, line
1168 when basic authentication is present:

---
auth = base64.encodestring(urllib.parse.unquote(auth))
---

because unquote() returns str, not bytes.

----------
components: Library (Lib)
messages: 71513
nosy: ddvoinikov
severity: normal
status: open
title: base64.encodestring does not actually accept strings
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________

From report at bugs.python.org  Wed Aug 20 08:09:34 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Wed, 20 Aug 2008 06:09:34 +0000
Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
In-Reply-To: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za>
Message-ID: <1219212574.73.0.0447441452437.issue1276@psf.upfronthosting.co.za>


Changes by Hye-Shik Chang <hyeshik at gmail.com>:


Added file: http://bugs.python.org/file11170/cjkmactemporary.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1276>
_______________________________________

From report at bugs.python.org  Wed Aug 20 08:13:35 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Wed, 20 Aug 2008 06:13:35 +0000
Subject: [issue3614] typo in xmlrpc.client
In-Reply-To: <1219212814.95.0.707077475128.issue3614@psf.upfronthosting.co.za>
Message-ID: <1219212814.95.0.707077475128.issue3614@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov <dmitry at targeted.org>:

In xmlrpc.client:1204:
---
headers = {}
if extra_headers:
    for key, val in extra_headers:
        header[key] = val
---
shouldn't it read 
---
        headers[key] = val
              ^
---
?

Otherwise it bails out with 
---
NameError: global name 'header' is not defined
---

----------
components: Library (Lib)
messages: 71514
nosy: ddvoinikov
severity: normal
status: open
title: typo in xmlrpc.client
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3614>
_______________________________________

From report at bugs.python.org  Wed Aug 20 08:21:24 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 20 Aug 2008 06:21:24 +0000
Subject: [issue3609] does parse_header really belong in CGI module?
In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>
Message-ID: <1219213284.92.0.324061405409.issue3609@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

> I imagine if they were moved (at least for a few versions) the old ones
> would still work, with a deprecation warning?

Yes, that's what I was thinking.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3609>
_______________________________________

From report at bugs.python.org  Wed Aug 20 09:36:31 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 20 Aug 2008 07:36:31 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1219168770.58.0.854601079897.issue2834@psf.upfronthosting.co.za>
Message-ID: <200808200836.24701.mark@qtrac.eu>


Mark Summerfield <mark at qtrac.eu> added the comment:

On 2008-08-19, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Fixed in r65860. Someone should check the docs though (at least try to
> generate them, and review my changes a bit since English isn't my mother
> tongue).

I've revised the ASCII and LOCALE-related texts in re.rst in r65903.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Wed Aug 20 09:40:55 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 20 Aug 2008 07:40:55 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1219168770.58.0.854601079897.issue2834@psf.upfronthosting.co.za>
Message-ID: <200808200840.49761.mark@qtrac.eu>


Mark Summerfield <mark at qtrac.eu> added the comment:

On 2008-08-19, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Fixed in r65860. Someone should check the docs though (at least try to
> generate them, and review my changes a bit since English isn't my mother
> tongue).

And two more (tiny) fixes in r65904; that's my lot:-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Wed Aug 20 10:49:14 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Wed, 20 Aug 2008 08:49:14 +0000
Subject: [issue3615] Expect methods for testing.
In-Reply-To: <1219222153.94.0.41823703199.issue3615@psf.upfronthosting.co.za>
Message-ID: <1219222153.94.0.41823703199.issue3615@psf.upfronthosting.co.za>


New submission from J. Pablo Fern?ndez <pupeno at pupeno.com>:

I'm attaching a patch that adds expect methods to TestCase. They are
like fail methods, but they don't fail immediately. They are useful when
you want to catch more than one error at a time.
I included some tests.
There are docstrings but more documentation might be needed. I'll gladly
write it if/when the code is good to go.
The original code was written by Donovan Baarda for an internal project
at Google, I only extracted the bits that made sense to publish and
changed the style to me more Python-alike.

----------
components: Library (Lib)
files: expect.diff
keywords: patch
messages: 71518
nosy: pupeno
severity: normal
status: open
title: Expect methods for testing.
versions: Python 3.0
Added file: http://bugs.python.org/file11171/expect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3615>
_______________________________________

From report at bugs.python.org  Wed Aug 20 10:49:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 08:49:39 +0000
Subject: [issue2834] re.IGNORECASE not Unicode-ready
In-Reply-To: <1210581845.07.0.550614143529.issue2834@psf.upfronthosting.co.za>
Message-ID: <1219222179.51.0.681846479864.issue2834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks a lot Mark!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2834>
_______________________________________

From report at bugs.python.org  Wed Aug 20 10:59:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 08:59:57 +0000
Subject: [issue3607] test_multiprocessing failure (Unserializable message)
In-Reply-To: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
Message-ID: <1219222797.27.0.653958532914.issue3607@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Sorry, I did not notice the failure because test_multiprocessing have
other problems on Windows.
r65905 restores part of the copy_reg calls, just enough to let the tests
pass.

I am working on the proper fix, which is to use the custom pickler in
connection.h::connection_send_obj(), instead of the standard pickle.dumps().

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3607>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:00:58 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 09:00:58 +0000
Subject: [issue3616] shutil.rmtree() fails on invalid filename
In-Reply-To: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za>
Message-ID: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

If the directory contains invalid filenames (invalid in the system 
charset), an exception is raised by os.path.join() used by 
shutil.rmtree():

    fullname = os.path.join(path, name)
  File "/home/haypo/prog/py3k/Lib/posixpath.py", line 64, in join
    if b.startswith('/'):
TypeError: expected an object with the buffer interface

name is an bytes object, not a str object. My system charset is utf-8.

Example to reproduce the problem:

   mkdir x
   # create a file with an invalid name
   touch -- $(echo -e 'x/--\0250--')
   python -c "import shutils; shutil.rmtree('x')"

=> TypeError: expected an object with the buffer interface

----------
components: Library (Lib)
messages: 71521
nosy: haypo
severity: normal
status: open
title: shutil.rmtree() fails on invalid filename
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3616>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:02:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:02:43 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219222963.54.0.459486086765.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I also noticed a crash in PyErr_SetObject(): in block <line 68..86>, 
> tstate->exc_value value may changes and so it's possible that 
> tstate->exc_value becomes NULL. 

How can tstate->exc_value become NULL at that point? Could you investigate?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:13:26 2008
From: report at bugs.python.org (Santiago Gala)
Date: Wed, 20 Aug 2008 09:13:26 +0000
Subject: [issue3603] trivial typo in Include/pymath.h
In-Reply-To: <1219173065.49.0.835954949015.issue3603@psf.upfronthosting.co.za>
Message-ID: <1219223606.4.0.855951091408.issue3603@psf.upfronthosting.co.za>


Santiago Gala <sgala at apache.org> added the comment:

Notice the typo is still in a number of branches/tags (I know, tags
should be static, but nothing impedes committing into a subversion tag
once it is created, so I quote for reference):

sgala at marlow ~/newcode/python.git (py3k)$ for i in $(git branch -a| sed
-e "s/\*//"); do if git rev-parse --verify $i:Include/pymath.h
>&/dev/null ;then PAGER= git grep doube $i:Include/pymath.h 2>/dev/null
; fi; done
benjaminp-testing:Include/pymath.h:extern double copysign(doube, double);
okkoto-sizeof:Include/pymath.h:extern double copysign(doube, double);
py3k-ctypes-pep3118:Include/pymath.h:extern double copysign(doube, double);
py3k-urllib:Include/pymath.h:extern double copysign(doube, double);
tags/r26a3:Include/pymath.h:extern double copysign(doube, double);
tags/r26b1:Include/pymath.h:extern double copysign(doube, double);
tags/r26b2:Include/pymath.h:extern double copysign(doube, double);
tags/r30a5:Include/pymath.h:extern double copysign(doube, double);
tags/r30a5-real:Include/pymath.h:extern double copysign(doube, double);
tags/r30a5-real at 62867:Include/pymath.h:extern double copysign(doube,
double);
tags/r30b1:Include/pymath.h:extern double copysign(doube, double);
tags/r30b2:Include/pymath.h:extern double copysign(doube, double);
tlee-ast-optimize:Include/pymath.h:extern double copysign(doube, double);
tnelson-trunk-bsddb-47-upgrade:Include/pymath.h:extern double
copysign(doube, double);
trunk-math:Include/pymath.h:extern double copysign(doube, double);


I just paste the list because I can't say which branches are currently
active or suitable to be retaken in the  future. The origin of the typo
is in trunk-math.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3603>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:36:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:36:39 +0000
Subject: [issue3616] shutil.rmtree() fails on invalid filename
In-Reply-To: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za>
Message-ID: <1219224999.76.0.0718712564308.issue3616@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is certainly a consequence of #3187, which is very high priority
but also very difficult to find a satisying solution to.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3616>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:37:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:37:21 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219225041.58.0.892956604425.issue3187@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See #3616 for a consequence of this.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:37:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:37:30 +0000
Subject: [issue3616] shutil.rmtree() fails on invalid filename
In-Reply-To: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za>
Message-ID: <1219225050.05.0.918738859793.issue3616@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
superseder:  -> os.listdir can return byte strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3616>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:43:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:43:18 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219225398.14.0.250000375695.issue3608@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, this is not a bug in itself. Memoryview objects are designed to
give access to a memory area backed by another object - they don't "own"
the memory by themselves (in the sense that you e.g. own a reference to
a PyObject).

Please note by the way that the Py_buffer struct now has a reference to
the original object, the "obj" field. PyBuffer_FillInfo() will incref
it, and PyBuffer_Release() will decref it again. However, it you set
this field to NULL, you are responsible for doing your own reference
management.

I agree that it may be nice to support your use case, but I'm not sure
what the semantics should be. For clarity, perhaps it should be a
derived class of memoryview.

----------
type: resource usage -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:43:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:43:29 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219225409.54.0.925515461567.issue3608@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:47:44 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Aug 2008 09:47:44 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

Since we are shipping the msvcr90.dll (+ assemblies) together with the
Python installer for Windows, we need to include the MS EULA for VS2008
in the third-party licenses section as this is the license that covers
the VS DLLs.

----------
messages: 71527
nosy: lemburg
severity: normal
status: open
title: Add MS EULA to the list of third-party licenses in the Windows installer
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:51:23 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Aug 2008 09:51:23 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219225883.67.0.196811742816.issue3617@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Note that there are a few gotchas in the MS EULA, such as disallowing to
ship the DLLs with GPLed Python products or requiring that the PSF
prevents further redistribution of the DLLs unless used in conjunction
with Python.

----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:54:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:54:01 +0000
Subject: [issue3615] Expect methods for testing.
In-Reply-To: <1219222153.94.0.41823703199.issue3615@psf.upfronthosting.co.za>
Message-ID: <1219226041.12.0.0368430146071.issue3615@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Interesting, but it should be discussed on the mailing-list first.
Also, since this is a new feature, it must be retargeted to 2.7/3.1.

----------
nosy: +pitrou
priority:  -> normal
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3615>
_______________________________________

From report at bugs.python.org  Wed Aug 20 11:56:20 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 09:56:20 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1219226180.12.0.864337861426.issue3300@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's an unquote()-related failure in #3613.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 20 12:00:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 10:00:13 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1219226413.43.0.715986277053.issue3613@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The encodestring() function is refered to in the docs as "the legacy
interface". Perhaps it should be simply deprecated in 3.0?

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl, pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________

From report at bugs.python.org  Wed Aug 20 12:03:06 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 20 Aug 2008 10:03:06 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1219226586.05.0.715091118433.issue3613@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Hi Dmitry,

RE the method behaviour: I think it probably is correct to NOT accept a
string. Given that it's base64 encoding it, it only makes sense to
encode bytes, not arbitrary Unicode characters which have no
well-defined binary representation.

RE the method name: I agree, it should be renamed to encodestring. I
argued a similar case for the array.tostring and fromstring methods
(which actually act on bytes in Python 3.0) - here:
http://bugs.python.org/issue3565. So far nobody replied on that issue; I
think it may be too late to rename them. Best we can do is document them.

RE xmlrpc.client:1168. We just checked in a patch to urllib which adds
an unquote_to_bytes function (see
http://docs.python.org/dev/3.0/library/urllib.parse.html#urllib.parse.unquote_to_bytes).
(Unquote itself still returns a string). It should be correct to just
change xmlrpc.client:1168 to call urllib.parse.unquote_to_bytes. (Though
I've not tested it).

----------
nosy: +mgiuca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________

From report at bugs.python.org  Wed Aug 20 12:03:35 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 20 Aug 2008 10:03:35 +0000
Subject: [issue3300] urllib.quote and unquote - Unicode issues
In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za>
Message-ID: <1219226615.31.0.00154280975095.issue3300@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Thanks for pointing that out, Antoine. I just commented on that bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3300>
_______________________________________

From report at bugs.python.org  Wed Aug 20 12:21:06 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 20 Aug 2008 10:21:06 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219227666.46.0.0540417663175.issue3612@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I have no objections against this patch - feel free to check it in if it
is not too late before the beta.

Also I think that LPDWORD and friends are a good idea, you should extend
the patch with them.

----------
assignee: theller -> ocean-city
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Wed Aug 20 12:42:25 2008
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Wed, 20 Aug 2008 10:42:25 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1219228945.15.0.515141856247.issue3613@psf.upfronthosting.co.za>


Dmitry Dvoinikov <dmitry at targeted.org> added the comment:

> I think it probably is correct to NOT accept a string

I agree.

> it should be renamed to encodestring

Huh ? It is already called that :) IMO it should be renamed to
encodebytes or simply encode if the module is only (or most frequently)
used to encode bytes.

> Best we can do is document them.

Oh well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________

From report at bugs.python.org  Wed Aug 20 12:47:45 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 20 Aug 2008 10:47:45 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1219229265.09.0.717680500247.issue3613@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> > it should be renamed to encodestring
> Huh ? It is already called that :)

Um ... yes. I mean encodebytes :)

> > Best we can do is document them.
> Oh well.

But I don't know the rules. People are saying things like "no new
features after beta3" but I take it that
backwards-compatibility-breaking changes are included in this.

But maybe it's still OK for us to break code after the beta. Perhaps
someone involved in the release can comment on this issue (and hopefully
with a view to my array patch - http://bugs.python.org/issue3565 - as well).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________

From report at bugs.python.org  Wed Aug 20 13:00:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 11:00:50 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

BufferedWriter from Lib/io.py is thread-safe, but... the Python 
instruction "with self._write_lock:" could be interrupted when the 
lock is already acquired. Especially, _lsprof.Profiler() uses ceval 
hook and is called when the lock is acquired. But if the profiler (or 
any other module using the hook) re-use the stream (stdout or stderr), 
we get a deadlock!?

Well, this problem is really not critical since only developers 
profilers (really?).

Solution: use C implementation of Lib/io.py (from Python 2.6) to avoid 
ceval hook?

Example with py3k trunk:
 >>> import _lsprof
 >>> prof=_lsprof.Profiler(42)
 >>> prof.enable()
 # _lsprof calls 42() 
 #   -> 42 is not callable
 #   -> call PyErr_WriteUnraisable(<42 is not callable>)
 #   -> deadlock

Traceback example:

#6  0x080ecb30 in PyThread_acquire_lock (lock=0x820f550, waitflag=1) 
at Python/thread_pthread.h:352
(...)
#8  0x08162521 in PyCFunction_Call (func=0x83abfbc, arg=0xb7dc6034, 
kw=0x0) at Objects/methodobject.c:81
#9  0x080b3659 in call_function (pp_stack=0xbfbf9474, oparg=0) at 
Python/ceval.c:3403
#10 0x080ae7a6 in PyEval_EvalFrameEx (f=0x83b9f94, throwflag=0) at 
Python/ceval.c:2205
#11 0x080b3aae in fast_function (func=0x83a25b4, pp_stack=0xbfbf9724, 
n=2, na=2, nk=0) at Python/ceval.c:3491
#12 0x080b37ef in call_function (pp_stack=0xbfbf9724, oparg=1) at 
Python/ceval.c:3424
#13 0x080ae7a6 in PyEval_EvalFrameEx (f=0x83b981c, throwflag=0) at 
Python/ceval.c:2205
#14 0x080b1aee in PyEval_EvalCodeEx (co=0x838a328, globals=0x8330534, 
locals=0x0, args=0x8373da0, argcount=2, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2840
#15 0x0814ab2e in function_call (func=0x83a3b8c, arg=0x8373d8c, 
kw=0x0) at Objects/funcobject.c:628
#16 0x08118d19 in PyObject_Call (func=0x83a3b8c, arg=0x8373d8c, 
kw=0x0) at Objects/abstract.c:2181
#17 0x08132eb0 in method_call (func=0x83a3b8c, arg=0x8373d8c, kw=0x0) 
at Objects/classobject.c:323
#18 0x08118d19 in PyObject_Call (func=0x83037dc, arg=0x83141f4, 
kw=0x0) at Objects/abstract.c:2181
#19 0x080b2ed8 in PyEval_CallObjectWithKeywords (func=0x83037dc, 
arg=0x83141f4, kw=0x0) at Python/ceval.c:3283
#20 0x08141779 in PyFile_WriteObject (v=0x8398e28, f=0x83ab0dc, 
flags=1) at Objects/fileobject.c:164
#21 0x08141974 in PyFile_WriteString (s=0x819a2f2 "Exception ", 
f=0x83ab0dc) at Objects/fileobject.c:189
#22 0x080c473c in PyErr_WriteUnraisable (obj=0x81fbd78) at 
Python/errors.c:696
#23 0xb7f9612f in CallExternalTimer (pObj=0x83a7aa8) 
at /home/haypo/prog/py3k/Modules/_lsprof.c:135
#24 0xb7f96984 in Stop (pObj=0x83a7aa8, self=0x826c6d8, 
entry=0x826ec80) at /home/haypo/prog/py3k/Modules/_lsprof.c:337
#25 0xb7f96c60 in ptrace_leave_call (self=0x83a7aa8, key=0x81cb150) 
at /home/haypo/prog/py3k/Modules/_lsprof.c:420
#26 0xb7f96d5c in profiler_callback (self=0x83a7aa8, frame=0x835a0b4, 
what=6, arg=0x83ab92c) at /home/haypo/prog/py3k/Modules/_lsprof.c:471
#27 0x080b28cb in call_trace (func=0xb7f96c85 <profiler_callback>, 
obj=0x83a7aa8, frame=0x835a0b4, what=6, arg=0x83ab92c)
    at Python/ceval.c:3090
#28 0x080b35da in call_function (pp_stack=0xbfbf9d74, oparg=1) at 
Python/ceval.c:3403
#29 0x080ae7a6 in PyEval_EvalFrameEx (f=0x835a0b4, throwflag=0) at 
Python/ceval.c:2205


ceval hook: Python/ceval.3403:
   PCALL(PCALL_CFUNCTION);
   if (flags & (METH_NOARGS | METH_O)) {
      ...
   } else {
      PyObject *callargs;
      callargs = load_args(pp_stack, na);
      READ_TIMESTAMP(*pintr0);
      C_TRACE(x, PyCFunction_Call(func,callargs,NULL)); <= **here**
      READ_TIMESTAMP(*pintr1);
      Py_XDECREF(callargs);
   }

----------
components: Library (Lib)
messages: 71537
nosy: haypo
severity: normal
status: open
title: possible deadlock in IO library (Lib/io.py)
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Wed Aug 20 13:56:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 11:56:37 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219233397.83.0.742568330492.issue3618@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes indeed. We could use an RLock to avoid the problem but RLock's are
damn slow since they are written in pure Python (see #3001). Rewriting
the critical parts of RLock (constructor, acquire(), release(),
__enter__(), __exit__()) in C should not be too complicated, would you
want to do it? :)

> Solution: use C implementation of Lib/io.py (from Python 2.6) to avoid 
> ceval hook?

I guess it's out of question. However, Buffered{Reader,Writer,Random}
should be rewritten in C one day, it is necessary for speed. Then the
problem will vanish since a lock will only need to be taken when
releasing the GIL, that is not when Python code is being interpreted.

----------
nosy: +pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Wed Aug 20 15:15:27 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Aug 2008 13:15:27 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219238127.09.0.938032881657.issue3612@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've committed basic type addition in r65908. Addition of LPDWORD and
its friends will follow.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Wed Aug 20 15:49:41 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 13:49:41 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1219240181.75.0.826039026819.issue3001@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

As suggested by pitrou, I wrote an implementation of RLock in C. 
Changes to Python version:
 - no debug message: i leave the message in #if 0 ... #endif
 - acquire() method argument "blocking" is not a keyword

Notes:
 - RLock has no docstring!
 - In the Python version, RLock._release_save() replaces owner and 
counter attributes before release the lock. But releasing the lock may 
fails and no the object is in an inconsistent state

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file11172/rlock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Wed Aug 20 15:51:48 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 13:51:48 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219240308.5.0.641690444586.issue3618@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

@pitrou: I wrote an implementation of RLock in C (see #3001). So it 
would be possible to use threading.RLock instead of threading.Lock ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:00:35 2008
From: report at bugs.python.org (Kent Tenney)
Date: Wed, 20 Aug 2008 14:00:35 +0000
Subject: [issue3619] A more informative message for ImportError
In-Reply-To: <1219240834.62.0.382152843898.issue3619@psf.upfronthosting.co.za>
Message-ID: <1219240834.62.0.382152843898.issue3619@psf.upfronthosting.co.za>


New submission from Kent Tenney <ktenney at gmail.com>:

from foo import bar
ImportError: cannot import name bar

The error may be due to the wrong 'foo' being found, some investigation
is required.

If the the ImportError message included the filename for 'foo', the
problem would be obvious.
ImportError cannot import name bar from  /usr/lib/<snip>/foo.pyc

A c.l.p. thread on this is at
http://groups.google.com/group/comp.lang.python/browse_thread/thread/88474a32877026fc/

a patch from Wojtek Walczak is here and attached
http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch

a thread about it on python-dev is here
http://mail.python.org/pipermail/python-dev/2008-August/081889.html

including a comment on the patch
http://mail.python.org/pipermail/python-dev/2008-August/081897.html

----------
components: None
files: from-import-py2.5.1.patch
keywords: patch
messages: 71542
nosy: ktenney
severity: normal
status: open
title: A more informative message for ImportError
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11173/from-import-py2.5.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3619>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:04:34 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 14:04:34 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219241074.13.0.577528372803.issue3618@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Oops, I forgot to update PyInit__Thread() with my new time:
 - Add PyType_Ready()
 - Register RLockType to threading dict

Here is the new patch

----------
keywords: +patch
Added file: http://bugs.python.org/file11174/rlock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:05:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 14:05:34 +0000
Subject: [issue3619] A more informative message for ImportError
In-Reply-To: <1219240834.62.0.382152843898.issue3619@psf.upfronthosting.co.za>
Message-ID: <1219241134.05.0.0978872501587.issue3619@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
components: +Interpreter Core -None
priority:  -> low
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3619>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:06:16 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 14:06:16 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1219241176.46.0.277741981394.issue3001@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Oops, I forgot to update PyInit__Thread() with my new time:
 - Add PyType_Ready()
 - Register RLockType to threading dict

Here is the new patch.

Added file: http://bugs.python.org/file11175/rlock-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:06:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 14:06:20 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219241180.92.0.73137965158.issue3618@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Removed file: http://bugs.python.org/file11174/rlock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:06:51 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 14:06:51 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219241211.19.0.0726673327827.issue3618@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Ooops again, I uploaded my patch to the wrong issue! The new patch is 
now in the issue #3001.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:17:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 14:17:08 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1219241828.87.0.0582704132386.issue3001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Wow, that was quick. Did you try to replace threading.RLock with your
implementation, and run the tests?

By the way:
> - acquire() method argument "blocking" is not a keyword
> - In the Python version, RLock._release_save() replaces owner and 
> counter attributes before release the lock. But releasing the lock may 
> fails and no the object is in an inconsistent state

Removing the debugging statements is fine, but apart from that the C
implementation should mimick the current behaviour. Even if this
behaviour has potential pitfalls.

Speaking of which, it would be nice if RLock was subclassable. I don't
know whether any software relies on this though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:57:32 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Aug 2008 14:57:32 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219244252.42.0.646754740077.issue3612@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've created the patch which adds LPDWORD and friends.
Can you review it?

Added file: http://bugs.python.org/file11176/adds_LPDWORD_and_friends.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Wed Aug 20 16:58:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 14:58:20 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219244300.3.0.371494872668.issue3611@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

> How can tstate->exc_value become NULL at that point? [error.c:86]
> Could you investigate?

PyEval_CallObject(exception, args) may calls PyErr_SetObject(). Since 
the same thread state is the same, tstate->exc_value also changes 
during this call.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 17:09:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 15:09:29 +0000
Subject: [issue3620] test_asyncore is not cleanup after its self?
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This is from the sparc Unbuntu 3.0 bot. I'm having trouble reproducing
it, though.

test test_smtplib produced unexpected output:
**********************************************************************
*** line 2 of actual output doesn't appear in expected output after line 1:
+ error: uncaptured python exception, closing channel
<test.test_smtplib.SimSMTPChannel 127.0.0.1:38832 at 0x268d0a8> (<class
'socket.error'>:[Errno 9] Bad file descriptor
[/home/pybot/buildarea/3.0.klose-ubuntu-sparc/build/Lib/asyncore.py|readwrite|100]
[/home/pybot/buildarea/3.0.klose-ubuntu-sparc/build/Lib/asyncore.py|handle_write_event|426])
**********************************************************************

----------
components: Tests
messages: 71549
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: test_asyncore is not cleanup after its self?
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3620>
_______________________________________

From report at bugs.python.org  Wed Aug 20 17:17:52 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 20 Aug 2008 15:17:52 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1219245472.63.0.534465867364.issue3613@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Did someone fix xmlrpc.client:1168 yet?

IMO it's okay to add encodebytes(), but let's leave encodestring()
around with a deprecation warning, since it's so late in the release cycle.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3613>
_______________________________________

From report at bugs.python.org  Wed Aug 20 17:24:25 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 15:24:25 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219244300.3.0.371494872668.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219245886.48ac373e03174@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon STINNER Victor <report at bugs.python.org>:
>
> > How can tstate->exc_value become NULL at that point? [error.c:86]
> > Could you investigate?
>
> PyEval_CallObject(exception, args) may calls PyErr_SetObject(). Since
> the same thread state is the same, tstate->exc_value also changes
> during this call.

Hmm, indeed.
However, I don't see why your Python code triggers that. Does instantiating the
ProcError object somehow fail, and for what reason? Or did you witness it in
other circumstances?

As for the original problem ("tstate->exc_traceback points to a zombi object")
it would be nice to have a small snippet of Python code to reproduce it. Is it
possible for you to do that?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 17:44:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 15:44:54 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219247094.29.0.551349290316.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I retract what I said above. PyErr_SetObject() and friends only change
tstate->curexc_* variables, not tstate->exc_*.

The former (tstate->curexc_*) contain the current, pending (uncaught)
exception state of the thread. The latter (tstate->exc_*) contain the
exception currently handled by an "except" statement in Python code. 

So, theoretically, there is no way calling PyEval_CallObject() can
change tstate->exc_value:
- if it raises an exception or calls code that raises an exception
without catching it, the exception ends up in tstate->curexc_*, not in
tstate->exc_*
- if it calls code that raises an exception /and catches it/, exception
stacking means the exception should be discarded after the end of the
"except" block and the last tstate->exc_* values restored.

Of course, there may be bugs in the implementation of the above. The
best way to find out would be to have a small snippet of Python code
reproducing the problem. :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 18:01:13 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 16:01:13 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219248073.35.0.647382136643.issue3611@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

About the PyEval_CallObject() call in errors.c, here is an example:
   Call exception<0x81dcee0>(args<0x8751dc4>)
with exception=
   object  : <class 'AttributeError'>
   type    : type
   refcount: 6
   address : 0x81dcee0
and args=
   object  : ("type object 'ProcError' has no 
attribute '__subclasscheck__'",)
   type    : tuple
   refcount: 1
   address : 0x8751dc4

This exception may comes from PyObject_IsSubclass() which calls 
PyObject_GetAttr(cls, "__subclasscheck__").

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 18:14:10 2008
From: report at bugs.python.org (Jason Spiro)
Date: Wed, 20 Aug 2008 16:14:10 +0000
Subject: [issue3621] it would be nice if installers made by bdist_wininst
	stored an EstimatedSize property in the Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>


New submission from Jason Spiro <jasonspiro4 at gmail.com>:

== Summary ==

Installers made by bdist_wininst never set EstimatedSize in the Windows 
registry.  So Windows makes an estimate[1] of the installed software's 
size so the Add/Remove Programs control panel can tell users how much 
space the software is are taking up.  Windows overestimates the size: 
it estimates the size as equal to the size of the entire C:\Python 
directory.

Nowadays, disk space is cheaper than ever, so I assume it's uncommon 
for people to try to uninstall software to gain space back.  So I do 
not think it's worth fixing this bug.  Does anyone think it *is* worth 
fixing?

== Steps to repro ==

You *must* be running Windows XP or higher to repro this.[2]  I used 
Python 2.5 (which I installed using the MSI installer) but I would be 
extremely surprised if this was already fixed in a newer Python's 
distutils.

- Download the attached testcase.zip
- Unzip it to a temp directory
- From the temp directory, run the commands:
        setup.py bdist_wininst
        cd dist
        foo-1.0.win32.exe
- Click on Start Menu > Settings > Control Panel > Add/Remove Programs
- Scroll down to "Python 2.5 foo-1.0".

== Actual results ==

- The "Size" column on the right says 46.86MB (that's the size of my 
entire "C:\Python 2.5" directory.)

== Expected results ==

- The "Size" column on the right should say something close to 0.1 
megabytes.

== Suggested fix ==

- When creating an installer, bdist_wininst should look at the total 
size of all files to install, multiply that number by 3 (a reasonable 
estimate of the total size the .pyc and .pyo files will take up), and 
make the installer set the EstimatedSize[3] in the registry to that 
number.

== Footnotes ==

^ [1].  See the blog entry "How does Add/Remove Programs get the size 
and other information?" by Raymond Chen at 
http://blogs.msdn.com/oldnewthing/archive/2004/07/09/178342.aspx for 
info on the algorithm Windows uses.

^ [2].  Versions of Windows older than XP never try to estimate the 
size of installed programs.

^ [3].  This is 
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\(application 
descriptor)\EstimatedSize and should be a DWORD representing the number 
of kilobytes the software takes up, according to 
http://forum.installsite.net/?showtopic=698#entry12501

----------
components: Distutils
messages: 71554
nosy: jasonspiro
severity: normal
status: open
title: it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________

From report at bugs.python.org  Wed Aug 20 18:15:02 2008
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 20 Aug 2008 16:15:02 +0000
Subject: [issue3565] array documentation, method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1219248902.32.0.539918037799.issue3565@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

A similar issue came up in another bug
(http://bugs.python.org/issue3613), and Guido said:

"IMO it's okay to add encodebytes(), but let's leave encodestring()
around with a deprecation warning, since it's so late in the release cycle."

I think that's probably wise RE this bug as well - my original
suggestion to REPLACE tostring/fromstring with tobytes/frombytes was
probably a bit over-zealous.

I'll have another go at this during some spare cycles tomorrow -
basically taking my current patch and adding tostring/fromstring back
in, to call tobytes/frombytes with deprecation warnings. Does this sound
like a good plan?

(Also policy question: When you have deprecated functions, how do you
document them? I assume you say "deprecated" in the docs; is there a
standard template for this?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Wed Aug 20 18:16:22 2008
From: report at bugs.python.org (Jason Spiro)
Date: Wed, 20 Aug 2008 16:16:22 +0000
Subject: [issue3621] it would be nice if installers made by bdist_wininst
	stored an EstimatedSize property in the Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1219248982.15.0.244264057716.issue3621@psf.upfronthosting.co.za>


Jason Spiro <jasonspiro4 at gmail.com> added the comment:

Attaching testcase.  It's basically just some sample code from the 
distutils documentation.

Added file: http://bugs.python.org/file11177/testcase.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________

From report at bugs.python.org  Wed Aug 20 18:49:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 16:49:36 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219248073.35.0.647382136643.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219251001.48ac4b391e56d@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

[...]
>
> This exception may comes from PyObject_IsSubclass() which calls
> PyObject_GetAttr(cls, "__subclasscheck__").

If you look at the code for PyObject_IsSubclass(), there is a pair of
PyErr_Fetch / PyErr_Restore calls around PyObject_GetAttr(cls,
"__subclasscheck__"). So this exception should vanish immediately rather than
stay around.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 19:10:04 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 17:10:04 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219252204.41.0.3702540164.issue3611@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

I'm unable to write a short Python script to reproduce the bug. So 
download the full program:
   http://neudorf.hachoir.org/tmp/fusil3000.tar.gz

Run in with:
   $ gdb python3.0
   (gdb) run fusil-python --fast

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 19:14:41 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 20 Aug 2008 17:14:41 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219252481.4.0.342922603298.issue3617@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Aug 20 19:18:14 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Aug 2008 17:18:14 +0000
Subject: [issue1675334] Draft implementation for PEP 364
Message-ID: <1219252694.9.0.89569033564.issue1675334@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

At this point we should probably just have PEP 364 rejected since 2to3
handles the renamings so well.

----------
assignee: brett.cannon -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675334>
_______________________________________

From report at bugs.python.org  Wed Aug 20 19:24:05 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Aug 2008 17:24:05 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219253045.72.0.972466322557.issue3602@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just some quick notes on this. The decorator should become:

  def catchwarning(*, record=False, using=warnings)

Name change is to follow the naming convention in 'warnings' (even
though I prefer underscores). The 'using' argument is what module is
being used as the 'warnings' module (mostly just for testing
warings/_warnings). And they are both keyword-only (or at least in
spirit in 2.6) so that the potential to support properly dealing with
__warningregistry__ in the future can be added and the *args arguments
can be those modules to watch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Wed Aug 20 19:29:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 17:29:42 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219253382.01.0.538890332193.issue3602@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I don't think the using argument should live in warnings; it's too test
specific. I recommend we still keep a catch_warning in test_support (or
even just test_warnings since this seems to be the only use-case).

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Wed Aug 20 20:04:34 2008
From: report at bugs.python.org (Roger Upole)
Date: Wed, 20 Aug 2008 18:04:34 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219255474.78.0.186669375684.issue3608@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

As background, what I need is an equivalent of
PyBuffer_New(size), which creates an object that manages its
own buffer memory, and is not based on another object at all.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 20:11:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 18:11:59 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219255474.78.0.186669375684.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219255911.5651.5.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As background, what I need is an equivalent of
> PyBuffer_New(size), which creates an object that manages its
> own buffer memory, and is not based on another object at all.

Well, you can create ?either a bytes or bytearray object with an
internal buffer of the desired length. Then you'll be able to create a
memoryview out of it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 20:28:38 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 20 Aug 2008 18:28:38 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1219256918.93.0.370196967669.issue3001@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I doubt subclassability of RLock matters but who knows, people do code
things.

Regardless, using a C version wrapped in a simple python container class
that calls the underlying C implementation's methods should be
sufficient to allow sub-classing.

Given the final 2.6 beta is scheduled for today, this won't make it into
2.6/3.0 so we've got some time to polish up what we want.

----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Wed Aug 20 20:31:04 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 20 Aug 2008 18:31:04 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219257064.58.0.306046048566.issue3612@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I think this is too fancy.  I would prefer to spell the definitions out
like this:

  LPDWORD = PDWORD = POINTER(DWORD)
  LPCSTR = LPSTR = c_wchar_p

We could avoid the giant __all__ list when we 'import ctypes as _ctypes'
and write (for example):

  DWORD = _ctypes.c_ulong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Wed Aug 20 20:44:41 2008
From: report at bugs.python.org (Adam Milner)
Date: Wed, 20 Aug 2008 18:44:41 +0000
Subject: [issue1674032] Make threading.Event().wait(timeout=3) return isSet
Message-ID: <1219257881.14.0.99051126599.issue1674032@psf.upfronthosting.co.za>


Adam Milner <carmiac at gmail.com> added the comment:

I would like to add my support for this change.  As David described, it
is often useful to know why the x.wait() has returned, not just that it has.

----------
nosy: +carmiac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674032>
_______________________________________

From report at bugs.python.org  Wed Aug 20 20:54:57 2008
From: report at bugs.python.org (Roger Upole)
Date: Wed, 20 Aug 2008 18:54:57 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219258497.31.0.0814978590117.issue3608@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

Aha, thanks.  I'll go that route for now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 21:00:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 19:00:36 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1219258836.46.0.461360180856.issue3001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Gregory, would you have an advice on #3618?

----------
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Wed Aug 20 21:50:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 19:50:56 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219261856.15.0.41554618228.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem comes when PyErr_SetObject triggers garbage collection which
runs python code (finalizers...).

I could reproduce the crash several times, and each time garbage
collection was triggered by the normalization of the exception (the call
to PyEval_CallObject(exception, args)).

An obvious fix is to save exc_value near the "/* Implicit exception
chaining */" comment.

However, I fear that there are other places where exc_value is reset,
and "exception chaining" may break in subtle ways.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 22:04:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 20:04:00 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219261856.15.0.41554618228.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219262636.5651.15.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The problem comes when PyErr_SetObject triggers garbage collection which
> runs python code (finalizers...).

Mmmh, normally this shouldn't change the value of tstate->exc_value once
that Python code returns. That's what exception stacking is for.

Having a snippet deterministically reproducing the problem would really
help in any case.

> An obvious fix is to save exc_value near the "/* Implicit exception
> chaining */" comment.

Well, it may be a fix for the crash but I'm not sure it makes the
semantics correct. If tstate->exc_value was really changed, there is a
reason and I'm not sure it should be ignored.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 22:11:07 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Aug 2008 20:11:07 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219263067.58.0.322118264034.issue3612@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>We could avoid the giant __all__ list when we 'import ctypes as >_ctypes'

How about the attached patch "avoid_giant_all.patch"?

Added file: http://bugs.python.org/file11178/avoid_giant_all.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Wed Aug 20 22:27:05 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Aug 2008 20:27:05 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219264025.92.0.277277593147.issue3612@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

And "avoid_giant_all_and_add_LPs.patch" adds bunch of LP(C)s.
I'm not sure all LP types are needed. (Especially handle types)

Added file: http://bugs.python.org/file11179/avoid_giant_all_and_add_LPs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Wed Aug 20 22:50:13 2008
From: report at bugs.python.org (Kenneth Arnold)
Date: Wed, 20 Aug 2008 20:50:13 +0000
Subject: [issue504152] rfc822 long header continuation broken
Message-ID: <1219265413.24.0.275977608376.issue504152@psf.upfronthosting.co.za>


Kenneth Arnold <kenneth.arnold at gmail.com> added the comment:

This issue still seems to be present in Python 2.5's email module.

feedparser.py line 444-445 says:

# XXX reconsider the joining of folded lines
lhdr = EMPTYSTRING.join(lastvalue)[:-1].rstrip('\r\n')

I think that should be something like:
lhdr = EMPTYSTRING.join(ln.rstrip('\r\n') for ln in lastvalue)[:-1])

The resulting headers still need a fair amount of massaging, though; why
not just use Header instances for the headers?

----------
nosy: +kcarnold

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue504152>
_______________________________________

From report at bugs.python.org  Wed Aug 20 23:11:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Aug 2008 21:11:25 +0000
Subject: [issue3608] memoryview constructor has no deallocator
In-Reply-To: <1219186239.27.0.516821193842.issue3608@psf.upfronthosting.co.za>
Message-ID: <1219266685.34.0.411707343215.issue3608@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3608>
_______________________________________

From report at bugs.python.org  Wed Aug 20 23:21:26 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 21:21:26 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219267286.19.0.694792965175.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Having a snippet deterministically reproducing the problem 
> would really help in any case.
Here you are. Don't ask how I found this.

The attached script, when run, prints

(KeyError(), ValueError())
(KeyError(), None)

The current exception context (tstate->exc_value) is lost when a
generator is deleted, if it was paused inside a "try" block.

This is the cause of the crash: the gc runs inside PyErr_SetObject and
collects such a generator.

Added file: http://bugs.python.org/file11180/lostcontext.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 23:21:31 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 21:21:31 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219267291.25.0.233753827286.issue3611@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

It looks that the problem is that PyErr_SetObject() is not re-entrant.
The crash occurs when PyErr_SetObject() is called (indirectly) by 
PyErr_SetObject(): tstate->exc_value value is changed (set to NULL).

As noticed by amaury.forgeotdarc, the problem is linked to be garbage 
collector: the crash occurs when the garbage collector calls a 
destructor which will reuse PyErr_SetObject().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 20 23:36:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 21:36:40 +0000
Subject: [issue3614] typo in xmlrpc.client
In-Reply-To: <1219212814.95.0.707077475128.issue3614@psf.upfronthosting.co.za>
Message-ID: <1219268200.52.0.535160543329.issue3614@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Corrected as r65920. Thanks for the report!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3614>
_______________________________________

From report at bugs.python.org  Wed Aug 20 23:51:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Aug 2008 21:51:26 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219253382.01.0.538890332193.issue3602@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808201451l71554ddy7660186e09961c0f@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> I don't think the using argument should live in warnings; it's too test
> specific. I recommend we still keep a catch_warning in test_support (or
> even just test_warnings since this seems to be the only use-case).
>

But decoupling from the core code of the context manager for this is
not straight-forward without mucking around in sys.modules and that is
always a risky thing to do.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Wed Aug 20 23:53:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 21:53:46 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <bbaeab100808201451l71554ddy7660186e09961c0f@mail.gmail.com>
Message-ID: <1afaf6160808201453q17838e17t5c9b807eafe470d9@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Wed, Aug 20, 2008 at 4:51 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> Brett Cannon <brett at python.org> added the comment:
>
> On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>>
>> I don't think the using argument should live in warnings; it's too test
>> specific. I recommend we still keep a catch_warning in test_support (or
>> even just test_warnings since this seems to be the only use-case).
>>
>
> But decoupling from the core code of the context manager for this is
> not straight-forward without mucking around in sys.modules and that is
> always a risky thing to do.

Why would you have to much around in sys.modules?
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3602>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Wed Aug 20 23:58:04 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 21:58:04 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219269484.11.0.41805580417.issue3611@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Great job amaury! So in ceval, here is the block responsible to clear 
the execution informations:

Index: Python/ceval.c
===================================================================
--- Python/ceval.c      (r?vision 65915)
+++ Python/ceval.c      (copie de travail)
@@ -2453,11 +2453,6 @@

                        if (b->b_type == EXCEPT_HANDLER) {
                                UNWIND_EXCEPT_HANDLER(b);
-                               if (why == WHY_EXCEPTION) {
-                                       Py_CLEAR(tstate->exc_type);
-                                       Py_CLEAR(tstate->exc_value);
-                                       
Py_CLEAR(tstate->exc_traceback);
-                               }
                                continue;
                        }
                        UNWIND_BLOCK(b);

Without these 5 lines, the bug disappears and it looks (i tried few 
tests) that CPython is still ok.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:03:08 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Aug 2008 22:03:08 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1afaf6160808201453q17838e17t5c9b807eafe470d9@mail.gmail.com>
Message-ID: <bbaeab100808201503j761acdeau9136d9b7f2bca80c@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Aug 20, 2008 at 2:53 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> On Wed, Aug 20, 2008 at 4:51 PM, Brett Cannon <report at bugs.python.org> wrote:
>>
>> Brett Cannon <brett at python.org> added the comment:
>>
>> On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson
>> <report at bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>>>
>>> I don't think the using argument should live in warnings; it's too test
>>> specific. I recommend we still keep a catch_warning in test_support (or
>>> even just test_warnings since this seems to be the only use-case).
>>>
>>
>> But decoupling from the core code of the context manager for this is
>> not straight-forward without mucking around in sys.modules and that is
>> always a risky thing to do.
>
> Why would you have to much around in sys.modules?
>>

Well, the bulk of the code needs to live in 'warnings' for it to exist
if the 'test' package is missing. So any differences need to come from
the test.support version. Now the module argument is so that you can
control exactly what module has its showwarnings() implementation
changed without worrying about what 'warnings' is set in sys.modules
and really mucking up the interpreter. But if this argument is missing
then warnings.catchwarnings() will have to set warnings.showwarnings()
blindly since it doesn't know what module object is being tested. So
if I want that change to happen on another module, I need to change
what module is in sys.modules, call the context manager, and then put
it all back so that what I want happen occurs.

That's why you would have to mess with sys.modules. =) The argument
could be renamed '_using', but that just seems silly. And with it
being considered keyword-only (and I will make it the last argument
listed, then most people won't ever run into it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:05:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 22:05:32 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <bbaeab100808201503j761acdeau9136d9b7f2bca80c@mail.gmail.com>
Message-ID: <1afaf6160808201505t73fbfb0dk2e185baf5b39e1ac@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Wed, Aug 20, 2008 at 5:03 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> Well, the bulk of the code needs to live in 'warnings' for it to exist
> if the 'test' package is missing. So any differences need to come from
> the test.support version. Now the module argument is so that you can
> control exactly what module has its showwarnings() implementation
> changed without worrying about what 'warnings' is set in sys.modules
> and really mucking up the interpreter. But if this argument is missing
> then warnings.catchwarnings() will have to set warnings.showwarnings()
> blindly since it doesn't know what module object is being tested. So
> if I want that change to happen on another module, I need to change
> what module is in sys.modules, call the context manager, and then put
> it all back so that what I want happen occurs.

Alternatively, you could just have another copy of catch_warning in
test_warnings with the extra argument.
>
> That's why you would have to mess with sys.modules. =) The argument
> could be renamed '_using', but that just seems silly. And with it
> being considered keyword-only (and I will make it the last argument
> listed, then most people won't ever run into it.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3602>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:25:23 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Aug 2008 22:25:23 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219271123.34.0.862907475099.issue3611@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:28:17 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Aug 2008 22:28:17 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219271297.35.0.802986667145.issue3618@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: high -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:42:04 2008
From: report at bugs.python.org (Allan Crooks)
Date: Wed, 20 Aug 2008 22:42:04 +0000
Subject: [issue3622] Slight documentation quirk for random.random
In-Reply-To: <1219272124.61.0.469101656014.issue3622@psf.upfronthosting.co.za>
Message-ID: <1219272124.61.0.469101656014.issue3622@psf.upfronthosting.co.za>


New submission from Allan Crooks <amc1 at users.sourceforge.net>:

The documentation for random.random function shows this:
  random() -> x in the interval [0, 1).

That should either be "[0, 1]" or "(0, 1)".

----------
assignee: georg.brandl
components: Documentation
messages: 71582
nosy: amc1, georg.brandl
severity: normal
status: open
title: Slight documentation quirk for random.random
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3622>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:49:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Aug 2008 22:49:22 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1afaf6160808201505t73fbfb0dk2e185baf5b39e1ac@mail.gmail.com>
Message-ID: <bbaeab100808201549u7f86b881p5612e4952d510c8f@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Aug 20, 2008 at 3:05 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:

> Alternatively, you could just have another copy of catch_warning in
> test_warnings with the extra argument.

Sure, but I am not about to support that much code duplication in
Python code when it is purely just to shave off an argument that can
be clearly documented.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:49:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 22:49:32 +0000
Subject: [issue3622] Slight documentation quirk for random.random
In-Reply-To: <1219272124.61.0.469101656014.issue3622@psf.upfronthosting.co.za>
Message-ID: <1219272572.02.0.756300723867.issue3622@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

[0, 1) denotes an interval, not a python object; 0 is included, 1 is
excluded.

And it follows (one of) the standard syntax to express intervals:
http://en.wikipedia.org/wiki/Interval_notation

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3622>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:51:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 22:51:19 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219272679.86.0.103066546333.issue3602@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

All right. You win! :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:52:15 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Wed, 20 Aug 2008 22:52:15 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1219272735.73.0.805807230774.issue1589@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

I would think most people/applications want to know to which host they
are talking to. The reason I am advocating adding a default check to the
stdlib is because this is IMO important for security, and it is easy to
get it wrong (I don't think I have it 100% correct in M2Crypto either,
although I believe it errs on the side of caution). I believe it would
be a disservice to ship something that effectively teaches developers to
ignore security (like the old socket.ssl does).

A TLS extension also allows SSL vhosts, so static IPs are no longer
strictly necessary (this is not universally supported yet, though).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:54:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 22:54:39 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219272879.8.0.442142936716.issue3611@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Unfortunately, removing those lines causes a RuntimeError about
exceeding the recursion limit for about 1/3 of the tests.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:58:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Aug 2008 22:58:44 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

_json module of python 3.0 has some bugs.

(a) [_json.c] raise_errmsg() calls json.decoder.errmsg() from Python 
module, but this function may fails. If it fails, error should be be 
set to NULL. Example:

>>> import _json
>>> _json.scanstring(b"xxx", 1, "xxx")
Erreur de segmentation (core dumped)

=> json.decoder.errmsg() calls linecol() which raise an error on 
b"xxx".index("\n").

(b) [_json.c] py_encode_basestring_ascii() calls PyBytes_Check(rval) 
but rval can be NULL if ascii_escape_str() or ascii_escape_unicode() 
fails. Example:

>>> import _json
>>> _json.encode_basestring_ascii(b"xx\xff")
Erreur de segmentation (core dumped)

(c) [Lib/json/decoder.py] linecol() doesn't support bytes, but it's 
called with bytes argument: see point (a). For an example, see point 
(a).

----------
components: Library (Lib)
files: _json.patch
keywords: patch
messages: 71588
nosy: haypo
severity: normal
status: open
title: _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11181/_json.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Thu Aug 21 00:59:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 22:59:49 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219273189.92.0.828938557533.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you try with the following patch,
"throwflag" is specific to a generator being deleted.

Index: Python/ceval.c
===================================================================
--- Python/ceval.c      (revision 65919)
+++ Python/ceval.c      (working copy)
@@ -2453,7 +2453,7 @@

                        if (b->b_type == EXCEPT_HANDLER) {
                                UNWIND_EXCEPT_HANDLER(b);
-                               if (why == WHY_EXCEPTION) {
+                               if (why == WHY_EXCEPTION && !throwflag) {
                                        Py_CLEAR(tstate->exc_type);
                                        Py_CLEAR(tstate->exc_value);
                                        Py_CLEAR(tstate->exc_traceback);

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:01:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 23:01:30 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1219273290.58.0.225648409481.issue3623@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:04:03 2008
From: report at bugs.python.org (Matt Aasted)
Date: Wed, 20 Aug 2008 23:04:03 +0000
Subject: [issue3624] Null byte \0 not listed as a possible escape sequence
In-Reply-To: <1219273443.74.0.909358695048.issue3624@psf.upfronthosting.co.za>
Message-ID: <1219273443.74.0.909358695048.issue3624@psf.upfronthosting.co.za>


New submission from Matt Aasted <aasted at gmail.com>:

In current, future and past documentation, the valid escape sequence \0
(equivalent to \x00) is missing from the list of possible escape
sequences in the documentation. As far as I can tell, it is not a case
covered by any of the other elements in the list, and is valid python
though I have only tested current (2.5.2) for it.

Current version can be found here: http://docs.python.org/ref/strings.html

----------
assignee: georg.brandl
components: Documentation
messages: 71590
nosy: georg.brandl, voket
severity: normal
status: open
title: Null byte \0 not listed as a possible escape sequence
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3624>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:09:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Aug 2008 23:09:08 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219273748.87.0.710667028994.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And if it doesn't work, try the following instead:

if (why == WHY_EXCEPTION) {
	PyObject *tmp1, *tmp2, *tmp3;
	tmp1 = tstate->exc_type;
	tmp2 = tstate->exc_value;
	tmp3 = tstate->exc_traceback;
	tstate->exc_type = NULL;
	tstate->exc_value = NULL;
	tstate->exc_traceback = NULL;
	Py_XDECREF(tmp1);
	Py_XDECREF(tmp2);
	Py_XDECREF(tmp3);
}

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:13:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 23:13:11 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219273991.34.0.673878603946.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This last proposal does not correct the behaviour of lostcontext.py.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:19:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 23:19:56 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219274396.96.0.847121430288.issue3611@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's Amaury's patch and a unittest based on lostcontext.py.

----------
keywords: +patch
Added file: http://bugs.python.org/file11182/3611.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:21:53 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Aug 2008 23:21:53 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219274513.31.0.0319051114783.issue3611@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:24:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Aug 2008 23:24:46 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219274686.06.0.235685370125.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Short patch review: __context__ tests are mostly found in test_raise.py
(class TestContext)

test_exceptions.py seems to only deal with the exception object.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:24:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 23:24:52 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219274692.99.0.404957995623.issue3611@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Patch was applied in r65921.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 01:25:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Aug 2008 23:25:46 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219274746.98.0.154474131378.issue3611@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I'll move the test after the betas.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 02:58:37 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 00:58:37 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219280317.92.0.983073629006.issue3611@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 03:20:45 2008
From: report at bugs.python.org (Bob Ippolito)
Date: Thu, 21 Aug 2008 01:20:45 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1219281645.07.0.455440854124.issue3623@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

That patch looks ok to me, but I'm not at all familiar with the changes in 
python 3.0 yet. Is this something that needs to be backported to 2.6?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Thu Aug 21 03:22:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 01:22:37 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1219281757.06.0.0354130939113.issue3623@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Christian, I believe, did the original 3.0 porting, so he can probably
shed some light on this.

----------
nosy: +benjamin.peterson, christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Thu Aug 21 03:18:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 01:18:20 +0000
Subject: [issue3603] trivial typo in Include/pymath.h
In-Reply-To: <1219173065.49.0.835954949015.issue3603@psf.upfronthosting.co.za>
Message-ID: <1219281500.03.0.560640626505.issue3603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Don't worry. It's taken care of in all the active lines of development.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3603>
_______________________________________

From report at bugs.python.org  Thu Aug 21 04:33:58 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 21 Aug 2008 02:33:58 +0000
Subject: [issue3612] Add some basic mssing types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219286038.97.0.360730580343.issue3612@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Module will be deleted at the end of file anyway (delete _ctypes), maybe
we could just do "import ctypes" and "delete ctypes".

Added file: http://bugs.python.org/file11183/avoid_giant_all_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Thu Aug 21 04:49:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 02:49:24 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1219286964.36.0.510990149986.issue3373@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Guido, can you comment?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Thu Aug 21 04:54:26 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 21 Aug 2008 02:54:26 +0000
Subject: [issue3612] Add some missing basic types in ctypes.wintypes
In-Reply-To: <1219208632.69.0.435134240035.issue3612@psf.upfronthosting.co.za>
Message-ID: <1219287266.36.0.155703610609.issue3612@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
title: Add some basic mssing types in ctypes.wintypes -> Add some missing basic types in ctypes.wintypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3612>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:06:09 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 03:06:09 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1219287969.17.0.728069005245.issue3419@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:06:26 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 03:06:26 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1219287986.34.0.247264356134.issue3589@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3589>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:06:44 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 03:06:44 +0000
Subject: [issue3444] add warnings for intra-package imports
In-Reply-To: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>
Message-ID: <1219288004.04.0.491568053195.issue3444@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3444>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:07:04 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 03:07:04 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219288024.2.0.0821214802897.issue3352@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:07:23 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 03:07:23 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219288043.92.0.696062837486.issue3187@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:07:41 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 03:07:41 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219288061.75.0.218806078568.issue3618@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:21:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 03:21:07 +0000
Subject: [issue2356] sys.exitfunc should raise a Py3K warning
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1219288867.05.0.509199454742.issue2356@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Actually, a fixer probably won't work since that would require the
atexit module to be imported.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:22:16 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 03:22:16 +0000
Subject: [issue3625] test issues on 64bit windows
In-Reply-To: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>
Message-ID: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

A number of tests are designed to be skipped on 64bits, but they don't
detect 64bit windows builds as 64bits.  Also, test_bytes.test_repeat()
assumes sys.maxint bytes can't be allocated, which isn't necessarily
true on Win64.

I'm attaching a patch that arranges to skip these tests.

----------
assignee: mhammond
components: Tests, Windows
files: win64_test_failures.patch
keywords: 64bit, patch, patch
messages: 71603
nosy: mhammond
severity: normal
status: open
title: test issues on 64bit windows
versions: Python 2.6
Added file: http://bugs.python.org/file11184/win64_test_failures.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3625>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:33:02 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 21 Aug 2008 03:33:02 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219289582.11.0.80139524653.issue1342811@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Well, beta3 was released and the problem remained there.

Robert, I believe MvL assigned this to you for a reason.. I'm a bit
stressed but what I'm trying to say is that you could have decided about
this issue yourself and you decided to keep the broken patch there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Thu Aug 21 05:49:16 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 03:49:16 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219290557.0.0.691094705015.issue3617@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Thu Aug 21 06:10:07 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 04:10:07 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219291807.3.0.339435030484.issue3617@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Obviously IANAL, but my reading of eula.txt included with VS9 seems less
restrictive than the 2003 one.  It has 2 clauses that seem relevant:

* [you must] require distributors and external end users to agree to
terms that protect it at least as much as this agreement;

* [you must not] modify or distribute the source code of any
Distributable Code so that any part of it becomes subject to an Excluded
License.  An Excluded License is [description of GPL]

I do see how the first could be considered an issue (otoh, I'd try to
argue we aren't doing anything to imply any worse terms :), but I don't
see how the second is, even for GPLd programs that simply used the compiler.

Maybe it would be helpful if you referenced the specific clauses you
think are of concern?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Thu Aug 21 06:36:04 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Thu, 21 Aug 2008 04:36:04 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>


New submission from Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net>:

Attempting to build 3.0b3, the sharedmods make target results only in a
python command prompt.  In fact, it seems that the interpreter doesn't
accept any arguments:

$ /usr/bin/python --version
Python 2.5.2

$ /usr/bin/python -c 'print "Hello, World!"'
Hello, World!

$ ./python.exe --version
Python 3.0b3 (r30b3:65927, Aug 20 2008, 22:34:44) 
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

$ ./python.exe -c 'print "Hello, World!"'
Python 3.0b3 (r30b3:65927, Aug 20 2008, 22:34:44) 
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

The same happened with 3.0b2 when I tried to determine if this was a
recent regression.  I have successfully built 2.5 on a number of occasions.

----------
components: Interpreter Core
messages: 71606
nosy: yselkowitz
severity: normal
status: open
title: python3.0 interpreter on Cygwin ignores all arguments
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Thu Aug 21 06:47:32 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 21 Aug 2008 04:47:32 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219294052.24.0.893379814992.issue3618@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Thu Aug 21 07:15:26 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 21 Aug 2008 05:15:26 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219295726.36.0.042958118451.issue3618@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

see the python-3000 thread I just started asking for opinions on this. 
I'd personally say this bug is a good reason to go ahead with #3001 for 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Thu Aug 21 07:43:42 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Thu, 21 Aug 2008 05:43:42 +0000
Subject: [issue3627] apple security patches need to be forward ported to py3k
In-Reply-To: <1219297422.68.0.603691629557.issue3627@psf.upfronthosting.co.za>
Message-ID: <1219297422.68.0.603691629557.issue3627@psf.upfronthosting.co.za>


New submission from Neal Norwitz <nnorwitz at gmail.com>:

The trunk revision was 65335.

----------
components: Interpreter Core
messages: 71608
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: apple security patches need to be forward ported to py3k
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3627>
_______________________________________

From report at bugs.python.org  Thu Aug 21 08:58:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Aug 2008 06:58:20 +0000
Subject: [issue3624] Null byte \0 not listed as a possible escape sequence
In-Reply-To: <1219273443.74.0.909358695048.issue3624@psf.upfronthosting.co.za>
Message-ID: <1219301900.43.0.96256028443.issue3624@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The \0 falls under this case:

\ooo  	Character with octal value ooo

where the note says "As in Standard C, up to three octal digits are
accepted. "

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3624>
_______________________________________

From report at bugs.python.org  Thu Aug 21 09:29:56 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Thu, 21 Aug 2008 07:29:56 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219303796.71.0.134537963362.issue1342811@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

I am sry that you see it that way, I do not. I was given commit access
solely for gsoc purposes and committing changes before a late release
without review from a committer IMHO violates strict policies. I tried
to get somebody to review the patch twice on the #python-dev channel,
but was ignored. Maybe I should have made more fuss about it. Also,
since it is still a beta, it is not the end of the world. I don't like
it either but take the blame now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Thu Aug 21 10:06:31 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 21 Aug 2008 08:06:31 +0000
Subject: [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

When I try to run IDLE in Py30b3 I get a traceback, then the main window
appears with an error message box and an OK button; once I click OK,
IDLE goes away.

$ ~/opt/python30b3/bin/idle
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/mark/opt/python30b3/lib/python3.0/idlelib/run.py", line
76, in main
    sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'

It looks like there's been some mixup with threading... in an earlier
beta there was setDaemon(), then it became set_daemon(), and now it is
back to setDaemon() again. And unfortunately, the obvious fix (change
the name to setDaemon()), although it gets past this problem, just leads
to another:

$ ~/opt/python30b3/bin/idle # using setDaemon
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/mark/opt/python30b3/lib/python3.0/idlelib/run.py", line
76, in main
    sockthread.setDaemon(True)
  File "/home/mark/opt/python30b3/lib/python3.0/threading.py", line 674,
in setDaemon
    "Thread.daemon property", DeprecationWarning)
  File "/home/mark/opt/python30b3/lib/python3.0/warnings.py", line 18,
in showwarning
    file.write(formatwarning(message, category, filename, lineno, line))
TypeError: idle_formatwarning_subproc() takes exactly 4 positional
arguments (5 given)

I did run make test and got 300 tests OK with 22 skipped all expected on
linux2.

----------
components: IDLE
messages: 71611
nosy: mark
severity: normal
status: open
title: IDLE does not run with Py30b3
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3628>
_______________________________________

From report at bugs.python.org  Thu Aug 21 10:20:42 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 08:20:42 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219306842.92.0.394002937162.issue3187@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

If the filename can not be encoded correctly in the system charset, 
it's not really a problem. The goal is to be able to use open(), 
shutil.copyfile(), os.unlink(), etc. with the given filename.

orig = filename from the kernel (bytes)
filename = filename from listdir() (str)
dest = filename to the kernel (bytes)

The goal is to get orig == dest. In my program Hachoir, to workaround 
this problem I store the original filename (bytes) and convert it to 
unicode with characters replacements (eg. replace invalid byte 
sequence by "?"). So the bytes string is used for open(), 
unlink(), ... and the unicode string is displayed to stdout for the 
user.

IMHO, the best solution is to create such class:

class Filename:
    def __init__(self, orig):
        self.as_bytes = orig
        self.as_str = myformat(orig)
    def __str__(self):
        return self.as_str
    def __bytes__(self):
        return self.as_bytes

New problems: I guess that functions operating on filenames 
(os.path.*) will have to support this new type (Filename class).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 10:25:57 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Aug 2008 08:25:57 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219291807.3.0.339435030484.issue3617@psf.upfronthosting.co.za>
Message-ID: <48AD268F.6070802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Hammond wrote:
> Mark Hammond <mhammond at users.sourceforge.net> added the comment:
> 
> Obviously IANAL, but my reading of eula.txt included with VS9 seems less
> restrictive than the 2003 one.  It has 2 clauses that seem relevant:
> 
> * [you must] require distributors and external end users to agree to
> terms that protect it at least as much as this agreement;
> 
> * [you must not] modify or distribute the source code of any
> Distributable Code so that any part of it becomes subject to an Excluded
> License.  An Excluded License is [description of GPL]
> 
> I do see how the first could be considered an issue (otoh, I'd try to
> argue we aren't doing anything to imply any worse terms :), but I don't
> see how the second is, even for GPLd programs that simply used the compiler.
> 
> Maybe it would be helpful if you referenced the specific clauses you
> think are of concern?

This was already discussed on the PSF members mailing list.

I don't have the VC9 EULA available, but these are the clauses of concern
from VC7.1:

"""
3.	DISTRIBUTION REQUIREMENTS AND OTHER LICENSE RIGHTS AND LIMITATIONS.  If you choose to exercise
your rights under Section 2, any redistribution by you is subject to your compliance with Section
3.1; some of the Redistributable Code has additional limited use rights described in Section 3.2.

       3.1	General Distribution Requirements.

             (a)	If you choose to redistribute Sample Code, or Redistributable Code (collectively,
the ?Redistributables?) as described in Section 2, you agree:

                  (i) except as otherwise noted in Section 2.1 (Sample Code), to distribute the
Redistributables only in object code form and in conjunction with and as a part of a software
application product developed by you that adds significant and primary functionality to the
Redistributables (?Licensee Software?);

                  (ii) that the Redistributables only operate in conjunction with Microsoft Windows
platforms;

                  (iii) that if the Licensee Software is distributed beyond Licensee?s premises or
externally from Licensee?s organization, to distribute the Licensee Software containing the
Redistributables pursuant to an end user license agreement (which may be ?break-the-seal?,
?click-wrap? or signed), with terms no less protective than those contained in this EULA;

                  (iv) not to use Microsoft?s name, logo, or trademarks to market the Licensee
Software;

                  (v) to display your own valid copyright notice which shall be sufficient to
protect Microsoft?s copyright in the Software;

                  (vi) not to remove or obscure any copyright, trademark or patent notices that
appear on the Software as delivered to you;

                  (vii) to indemnify, hold harmless, and defend Microsoft from and against any
claims or lawsuits, including attorney?s fees, that arise or result from the use or distribution of
the Licensee Software;

                  (viii) to otherwise comply with the terms of this EULA; and (ix) agree that
Microsoft reserves all rights not expressly granted.

             You also agree not to permit further distribution of the Redistributables by your end
users except you may permit further redistribution of the Redistributables by your distributors to
your end-user customers if your distributors only distribute the Redistributables in conjunction
with, and as part of, the Licensee Software, you comply with all other terms of this EULA, and your
distributors comply with all restrictions of this EULA that are applicable to you.

             (b)	If you use the Redistributables, then in addition to your compliance with the
applicable distribution requirements described for the Redistributables, the following also applies.
 Your license rights to the Redistributables are conditioned upon your not

                  (i) creating derivative works of the Redistributables in any manner that would
cause the Redistributables in whole or in part to become subject to any of the terms of an Excluded
License; or

                  (ii) distributing the Redistributables (or derivative works thereof) in any manner
that would cause the Redistributables to become subject to any of the terms of an Excluded License.
 An ?Excluded License? is any license that requires as a condition of use, modification and/or
distribution of software subject to the Excluded License, that such software or other software
combined and/or distributed with such software be (x) disclosed or distributed in source code form;
(y) licensed for the purpose of making derivative works; or (z) redistributable at no charge.
"""

Specifically:
-------------

3.1 (a) (iii) ... pursuant to an end user license agreement (which may be ?break-the-seal?,
?click-wrap? or signed), with terms no less protective than those contained in this EULA ...

The PSF license is *less* protective than the MS EULA.

3.1 (a) ... You also agree not to permit further distribution of the Redistributables ...

This clause also allows an exception to the rule, but that's mainly meant to cover distributors of
the software as a whole.

3.1 (b) ... [may not be distributed together with an app under a GPL-like license] ...

This is only important for people wanting to use e.g. py2exe for creating a GPLed application.

Note that I'm not suggesting to dive into all this. We should simply put the EULA into the installer
package and be done with it :-)

----------
title: Add MS EULA to the list of third-party licenses in the Windows installer -> Add MS EULA to the list of third-party licenses in the	Windows installer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Thu Aug 21 10:42:01 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 21 Aug 2008 08:42:01 +0000
Subject: [issue3629] Py30b3 won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

Here are the results of running the same tiny program against 2.5.2,
30b2, and 30b3. The program creates a regex and tries to match 3
strings. For 2.5.2 and 30b2 this works fine; for 30b3 the regex won't
even compile:

$ python -V
Python 2.5.2
$ python /tmp/retext.py
name="name1" value="value1"
name="name2" value="value #2"
name="name3" value="value '3'"
$
$ ~/opt/python30b2/bin/python3.0 -V
Python 3.0b2
$ ~/opt/python30b2/bin/python3.0 /tmp/retext.py
name="name1" value="value1"
name="name2" value="value #2"
name="name3" value="value '3'"
$
$ ~/opt/python30b3/bin/python3.0 /tmp/retext.py
Traceback (most recent call last):
  File "/tmp/retext.py", line 8, in <module>
    """, re.VERBOSE)
  File "/home/mark/opt/python30b3/lib/python3.0/re.py", line 203, in compile
    return _compile(pattern, flags)
  File "/home/mark/opt/python30b3/lib/python3.0/re.py", line 255, in
_compile
    p = sre_compile.compile(pattern, flags)
  File "/home/mark/opt/python30b3/lib/python3.0/sre_compile.py", line
520, in compile
    groupindex, indexgroup
RuntimeError: invalid SRE code

----------
components: Regular Expressions
files: retext.py
messages: 71614
nosy: mark
severity: normal
status: open
title: Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11185/retext.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Thu Aug 21 10:51:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 08:51:11 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1219306842.92.0.394002937162.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219308697.48ad2c99d63b0@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon STINNER Victor <report at bugs.python.org>:
> IMHO, the best solution is to create such class:
>
> class Filename:
>     def __init__(self, orig):
>         self.as_bytes = orig
>         self.as_str = myformat(orig)
>     def __str__(self):
>         return self.as_str
>     def __bytes__(self):
>         return self.as_bytes

I agree that logically it's the right solution. It's also the most invasive. If
that class is made a subclass of str, however, existing code shouldn't break
more than it currently does.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 10:53:56 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 21 Aug 2008 08:53:56 +0000
Subject: [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1219308836.24.0.122071420081.issue3628@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

Just realised how to fix this. Change line 76 in idlelib/run.py:

# change this:
    sockthread.set_daemon(True)
# to this:
    sockthread.daemon = True

and IDLE runs fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3628>
_______________________________________

From report at bugs.python.org  Thu Aug 21 11:22:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Aug 2008 09:22:31 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219310551.4.0.605902012324.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Cygwin seems to have a broken implementation of mbstowcs.
See http://www.google.com/codesearch?q=cygwin+mbstowcs\(NULL

The attached patch corrects the problem.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file11186/cygwin-mbstowcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Thu Aug 21 11:49:38 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 09:49:38 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219312178.57.0.13800405903.issue3617@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

MAL:
> This was already discussed on the PSF members mailing list.

Yeah, but not specifically about VS2008 which this bug seemed to be
specifically targetting.  FWIW, this appears like *less* of a problem
for 2.6 than for 2.4 and 2.5 as it doesn't appear to have as draconian
clauses as the ones you quote.

> Note that I'm not suggesting to dive into all this. We 
> should simply put the EULA into the installer package 
> and be done with it :-)

I can't argue with that - including the relevant EULA certainly would be
prudent (I wonder what the license on the EULA itself is - it doesn't
seem to be covered as 'Distributable Code' under the terms of its own
license ;)  What the hell though - at the risk of being sued, I've
attached it ;)

Added file: http://bugs.python.org/file11187/msvs2008_prof_edition_eula.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Thu Aug 21 11:54:24 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 09:54:24 +0000
Subject: [issue3630] Unable to inherit bytes: bytes.__init__() doesn't accept
	arguments
In-Reply-To: <1219312456.78.0.90200161612.issue3630@psf.upfronthosting.co.za>
Message-ID: <1219312456.78.0.90200161612.issue3630@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

Example:

   class MyBytes(bytes):
      def __init__(self, *args, **kw):
         bytes.__init__(self, *args, **kw)
   a = bytes(b"hello")   # ok
   b = MyBytes(b"hello") # error

=> DeprecationWarning: object.__init__() takes no parameters

The example works fine in Python 2.6 but fails in Python 3.0.

----------
components: Library (Lib)
messages: 71619
nosy: haypo
severity: normal
status: open
title: Unable to inherit bytes: bytes.__init__() doesn't accept arguments
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3630>
_______________________________________

From report at bugs.python.org  Thu Aug 21 11:57:36 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Aug 2008 09:57:36 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219312656.85.0.612616724599.issue3617@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Attaching the VS7.1 EULA. This is only relevant for Python 2.5... should
we do another patch level release.

----------
versions: +Python 2.5
Added file: http://bugs.python.org/file11188/eula.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Thu Aug 21 12:01:06 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Aug 2008 10:01:06 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219312178.57.0.13800405903.issue3617@psf.upfronthosting.co.za>
Message-ID: <48AD3CDD.30204@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Hammond wrote:
> MAL:
>> Note that I'm not suggesting to dive into all this. We 
>> should simply put the EULA into the installer package 
>> and be done with it :-)
> 
> I can't argue with that - including the relevant EULA certainly would be
> prudent (I wonder what the license on the EULA itself is - it doesn't
> seem to be covered as 'Distributable Code' under the terms of its own
> license ;)  What the hell though - at the risk of being sued, I've
> attached it ;)

Thanks. I'll have a look at the new EULA as well... I was under the
assumption that EULAs tend to grow more restrictive rather then
open up possibilities ;-)

I've added the VC7.1 EULA as well.

----------
title: Add MS EULA to the list of third-party licenses in the	Windows installer -> Add MS EULA to the list of third-party licenses in the Windows installer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Thu Aug 21 12:09:49 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Aug 2008 10:09:49 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1219313389.23.0.129984022001.issue3617@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Adding the EULA should be easy... the MSI installer code already adds
the other licenses for OpenSSL, etc. to the license text in
Tools/msi/msi.py (took me a while to find that file, since I would have
expected this to live under PCbuild/).

The only "problem" is finding the path to the EULA text file, since that
depends on the where VS is installed (and perhaps the edition as well).

----------
components: +Windows
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Thu Aug 21 12:16:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 10:16:42 +0000
Subject: [issue3630] Unable to inherit bytes: bytes.__init__() doesn't accept
	arguments
In-Reply-To: <1219312456.78.0.90200161612.issue3630@psf.upfronthosting.co.za>
Message-ID: <1219313802.53.0.306626140885.issue3630@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

With immutable types, you must use __new__ instead. Passing the
arguments to __init__ is too late since the object is immutable and it
has already been built in memory, thus you can't initialize it with
another value.

>>> class B(bytes):
...  def __new__(cls, *args, **kargs):
...   print(args)
...   return bytes.__new__(cls, *args, **kargs)
...
>>> b = B(b"foo")
(b'foo',)
>>> b
b'foo'
>>> type(b)
<class '__main__.B'>

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3630>
_______________________________________

From report at bugs.python.org  Thu Aug 21 12:59:29 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 10:59:29 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219316369.16.0.371557599728.issue3187@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

I wrote a Filename class. I tries different methods:
 * no parent class "class Filename: ..." -> I don't know how to make 
bytes(filename) works!? But it's the best option to avoid strange bugs 
(mix bytes/str, remember Python 2.x...)
 * str parent class "class Filename(str): ..." -> doesn't work because 
os functions uses the fake unicode filename before testing the bytes 
(real) filename
 * bytes parent class "class Filename(bytes): ..." -> that's the 
current implementation

The idea is to encode str -> bytes (and not bytes -> str because we 
want to avoid problems with such conversions). So I reimplemented most 
bytes methods: __addr__, __raddr__, __contains__, startswith, endswith 
and index. index method has no start/end arguments since the behaviour 
would be different than a real unicode string :-/

I added an example of fixed os.listdir(): create Filename() object if 
we get bytes. Should we always create Filename objects? I don't think 
so.

Added file: http://bugs.python.org/file11189/filename.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 13:36:29 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 11:36:29 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219318589.16.0.526735554317.issue3618@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

So if we consider that RLock is fast enough (see my C version of RLokc 
in #3001), we can use RLock instead of Lock to avoid this issue. Here 
is a patch to use RLock and also including an unit test of this issue.

Added file: http://bugs.python.org/file11190/io_deadlock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:20:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 12:20:07 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219318589.16.0.526735554317.issue3618@psf.upfronthosting.co.za>
Message-ID: <1219321231.48ad5d8f75360@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon STINNER Victor <report at bugs.python.org>:
>
> So if we consider that RLock is fast enough (see my C version of RLokc
> in #3001), we can use RLock instead of Lock to avoid this issue. Here
> is a patch to use RLock and also including an unit test of this issue.

I tried your test and it seems to lock when using the Python implementation of
RLock, but perhaps it's precisely because the implementation is in Python.

Also, your RLock implementation has to be finished before going further ;)
(see my comments in #3001)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3618>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:29:03 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:29:03 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

I wrote a patch to improve gdbinit (gdb macros):
 - implement py_decref
 - reuse pyo in pylocals
 - direclty call PyCode_Addr2Line() in lineno instead of a long and 
complex reimplemention in gdb script language
 - avoid memory leak in pylocals: call py_decref($_name)

See also #3610 (for Python 3.0).

----------
files: gdbinit_python26.patch
keywords: patch
messages: 71627
nosy: haypo
severity: normal
status: open
title: Improve gdbinit of Python 2.6
Added file: http://bugs.python.org/file11191/gdbinit_python26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:30:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:30:00 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1219321800.26.0.151116643988.issue3631@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


----------
components: +None
type:  -> feature request
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:33:46 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 12:33:46 +0000
Subject: [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1219322026.61.0.855635021263.issue3628@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3628>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:34:19 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Aug 2008 12:34:19 +0000
Subject: [issue3629] Py30b3 won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1219322059.86.0.374423566943.issue3629@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:39:40 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:39:40 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>


New submission from STINNER Victor <haypo at users.sourceforge.net>:

"pyo" macro from gdbinit (see #3631) uses _PyObject_Dump() to display 
an object. This function calls (indirectly) string_print() to display 
one line of text. But if the GIL is released (I guess it's the GIL or 
is it called the "thread state"?), gdb crashs Python:

   object  : Fatal Python error: PyEval_SaveThread: NULL tstate
   Program received signal SIGABRT, Aborted.
   0xffffe410 in __kernel_vsyscall ()

Workaround: ensure GIL before Py_BEGIN_ALLOW_THREADS... That sounds 
ugly but it works :-) So I propose to enable it in debug mode (#ifdef 
Py_DEBUG) with a patch.

I guess that the issue is very specific to (gdb) debugging and should 
not affect normal usage of Python. That's why I choosed to enable it 
only in debug mode.

----------
components: Library (Lib)
files: string_print.patch
keywords: patch
messages: 71628
nosy: haypo
severity: normal
status: open
title: use string_print() in gdb
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file11192/string_print.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:55:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 12:55:43 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1219316369.16.0.371557599728.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219323369.48ad65e94f011@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

>  * bytes parent class "class Filename(bytes): ..." -> that's the
> current implementation

I don't think that makes sense (especially under Windows which has Unicode file
APIs). os.listdir() and friends should really return str or str-like objects,
not bytes-like objects with an additional __str__ method.

>  * str parent class "class Filename(str): ..." -> doesn't work because
> os functions uses the fake unicode filename before testing the bytes
> (real) filename

Well, of course, if we create a filename type, then all os functions must be
adapted to accept it rather than assume str.

All this is highly speculative of course, and if we really follow this course
(i.e. create a filename type) it should probably be postponed to 3.1: too many
changes with far-reaching consequences.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:56:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Aug 2008 12:56:03 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1219323363.31.0.333373176417.issue3632@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I once fell into the same issue, but the patch should modify
_PyObject_Dump(), around the call to PyObject_Print.

string_print() is not the only function called by _PyObject_Dump, by far...

And beware that many people routinely run python in "debug mode" outside
gdb, for example during development.
That's why it's better to modify _PyObject_Dump only; we can be sure
that it only affects a debugger session.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:57:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:57:01 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1219323421.7.0.300373725174.issue3632@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

Oh! I have a better idea: why not patching _PyObject_Dump() instead of 
string_print() :-) So here is a new patch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:57:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:57:19 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1219323439.92.0.295396610237.issue3632@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Added file: http://bugs.python.org/file11193/pyobject_dump.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:57:23 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 12:57:23 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1219323443.73.0.836694770472.issue3632@psf.upfronthosting.co.za>


Changes by STINNER Victor <haypo at users.sourceforge.net>:


Removed file: http://bugs.python.org/file11192/string_print.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Thu Aug 21 14:59:16 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 21 Aug 2008 12:59:16 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1219323556.97.0.920688137806.issue3631@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Thanks for the patch.  Most of it looks okay except for the rewrite of
the lineno command.  That was written in gdb's command language so
that you could get a python stack from a core dump, not just from a
running process.  Is there some reason it can't remain as it was
(changes to line number data structures between versions, perhaps)?

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:13:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 13:13:14 +0000
Subject: [issue3629] Py30b3 won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1219324394.4.0.289253867672.issue3629@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The error is in the bytecode verifier and also occurs with 2.6.
(perhaps a good reason not to backport it to 2.5 :-))

----------
nosy: +gvanrossum, pitrou
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:16:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 13:16:17 +0000
Subject: [issue3629] Py30b3 won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1219324577.6.0.13327676686.issue3629@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The following expression is sufficient to reproduce the bug:

re.compile("(?P<quote>)(?(quote))")

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:18:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 13:18:22 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219324702.74.0.123910929994.issue2415@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:18:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 13:18:35 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a failure that seems to occur quite often (always?) on the
Solaris buildbot:

======================================================================
FAIL: test_invalid_inputs (test.test_float.HexFloatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home2/buildbot/slave/3.0.loewis-sun/build/Lib/test/test_float.py",
line 451, in test_invalid_inputs
    self.assertRaises(ValueError, fromHex, x)
AssertionError: ValueError not raised by fromhex

----------------------------------------------------------------------

----------
components: Interpreter Core
messages: 71635
nosy: pitrou
priority: critical
severity: normal
status: open
title: float.fromhex discrepancy under Solaris
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:28:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 13:28:23 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1219325303.17.0.390670702791.issue3373@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(FWIW, I just ran Misc/find_recursion_limit.py on a 32-bit Windows box.

With 2.6 I get 5900.
With 3.0 I get 9000.

So the good news is that 3.0 seems to be less stack-hungry :-))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:29:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 13:29:24 +0000
Subject: [issue3627] apple security patches need to be forward ported to py3k
In-Reply-To: <1219297422.68.0.603691629557.issue3627@psf.upfronthosting.co.za>
Message-ID: <1219325364.36.0.749458746923.issue3627@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I tried merging this once, but there were many conflicts. Are you
available to do this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3627>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:29:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 13:29:30 +0000
Subject: [issue3625] test issues on 64bit windows
In-Reply-To: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>
Message-ID: <1219325370.54.0.445052222408.issue3625@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mark, that check looks fragile:

+IS32BIT = sys.maxint == 0x7fffffff and "64 bit" not in sys.version

Why don't you check for sys.maxsize instead? By construction,
sys.maxsize should give you the pointer width (minus the sign bit ;-)).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3625>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:39:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 13:39:20 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1219325960.05.0.910617497471.issue3631@psf.upfronthosting.co.za>


STINNER Victor <haypo at users.sourceforge.net> added the comment:

@skip: oh yes, you're right about the core file :-) So forget the 
changes in lineno. I first rewrote lineno for Python 3.0 because the 
code changed and it was easier for me to reuse PyCode_Addr2Line() :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:39:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 13:39:59 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219325999.7.0.837616281616.issue3633@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This probably has been happening for quite a while. We just didn't
notice because that bot was busy hanging on test_nis.

The failure is in test_math. Mark, do you know anything?

----------
nosy: +benjamin.peterson, marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:40:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 13:40:47 +0000
Subject: [issue3620] test_smtplib is flaky
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1219326047.59.0.532215355199.issue3620@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The failure happens even when test_smtplib runs before both
test_asyncore and test_asynchat (*). So the latter can't be the culprit.


(*)
http://www.python.org/dev/buildbot/3.0.stable/sparc%20Debian%203.0/builds/419/step-test/0

----------
nosy: +pitrou
title: test_asyncore is not cleanup after its self? -> test_smtplib is flaky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3620>
_______________________________________

From report at bugs.python.org  Thu Aug 21 15:43:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 13:43:17 +0000
Subject: [issue2356] sys.exitfunc should raise a Py3K warning
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1219326197.36.0.703474292041.issue2356@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is going to be very hard to implement without module descriptors.
It might be better to make a 2to3 fixer which inserts an import too.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:11:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 14:11:34 +0000
Subject: [issue3601] test_unicode.test_raiseMemError fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1219327894.86.0.0599091112007.issue3601@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:23:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:23:16 +0000
Subject: [issue3607] test_multiprocessing failure (Unserializable message)
In-Reply-To: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
Message-ID: <1219328596.87.0.693678990431.issue3607@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3607>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:24:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:24:49 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1219328689.2.0.559379196187.issue2548@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:26:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:26:03 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1219328763.38.0.133513693128.issue1745@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:27:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:27:16 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1219328836.24.0.385697710466.issue3297@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:27:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:27:29 +0000
Subject: [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1219328849.61.0.679467915198.issue2744@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2744>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:28:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:28:57 +0000
Subject: [issue2965] Update interface of weakref dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1219328937.7.0.364467522723.issue2965@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2965>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:29:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:29:40 +0000
Subject: [issue2357] sys.exc_{type,values,traceback} needs a 2to3 fixer
In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za>
Message-ID: <1219328980.14.0.427625324582.issue2357@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
title: sys.exc_{type,values,traceback} should raise a Py3K warning -> sys.exc_{type,values,traceback} needs a 2to3 fixer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2357>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:49:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:49:12 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1219330152.19.0.581915202705.issue1967@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
title: Backport dictviews to 2.6 -> Backport dictviews to 2.7
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1967>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:50:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:50:51 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219330251.6.0.319630362609.issue2534@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:51:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:51:27 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1219330287.84.0.370860835265.issue3279@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:51:28 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 14:51:28 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219330288.26.0.492685543184.issue3633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll take a look, though if anyone has some time to spare and access to a 
Solaris machine then they can probably figure this out more quickly.

The first step would be to fix the test so that it at least shows which 
input the failure occurs for.

----------
assignee:  -> marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:51:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:51:46 +0000
Subject: [issue2333] Backport dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1219330306.73.0.815161163021.issue2333@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2333>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:51:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:51:51 +0000
Subject: [issue2331] Backport parameter annotations
In-Reply-To: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za>
Message-ID: <1219330311.49.0.763715772611.issue2331@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2331>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:52:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:52:00 +0000
Subject: [issue2334] Backport set comprehensions
In-Reply-To: <1205775496.96.0.230528149509.issue2334@psf.upfronthosting.co.za>
Message-ID: <1219330320.97.0.379341209756.issue2334@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2334>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:52:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:52:49 +0000
Subject: [issue2402] get rid of warnings in regrtest with -3
Message-ID: <1219330369.36.0.854636494654.issue2402@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Brett has been doing this.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2402>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:53:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:53:35 +0000
Subject: [issue2764] c_char doesn't implement py3k buffer interface
In-Reply-To: <1209940505.31.0.9485811448.issue2764@psf.upfronthosting.co.za>
Message-ID: <1219330415.0.0.449209379983.issue2764@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ping

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2764>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:54:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:54:43 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1219330483.83.0.949358178287.issue2874@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2874>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:55:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:55:18 +0000
Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1219330518.68.0.787140538828.issue2501@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2501>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:56:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:56:11 +0000
Subject: [issue3002] shutil.copyfile blocks indefinitely on named pipes
In-Reply-To: <1212075150.42.0.761610345558.issue3002@psf.upfronthosting.co.za>
Message-ID: <1219330571.77.0.884360640965.issue3002@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3002>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:57:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:57:30 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1219330650.39.0.632779886719.issue2226@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:57:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:57:52 +0000
Subject: [issue2443] uninitialized access to va_list
In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za>
Message-ID: <1219330672.47.0.312267586036.issue2443@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2443>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:58:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:58:15 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1219330695.4.0.949336337928.issue3590@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3590>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:59:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:59:15 +0000
Subject: [issue2322] Clean up getargs.c and its formatting possibilities
In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
Message-ID: <1219330755.73.0.738182046841.issue2322@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2322>
_______________________________________

From report at bugs.python.org  Thu Aug 21 16:59:55 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 14:59:55 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1219323369.48ad65e94f011@imp.free.fr>
Message-ID: <200808211659.40281.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le Thursday 21 August 2008 14:55:43 Antoine Pitrou, vous avez ?crit?:
> >  * bytes parent class "class Filename(bytes): ..." -> that's the
> > current implementation
>
> I don't think that makes sense (especially under Windows which has Unicode
> file APIs). os.listdir() and friends should really return str or str-like
> objects, not bytes-like objects with an additional __str__ method.

In we use "class Filename(str): ...", we have to ensure that all operations 
takes care of the charset because the unicode version is invalid and not be 
used to access to the file system. Dummy example: Filename()+"/" should not 
return str but raise an error or create a new filename.

> Well, of course, if we create a filename type, then all os functions must
> be adapted to accept it rather than assume str.

If Filename has no parent class but is convertible to bytes(), os functions 
requires no change and so we can fix it before final 3.0 ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 17:09:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 15:09:21 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219331361.45.0.356158278326.issue3187@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If Filename has no parent class but is convertible to bytes(), os
> functions requires no change and so we can fix it before final 3.0 ;-)

This sounds highly optimistic.

Also, I think it's wrong to introduce a string-like class with implicit
conversion both to bytes and to str, while we have taken all measures to
make sure that bytes/str exchangeability doesn't exist any more in py3k.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 17:14:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 15:14:29 +0000
Subject: [issue2764] c_char doesn't implement py3k buffer interface
In-Reply-To: <1209940505.31.0.9485811448.issue2764@psf.upfronthosting.co.za>
Message-ID: <1219331669.07.0.736294139049.issue2764@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thomas, the bytes object is not broken anymore with respect to the
buffer API, but it depends which buffer API you are talking about :-) I
hope it is the new, 3.0 one.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2764>
_______________________________________

From report at bugs.python.org  Thu Aug 21 17:24:58 2008
From: report at bugs.python.org (Nick Edds)
Date: Thu, 21 Aug 2008 15:24:58 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1219332298.81.0.654583356675.issue2876@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I've been thinking about this a bit, and I don't see how handling it
should be all that different from handling module renaming. 

For import UserDict, we can just change UserDict to collections and deal
with UserDict.UserDict with a deprecation warning and
UserDict.IterableUserDict and UserDict.Mixin with transformations to
collections.UserDict and collections.MutableMapping.

For from imports, we can raise the deprecation warning on UserDict, and
otherwise change from UserDict import ... to from collections import ...
and then for non-import appearances of UserDict, IterableUserDict, and
Mixin rename or raise a deprecation warning as appropriate.

For the other import cases, similar things could be done.

I think the old version of fix_imports, which had support like this,
would basically be all that we need. I should be able to mimic that
functionality, but also make it more scalable than the previous version.

Is there something I'm missing here about the difference between modules
and classes? From the use-cases I've observed of UserDict, it seems like
this functionality would be sufficient.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Thu Aug 21 17:25:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 15:25:22 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1219332322.15.0.165222930437.issue2548@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For what it's worth, py3k has a subtler recursion checking algorithm
which would probably fix this problem if backported properly. See
_Py_CheckRecursiveCall() in ceval.c (lines 462+), and especially the
role played by the tstate->overflowed flag, which allows a moderate
overflow of the recursion count in order for error handling code to
execute properly.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Thu Aug 21 18:02:09 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 16:02:09 +0000
Subject: [issue3629] Py30b3 won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1219334529.51.0.410362943545.issue3629@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Duly accepted. (Though if someone has a quick fix I'd be open to it. :-)

----------
assignee:  -> gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Thu Aug 21 18:10:22 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 16:10:22 +0000
Subject: [issue3373] sys recursion limit a lot shorter on trunk?
In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za>
Message-ID: <1219335022.31.0.0257251000744.issue3373@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think it's fine as it is. Incrementing the stack level more frequently
is a good thing since there used to be paths that didn't increment it at
all and hence could cause segfaults.  The default is conservative since
increasing it could cause segfaults, and on some systems threads don't
get a very large stack.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3373>
_______________________________________

From report at bugs.python.org  Thu Aug 21 18:11:46 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 16:11:46 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1219335106.15.0.622790890087.issue1745@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This will definitely not be in 2.6.

----------
keywords:  -26backport

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Thu Aug 21 18:17:46 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 16:17:46 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219335466.91.0.576198067043.issue3187@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The proper work-around is for the app to pass bytes into os.listdir();
then it will return bytes.  It would be nice if open() etc. accepted
bytes (as well as strings of course), at least on Unix, but not
absolutely necessary -- the app could also just know the right encoding.

I see two reasonable alternatives for what os.listdir() should return
when the input is a string and one of the filenames can't be decoded:
either omit it from the output list; or use errors='replace' in the
encoding.  Failing the entire os.listdir() call is not acceptable, and
neither is returning a mixture of str and bytes instances.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 18:24:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 16:24:21 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1219335861.46.0.190698859869.issue3338@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the standard recursion limit is precisely there to guard against
segfaults when blowing up the C stack, so if you make the recursion
limit much larger, it's quite normal to get segfaults.

Therefore, I don't think this is a real bug.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Thu Aug 21 18:26:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 16:26:59 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219336019.69.0.338239992431.issue3611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug is not closed :-/ With py3k trunk, I still get a crash. So I 
added a flag to detect inner calls. Here is an example of inner call 
backtrace:

(gdb) where
(...)
#2  0xb7df4201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x080a23a9 in PyErr_SetObject (exception=0x818b760, 
value=0xb75a3694) at Python/errors.c:61
#4  0x08094048 in do_raise (exc=0xb75a3694, cause=0x0) at 
Python/ceval.c:2928
#5  0x0808fa70 in PyEval_EvalFrameEx (f=0x83557d4, throwflag=0) at 
Python/ceval.c:1510
(...)
#23 0x08094bd8 in PyEval_CallObjectWithKeywords (func=0xb7a6c96c, 
arg=0xb7c6802c, kw=0x0) at Python/ceval.c:3283
#24 0x0806befd in slot_tp_del (self=0xb759d44c) at 
Objects/typeobject.c:5268
(...)
#26 0x0811f05d in PyDict_Clear (op=0xb7595e84) at 
Objects/dictobject.c:846
#27 0x08121112 in dict_tp_clear (op=0xb7595e84) at 
Objects/dictobject.c:1841
#28 0x080c81e9 in delete_garbage (collectable=0xbfcc75c4, 
old=0x8179434) at Modules/gcmodule.c:684
(...)
#31 0x080c9000 in _PyObject_GC_Malloc (basicsize=28) at 
Modules/gcmodule.c:1333
#32 0x08060aee in PyType_GenericAlloc (type=0x818b0a0, nitems=0) at 
Objects/typeobject.c:667
(...)
#37 0x080a24cc in PyErr_SetObject (exception=0x818b0a0, 
value=0xb75acea0) at Python/errors.c:87
(...)
#44 0x080912f7 in PyEval_EvalFrameEx (f=0x83660e4, throwflag=0) at 
Python/ceval.c:1940
(...)

First Python stack:

(gdb) pystack
/home/haypo/prog/py3k/Lib/io.py (1074): _flush_unlocked
/home/haypo/prog/py3k/Lib/io.py (1070): flush
/home/haypo/prog/py3k/Lib/io.py (1454): flush
/home/haypo/prog/py3k/Lib/io.py (1459): close
/home/haypo/prog/py3k/Lib/io.py (390): __del__
/home/haypo/fusil3000/fusil/process/cpu_probe.py (30): live
/home/haypo/fusil3000/fusil/mas/univers.py (15): executeAgent
(...)

Second Python stack:

(gdb) pystack
/home/haypo/fusil3000/fusil/process/cpu_probe.py (30): live
/home/haypo/fusil3000/fusil/mas/univers.py (15): executeAgent
/home/haypo/fusil3000/fusil/mas/univers.py (24): execute
/home/haypo/fusil3000/fusil/application.py (196): executeProject
(...)

So the real fix is to make PyErr_SetObject() re-entrant.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 18:28:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 16:28:28 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219336108.09.0.05469119913.issue3611@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution: accepted -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 19:14:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 17:14:32 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219338872.52.0.177102829838.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

On a Windows box, I manage to make the following script reliably hang on
a non-debug build of beta3. This can be a good base for further diagnosing.


def f():
    class Bug:
        def __del__(self):
            1/0

    import gc
    trash = [Bug()]
    trash.append(trash)
    try:
        gc.collect()
        gc.set_threshold(1, 1, 1)
        del trash
        len()
    except TypeError:
        raise

if __name__ == "__main__":
    f()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 19:16:29 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 17:16:29 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219338989.6.0.223587694946.issue3611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a new snippet with strange exception handling:
--------------------- 8< -------------------------
from gc import collect
import _weakref

class FuzzingUserClass:
    pass

obj = _weakref.ref(FuzzingUserClass)

# Exception not raised??
obj.__init__(
    0,
    0,
    0,
)

# Exception catched here??
collect()
--------------------- 8< -------------------------

Result:
    Exception TypeError: '__init__ expected at most 2 arguments, 
    got 3' in 'garbage collection' ignored
    Fatal Python error: unexpected exception during garbage collection
    Abandon (core dumped)

The exception is raised in Objects/weakrefobject.c:
  weakref___init__() 
  => parse_weakref_init_args() 
  => PyArg_UnpackTuple() *here*

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 19:18:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 17:18:53 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219339133.75.0.60856152567.issue2415@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a patch. It's only implemented for bytes. Doing this for
bytearray would require a bit of refactoring, and can I think wait for
3.1. I added two new C functions. PyObject_Bytes and PyBytes_FromObject.
You can review it at http://codereview.appspot.com/3245.

----------
keywords: +patch
Added file: http://bugs.python.org/file11194/2415.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Thu Aug 21 19:19:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 17:19:33 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219339173.29.0.027216142869.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Haypo, this is a separate bug I think. Please open a new ticket :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 19:25:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 17:25:01 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

_weakref.__init__() doesn't catch errors correctly. Example:
--------------------- 8< -------------------------
from gc import collect
import _weakref

class FuzzingUserClass:
    pass

obj = _weakref.ref(FuzzingUserClass)

# Exception not raised??
obj.__init__(
    0,
    0,
    0,
)

# Exception catched here??
collect()
--------------------- 8< -------------------------

Attached patch fix the bug for py3k branch: return -1 on error 
(instead of 1).

----------
components: Library (Lib)
files: weakref_init.patch
keywords: patch
messages: 71662
nosy: haypo
severity: normal
status: open
title: invalid result value of _weakref.__init__()
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11195/weakref_init.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Thu Aug 21 19:25:51 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 17:25:51 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219339551.45.0.941663023829.issue3611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@pitrou: Ok, done (issue #3634). We were right, it's a different bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 19:43:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Aug 2008 17:43:48 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219340628.49.0.22316701036.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Antoine, your script hangs at the end due to the io.py deadlock (see #3618)

- at the end of the script, flush_io() is called
- this enters code in io.py
- here, garbage collection occurs (thanks to low thresholds)
- the Bug() instance is collected
- the exception is handled by a PyErr_WriteUnraisable
- which tries to print

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:18:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Aug 2008 18:18:13 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219342693.61.0.948508691155.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I found another way to loose the current exception context; see
lostcontext2.py

Completely removing the block starting with
       if (why == WHY_EXCEPTION && !throwflag) {
corrects the script;

but according to Benjamin: """removing those lines causes a RuntimeError
about exceeding the recursion limit for about 1/3 of the tests."""

So a better fix must be found. At least we have the unit test :-).

Added file: http://bugs.python.org/file11196/lostcontext2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:21:10 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:21:10 +0000
Subject: [issue2356] sys.exitfunc should raise a Py3K warning
In-Reply-To: <1219326197.36.0.703474292041.issue2356@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808211121p16b8ffdby183124d8b209b987@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Aug 21, 2008 at 6:43 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> This is going to be very hard to implement without module descriptors.
> It might be better to make a 2to3 fixer which inserts an import too.
>

So for every sys import you are going to add an "import atexit"? That
doesn't seem reasonable. And if the call is in an expression context
you definitely cannot add the import.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:33:03 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:33:03 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1219343583.2.0.693789043857.issue2876@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

As I said, it isn't using the import filter, it's whether this should be
done through a warning instead because the superclasses have changed.

I really should ask on python-dev about this.

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:34:27 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:34:27 +0000
Subject: [issue2350] Warn against importing 'exceptions'
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1219343667.45.0.630390244883.issue2350@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:34:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:34:39 +0000
Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning
In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
Message-ID: <1219343679.73.0.923757859202.issue2351@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:34:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:34:56 +0000
Subject: [issue2357] sys.exc_{type,values,traceback} needs a 2to3 fixer
In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za>
Message-ID: <1219343696.55.0.780844030277.issue2357@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2357>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:35:05 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:35:05 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219343705.89.0.0997942767039.issue3602@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:35:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:35:15 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1219343715.01.0.399127360082.issue3594@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3594>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:35:23 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:35:23 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219343723.84.0.145474545398.issue3574@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:45:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 18:45:17 +0000
Subject: [issue2356] sys.exitfunc should raise a Py3K warning
In-Reply-To: <bbaeab100808211121p16b8ffdby183124d8b209b987@mail.gmail.com>
Message-ID: <1afaf6160808211145t1f5d2ab4i7fce0c43fcd2a12c@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Thu, Aug 21, 2008 at 1:21 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> So for every sys import you are going to add an "import atexit"? That
> doesn't seem reasonable. And if the call is in an expression context
> you definitely cannot add the import.

You're right; it's not going to be perfect, but 2to3 could warn when
it couldn't insert the import statement.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2356>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:49:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:49:20 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1219344560.73.0.283998521382.issue2876@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You know what, Nick, go for the fixer. UserDict.UserDict will need a
deprecation warning, but otherwise a fixer for IterableUserDict and
DictMixin is fine.

And I can handle the deprecation if you want.

----------
assignee: collinwinter -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Thu Aug 21 20:51:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 18:51:36 +0000
Subject: [issue2356] sys.exitfunc should raise a Py3K warning
In-Reply-To: <1afaf6160808211145t1f5d2ab4i7fce0c43fcd2a12c@mail.gmail.com>
Message-ID: <bbaeab100808211151g5fd93e0du17ad67f96775024d@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Aug 21, 2008 at 11:45 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> On Thu, Aug 21, 2008 at 1:21 PM, Brett Cannon <report at bugs.python.org> wrote:
>>
>> So for every sys import you are going to add an "import atexit"? That
>> doesn't seem reasonable. And if the call is in an expression context
>> you definitely cannot add the import.
>
> You're right; it's not going to be perfect, but 2to3 could warn when
> it couldn't insert the import statement.
>>

OK, I can live with that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Thu Aug 21 21:05:40 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 21 Aug 2008 19:05:40 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219345540.17.0.663278348054.issue1342811@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
keywords: +needs review -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Thu Aug 21 21:06:22 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 21 Aug 2008 19:06:22 +0000
Subject: [issue3573] IDLE hangs when passing invalid command line args
	(directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1219345582.39.0.973422720657.issue3573@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
keywords: +needs review -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________

From report at bugs.python.org  Thu Aug 21 21:21:40 2008
From: report at bugs.python.org (Michael Yang)
Date: Thu, 21 Aug 2008 19:21:40 +0000
Subject: [issue3635] pickle.dumps cannot save instance of dict-derived class
	that overrides __getattribute__
In-Reply-To: <1219346500.78.0.74794831892.issue3635@psf.upfronthosting.co.za>
Message-ID: <1219346500.78.0.74794831892.issue3635@psf.upfronthosting.co.za>


New submission from Michael Yang <yangofzeal at gmail.com>:

# pickle.dumps is not able to process an instance of
# a class that inherits from 'dict' and
# overrides the built-in __getattribute__ method
# but can successfully process one that 
# overrides the__getattr__ method

>>> class Examp1(dict):
...   def __getattr__(self,name):
...     return self[name]
... 
>>> class Examp2(dict):
...   def __getattribute__(self,name):
...     return self[name]
... 
>>> ex1 = Examp1()
>>> ex2 = Examp2()
>>> ex1['aKey'] = (3,4)
>>> ex2['aKey2'] = (4,5)
>>> ex1
{'aKey': (3, 4)}
>>> ex1.aKey
(3, 4)
>>> ex2
{'aKey2': (4, 5)}
>>> ex2.aKey2
(4, 5)
>>> import pickle
>>> pickle.dumps(ex1)
b'\x80\x03c__main__\nexamp1\nq\x00)\x81q\x01X\x04\x00\x00\x00aKeyq\x02K\x03K\x04\x86q\x03s}q\x04b.'
>>> pickle.dumps(ex2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[hidden]/python3/3.0b2/common/lib/python3.0/pickle.py", line
1319, in dumps
    Pickler(f, protocol).dump(obj)
  File "<stdin>", line 3, in __getattribute__
KeyError: '__reduce_ex__'

----------
components: Extension Modules
messages: 71671
nosy: msyang
severity: normal
status: open
title: pickle.dumps cannot save instance of dict-derived class that overrides __getattribute__
type: behavior
versions: Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3635>
_______________________________________

From report at bugs.python.org  Thu Aug 21 21:52:42 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 19:52:42 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219348362.84.0.0469624691979.issue3633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for the test-suite to get more information about where 
float.fromhex is failing.  Could someone else please review this quickly 
so that I can check it in?  It shouldn't take more than a few minutes to 
review.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11197/issue3633_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 21:55:49 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 19:55:49 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1219348549.17.0.403822029929.issue3419@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3419>
_______________________________________

From report at bugs.python.org  Thu Aug 21 21:55:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 19:55:51 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219348551.89.0.851906319111.issue3633@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

That looks fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:05:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 20:05:04 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219349104.86.0.436630647309.issue1342811@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think the new patch looks fine and should be applied.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:09:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 20:09:00 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219349340.08.0.703238222637.issue3633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Benjamin!  Change to test committed in r65958, merged to py3k in 
r65959.  Time to watch the py3k solaris buildbot.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:24:25 2008
From: report at bugs.python.org (richard_b_martin)
Date: Thu, 21 Aug 2008 20:24:25 +0000
Subject: [issue3636] Managing dual 2.x and 3.0 installations on Windows
In-Reply-To: <1219350265.84.0.067322027975.issue3636@psf.upfronthosting.co.za>
Message-ID: <1219350265.84.0.067322027975.issue3636@psf.upfronthosting.co.za>


New submission from richard_b_martin <martin at ambric.com>:

I installed a 3.0 beta for the first time in Windows.  I was surprised
when my 2.5 scripts started to fail.  I traced it down to the 3.0
install modifying the registry.  

If you run "assoc .py" from a command line, the return value is
Python.File.  If you search the registry for references to Python.File,
you'll find a path that points to python.exe.   The 3.0 install changed
this value.  

So at least a warning in the installation instructions would be nice. 
Probably better would be a script that allow a user to switch between
2.x and 3.0 installations.  That would include having to perhaps modify
the env. variables, Path and PYTHONPATH (see bug 2375) and the registry.

Many thanks, by the way, to all the python developers over the years.

----------
assignee: georg.brandl
components: Documentation
messages: 71676
nosy: georg.brandl, richard_b_martin
severity: normal
status: open
title: Managing dual 2.x and 3.0 installations on Windows
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3636>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:28:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 20:28:59 +0000
Subject: [issue3573] IDLE hangs when passing invalid command line args
	(directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1219350539.13.0.920625329117.issue3573@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:33:03 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 20:33:03 +0000
Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning
In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
Message-ID: <1219350783.9.0.711712672966.issue2351@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:33:23 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 20:33:23 +0000
Subject: [issue2357] sys.exc_{type,values,traceback} needs a 2to3 fixer
In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za>
Message-ID: <1219350803.3.0.358849657458.issue2357@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2357>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:33:41 2008
From: report at bugs.python.org (Piotr Findeisen)
Date: Thu, 21 Aug 2008 20:33:41 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1219350821.16.0.848573229931.issue3445@psf.upfronthosting.co.za>


Piotr Findeisen <piotr.findeisen at gmail.com> added the comment:

IMO, I'd be better to always ignore missing attributes. Consider another
use case (following code I've posted also on comp.lang.python):

from functools import wraps, partial
def never_throw(f):
    @wraps(f)
    def wrapper(*args, **kwargs):
        try: return f(*args, **kwargs)
        except: pass
    return wrapper 

Looks reasonable. But if I write
never_throw(partial(int))('45a')
I got the exception saying partial objects also don't have __module__
attribute.

I was to use some additional parameters to @wraps, I would have to
rewrite all my decorator definitions. And stil -- the main intent of
wraps and update_wrapper is to write decorators, so IMO they should not
throw on missing attributes.

----------
nosy: +findepi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:33:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 20:33:50 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1219350830.53.0.763834037315.issue3594@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3594>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:33:57 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 20:33:57 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219350837.94.0.99298288108.issue3574@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:35:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 20:35:50 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219350950.88.0.175596930433.issue2415@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:46:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 20:46:16 +0000
Subject: [issue3637] 2to3 refactoring
In-Reply-To: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>
Message-ID: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

The attached patch moves cmdline processing logic out of RefactoringTool
and into its own module lib2to3.main. Guido and Collin: If you could
review this (it's on Rietveld [1]) sometime soon, I can check this in
and start writing the API docs for 2to3.

Thanks.

[1] http://codereview.appspot.com/3247

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_refactoring.patch
keywords: patch
messages: 71678
nosy: benjamin.peterson, collinwinter, gvanrossum
severity: normal
status: open
title: 2to3 refactoring
type: feature request
Added file: http://bugs.python.org/file11198/2to3_refactoring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3637>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:52:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 20:52:08 +0000
Subject: [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1219351928.22.0.73203173638.issue3628@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This should be changed in 2.6 as well (from sockthread.setDaemon(True) to 
sockthread.daemon = True).

By the way, I notice that there are also used of setDaemon, isDaemon, 
getName and setName in Lib/multiprocessing/dummy/__init__.py;  these 
should probably also be replaced.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3628>
_______________________________________

From report at bugs.python.org  Thu Aug 21 22:55:34 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 20:55:34 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1219335466.91.0.576198067043.issue3187@psf.upfronthosting.co.za>
Message-ID: <200808212255.18585.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le Thursday 21 August 2008 18:17:47 Guido van Rossum, vous avez ?crit?:
> The proper work-around is for the app to pass bytes into os.listdir();
> then it will return bytes.

In my case, I just would like to remove a directory with shutil.rmtree(). I 
don't know if it contains bytes or characters filenames :-)

> It would be nice if open() etc. accepted 
> bytes (as well as strings of course), at least on Unix, but not
> absolutely necessary -- the app could also just know the right encoding.

An invalid filename has no charset. It's just a "raw" byte string. So open(), 
unlink(), etc. have to accept byte string. Maybe not in the Python version 
with in low level (C version)?

> I see two reasonable alternatives for what os.listdir() should return
> when the input is a string and one of the filenames can't be decoded:
> either omit it from the output list;

It's not a good option: rmtree() will fails because the directory in not 
empty :-/

> or use errors='replace' in the encoding.

It will also fails because filenames will be invalid (valid unicode string but 
non existent file names :-/).

> Failing the entire os.listdir() call is not acceptable, and 
> neither is returning a mixture of str and bytes instances.

Ok, I have another suggestion:
 - *by default*, listdir() only returns str and raise an error (TypeError?) 
   on invalid filename
 - add an optional argument (a callback), eg. "fallback_encoder", to catch
   such errors (similar to "onerror" from shutils.rmtree())

Example of new listdir implementation (pseudo-code):

   charset = sys.getfilesystemcharset()
   dirobj = opendir(path)
   try:
      for bytesname in readdir(dirobj):
          try:
              name = str(bytesname, charset)
          exept UnicodeDecodeError:
              name = fallback_encoder(bytesname)
          yield name
   finally:
      closedir(dirobj)

The default fallback_encoder:

   def fallback_encoder(name):
      raise

Keep raw bytes string:

   def fallback_encoder(name):
      return name

Create my custom filename object:

   class Filename:
      ...

   def fallback_encoder(name):
      return Filename(name)

If a callback is overkill, we can just add an option, 
eg. "keep_invalid_filename=True", to ask listdir() to keep bytes string if 
the conversion to unicode fails.

In any case, open(), unlink(), etc. have to accept byte string to be accept to 
read, copy, remove invalid filenames. In a perfect world, all filenames would 
be valid UTF-8 strings, but in the real world (think to Matrix :-)), we have 
to support such strange cases...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:12:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 21:12:29 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219353149.26.0.688636164101.issue3633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The problem appears to be that on Solaris, the isxdigit function (which 
is supposed to check whether a character is a valid hex digit) returns 
true for Unicode fullwidth digits.  On other systems I have access to, 
isxdigit just returns true for the ASCII hex digits, and you use the C99 
iswxdigit function if you want to allow other Unicode digits.

One could argue that these fullwidth digits should be permitted, but I 
don't know any quick way to convert a unicode digit to its value.  For 
now, it just seems simplest to replace the isxdigit call with an 
explicit check for the ASCII 7-bit characters '0' through '9', 'a' 
through 'f'.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:12:31 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 21 Aug 2008 21:12:31 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1219272735.73.0.805807230774.issue1589@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0808211412h28a6ca1bpda2a513d7500466c@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

checking hostnames is false security, not real security.

On 8/20/08, Heikki Toivonen <report at bugs.python.org> wrote:
>
>  Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:
>
>
> I would think most people/applications want to know to which host they
>  are talking to. The reason I am advocating adding a default check to the
>  stdlib is because this is IMO important for security, and it is easy to
>  get it wrong (I don't think I have it 100% correct in M2Crypto either,
>  although I believe it errs on the side of caution). I believe it would
>  be a disservice to ship something that effectively teaches developers to
>  ignore security (like the old socket.ssl does).
>
>  A TLS extension also allows SSL vhosts, so static IPs are no longer
>  strictly necessary (this is not universally supported yet, though).
>
>
>  _______________________________________
>  Python tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue1589>
>  _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:14:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 21:14:45 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219353149.26.0.688636164101.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219353283.5666.2.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 21 ao?t 2008 ? 21:12 +0000, Mark Dickinson a ?crit :
> For now, it just seems simplest to replace the isxdigit call with an 
> explicit check for the ASCII 7-bit characters '0' through '9', 'a' 
> through 'f'.

+1
I don't think it makes a lot of sense to support full width unicode
digits. Hex representation is quite specialized, it won't be produced by
casual users.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:22:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 21:22:24 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219353744.52.0.617334105841.issue2415@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Isn't it a new feature and, therefore, should wait for 3.1?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:26:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 21:26:44 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219354004.46.0.238314472976.issue3633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.  I'm reasonably confident that this should fix the 
problem, but I don't have a Solaris machine to test it on.

If anyone can check this on Solaris that would be fantastic, but I'll 
settle for a 'looks okay to me' from another core developer.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:27:18 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 21:27:18 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219354038.39.0.382870191831.issue3633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

...and here's the actual patch!

Added file: http://bugs.python.org/file11199/issue3633.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:31:45 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 21:31:45 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219354305.65.0.864885870468.issue3633@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:32:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 21:32:40 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219354360.29.0.624041238283.issue2415@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Well, yes I suppose. However, I think it's a serious enough deficiency
that it should block. I'll let Barry decide, though.

----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:32:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Aug 2008 21:32:42 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219354004.46.0.238314472976.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219354359.5666.7.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 21 ao?t 2008 ? 21:26 +0000, Mark Dickinson a ?crit :
> Here's a patch.  I'm reasonably confident that this should fix the 
> problem, but I don't have a Solaris machine to test it on.
> 
> If anyone can check this on Solaris that would be fantastic, but I'll 
> settle for a 'looks okay to me' from another core developer.

Looks okay to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:45:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Aug 2008 21:45:14 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219355114.96.0.605121010449.issue3633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Antoine.  Committed, r65964 (2.6) and r65965 (3.0).  Setting 
status to pending;  will close if/when the Solaris buildbot goes green.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Thu Aug 21 23:52:45 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Thu, 21 Aug 2008 21:52:45 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219355565.87.0.301639756106.issue3626@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

Thank you, that fixes that issue.  But further along the build fails:

Traceback (most recent call last):
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/setup.py",
line 1569, in <module>
    class PyBuildInstallLib(install_lib):
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/setup.py",
line 1575, in PyBuildInstallLib
    so_ext = sysconfig.get_config_var("SO")
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/distutils/sysconfig.py",
line 552, in get_config_var
    return get_config_vars().get(name)
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/distutils/sysconfig.py",
line 491, in get_config_vars
    func()
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/distutils/sysconfig.py",
line 360, in _init_posix
    parse_makefile(filename, g)
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/distutils/sysconfig.py",
line 272, in parse_makefile
    line = fp.readline()
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/distutils/text_file.py",
line 173, in readline
    line = self.file.readline()
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/io.py",
line 1751, in readline
    decoder = self._decoder or self._get_decoder()
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/io.py",
line 1501, in _get_decoder
    make_decoder = codecs.getincrementaldecoder(self._encoding)
  File
"/usr/src/ports/python/python3.0/python3.0-3.0b3-1/src/Python-3.0b3/Lib/codecs.py",
line 960, in getincrementaldecoder
    decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: U
make: *** [sharedmods] Error 1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:00:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 22:00:14 +0000
Subject: [issue3638] tkinter.mainloop() is meanling less and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

mainloop() is a method of a Tkapp object, but it's also a method of 
_tkinter module. In TkApp_MainLoop, self is seen as a TkappObject 
whereas it can be a module object! So instruction 
like "self->dispatch=1" will replace a random byte in the module 
object (eg. ob_type attribute). Example to crash:
  import gc
  import _tkinter
  _tkinter.mainloop()
  gc.collect()

It always crashs in my Python 3.0, but not in Python 2.6.

Solution: just remove _tkinter.mainloop() => it should have no side 
effect since users use tkinter (without the "_") which only uses 
Tkapp.mainloop() (the right way to use Tkapp_MainLoop() function). 
Solution "implemented" in the patch.

----------
components: Library (Lib)
files: tkinter_remove_mainloop.patch
keywords: patch
messages: 71691
nosy: haypo
severity: normal
status: open
title: tkinter.mainloop() is meanling less and crash: remove it
type: crash
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11200/tkinter_remove_mainloop.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:06:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 22:06:50 +0000
Subject: [issue2366] Fixer for new metaclass syntax is needed
In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
Message-ID: <1219356410.08.0.584859164031.issue2366@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Good work on the patch! It looks pretty good. I'm attaching a patch with
a few minor changes. I don't really understand the need for
fixup_parse_tree, since I see in the Grammar that a suite is required
for every classdef.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:22:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 22:22:41 +0000
Subject: [issue2431] 2to3 is rather slow
In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za>
Message-ID: <1219357361.7.0.511869273514.issue2431@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think we can safely say this has been fixed especially with regards to
fix_imports. Thanks to Nick Edds! It only takes me about 3 seconds to
process the example file.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2431>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:24:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 22:24:06 +0000
Subject: [issue2012] Add migration step for DictMixin ->
	collections.MutableMapping
In-Reply-To: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>
Message-ID: <1219357446.31.0.490016269864.issue2012@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Write UserDict fixer for 2to3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2012>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:27:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 22:27:30 +0000
Subject: [issue3182] 2to3 Slight Patch
In-Reply-To: <1214241944.19.0.631532213789.issue3182@psf.upfronthosting.co.za>
Message-ID: <1219357650.93.0.882934825798.issue3182@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3182>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:30:27 2008
From: report at bugs.python.org (Lisandro Dalcin)
Date: Thu, 21 Aug 2008 22:30:27 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>


New submission from Lisandro Dalcin <dalcinl at gmail.com>:

from warnings import warn

warn("hello world") # -> Success
warn(UserWarning)   # -> Segmentation fault
warn(None)          # -> Segmentation fault
warn(1)             # -> Segmentation fault

----------
components: Interpreter Core
messages: 71694
nosy: dalcinl
severity: normal
status: open
title: segfaults calling warnings.warn() with non-string message
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:30:44 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Aug 2008 22:30:44 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1219357844.78.0.940869523339.issue3445@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If the object being wrapped isn't a plain vanilla function, then the
odds are *very* good that __doc__ cannot be copied to the new function
and still be correct. This is definitely the case for both modules and
partial objects.

So for both the use cases mentioned thus far, the AttributeError appears
to me to be flagging a real problem with the way update_wrapper is being
used.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Fri Aug 22 00:32:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 22:32:11 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219357931.56.0.757391674268.issue3639@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:20:44 2008
From: report at bugs.python.org (Tony Wallace)
Date: Thu, 21 Aug 2008 23:20:44 +0000
Subject: [issue3107] test_list uses unreasonable amounts of memory on 64-bit
	Linux
In-Reply-To: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>
Message-ID: <1219360844.12.0.848606545607.issue3107@psf.upfronthosting.co.za>


Tony Wallace <hushp1pt at yahoo.com> added the comment:

It worked- I took a patch of r65334, as 
 svn diff -c 65334
"http://svn.python.org/projects/python/branches/release25-maint"

and applied that patch ONLY to a clean release 2.5.2 source, ignoring
the patch failure in Misc/NEWS.  Built it all over again the same as
before (that is, 
 CentOS release 4.4 (Final)
 Linux manfred 2.6.9-42.0.8.ELsmp #1 SMP Tue Jan 30 12:18:01 EST 2007
x86_64 x86_64 x86_64 GNU/Linux 
 ./configure --prefix=/home/tools/sqa/amd64_rhel4/Python-2.5.2
--enable-shared  --build=x86_64-redhat-linux --enable-static )

Now, make test runs all the way through with no difficulty. 

Thanks, everyone.  I consider this closed.  Maintainer, please dispose
this bug as you think appropriate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3107>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:21:43 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 23:21:43 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

[from python-dev]
I've found a recursion related crash in test_cpickle on 64bit builds. 
Specifically, the 'cPickleDeepRecursive' is causing a stack overflow,
and the debugger tells me the actual recursion depth was 629 at the crash.

The reason the 64bit build doesn't see more crashes is apparently due to
another regression in 2.6 - http://bugs.python.org/issue3373.  It
appears that in some cases, the recursion counter is actually
incremented *twice* for each entry, thereby causing the "maximum
recursion depth exceeded" exception to appear at a true recursion limit
of 500.  However, test_cpickle takes a different path and doesn't see
this doubling of the count - therefore dieing at the depth of 629 that I
can see.

My solution to this was to simply double the stack size for the
executables in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug
builds.)  Is this an appropriate fix?

----------
components: Tests
messages: 71697
nosy: mhammond, pitrou
severity: normal
status: open
title: test_cpickle crash on AMD64 Windows build
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:22:00 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 23:22:00 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219360920.43.0.816501422098.issue3640@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


----------
assignee:  -> mhammond
keywords: +64bit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:26:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 23:26:21 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219361181.01.0.516081202164.issue3611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's now known that PyErr_SetObject() have to be re-entrant because of 
the garbage collector interaction. As I wrote in my comments, tstate 
may be changed during PyEval_CallObject() call. The problem is to 
known which values have to be protected during PyErr_SetObject() 
re-entrant call... I tried to save/restore tstate->exc_value if it's 
value changes, but I'm not sure that it's enough.

Added file: http://bugs.python.org/file11201/pyerr_setobject_reentrant.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:31:58 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 23:31:58 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219361518.85.0.279111555392.issue3187@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

So shutil should be fixed to pass a bytes value to os.listdir().  But
then os.remove() should be fixed to accept bytes as well.  This is the
crux I believe: on Unix at least, syscall wrappers should accept bytes
for filenames.  And this would then have to be extended to things like
the functions in os.path, and we'd need bytes versions of os.sep and
os.altsep...  This sounds like a good project for 3.1.

I do not accept an os.listdir() that raises an error because one
filename cannot be decoded.  It sounds like using errors='replace' is
also wrong -- so the only solution is for os.listdir() to skip files it
cannot decode.  While this doesn't help for rmtree(), it is better than
errors='replace' for code that descends into the tree looking for files
matching a pattern or other property.  So I propose this as a patch for 3.0.

The callback variant is too complex; you could write it yourself by
using os.listdir() with a bytes argument.  This also applies to
proposals like passing optional encoding and errors arguments to
os.listdir().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:35:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 23:35:52 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1219361518.85.0.279111555392.issue3187@psf.upfronthosting.co.za>
Message-ID: <1afaf6160808211635u7646decfx59382760312ca619@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Thu, Aug 21, 2008 at 6:31 PM, Guido van Rossum
<report at bugs.python.org> wrote:
>
> Guido van Rossum <guido at python.org> added the comment:
>
> So shutil should be fixed to pass a bytes value to os.listdir().  But
> then os.remove() should be fixed to accept bytes as well.  This is the
> crux I believe: on Unix at least, syscall wrappers should accept bytes
> for filenames.  And this would then have to be extended to things like
> the functions in os.path, and we'd need bytes versions of os.sep and
> os.altsep...  This sounds like a good project for 3.1.
>
> I do not accept an os.listdir() that raises an error because one
> filename cannot be decoded.  It sounds like using errors='replace' is
> also wrong -- so the only solution is for os.listdir() to skip files it
> cannot decode.  While this doesn't help for rmtree(), it is better than
> errors='replace' for code that descends into the tree looking for files
> matching a pattern or other property.  So I propose this as a patch for 3.0.

As much as this maybe the right idea, I don't like the idea of
silently losing the contents of a directory. That's asking for
difficult to discover bugs. Could Python emit a warning in this case?
>
> The callback variant is too complex; you could write it yourself by
> using os.listdir() with a bytes argument.  This also applies to
> proposals like passing optional encoding and errors arguments to
> os.listdir().
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3187>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:40:04 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 23:40:04 +0000
Subject: [issue3625] test issues on 64bit windows
In-Reply-To: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>
Message-ID: <1219362004.09.0.549499961784.issue3625@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I forgot about sys.maxsize - that makes things much cleaner, and even
means I don't need to skip the check for insane amounts of memory.

If you think this is OK, please also specifically say if you approve for
me to check it into trunk for 2.6.  Thanks.

Added file: http://bugs.python.org/file11202/win64_test_failures.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3625>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:41:59 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Aug 2008 23:41:59 +0000
Subject: [issue3107] test_list uses unreasonable amounts of memory on 64-bit
	Linux
In-Reply-To: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>
Message-ID: <1219362119.19.0.870503314986.issue3107@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

It looks like I made a dupe at http://bugs.python.org/issue3625, where I
reported the same thing on 64bit windows (and 2 other cases that I'd be
interested to know if cause problems for you too...)

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3107>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:45:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Aug 2008 23:45:23 +0000
Subject: [issue2357] sys.exc_{type,values,traceback} needs a 2to3 fixer
In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za>
Message-ID: <1219362323.49.0.773874917094.issue2357@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the work, Jeff! I reviewed the fixer, changed a few things,
added a few more tests, and committed it in r65968.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2357>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:54:23 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Aug 2008 23:54:23 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219362863.43.0.588033821395.issue3611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, it was not enough: exc_{type,value,traceback} have to be 
saved/restored. So here is a new patch. I doesn't change Python 
behaviour for previous pitrou snippet (msg71658): it doesn't crash 
here and display two errors.

I think that this issue mix differents bugs:
 (1) lostcontext.py fixed by ? if (why == WHY_EXCEPTION 
&& !throwflag) ?
 (2) pitrou snippet
 (3) PyErr_SetObject() is no re-entrant: not fixed yet (please review 
my new patch attached to this comment ;-))

Added file: http://bugs.python.org/file11203/pyerr_setobject_reentrant-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 22 01:59:09 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 23:59:09 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1afaf6160808211635u7646decfx59382760312ca619@mail.gmail.com>
Message-ID: <ca471dc20808211658q739d72d5p7afae281f71324e2@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

>> I do not accept an os.listdir() that raises an error because one
>> filename cannot be decoded.  It sounds like using errors='replace' is
>> also wrong -- so the only solution is for os.listdir() to skip files it
>> cannot decode.  While this doesn't help for rmtree(), it is better than
>> errors='replace' for code that descends into the tree looking for files
>> matching a pattern or other property.  So I propose this as a patch for 3.0.
>
> As much as this maybe the right idea, I don't like the idea of
> silently losing the contents of a directory. That's asking for
> difficult to discover bugs.

Well, the other approaches also cause difficult to discover bugs (the
original bug report here was an example :-).

> Could Python emit a warning in this case?

This may be the best compromise yet. It would have to use the warnings
module so that you could disable it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 02:15:33 2008
From: report at bugs.python.org (Lee Cantey)
Date: Fri, 22 Aug 2008 00:15:33 +0000
Subject: [issue1001604] glob doesn't return unicode with no dir in unicode
	filename
Message-ID: <1219364133.21.0.878156943893.issue1001604@psf.upfronthosting.co.za>


Lee Cantey <lcantey at gmail.com> added the comment:

2.5.1 (r251:54863, Jul 10 2008, 17:24:48)

Fails for me with 2.5.1 on Linux, OS X, and Windows.

>>> glob.glob("*")
['t.txt', 't\xd0\xb4.txt', 't\xe2\xbd\x94.txt']
>>> glob.glob(u"*")
['t.txt', 't\xd0\xb4.txt', 't\xe2\xbd\x94.txt']
>>> glob.glob(u"./*")
[u'./t.txt', u'./t\u0434.txt', u'./t\u2f54.txt']

----------
components: +Library (Lib) -None
nosy: +lcantey
type:  -> behavior
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1001604>
_______________________________________

From report at bugs.python.org  Fri Aug 22 02:17:09 2008
From: report at bugs.python.org (Lee Cantey)
Date: Fri, 22 Aug 2008 00:17:09 +0000
Subject: [issue1777458] glob doesn't return unicode with unicode parameter
Message-ID: <1219364229.15.0.438654659159.issue1777458@psf.upfronthosting.co.za>


Lee Cantey <lcantey at gmail.com> added the comment:

Updated original report with the following:

2.5.1 (r251:54863, Jul 10 2008, 17:24:48)

Fails for me with 2.5.1 on Linux, OS X, and Windows.

>>> glob.glob("*")
['t.txt', 't\xd0\xb4.txt', 't\xe2\xbd\x94.txt']
>>> glob.glob(u"*")
['t.txt', 't\xd0\xb4.txt', 't\xe2\xbd\x94.txt']
>>> glob.glob(u"./*")
[u'./t.txt', u'./t\u0434.txt', u'./t\u2f54.txt']

----------
nosy: +lcantey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777458>
_______________________________________

From report at bugs.python.org  Fri Aug 22 02:19:55 2008
From: report at bugs.python.org (tav)
Date: Fri, 22 Aug 2008 00:19:55 +0000
Subject: [issue3641] Builtin ascii() function from future_builtins includes
	leading "u" of unicode strings
In-Reply-To: <1219364395.89.0.296676765919.issue3641@psf.upfronthosting.co.za>
Message-ID: <1219364395.89.0.296676765919.issue3641@psf.upfronthosting.co.za>


New submission from tav <tav at espians.com>:

Perhaps I misunderstood the intended behaviour of the ascii() builtin in 
the future_builtins module, but the following behaviour is unexpected:

  >>> from __future__ import unicode_literals
  >>> from future_builtins import ascii

  >>> test = 'hello'

  >>> ascii(test)
  "u'hello'"

Surely the leading 'u' should not be there?

After all, this is a future builtin we are importing -- when all 
'strings' are unicode by default?

----------
components: Library (Lib)
messages: 71708
nosy: tav
severity: normal
status: open
title: Builtin ascii() function from future_builtins includes leading "u" of unicode strings
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3641>
_______________________________________

From report at bugs.python.org  Fri Aug 22 02:27:18 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 22 Aug 2008 00:27:18 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219364838.74.0.727610676744.issue3639@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Two small clues.

First, a backtrace:

#0  0xb7df102a in strcmp () from /lib/tls/i686/cmov/libc.so.6
#1  0x0809e678 in warn_explicit (category=0x81dd140, message=0xb7ac58f4,
filename=0xb7acced0, lineno=1, module=0xb7f53300,
    registry=0xb7ac9e94, sourceline=0x0) at Python/_warnings.c:393
#2  0x0809f1df in do_warn (message=0x81fbd78, category=0x81dd140,
stack_level=1) at Python/_warnings.c:606
#3  0x0809f37d in warnings_warn (self=0xb7aceab4, args=0xb7af0a7c,
kwds=0x0) at Python/_warnings.c:628
#4  0x081624ee in PyCFunction_Call (func=0xb7acace4, arg=0xb7af0a7c,
kw=0x0) at Objects/methodobject.c:84
#5  0x080b3633 in call_function (pp_stack=0xbfd51f44, oparg=1) at
Python/ceval.c:3403
#6  0x080ae776 in PyEval_EvalFrameEx (f=0x82b5e6c, throwflag=0) at
Python/ceval.c:2205
#7  0x080b1ac8 in PyEval_EvalCodeEx (co=0xb7ade988, globals=0xb7f4f5d4,
locals=0xb7f4f5d4, args=0x0, argcount=0, kws=0x0,
    kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2840
#8  0x080a686f in PyEval_EvalCode (co=0xb7ade988, globals=0xb7f4f5d4,
locals=0xb7f4f5d4) at Python/ceval.c:519
#9  0x080df486 in run_mod (mod=0x82ba910, filename=0x81a09e4 "<stdin>",
globals=0xb7f4f5d4, locals=0xb7f4f5d4,
    flags=0xbfd52370, arena=0x8216df8) at Python/pythonrun.c:1553
#10 0x080dd67e in PyRun_InteractiveOneFlags (fp=0xb7ec7440,
filename=0x81a09e4 "<stdin>", flags=0xbfd52370)
    at Python/pythonrun.c:958
#11 0x080dd1e0 in PyRun_InteractiveLoopFlags (fp=0xb7ec7440,
filename=0x81a09e4 "<stdin>", flags=0xbfd52370)
    at Python/pythonrun.c:870
#12 0x080dd038 in PyRun_AnyFileExFlags (fp=0xb7ec7440,
filename=0x81a09e4 "<stdin>", closeit=0, flags=0xbfd52370)
    at Python/pythonrun.c:839
#13 0x080ef6ba in Py_Main (argc=1, argv=0xb7f22028) at Modules/main.c:592
#14 0x0805a689 in main (argc=1, argv=0xbfd534c4) at ./Modules/python.c:57


Then, this behavior:
Python 3.0b3+ (py3k:65930M, Aug 21 2008, 21:23:08)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _warnings
[40709 refs]
>>> _warnings.warn(0)
__main__:1: UserWarning: 0
[40739 refs]
>>> _warnings.warn(12345)
__main__:1: UserWarning: 12345
[40744 refs]
>>> _warnings.warn(AttributeError)
__main__:1: UserWarning: <class 'AttributeError'>
[40750 refs]
>>> import warnings
[41483 refs]
>>> warnings.warn(0)
[41483 refs]
>>> warnings.warn(12345)
[41483 refs]
>>> warnings.warn(10101)
Segmentation fault

That is, _warnings.warn(spam) works OK and avoids the
warnings.warn(spam) crash for values already called by the former.

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 02:36:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 00:36:43 +0000
Subject: [issue3641] Builtin ascii() function from future_builtins includes
	leading "u" of unicode strings
In-Reply-To: <1219364395.89.0.296676765919.issue3641@psf.upfronthosting.co.za>
Message-ID: <1219365403.77.0.988127463781.issue3641@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is a side effect of ascii returning a python 2.x unicode object.
The repr still gives a leading "u". The point of ascii is that it
returns a unicode object with only ascii characters. See PEP 3138 for
more information.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3641>
_______________________________________

From report at bugs.python.org  Fri Aug 22 02:53:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 00:53:14 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219366394.52.0.656271775344.issue3611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

With my last patch (pyerr_setobject_reentrant-v2.patch) my program 
works fine! I known that PyErr_SetObject() makes re-entrant calls 
every ~30 seconds, so the code is tested ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 22 02:57:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 00:57:00 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219366620.33.0.934817722461.issue3611@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 22 03:03:01 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Aug 2008 01:03:01 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

I'm getting a compiler warning on Linux AMD64. It's most probably an
issue related to 64bit builds, because size_t > uint_t on 64bit systems.
Such warnings may hide overflow issues.

gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I.
-IInclude -I./Include   -DPy_BUILD_CORE -o Objects/obmalloc.o
Objects/obmalloc.c
Objects/obmalloc.c: In function 'new_arena':
Objects/obmalloc.c:529: warning: comparison is always false due to
limited range of data type

I was able to silence the compiler by declaring numarenas as size_t
instead of uint.

----------
components: Build
keywords: 64bit, needs review
messages: 71712
nosy: christian.heimes
priority: release blocker
severity: normal
status: open
title: Objects/obmalloc.c:529: warning: comparison is always false due to limited range of data type
type: compile error
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Fri Aug 22 03:06:17 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Aug 2008 01:06:17 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219367177.35.0.992045997109.issue3642@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'm seeing a similar issue in py3k:

Objects/bytesobject.c: In function '_PyBytes_FormatLong':
Objects/bytesobject.c:3203: warning: comparison is always false due to
limited range of data type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Fri Aug 22 03:41:23 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 01:41:23 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_thread_state() doesn't check that the argument is a function and 
doesn't check function call result and so the exception is catched 
later:

Non callable argument:
   import _testcapi
   _testcapi._test_thread_state(10)
   # no exception raise here
   import gc
   # exception raised too late!
=> TypeError: 'int' object is not callable

Callback error:
   import _testcapi
   def err():
      raise ValueError("xxx")
   _testcapi._test_thread_state(err)
   # no exception raise here
   import gc
   # exception raised too late!
=> ValueError: xxx

So I wrote a patch which fixes that but also raise_exception() which 
have to check that the argument is an exception class.

----------
components: Library (Lib)
files: testcapi_py26.patch
keywords: patch
messages: 71714
nosy: haypo
severity: normal
status: open
title: Add more checks to testcapi
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11204/testcapi_py26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Fri Aug 22 03:44:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 01:44:21 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219369461.44.0.47721526738.issue3643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 3.0 has an new function which requires an extra patch: 
exception_print() have to check that the argument is an exception 
instance:

   >>> import _testcapi
   >>> _testcapi.exception_print(10)
   Erreur de segmentation (core dumped)

Added file: http://bugs.python.org/file11205/testcapi_py30.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Fri Aug 22 03:56:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 01:56:22 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219370182.38.0.151231473915.issue3643@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Your patches are pretty harmless, but this module is just for testing
purposes.

----------
nosy: +benjamin.peterson
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Fri Aug 22 03:59:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 01:59:39 +0000
Subject: [issue3633] float.fromhex discrepancy under Solaris
In-Reply-To: <1219324715.21.0.0788061296903.issue3633@psf.upfronthosting.co.za>
Message-ID: <1219370379.51.0.430272641096.issue3633@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The buildbot is still failing, but not on test_math.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3633>
_______________________________________

From report at bugs.python.org  Fri Aug 22 04:38:06 2008
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 22 Aug 2008 02:38:06 +0000
Subject: [issue2366] Fixer for new metaclass syntax is needed
In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
Message-ID: <1219372686.94.0.49216968415.issue2366@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Benjamin, the 2to3 parse tree straddles the 2.x Grammar and 3.x Grammar
(it's its own thing) which is why fixup_parse_tree is there.  From the
docstring:
  one-line classes don't get a suite in the parse tree so we add one to
normalize the tree
The 2to3 parser is very line oriented - only the try/except logic uses
blocks (I think).

There haven't been any objection so I've assigned this to myself and
I'll check it in and close it soonish.

----------
assignee: collinwinter -> jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
_______________________________________

From report at bugs.python.org  Fri Aug 22 04:45:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 02:45:37 +0000
Subject: [issue2366] Fixer for new metaclass syntax is needed
In-Reply-To: <1219372686.94.0.49216968415.issue2366@psf.upfronthosting.co.za>
Message-ID: <1afaf6160808211945q686377f9g9836aa905db70ae@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Thu, Aug 21, 2008 at 9:38 PM, Jack Diederich <report at bugs.python.org> wrote:
>
> Jack Diederich <jackdied at gmail.com> added the comment:
>
> Benjamin, the 2to3 parse tree straddles the 2.x Grammar and 3.x Grammar
> (it's its own thing) which is why fixup_parse_tree is there.  From the
> docstring:
>  one-line classes don't get a suite in the parse tree so we add one to
> normalize the tree
> The 2to3 parser is very line oriented - only the try/except logic uses
> blocks (I think).

Yes. Sorry that was a brain seg fault. :)

>
> There haven't been any objection so I've assigned this to myself and
> I'll check it in and close it soonish.

Add an example example.py while you're at it.
>
> ----------
> assignee: collinwinter -> jackdied
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2366>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
_______________________________________

From report at bugs.python.org  Fri Aug 22 05:36:57 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 03:36:57 +0000
Subject: [issue3644] ``make htmlview`` for docs fails on OS X
In-Reply-To: <1219376217.3.0.964627444856.issue3644@psf.upfronthosting.co.za>
Message-ID: <1219376217.3.0.964627444856.issue3644@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Running ``make htmlview`` on OS X Leopard causes the following::

> make htmlview                                        
~/Dev/python/3.x/scratch/Doc
mkdir -p build/html build/doctrees
python2.5 tools/sphinx-build.py -b html -d build/doctrees -D
latex_paper_size=  . build/html 
Sphinx v0.5, building html
loading pickled environment... done
building [html]: targets for 0 source files that are out of date
updating environment: 0 added, 0 changed, 0 removed
no targets are out of date.

Build finished. The HTML pages are in build/html.
python2.5 -c "import webbrowser; webbrowser.open('build/html/index.html')"
0:42: execution error: An error of type -2110 has occurred. (-2110)

----------
assignee: georg.brandl
components: Documentation
messages: 71720
nosy: brett.cannon, georg.brandl
priority: low
severity: normal
status: open
title: ``make htmlview`` for docs fails on OS X
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3644>
_______________________________________

From report at bugs.python.org  Fri Aug 22 06:08:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 04:08:20 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219378100.43.0.586220488446.issue3639@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If you search for _PyUnicode_AsString() in Python/_warnings.c you will
find several places that assume that the proper measures have been taken
to make sure the object is a string. All of those places need to be
fixed so that if a string is not passed in then one is grabbed.

And the reason this turned out as a segfault is for a missing error
return value just before the strcmp() call.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 06:18:09 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Fri, 22 Aug 2008 04:18:09 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za>
Message-ID: <1219378689.43.0.0871272095656.issue3338@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

Well, it's definitely a bug, or inconsistency, if you like, between
cPickle and pickle.

My gut says that probably there is some fault in cPickle that is causing
this. When pickle.py can recurse to 10,000+ and cPickle segfaults at
2600 on a 64bit machine, something smells wrong.

Especially as there have been other, similar, *fixable* bugs already in
cPickle (cf #2702). Unfortunately I can only report the problem, I do
not have the expertise to debug.

regards,
D

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Fri Aug 22 07:41:09 2008
From: report at bugs.python.org (Henry Precheur)
Date: Fri, 22 Aug 2008 05:41:09 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

$ python2.5                                                            
                 
Python 2.5.2 (r252:60911, Jun 16 2008, 15:20:47)                       
                 
[GCC 3.3.5 (propolice)] on openbsd4                                    
                 
Type "help", "copyright", "credits" or "license" for more information. 
                 
>>> def complete(text, state):                                         
                 
...     print 'complete %r %d' % (text, state)                         
                 
...     if text == 'i' and state == 0:                                 
                 
...         return 'import'                                            
                 
...     else:                                                          
                 
...         return None                                                
                 
...                                                                    
                 
>>> import readline; readline.parse_and_bind("tab: complete")
>>> readline.set_completer(complete)                                   
                                     
>>> i<TAB> # <TAB> is press the tab key                                
                 
complete 'i' 0                                                         
                 
complete 'i' 1                                                         
                 
Segmentation fault (core dumped)                                       
                 
                                                                       
                 
The problem is that Python is using a function present in libreadline  
                 
but not declared in readline/readline.h: completion_matches. Instead of
                 
using rl_completion_matches.                                           
                 
                                                                       
                 
Therefor the return type of completion_matches was an int which is     
                 
32bits on amd64 but the function was supposed to returns a pointer which
                
is 64 bits. So when the pointer had a "high" value, it was truncated.  
                 
                                                                       
                 
The problem is fixed by adding libcurses to AC_CHECK_LIB when checking
for functions in libreadline since libreadline depends on curses. This
makes Python use the correct functions declared on readline.h with a   
                       
correct return type.

Patch is attached.

(Others versions of Python should also be affected)

----------
components: Library (Lib)
files: patch.configure.in
messages: 71723
nosy: henry.precheur
severity: normal
status: open
title: readline module Crashs on OpenBSD/amd64
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file11206/patch.configure.in

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3645>
_______________________________________

From report at bugs.python.org  Fri Aug 22 07:52:47 2008
From: report at bugs.python.org (Henry Precheur)
Date: Fri, 22 Aug 2008 05:52:47 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1219384367.19.0.561838066277.issue3645@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

Looks like this patch should also be applied to python 2.6 & 3.

I did not tested but the patch is trivial enough to be applied without
too much fear of breaking something ;)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3645>
_______________________________________

From report at bugs.python.org  Fri Aug 22 08:23:27 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 22 Aug 2008 06:23:27 +0000
Subject: [issue2764] c_char doesn't implement py3k buffer interface
In-Reply-To: <1209940505.31.0.9485811448.issue2764@psf.upfronthosting.co.za>
Message-ID: <1219386207.7.0.200824528596.issue2764@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The test has already been fixed and reenabled in rev 65849.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2764>
_______________________________________

From report at bugs.python.org  Fri Aug 22 08:29:20 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 22 Aug 2008 06:29:20 +0000
Subject: [issue2404] Backport ctypes support for buffer protocol to Python 2.6
	(ref issue1971)
In-Reply-To: <1205869987.72.0.778621175658.issue2404@psf.upfronthosting.co.za>
Message-ID: <1219386560.87.0.856093321787.issue2404@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I forgot to close this issue.  Already implemented in svn rev 63962.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2404>
_______________________________________

From report at bugs.python.org  Fri Aug 22 09:24:23 2008
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 22 Aug 2008 07:24:23 +0000
Subject: [issue648658] xmlrpc can't do proxied HTTP
Message-ID: <1219389863.93.0.585449987157.issue648658@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Well, strictly speaking, yes. It just feels like a rather major omission
(when Python can do xmlrpc and handle proxies you hope it will handle
the combination).

"Desperate" doesn't really have a timeline, strangely enough :) I know I
will be talking to bazaar and bugzilla behind a proxy in the mid-term
future and it would be very useful to use an officially sanctioned
solution (though of course I will try the attached file if there isn't
one at the time).

I see Python 2.6 is nearing release candidates : is this likely to be
included or will we have to wait for 2.7 now?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue648658>
_______________________________________

From report at bugs.python.org  Fri Aug 22 10:13:46 2008
From: report at bugs.python.org (Konrad Hinsen)
Date: Fri, 22 Aug 2008 08:13:46 +0000
Subject: [issue3646] MacOS X framework install to non-standard directory fails
In-Reply-To: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
Message-ID: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>


New submission from Konrad Hinsen <konrad.hinsen at laposte.net>:

The file Mac/README in Python 2.6b3 says:

Installing in another place, for instance $HOME/Library/Frameworks if 
you have no admin privileges on your machine, has only been tested very 
lightly. This can be done by configuring with --enable-
framework=$HOME/Library/Frameworks. The other two directories, 
"/Applications/MacPython-2.6" and /usr/local/bin, will then also be 
deposited in $HOME. This is sub-optimal for the unix tools, which you 
would want in $HOME/bin, but there is no easy way to fix this right
now.


In reality, the framework is installed in the directory given on the 
command line, but the installer then wants to write the app to 
/Applications/MacPython-2.6 and crashes due to lack of write permission:

DYLD_FRAMEWORK_PATH=/shared_scratch/Python-2.6b3:  ../python.exe 
./scripts/Buil\
dApplet.py \
        --destroot "" \
        --
python=/shared_scratch/Library/Frameworks/Python.framework/Versions/2\
.6/Resources/Python.app/Contents/MacOS/Python`test -f 
"/shared_scratch/Library/\
Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/M
acOS/Py\
thon-32" && echo "-32"`  \
        --output "/Applications/Python 2.6/Build Applet.app" \
        ./scripts/BuildApplet.py
kCGErrorRangeCheck : Window Server communications from outside of 
session allow\
ed for root and console user only
./scripts/BuildApplet.py:34: DeprecationWarning: catching of string 
exceptions \
is deprecated
  except buildtools.BuildError, detail:
Traceback (most recent call last):
  File "./scripts/BuildApplet.py", line 149, in <module>
    main()
  File "./scripts/BuildApplet.py", line 33, in main
    buildapplet()
  File "./scripts/BuildApplet.py", line 116, in buildapplet
    progress=verbose, destroot=destroot)
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 115, in process
    copy_codefragment, raw, others, filename, destroot)
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 140, in process_common
    is_update, raw, others, filename, destroot)
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/buildtools.py", li\
ne 327, in process_common_macho
    builder.build()
  File "/Volumes/User data/Scratch/Python-2.6b3/Lib/plat-
mac/bundlebuilder.py",\
 line 147, in build
    os.mkdir(builddir)
OSError: [Errno 13] Permission denied: '/Applications/Python 2.6'
make[1]: *** [install_BuildApplet] Error 1
make: *** [frameworkinstallapps] Error 2

----------
components: Build
messages: 71728
nosy: khinsen
severity: normal
status: open
title: MacOS X framework install to non-standard directory fails
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3646>
_______________________________________

From report at bugs.python.org  Fri Aug 22 10:29:55 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 22 Aug 2008 08:29:55 +0000
Subject: [issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Message-ID: <1219393795.09.0.947437304626.issue1342811@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Fixed in r65971. Backported to the release25-maint and merged into the
py3k branch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1342811>
_______________________________________

From report at bugs.python.org  Fri Aug 22 10:50:37 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 08:50:37 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219395037.74.0.900755755314.issue3643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@benjamin.peterson: I know but the module (installed in CPython 
default installation) is for testing purpose only, but invalid uses of 
its method would lead to inconsistent CPython internal state and 
that's bad :-) If you tried to say that such issue is not critical: 
yes, it's just a suggestion to improve CPython ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:14:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:14:01 +0000
Subject: [issue3107] test_list uses unreasonable amounts of memory on 64-bit
	Linux
In-Reply-To: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>
Message-ID: <1219396441.57.0.501475028604.issue3107@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks, Tony!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3107>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:18:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:18:46 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219396726.96.0.504307924178.issue3640@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In my opinion this is a bug in cPickle. It is completely wrong to
consume more than 3KB of stack space for each recursion level, and it
should be fixed.

----------
components: +Library (Lib)
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:23:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:23:46 +0000
Subject: [issue3338] cPickle segfault with deep recursion
In-Reply-To: <1219378689.43.0.0871272095656.issue3338@psf.upfronthosting.co.za>
Message-ID: <1219397053.48ae85bd6e650@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, it's definitely a bug, or inconsistency, if you like, between
> cPickle and pickle.

There is clearly a problem with cPickle stack consumption and a new bug has been
opened for this in #3640.

What I don't agree with is your argument that pickle and cPickle should have the
same recursion limits - it's just "foolish consistency" to ask for identical
behaviour on such a low-level and implementation-dependent issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3338>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:32:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:32:06 +0000
Subject: [issue3625] test issues on 64bit windows
In-Reply-To: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>
Message-ID: <1219397526.96.0.0433029243681.issue3625@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mark, your patch is ok to me. You can check it in.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3625>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:33:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:33:30 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219397610.95.0.596800161026.issue3643@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Unless someone thinks it's somehow release-critical, I'm retargetting
this to 2.7/3.1.

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:38:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:38:00 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1219397880.54.0.12751307847.issue3645@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +needs review, patch
priority:  -> release blocker
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3645>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:51:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:51:34 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219398694.24.0.878307568143.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Guido, do we retarget the rest of this to 3.1? It sounds more reasonable
to me.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:53:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:53:07 +0000
Subject: [issue2619] Document PEP 3118
In-Reply-To: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>
Message-ID: <1219398787.63.0.944148726516.issue2619@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should this be a release blocker?

----------
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2619>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:53:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:53:46 +0000
Subject: [issue3101] global function _add_one_to_C
In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za>
Message-ID: <1219398826.39.0.643956567762.issue3101@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3101>
_______________________________________

From report at bugs.python.org  Fri Aug 22 11:56:52 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 09:56:52 +0000
Subject: [issue3101] global function _add_one_to_C
In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za>
Message-ID: <1219399012.3.0.523885543655.issue3101@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A sensible solution would be to put all the memoryview / buffer API
stuff in the same standalone file (e.g. memoryobject.c), rather than
having half of it dumped in abstract.c.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3101>
_______________________________________

From report at bugs.python.org  Fri Aug 22 12:08:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 10:08:56 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219399736.03.0.207425184128.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Victor, your patch addresses the symptom of the problem, not the cause.

The cause is that in some cases, the exception context chain is lost. Of
course what could be a minor annoyance becomes dramatic when this
precisely happens in code that makes use of this context.

IMO, PyErr_SetObject should not restore the previous exc_* members; it's
not its job to correct others' mistakes.
I join a patch that only protects it from crashing in this case: it just
saves exc_value in a local variable.

The bug shown by lostcontext2.py is still unresolved, but at least it
won't crash the interpreter.

Added file: http://bugs.python.org/file11207/pyerr_seterror_protect.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 22 12:22:10 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 10:22:10 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219400530.32.0.747338490815.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Amaury, it's not PyErr_SetObject's job to try to
save/restore the tstate->exc_* variables. We'll probably have to live
with the small context-losing glitches in 3.0.

For 3.1, a radical solution would be to drop the "exception
normalization" misfeature (which is a source of complications and
potential bugs) and always instantiate exception objects as soon as they
are raised rather than lazily. We need to make sure the performance loss
is reasonable though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 22 12:31:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 10:31:48 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219401108.7.0.870779542116.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, answering to myself, I don't think dropping exception normalization
would solve the problem, it would just let it occur in a different place...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 22 14:37:31 2008
From: report at bugs.python.org (mounty)
Date: Fri, 22 Aug 2008 12:37:31 +0000
Subject: [issue3493] No Backslash (\) in IDLE 1.2.2
In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
Message-ID: <1219408651.41.0.88109545434.issue3493@psf.upfronthosting.co.za>


mounty <python6+4 at ulfbaur.de> added the comment:

@ Terry J. Reedy

If it is working for you it doesn't necessarily mean that it is working
for mankind in general.

I traced down the problem to the OS X- implementation of Idle in general
and submitted an inquiry to the general python list as you suggested.
The feedback was null- nada- niente. But in the meantime I received a
nice bunch of Spam instead.

http://mail.python.org/pipermail/python-list/2008-August/504330.html

I believe the original poster has a French keyboard and seems to have 
similar problems. The problem is that Idle seems to ignore the
international local keyboard setting. And as we do have two significant
letters ("#" and "'") at the keyboard position where you have the "\"
Idle seems to filter the entry of a backslash.

@ marc 67
HTH

Cheers
Ulf

----------
nosy: +mounty

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3493>
_______________________________________

From report at bugs.python.org  Fri Aug 22 14:54:36 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 22 Aug 2008 12:54:36 +0000
Subject: [issue3647] urlparse - relative url parsing and joins to be RFC3986
	compliance
In-Reply-To: <1219409676.71.0.379802173537.issue3647@psf.upfronthosting.co.za>
Message-ID: <1219409676.71.0.379802173537.issue3647@psf.upfronthosting.co.za>


New submission from Senthil <orsenthil at gmail.com>:

Attaching two patches to make the current urlparse library, especially 
the relative url parsing and urljoin  to be RFC3986 compliance.
I have included all the tests prescribed in RFC3986 and verified them 
to pass with the patches.

Our parsing functionality of netloc (to 
username,password,hostname,port) is same as what RFC3986 specifies. It 
uses the term 'authority' instead of 'netloc'. I did not feel the need 
for name change. If required, it can done.

----------
components: Library (Lib)
files: urlparse_rfc3986-py26.diff
keywords: patch
messages: 71743
nosy: orsenthil
severity: normal
status: open
title: urlparse - relative url parsing and joins to be RFC3986 compliance
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11208/urlparse_rfc3986-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3647>
_______________________________________

From report at bugs.python.org  Fri Aug 22 14:55:00 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 22 Aug 2008 12:55:00 +0000
Subject: [issue3647] urlparse - relative url parsing and joins to be RFC3986
	compliance
In-Reply-To: <1219409676.71.0.379802173537.issue3647@psf.upfronthosting.co.za>
Message-ID: <1219409700.74.0.888458222445.issue3647@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file11209/urlparse_rfc3986-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3647>
_______________________________________

From report at bugs.python.org  Fri Aug 22 15:12:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 13:12:55 +0000
Subject: [issue3644] ``make htmlview`` for docs fails on OS X
In-Reply-To: <1219376217.3.0.964627444856.issue3644@psf.upfronthosting.co.za>
Message-ID: <1219410775.97.0.169046008192.issue3644@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is probably actually a problem with the webbrowser module. Try
running "import webbrowser; webbrowser.open('build/html/index.html')" on
the plain Python shell.

----------
components: +Library (Lib) -Documentation
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3644>
_______________________________________

From report at bugs.python.org  Fri Aug 22 15:14:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 13:14:34 +0000
Subject: [issue2968] Test_imports takes a long time to run
In-Reply-To: <1211728458.35.0.22936057327.issue2968@psf.upfronthosting.co.za>
Message-ID: <1219410874.6.0.0111213934329.issue2968@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is no longer an issue.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2968>
_______________________________________

From report at bugs.python.org  Fri Aug 22 15:18:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 13:18:16 +0000
Subject: [issue1504] Add 2to3 fixer for (un)bound methods
In-Reply-To: <1196162321.58.0.597340041678.issue1504@psf.upfronthosting.co.za>
Message-ID: <1219411096.1.0.485672376579.issue1504@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Must this still be open?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1504>
_______________________________________

From report at bugs.python.org  Fri Aug 22 16:14:10 2008
From: report at bugs.python.org (electronixtar)
Date: Fri, 22 Aug 2008 14:14:10 +0000
Subject: [issue3648] 'ascii' shoud be range(256) or just set another default
	encoding
In-Reply-To: <1219414450.32.0.0238360557627.issue3648@psf.upfronthosting.co.za>
Message-ID: <1219414450.32.0.0238360557627.issue3648@psf.upfronthosting.co.za>


New submission from electronixtar <electronicstar at 126.com>:

One of the MOST common scene for Python developers on CJK/Widecharacter 
is this error:

'ascii' codec can't decode byte 0xe5 in position 0: ordinal not in range
(128)


Why cann't Python just define ascii to range(256), or alternatively, 
just use another default encoding that handles 0x00 to 0xff. Sometimes 
encoding problems in Python are driving me mad.

Currently I am using mbcs, but it's only available on Windows.

----------
components: Interpreter Core
messages: 71747
nosy: electronixtar
severity: normal
status: open
title: 'ascii' shoud be range(256) or just set another default encoding
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3648>
_______________________________________

From report at bugs.python.org  Fri Aug 22 16:21:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 14:21:44 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219414904.04.0.609279694414.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I implemented the "invalid filename" class feature:
 - by default, os.listdir() raise an error (UnicodeDecodeError) on 
invalid filename. The previous behaviour was to return bytes object 
instead of str.
 - if invalid_filename=True: create an InvalidFilename class instance

InvalidFilename is not a bytes string, it's not a str string, it's a 
new class. It has three attributes:
 - bytes: the real filename
 - charset: charset (type str)
 - str: fake filename (type str) used by __str__() method

My patch also fixes os.path.join() to accept InvalidFilename: if at 
last one argument is an InvalidFilename, use InvalidFilename.join() 
(class method).

os.listdir() and os.unlink() are patched to accept InvalidFilename. 
unlink always accept InvalidFilename whereas listdir() only produces 
InvalidFilename is os.listdir(path, invalid_filename=True) is used.

I added an optional argument "invalid_filename" to shutil.rmtree(), 
default value is *True*.

To sum up, visible changes:
 - os.listdir() raise an error on invalid filename instead of return a 
mixed list of str and bytes
 - shutil.rmtree() manipulate str and InvalidFilename instead of str 
and bytes

Added file: http://bugs.python.org/file11210/invalid_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 16:53:31 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Aug 2008 14:53:31 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219416811.93.0.154285101815.issue3187@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm not interested in the InvalidFilename class; it's an API
complification that might seem right for your situation but will hinder
most other people.  However I *am* interested in a patch that makes
os.unlink() (and as many other functions as you can think of) accept
bytes.  You'll have to think what encoding to use on Windows though,
since (AFAIK) the Windows filesystem APIs *do* use Unicode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 17:03:12 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 22 Aug 2008 15:03:12 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219417392.2.0.366920074146.issue3639@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Brett,
I don't think I know C (and CPython) enough to fix this. I was able to
get rid of this specific segfault with this:

-            const char *text_char = _PyUnicode_AsString(text);
+            const char *text_char =
_PyUnicode_AsString(PyObject_Str(text));

But I have no idea whether I should also incref/decref the PyObject_Str.

----------
keywords: +patch
Added file: http://bugs.python.org/file11211/_warnings.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 17:19:47 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 15:19:47 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219418387.85.0.489354032124.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@gvanrossum: os.unlink() and os.lstat() already accept byte filenames 
(but open() doesn't).

Ok, here is very small patch for posixpath.join() to accept bytes 
strings. This patch is enough to fix my initial problem (#3616).

Added file: http://bugs.python.org/file11212/posix_path_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 17:34:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 15:34:00 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219419240.29.0.0156388426303.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My last patch (posix_join_bytes.patch) is also enough to fix the 
initial reported problem: error in posixpath.join() called by 
os.walk(). I tried os.walk() on a directory with invalid filenames and 
invalid directory name and it works well.

So the last bug is open() which disallow opening a file with an 
invalid name. So here is another patch for that.

Added file: http://bugs.python.org/file11213/io_byte_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 17:35:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 15:35:19 +0000
Subject: [issue3648] 'ascii' shoud be range(256) or just set another default
	encoding
In-Reply-To: <1219414450.32.0.0238360557627.issue3648@psf.upfronthosting.co.za>
Message-ID: <1219419319.38.0.751572287321.issue3648@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sometimes 
> encoding problems in Python are driving me mad.

The thing is, they are not "encoding problems in Python", they are
encoding problems in the outside world. Python cannot know magically
which encoding is used in third-party data, so you have to tell it
yourself what the encoding is.

The default is "ascii" because only ASCII chars (from 32 to 127) can be
interpreted properly in most situations without having any knowledge of
the encoding (barring obsolete stuff such as EBCDIC, that is).

The only solution is to know what encoding you are expecting and
decode/encode it yourself. Python can't decide it for you.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3648>
_______________________________________

From report at bugs.python.org  Fri Aug 22 17:57:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 15:57:28 +0000
Subject: [issue1777458] glob doesn't return unicode with unicode parameter
Message-ID: <1219420648.57.0.982658278795.issue1777458@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Seems fixed on 2.6.

Python 2.6b3+ (trunk, Aug 22 2008, 11:27:51) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import glob
>>> glob.glob("*.py")
['iocrash.py', 'setup.py']
>>> glob.glob(u"*.py")
[u'iocrash.py', u'setup.py']
>>> glob.glob(u"./*.py")
[u'.\\iocrash.py', u'.\\setup.py']

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777458>
_______________________________________

From report at bugs.python.org  Fri Aug 22 18:26:47 2008
From: report at bugs.python.org (Pascal Bach)
Date: Fri, 22 Aug 2008 16:26:47 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>


New submission from Pascal Bach <pascal.bach at nextrem.ch>:

This encoding is used in the GSM standard it is a 7-bit encoding similar
to ASCII. 
The encoding definition is found in:
Short Message Service Centre EMI - UCP Interface 4.6 Specification (p. 79)
as well as in: 
[3GPP 23.038] 3GPP TS 23.038 Alphabets and language-specific information.

I think this encoding would be useful for other GSM specific use cases.

----------
components: Unicode
files: ia5.py
messages: 71755
nosy: pascal.bach
severity: normal
status: open
title: IA5 Encoding should be in the default encodings
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file11214/ia5.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Fri Aug 22 18:54:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 16:54:50 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219424090.89.0.603091626399.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch glob.glob() to accept directory with invalid filename (invalid 
in the filesystem charset): just ignore bytes => str conversion error.

Added file: http://bugs.python.org/file11216/glob1_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 18:56:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 16:56:37 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219424197.42.0.0168851541066.issue3640@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem comes from this local variable in batch_list() and batch_dict:
    PyObject *slice[BATCHSIZE];
and BATCHSIZE=1000...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Fri Aug 22 18:53:49 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Aug 2008 16:53:49 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219424029.99.0.11967614374.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

To continue in the "accept bytes filenames" way, a new patch for 
fnmatch.filter(). Use sys.getfilesystemencoding() to convert the 
bytes. The patch contains a new unit test.

Added file: http://bugs.python.org/file11215/fnmatch_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 19:30:48 2008
From: report at bugs.python.org (Eric Smith)
Date: Fri, 22 Aug 2008 17:30:48 +0000
Subject: [issue3595] Windows base64 Decode
In-Reply-To: <1219112685.57.0.506715853146.issue3595@psf.upfronthosting.co.za>
Message-ID: <1219426248.76.0.0834309666846.issue3595@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Please upload your script, or (preferably) some small test code.

I suspect the problem is related to line endings and binary versus text
files.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3595>
_______________________________________

From report at bugs.python.org  Fri Aug 22 19:40:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 17:40:01 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219426801.99.0.0578765514141.issue3640@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Attached patch removes the big array, items are saved when they are
fetched from the container.
I preserved the the special case when there is only one item.

The patch does not merge cleanly into py3k, but the functions batch_list
and batch_dict look very similar and suffer the same problem.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11217/cpickle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Fri Aug 22 20:00:23 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 22 Aug 2008 18:00:23 +0000
Subject: [issue3555] Regression: nested exceptions crash (Cannot recover from
	stack overflow)
In-Reply-To: <1218740615.84.0.303510238935.issue3555@psf.upfronthosting.co.za>
Message-ID: <1219428023.66.0.918695347893.issue3555@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Antoine,
All the cases I could find would be more "test" than "use" cases. Given
that most ways to abort I find in 3.0 are related to "undetected error"s
in trunk, I'm almost convinced that 3.0 is right here :)

My last worry is that it'd be kinda easy to get Fatal errors from
sane-ish functions and deeply nested input:
============
class rec:
    def __str__(self):
        return str(self)

def overflower(x):
    try:
        return overflower(x)
    except:
        print (x)

list_rec = [100000000001]
for _ in range(12): list_rec = [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[list_rec]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

str_rec = rec()

overflower(1) # OK
overflower(list_rec) # Aborts
overflower(str_rec) # Aborts
============

Thanks for the feedback!
Attached is a file that shows how trunk is doing something weird when it
works (besides the other reported issues that arise from that).

Added file: http://bugs.python.org/file11218/nester.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3555>
_______________________________________

From report at bugs.python.org  Fri Aug 22 20:07:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 18:07:06 +0000
Subject: [issue3644] ``make htmlview`` for docs fails on OS X
In-Reply-To: <1219410775.97.0.169046008192.issue3644@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808221107m5bb01369k8ddbb11a683b32b9@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Aug 22, 2008 at 6:12 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> This is probably actually a problem with the webbrowser module. Try
> running "import webbrowser; webbrowser.open('build/html/index.html')" on
> the plain Python shell.
>

Yep, it is webbrowser thing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3644>
_______________________________________

From report at bugs.python.org  Fri Aug 22 20:08:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 18:08:46 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219417392.2.0.366920074146.issue3639@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808221108h259ffbfcle8d16b35b53992ae@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Aug 22, 2008 at 8:03 AM, Daniel Diniz <report at bugs.python.org> wrote:
>
> Daniel Diniz <ajaksu at gmail.com> added the comment:
>
> Brett,
> I don't think I know C (and CPython) enough to fix this. I was able to
> get rid of this specific segfault with this:
>
> -            const char *text_char = _PyUnicode_AsString(text);
> +            const char *text_char =
> _PyUnicode_AsString(PyObject_Str(text));
>
> But I have no idea whether I should also incref/decref the PyObject_Str.
>

That's along the lines of what needs to be done (and what I was
planning on doing), although you need to do more error checking on the
return values. Plus the patch I am cooking up adds more checks in the
code for the return value of _PyUnicode_AsString().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 20:13:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 18:13:27 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219428807.36.0.282936008875.issue3640@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an additional patch which adds a cpickle test to
Misc/find_recursion_limit.py. It helps show that Amaury's patch does fix
the issue. +1 for applying it.

Added file: http://bugs.python.org/file11219/find_recursion_limit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Fri Aug 22 20:49:06 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 18:49:06 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219430946.08.0.16720754358.issue3639@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The patch doesn't actually bother with a translation as the code causing
issue is only there to prevent infinite recursion. So if the object
being used is not a string, then there is no need to worry as it is not
part of the infinite recursion problem.

I also added a bunch of missing error checks.

----------
keywords: +needs review
Added file: http://bugs.python.org/file11220/fix_warn_funky_types.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 20:56:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 18:56:44 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219431404.49.0.347343548849.issue3639@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Brett, is this patch ready for review?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 20:59:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Aug 2008 18:59:37 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219431577.25.0.944313080941.issue3352@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are still some instances of get_name() in threading.py itself,
which gives errors like the following:


Unhandled exception in thread started by <bound method
Thread.__bootstrap of <Thread(reader 5, stopped daemon -1285227632)>>
Traceback (most recent call last):
  File "/home/antoine/cpython/cpickle/Lib/threading.py", line 499, in
__bootstrap
    self.__bootstrap_inner()
  File "/home/antoine/cpython/cpickle/Lib/threading.py", line 537, in
__bootstrap_inner
    (self.get_name(), _format_exc()))
AttributeError: 'Thread' object has no attribute 'get_name'

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Fri Aug 22 21:02:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 19:02:03 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1219431723.68.0.353418908477.issue3352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a patch.

Added file: http://bugs.python.org/file11221/get_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3352>
_______________________________________

From report at bugs.python.org  Fri Aug 22 21:05:15 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Aug 2008 19:05:15 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219431915.64.0.939260193115.issue3187@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

See http://codereview.appspot.com/3055 for a code review of Victor's
latest patches.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Fri Aug 22 21:11:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 19:11:35 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219432295.51.0.633673767822.issue3643@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I'll apply your patches when we get to 2.7. Do ping me if a forget,
though.

----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Fri Aug 22 21:20:26 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 19:20:26 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219432826.07.0.0629579268657.issue3649@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The provided file does not work for "EXTENSION" characters:

>>> import ia5
>>> u"[a]".encode("ia5")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "ia5.py", line 18, in encode
    return codecs.charmap_encode(input,errors,encoding_map)
TypeError: character mapping must be in range(256)

I doubt this can be achieved with just a charmap. You will have to roll
your own incremental stateful decoder.
Are you willing to do it?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Fri Aug 22 21:51:33 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Aug 2008 19:51:33 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219434693.38.0.000302106913829.issue3642@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The warning in obmalloc.c was silenced in r65975 (trunk) and r65976 (py3k)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Fri Aug 22 21:59:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 19:59:36 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1219435176.46.0.444061342443.issue3639@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That's why the keyword is set. =)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 22:03:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 20:03:11 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219435176.46.0.444061342443.issue3639@psf.upfronthosting.co.za>
Message-ID: <1afaf6160808221303o20a5a2e3p4d49c2345cb22f2a@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Fri, Aug 22, 2008 at 2:59 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> Brett Cannon <brett at python.org> added the comment:
>
> That's why the keyword is set. =)

Ah. I missed that. :) The patch looks fine.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3639>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3639>
_______________________________________

From report at bugs.python.org  Fri Aug 22 22:41:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 20:41:48 +0000
Subject: [issue2367] Fixer to handle new places where parentheses are needed
In-Reply-To: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za>
Message-ID: <1219437708.01.0.346840669532.issue2367@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the work! I reviewed the code, added support for generator
expressions, and wrote a few more tests. Committed in r65981.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2367>
_______________________________________

From report at bugs.python.org  Fri Aug 22 22:49:30 2008
From: report at bugs.python.org (Pascal Bach)
Date: Fri, 22 Aug 2008 20:49:30 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219438170.9.0.272057824698.issue3649@psf.upfronthosting.co.za>


Pascal Bach <pascal.bach at nextrem.ch> added the comment:

Well I have seen the problem. 

I'm willing to do this to improve python, but I don't know exactly how
to do it.

I looked at how utf-8 and utf-7 are done but I didn't exactly
understand, are they based on C code?

Is there an example how this needs to be done? It would be nice if you
could get me some help where to start.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:05:54 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2008 21:05:54 +0000
Subject: [issue3563] fix_idioms.py generates bad code
In-Reply-To: <1218870188.26.0.589326010093.issue3563@psf.upfronthosting.co.za>
Message-ID: <1219439154.81.0.107458878928.issue3563@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Why is the statement, whatever it is, even being touched?
Would not the same problem arise with any following outdented line?

IOW, why not delete that pair of lines from fix_idioms.py?
Does that break anything else in test_fixers?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3563>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:19:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Aug 2008 21:19:52 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219439992.67.0.344261181593.issue3602@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think I can clean up the code by shifting WarningMessage over to a
subclass of namedtuple and moving WarningsRecorder over to a subclass of
list.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:30:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 21:30:58 +0000
Subject: [issue3650] Memory leak in bytes.split()
In-Reply-To: <1219440658.47.0.131327756004.issue3650@psf.upfronthosting.co.za>
Message-ID: <1219440658.47.0.131327756004.issue3650@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

./python Lib/test/regrtest.py -R:: test_bytes
reveals a leak in py3k.

This is exactly the same as the one corrected by r65785 to bytearray.
(easy) patch attached, needs approval!

----------
files: bytes-split.patch
keywords: needs review, patch
messages: 71779
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Memory leak in bytes.split()
versions: Python 3.0
Added file: http://bugs.python.org/file11222/bytes-split.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3650>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:32:48 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2008 21:32:48 +0000
Subject: [issue3564] making partial functions comparable
In-Reply-To: <1218870311.31.0.296416489838.issue3564@psf.upfronthosting.co.za>
Message-ID: <1219440768.9.0.902293384413.issue3564@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The default equality comparison of Python objects is by id.
Some classes override this, others, in particular, functions, do not.
I also agree that partial functions should not either.

However, you can subclass functools.partial (I checked in 3.0b2) and add
__eq__ and __ne__ methods that implement the definition *you* need, even
if it gives the 'wrong' result of Antoine example.

----------
nosy: +tjreedy
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3564>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:33:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 21:33:48 +0000
Subject: [issue3650] Memory leak in bytes.split()
In-Reply-To: <1219440658.47.0.131327756004.issue3650@psf.upfronthosting.co.za>
Message-ID: <1219440828.05.0.913932568389.issue3650@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Go ahead.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3650>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:44:06 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2008 21:44:06 +0000
Subject: [issue3577] Interpreter name: python vs. python-3.0
In-Reply-To: <1218975329.44.0.7329421423.issue3577@psf.upfronthosting.co.za>
Message-ID: <1219441446.91.0.971983665874.issue3577@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3577>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:45:37 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2008 21:45:37 +0000
Subject: [issue3579] Faites Attention en Utilisant Cette Merveille!
In-Reply-To: <01c9008f$995b7180$550be758@etlhifeld>
Message-ID: <1219441537.05.0.198003936055.issue3579@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file11139/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3579>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:46:54 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2008 21:46:54 +0000
Subject: [issue3579] Faites Attention en Utilisant Cette Merveille!
Message-ID: <1219441614.81.0.000431719660819.issue3579@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3579>
_______________________________________

From report at bugs.python.org  Fri Aug 22 23:51:01 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2008 21:51:01 +0000
Subject: [issue3579] SPAM
Message-ID: <1219441862.0.0.516070805779.issue3579@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Faites Attention en Utilisant Cette Merveille! -> SPAM

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3579>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:06:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 22:06:00 +0000
Subject: [issue3650] Memory leak in bytes.split()
In-Reply-To: <1219440658.47.0.131327756004.issue3650@psf.upfronthosting.co.za>
Message-ID: <1219442760.84.0.143373913502.issue3650@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r65985

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3650>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:09:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 22:09:43 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

version 3.0, any call to eval() leaks one reference:

>>> eval('1')
1
[42093 refs]
>>> eval('1')
1
[42094 refs]
>>> eval('1')
1
[42095 refs]
>>> eval('1')
1
[42096 refs]

----------
components: Interpreter Core
messages: 71783
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: eval() leaks 1 reference every time
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:17:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Aug 2008 22:17:55 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219443475.2.0.500189225667.issue3651@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The error is inside compile, not eval:

>>> compile("1", "test", "eval")
<code object <module> at 0x7ffe1ce2ed50, file "test", line 1>
[43379 refs]
>>> compile("1", "test", "eval")
<code object <module> at 0x7ffe1ce2e3b0, file "test", line 1>
[43380 refs]
>>> compile("1", "test", "eval")
<code object <module> at 0x7ffe1ce2ed50, file "test", line 1>
[43381 refs]
>>> compile("1", "test", "eval")
<code object <module> at 0x7ffe1ce2e3b0, file "test", line 1>
[43382 refs]

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:20:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 22:20:06 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219443606.36.0.973638161921.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The leaked reference refers to the bytes object which encodes the code
being compiled:
>>> for x in range(1000): compile("1", "test", "eval")
>>> sys.getrefcount(b'1')
1004

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:22:23 2008
From: report at bugs.python.org (gd2shoe)
Date: Fri, 22 Aug 2008 22:22:23 +0000
Subject: [issue1396825] subprocess: wait for a period of time
Message-ID: <1219443743.78.0.362271043126.issue1396825@psf.upfronthosting.co.za>


gd2shoe <gd2shoe at gmail.com> added the comment:

This is just common sense.  I'm trying to avoid a poll() busy-wait
section of code.  I'll figure it out, but it would be much, much easier
if wait accepted a number of seconds, and returned None if the process
was still going (cf. Popen.poll() ).

I'm much happier with subprocess than os.popen*.  I'm also glad that
Popen.kill() is slated for 3.0 .

Since this isn't in the 3.0b3 documentation, I assume this either isn't
fixed or planned?  Are there implementation difficulties?

----------
nosy: +gd2shoe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1396825>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:23:45 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2008 22:23:45 +0000
Subject: [issue3636] Managing dual 2.x and 3.0 installations on Windows
In-Reply-To: <1219350265.84.0.067322027975.issue3636@psf.upfronthosting.co.za>
Message-ID: <1219443825.46.0.00153384089576.issue3636@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3636>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:24:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 22:24:20 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219443860.9.0.755666101342.issue3651@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Could it be related to the fact that test_bytes is leaking?

test_bytes leaked [129, 129, 129, 129] references, sum=516

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:28:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Aug 2008 22:28:14 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219444094.79.0.954691030294.issue3651@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Good point! It's leaking even more on my 64bit machine:

test_bytes leaked [195, 195, 195, 195] references, sum=780

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:37:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 22:37:07 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219444627.65.0.885972483697.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Benjamin: yes, test_bytes calls eval() 128 times.
Christian: please "svn up", I just corrected another leak in bytesobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:47:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Aug 2008 22:47:31 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219445251.21.0.319243242582.issue3651@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I was already up to date. r65985 leaks 195 references in each run on my box.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 00:55:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 22:55:22 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219445722.4.0.676543175537.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The attached patch corrects the eval() and compile() reference leak.
The problem is in PyObject_AsReadBuffer.

Needs review: view->obj seems to own the reference, but object.h say the
opposite.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11223/buffer-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 01:10:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 23:10:04 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219446604.52.0.207757556031.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PyObject_AsCharBuffer is affected as well.
This fixes for me the last refleak in test_bytes.

Added file: http://bugs.python.org/file11224/buffer-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 01:10:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 23:10:12 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219446612.83.0.0898129020929.issue3651@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file11223/buffer-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 01:24:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Aug 2008 23:24:15 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219447455.67.0.45615701447.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Benjamin,

I am testing the patch proposed earlier by Victor in
http://bugs.python.org/msg71579 (who might be the correct one, after all),
and I don't see the problems you mentioned. 
I run the test suite without problem, on winXP & Linux Debian x86.

Can you please try again?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Sat Aug 23 01:29:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2008 23:29:12 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219447752.12.0.71641000529.issue3611@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I can't reproduce it either. I suspect that I removed the wrong lines
initially and caused other problems. :) Sorry for the false alarm.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Sat Aug 23 02:02:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Aug 2008 00:02:21 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219449741.04.0.903328759678.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Of course, I forgot PyObject_AsWriteBuffer in my patch.

I wonder if turning view.obj into an owned reference was a good idea.
There are more calls to bf_getbuffer (in getarg.c), they leak too: 

test_struct leaked [5, 5, 5, 5] references, sum=20

because of a PyArg_ParseTuple with s# and a bytes object.

Added file: http://bugs.python.org/file11225/buffer-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 02:02:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Aug 2008 00:02:32 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219449752.58.0.248322170904.issue3651@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file11224/buffer-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 02:35:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Aug 2008 00:35:43 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219451743.81.0.515782264594.issue3651@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sat Aug 23 03:00:18 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 23 Aug 2008 01:00:18 +0000
Subject: [issue3625] test issues on 64bit windows
In-Reply-To: <1219288936.06.0.57687304874.issue3625@psf.upfronthosting.co.za>
Message-ID: <1219453218.56.0.430951654745.issue3625@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Thanks.  Checked into the trunk in r65986

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3625>
_______________________________________

From report at bugs.python.org  Sat Aug 23 03:13:10 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 01:13:10 +0000
Subject: [issue3652] Remove DeprecationWarning in _warnings about 'line'
In-Reply-To: <1219453990.4.0.253900549478.issue3652@psf.upfronthosting.co.za>
Message-ID: <1219453990.4.0.253900549478.issue3652@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The DeprecationWarning introduced in Python 2.6/3.0 about the 'line'
argument for showwarning() can be removed in 2.7/3.1.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 71797
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Remove DeprecationWarning in _warnings about 'line'
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3652>
_______________________________________

From report at bugs.python.org  Sat Aug 23 03:20:04 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 01:20:04 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219454404.33.0.992269883259.issue3602@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The patch does a couple of things. It moves
test.test_support.catch_warning() to warnings.catch_warnings() and
leaves a stub behind. WarningsRecorder becomes a subclass of list to
make it easier to work with. The uses of catch_warnings() in the stdlib
are moved to the 'warnings' implementation along with protecting the
warnings filter changes behind a sys.py3kwarning 'if' statement. And
finally, a oversight in the triggering of a DeprecationWarning for
showwarning() and the new 'line' argument has been fixed (with the
appropriate test).

----------
assignee: brett.cannon -> 
keywords: +needs review, patch
Added file: http://bugs.python.org/file11226/move_catch_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Sat Aug 23 03:26:55 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 23 Aug 2008 01:26:55 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219454815.13.0.0618444732933.issue3640@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Sorry for the initial noise - your analysis is correct, mine was flawed
:)  Simple recursion to a depth of 1000 does work fine on a 64bit build.

cpickle.patch does make test_cpickle pass for me.  FWIW,
find_recursionlimit.py now causes a segfault on 32 and 64bit Windows
(the comments imply a MemoryError is expected there), and the 32bit
version dies at a depth of 5900, while the 64bit version dies at 3800
(both doing an 'add') - so it does seem there is still a discrepancy -
but not one we need to care about now.

I'm +1 in general on this, but I'm not sure that I'm +1 on this patch
for 1.6 without more careful review than I am able to offer at the
moment; it seems fairly unlikely to be hit "in the wild", but I'll
obviously defer that to others.  OTOH, having the test suite segfault
isn't a good look, so we probably need to do *something* for 1.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Sat Aug 23 03:47:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Aug 2008 01:47:01 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219456021.34.0.12008798084.issue3602@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

See my comments on Rietveld. http://codereview.appspot.com/3255

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Sat Aug 23 03:55:35 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 23 Aug 2008 01:55:35 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1219456535.2.0.716566173798.issue3566@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Sat Aug 23 04:20:49 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 02:20:49 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219458049.72.0.739011164454.issue3602@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Added file: http://bugs.python.org/file11227/move_catch_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Sat Aug 23 04:21:21 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 02:21:21 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219458081.22.0.539295650395.issue3602@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

New patch is up with a minor change from Benjamin's review. My explicit
comments on the suggestions are on Rietveld.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Sat Aug 23 10:08:30 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Sat, 23 Aug 2008 08:08:30 +0000
Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
In-Reply-To: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za>
Message-ID: <1219478910.67.0.27130655522.issue1276@psf.upfronthosting.co.za>


Hye-Shik Chang <hyeshik at gmail.com> added the comment:

Committed patch "cjkmactemporary.diff" as r65988 in the py3k branch.
I'll open another issue for cjkcodecs implementation of Mac codecs.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1276>
_______________________________________

From report at bugs.python.org  Sat Aug 23 11:06:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Aug 2008 09:06:23 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219482383.75.0.0621759359194.issue3649@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You could start with utf_8.py, and of course replace the calls to
codecs.utf_8_encode and codecs.utf_8_decode.

- your "ia5_encode" follows this interface:
http://docs.python.org/dev/library/codecs.html#codecs.Codec.encode

- your "ia5_decode" has the signature:
    def ia5_decode(input, errors='strict', final=False)
and returns a tuple (output object, length consumed).
See
http://docs.python.org/dev/library/codecs.html#codecs.IncrementalDecoder.decode
for an explanation of the final parameter; 
in particular, if the input is a single 0x1B,
- it will return ('', 0) if final is False
- and raise UnicodeDecodeError("unexpected end of data") if final is True

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Sat Aug 23 11:18:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Aug 2008 09:18:48 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219454815.13.0.0618444732933.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219483124.5822.5.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 23 ao?t 2008 ? 01:26 +0000, Mark Hammond a ?crit :
> cpickle.patch does make test_cpickle pass for me.  FWIW,
> find_recursionlimit.py now causes a segfault on 32 and 64bit Windows
> (the comments imply a MemoryError is expected there), and the 32bit
> version dies at a depth of 5900, while the 64bit version dies at 3800
> (both doing an 'add') - so it does seem there is still a discrepancy -
> but not one we need to care about now.

Well, the discrepancy is expected, since pointers are bigger in 64-bit
mode than in 32-bit mode, and most function calls inside the interpreter
involve pushing a bunch of PyObject pointers on the stack.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Sat Aug 23 14:08:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Aug 2008 12:08:28 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1219493308.11.0.859326498595.issue3640@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Adapted the patch to python 3.0

Added file: http://bugs.python.org/file11228/cpickle-3.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Sat Aug 23 15:44:58 2008
From: report at bugs.python.org (C. Scott Ananian)
Date: Sat, 23 Aug 2008 13:44:58 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1219499098.65.0.96713473507.issue3566@psf.upfronthosting.co.za>


C. Scott Ananian <cscott at cscott.net> added the comment:

FWIW, the following code works around the issue for me:

class HTTPConnection(httplib.HTTPConnection):
    def request(self, method, url, body=None, headers={}):
        # patch upstream to recv() after we send, so that a closed
        # connection is discovered here rather than later in
        # HTTPResponse._read_status()
        try:
            self._send_request(method, url, body, headers)
            b = self.sock.recv(1, socket.MSG_PEEK)
            if b == '':
                self.close()
                raise socket.error(32) # sender closed connection.
        except socket.error, v:
            # trap 'Broken pipe' if we're allowed to automatically reconnect
            if v[0] != 32 or not self.auto_open:
                raise
            # try one more time
            self._send_request(method, url, body, headers)

In general, attempting to read a byte of the response just to trigger
the broken pipe error is suboptimal; it doesn't accurately distinguish
the "closed before received request" case from the "closed just after
received request" case.  For idempotent methods like GET and HEAD, this
doesn't matter, but it does for POST, etc.

There ought to be a better way to force the underlying OS to give you
the current 'closed' status on a socket which doesn't require your
trying to send/receive bytes.  The fundamental issue here is that the
TCP spec, and Linux, allow the request send to succeed even if TCP FIN
has been received from the other side -- the receipt of FIN after the
response is received is always going to be a race to some degree.

All of which is why the HTTP pipelining specs encourage you *not* to use
pipelining for non-idempotent requests.  The above patch could be
tweaked to only perform the MSG_PEEK and retry if this is the second or
later pipelined request.  Then, following the HTTP recommendations and
always calling HttpConnection.close()/HttpConnection.connect() before
invoking "unsafe" requests like POST, would make the whole thing safe.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Sat Aug 23 18:03:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Aug 2008 16:03:38 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1219507418.69.0.933120053865.issue3623@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Sat Aug 23 18:39:22 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 23 Aug 2008 16:39:22 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219509562.97.0.0204546749348.issue3643@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Sat Aug 23 18:55:55 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 23 Aug 2008 16:55:55 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Calling sys.excepthook(1,'1',1) crashes 3.0:

Python 3.0b3+ (py3k:65987, Aug 23 2008, 10:04:31)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.excepthook(1,'1',1)
Segmentation fault

gdb points at "PyException_GetTraceback  at Objects/exceptions.c:265
265         Py_XINCREF(base_self->traceback);"

This was found by Fusil and Victor Stinner (haypo) sent me a patch (see
attachment).

Thanks bpeterson for triaging :)

PS: I also think that issue3643 should be targeted to 3.0, as the
underlying issue is the same, it would be an easy way to segfault
python3.0 and has a clean patch available.

----------
components: Interpreter Core
files: print_exception.patch
keywords: patch
messages: 71807
nosy: ajaksu2
severity: normal
status: open
title: segfault calling sys.excepthook with non-Exception argument
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file11229/print_exception.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sat Aug 23 18:58:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Aug 2008 16:58:16 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219510696.04.0.0100604257284.issue3653@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sat Aug 23 20:31:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Aug 2008 18:31:52 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219516313.0.0.503529332465.issue3643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@pitrou: This issue is not critical. It's not a bug, it's an 
enhancement since _testcapi :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Sat Aug 23 21:46:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Aug 2008 19:46:27 +0000
Subject: [issue3601] test_unicode.test_raiseMemError fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1219520787.37.0.858282559144.issue3601@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch is ok on both UCS2 and UCS4 builds (on 32-bit machines).
Someone should test it on a 64-bit machine.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11230/memerror2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________

From report at bugs.python.org  Sat Aug 23 21:53:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Aug 2008 19:53:16 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219521196.99.0.733058733184.issue3643@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Still, _testcapi is built even for non-debug builds, so it is a
gratuitous way for bad code to crash or internally invalidate a Python
interpreter, so this should be treated like a bugfix.

----------
nosy: +georg.brandl
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Sat Aug 23 21:55:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Aug 2008 19:55:09 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219521309.23.0.63281291262.issue3653@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks good.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sat Aug 23 22:08:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Aug 2008 20:08:23 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219522103.59.0.86747105436.issue3653@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Applied in r65998.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sat Aug 23 22:28:18 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 23 Aug 2008 20:28:18 +0000
Subject: [issue3654] Duplicated test name in regex test script
In-Reply-To: <1219523298.64.0.249650635001.issue3654@psf.upfronthosting.co.za>
Message-ID: <1219523298.64.0.249650635001.issue3654@psf.upfronthosting.co.za>


New submission from Matthew Barnett <python at mrabarnett.plus.com>:

The regex test script test_re.py has 2 tests called 'test_ignore_case'.

----------
components: Tests
messages: 71813
nosy: mrabarnett
severity: normal
status: open
title: Duplicated test name in regex test script
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3654>
_______________________________________

From report at bugs.python.org  Sat Aug 23 22:33:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Aug 2008 20:33:12 +0000
Subject: [issue3643] Add more checks to testcapi
In-Reply-To: <1219369283.37.0.028447493951.issue3643@psf.upfronthosting.co.za>
Message-ID: <1219523592.25.0.318093300038.issue3643@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fair enough. Fixed in r66000 (trunk) and r66001 (py3k).

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6, Python 3.0 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3643>
_______________________________________

From report at bugs.python.org  Sat Aug 23 22:36:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Aug 2008 20:36:33 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219523793.99.0.0170314675493.issue3653@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch should probably used PyErr_Format() followed by
PyErr_WriteUnraisable().

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sat Aug 23 22:46:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Aug 2008 20:46:12 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219524372.54.0.27811694685.issue3653@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching new patch...

Added file: http://bugs.python.org/file11231/use_unraiseable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sat Aug 23 23:11:02 2008
From: report at bugs.python.org (Pauli Virtanen)
Date: Sat, 23 Aug 2008 21:11:02 +0000
Subject: [issue3655] latexwriter: \footnotemark can only take numbers as
	arguments
In-Reply-To: <1219525862.69.0.109867227566.issue3655@psf.upfronthosting.co.za>
Message-ID: <1219525862.69.0.109867227566.issue3655@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

LaTeXTranslator.visit_footnote_reference generates improper Latex if 
the footnote marker given is not a number. This will result in a Latex 
error if the RST document contains footnotes where the marker is not a 
number.

The problem is that the Latex commands \footnotemark and \footnotetext 
apparently expect their [] argument to always be a number.

For example:

    \footnotemark[x]

results to error:

    ! Missing number, treated as zero.
    <to be read again> 
                       x
    l.4733 ...\footnotemark[x]

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 71817
nosy: georg.brandl, pv
severity: normal
status: open
title: latexwriter: \footnotemark can only take numbers as arguments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3655>
_______________________________________

From report at bugs.python.org  Sat Aug 23 23:40:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Aug 2008 21:40:15 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1219527615.55.0.228061300303.issue874900@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is also causing hangs in 2.5.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Aug 24 00:38:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 22:38:46 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219531126.49.0.539530950329.issue3651@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Ignoring the question of whether owning the reference is the right thing
or not, the patch looks fine, although I don't see a reason for the
decrements to not be Py_DECREF since the function calls just won't even
happen if the object that the buffer is being created for is NULL.

As for changing whether Py_buffer holds a reference, that's tricky.
Removing the increment from PyBuffer_FillInfo() segfaults the
interpreter, so some code already assumes it does increment. There is
also the question of what the common use-case is; are buffers more like
items from a container, or their own object? The former says to
increment, the latter says to decrement. And since Py_buffer objects are
not true Python objects you can't just Py_DECREF() them.

My gut says to let buffers own a reference and to fix the "s#" leak.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 00:42:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Aug 2008 22:42:52 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219531372.04.0.982787292692.issue3642@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

There is no patch here, so undoing the "needs review" flag.

----------
keywords:  -needs review
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Sun Aug 24 01:26:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Aug 2008 23:26:45 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219534005.78.0.51575155874.issue3651@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

Making Py_buffer INCREF the original object is IMO the right thing to
do, because in most cases letting the original object disappear means
the memory region will become invalid as well. If you don't want the
INCREF, you can pass NULL as the obj parameter to PyBuffer_FillInfo() -
a piece of code in unicodeobject.c does just that.

However, since this decision was made recently (at the same time the s*
format codes were introduced), it is not reflected in the buffer API
documentation.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 02:28:05 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Aug 2008 00:28:05 +0000
Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning
In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
Message-ID: <1219537685.19.0.364740973083.issue2351@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I reviewed the patch and made some changes (which I uploaded). Mostly
changed the punctuation of the warning, made sure that PyErr_WarnPy3k()
was used for all cases, and simplified the code for the test.

Assigning to Benjamin for him to decide if he likes the changes to his
patch (which I probably should have done in Rietveld in hindsight =).

----------
assignee:  -> benjamin.peterson
keywords:  -26backport
type:  -> behavior
Added file: http://bugs.python.org/file11232/slice_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
_______________________________________

From report at bugs.python.org  Sun Aug 24 03:00:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 01:00:06 +0000
Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning
In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
Message-ID: <1219539606.88.0.248315348847.issue2351@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Those changes are great; thanks for the review! Are you happy enough
with it to let me apply?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
_______________________________________

From report at bugs.python.org  Sun Aug 24 03:56:45 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 24 Aug 2008 01:56:45 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1219543005.45.0.537125695395.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

it passes on release25-maint for me on linux.  i don't see it hanging in
any of the 2.5 buildbots.  looks like your r66003 change was a decent
fix for windows judging by the buildbot.

(fwiw, that test you patched in 66003 should probably use readlines()
and assertListEqual to be cross platform rather than the code thats
there now but i'm not motivated to change that unless some other
platform fails on it)

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Aug 24 04:43:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 02:43:38 +0000
Subject: [issue3637] 2to3 refactoring
In-Reply-To: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>
Message-ID: <1219545818.43.0.591554061725.issue3637@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3637>
_______________________________________

From report at bugs.python.org  Sun Aug 24 05:01:51 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 03:01:51 +0000
Subject: [issue3656] unicode encoding has lots of leaks of bytes
In-Reply-To: <1219546911.7.0.779995437215.issue3656@psf.upfronthosting.co.za>
Message-ID: <1219546911.7.0.779995437215.issue3656@psf.upfronthosting.co.za>


New submission from Neal Norwitz <nnorwitz at gmail.com>:

Some of these leaks reported by valgrind are likely duplicates.  I don't
know how many individual cases of these leaks there are.

11,119 bytes in 14 blocks are possibly lost in loss record 86 of 119
    realloc (vg_replace_malloc.c:429)
    _PyBytes_Resize (bytesobject.c:3159)
    multibytecodec_encode (multibytecodec.c:536)
    MultibyteCodec_Encode (multibytecodec.c:588)
    PyObject_Call (abstract.c:2181)
    PyEval_CallObjectWithKeywords (ceval.c:3283)
    PyCodec_Encode (codecs.c:354)
    PyUnicodeUCS2_AsEncodedString (unicodeobject.c:1347)
    unicode_encode (unicodeobject.c:6682)
    PyEval_EvalFrameEx (ceval.c:3403)
    PyEval_EvalFrameEx (ceval.c:3491)
    PyEval_EvalCodeEx (ceval.c:2840)

11,882 bytes in 15 blocks are possibly lost in loss record 87 of 119
    malloc (vg_replace_malloc.c:207)
    PyBytes_FromStringAndSize (bytesobject.c:87)
    PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2250)
    utf_8_encode (_codecsmodule.c:719)
    PyEval_EvalFrameEx (ceval.c:3403)
    PyEval_EvalFrameEx (ceval.c:3491)
    PyEval_EvalFrameEx (ceval.c:3491)
    PyEval_EvalCodeEx (ceval.c:2840)
    function_call (funcobject.c:628)
    PyObject_Call (abstract.c:2181)
    PyEval_EvalFrameEx (ceval.c:3704)
    PyEval_EvalCodeEx (ceval.c:2840)

271,937 bytes in 437 blocks are definitely lost in loss record 108 of 119
    malloc (vg_replace_malloc.c:207)
    PyBytes_FromStringAndSize (bytesobject.c:87)
    PyEval_EvalFrameEx (ceval.c:3403)
    PyEval_EvalCodeEx (ceval.c:2840)
    PyEval_EvalFrameEx (ceval.c:3501)
    PyEval_EvalFrameEx (ceval.c:3491)
    PyEval_EvalCodeEx (ceval.c:2840)
    function_call (funcobject.c:628)
    PyObject_Call (abstract.c:2181)
    PyEval_EvalFrameEx (ceval.c:3704)
    PyEval_EvalCodeEx (ceval.c:2840)
    function_call (funcobject.c:628)


331,647 bytes in 277 blocks are definitely lost in loss record 111 of 119
    realloc (vg_replace_malloc.c:429)
    _PyBytes_Resize (bytesobject.c:3159)
    PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2256)
    _PyUnicodeUCS2_AsDefaultEncodedString (unicodeobject.c:1412)
    source_as_string (bltinmodule.c:504)
    builtin_exec (bltinmodule.c:788)
    PyEval_EvalFrameEx (ceval.c:3403)
    PyEval_EvalCodeEx (ceval.c:2840)
    PyEval_EvalFrameEx (ceval.c:3501)
    PyEval_EvalCodeEx (ceval.c:2840)
    PyEval_EvalCode (ceval.c:519)
    builtin_exec (bltinmodule.c:785)

274,686 bytes in 446 blocks are definitely lost in loss record 114 of 128
    malloc (vg_replace_malloc.c:207)
    PyBytes_FromStringAndSize (bytesobject.c:87)
    PyEval_EvalFrameEx (ceval.c:3403)
    PyEval_EvalCodeEx (ceval.c:2840)
    PyEval_EvalFrameEx (ceval.c:3501)
    PyEval_EvalFrameEx (ceval.c:3491)
    PyEval_EvalCodeEx (ceval.c:2840)
    function_call (funcobject.c:628)
    PyObject_Call (abstract.c:2181)
    PyEval_EvalFrameEx (ceval.c:3704)
    PyEval_EvalCodeEx (ceval.c:2840)
    function_call (funcobject.c:628)

734,178 bytes in 293 blocks are definitely lost in loss record 121 of 
    realloc (vg_replace_malloc.c:429)
    _PyBytes_Resize (bytesobject.c:3159)
    PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2256)
    _PyUnicodeUCS2_AsDefaultEncodedString (unicodeobject.c:1412)
    source_as_string (bltinmodule.c:504)
    builtin_exec (bltinmodule.c:788)
    PyEval_EvalFrameEx (ceval.c:3403)
    PyEval_EvalCodeEx (ceval.c:2840)
    PyEval_EvalFrameEx (ceval.c:3501)
    PyEval_EvalCodeEx (ceval.c:2840)
    PyEval_EvalCode (ceval.c:519)
    builtin_exec (bltinmodule.c:785)

----------
components: Interpreter Core
messages: 71825
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: unicode encoding has lots of leaks of bytes
type: resource usage
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3656>
_______________________________________

From report at bugs.python.org  Sun Aug 24 05:30:09 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 03:30:09 +0000
Subject: [issue3656] unicode encoding has lots of leaks of bytes
In-Reply-To: <1219546911.7.0.779995437215.issue3656@psf.upfronthosting.co.za>
Message-ID: <1219548609.74.0.876637133611.issue3656@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

There are also tons of reference leaks when running regrtest.py with -R.
 Even code as simple as this leaks:

>>> eval('1')
1
[40731 refs]
>>> eval('1')
1
[40732 refs]
>>> eval('1')
1
[40733 refs]
>>> eval('1')
1
[40734 refs]
>>> eval('1')
1
[40735 refs]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3656>
_______________________________________

From report at bugs.python.org  Sun Aug 24 07:27:22 2008
From: report at bugs.python.org (Igor do Valle Campbell)
Date: Sun, 24 Aug 2008 05:27:22 +0000
Subject: [issue1346] Error using >>> from OpenGL.GLUT import *
In-Reply-To: <1193524395.52.0.467041983847.issue1346@psf.upfronthosting.co.za>
Message-ID: <1219555642.75.0.394340437513.issue1346@psf.upfronthosting.co.za>


Igor do Valle Campbell <igorcamp at gmail.com> added the comment:

You have to put the glut32.dll in Windows/system32 folder.

You can get glut32.dll here:

http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip

extract the glut32.dll to the Windows/system32 folder and voila.

----------
nosy: +igorcamp
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346>
_______________________________________

From report at bugs.python.org  Sun Aug 24 07:51:20 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 05:51:20 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219557080.26.0.73828198212.issue3651@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

This is a partial (or complete) duplicate of 3656.

----------
nosy: +nnorwitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 07:51:35 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 05:51:35 +0000
Subject: [issue3656] unicode encoding has lots of leaks of bytes
In-Reply-To: <1219546911.7.0.779995437215.issue3656@psf.upfronthosting.co.za>
Message-ID: <1219557095.08.0.645398929128.issue3656@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

This is a partial (or complete) duplicate of 3651.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3656>
_______________________________________

From report at bugs.python.org  Sun Aug 24 09:01:48 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 07:01:48 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>


New submission from Neal Norwitz <nnorwitz at gmail.com>:

test_pickletools fails sporadically on at least two platforms I've seen.

http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/4120/step-test/0
http://www.python.org/dev/buildbot/all/ppc%20Debian%20unstable%20trunk/builds/1908/step-test/0

File
"/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/pickletools.py",
line ?, in pickletools.__test__.disassembler_test
Failed example:
    dis(pickle.dumps(random.random, 0))
Expected:
        0: c    GLOBAL     'random random'
       15: p    PUT        0
       18: .    STOP
    highest protocol among opcodes = 0
Got:
        0: c    GLOBAL     'bsddb.test.test_thread random'
       31: p    PUT        0
       34: .    STOP
    highest protocol among opcodes = 0
**********************************************************************
1 items had failures:
   1 of  25 in pickletools.__test__.disassembler_test

----------
components: Interpreter Core
messages: 71830
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: pickle can pickle the wrong function
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Sun Aug 24 09:09:14 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 07:09:14 +0000
Subject: [issue3627] apple security patches need to be forward ported to py3k
In-Reply-To: <1219297422.68.0.603691629557.issue3627@psf.upfronthosting.co.za>
Message-ID: <1219561754.17.0.804013267788.issue3627@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Committed revision 66009.

----------
assignee:  -> nnorwitz
resolution:  -> fixed
status: open -> closed
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3627>
_______________________________________

From report at bugs.python.org  Sun Aug 24 09:14:44 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 07:14:44 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219562084.47.0.249051857414.issue3651@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Even with the patch, there are still tons of leaks.  I don't know if
it's due to the same problem or not.  So far there is:

test_unittest leaked [124, 124] references, sum=248
test_array leaked [110, 110] references, sum=220
test_audioop leaked [75, 75] references, sum=150
test_binascii leaked [4, 4] references, sum=8

There are probably more.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 10:37:49 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 08:37:49 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219567069.48.0.137637479993.issue3653@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

PyErr_Format sets the new exception and returns NULL though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sun Aug 24 11:14:45 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Aug 2008 09:14:45 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219569285.89.0.283105739249.issue3653@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sun Aug 24 11:18:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 09:18:36 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219569516.28.0.841348588026.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The main cause of these leaks is each time PyArg_ParseTuple("s#") is
passed a bytes object.
If FillInfo() increfs the given object, every object should have a
bf_releasebuffer that decrefs it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 11:47:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 09:47:41 +0000
Subject: [issue3656] unicode encoding has lots of leaks of bytes
In-Reply-To: <1219546911.7.0.779995437215.issue3656@psf.upfronthosting.co.za>
Message-ID: <1219571261.15.0.964493433526.issue3656@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> eval() leaks 1 reference every time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3656>
_______________________________________

From report at bugs.python.org  Sun Aug 24 12:36:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 10:36:31 +0000
Subject: [issue3654] Duplicated test name in regex test script
In-Reply-To: <1219523298.64.0.249650635001.issue3654@psf.upfronthosting.co.za>
Message-ID: <1219574191.85.0.799118478928.issue3654@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
type:  -> behavior
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3654>
_______________________________________

From report at bugs.python.org  Sun Aug 24 13:23:50 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 11:23:50 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219569516.28.0.841348588026.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219577023.5555.7.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 24 ao?t 2008 ? 09:18 +0000, Amaury Forgeot d'Arc a ?crit :
> If FillInfo() increfs the given object, every object should have a
> bf_releasebuffer that decrefs it.

There's no need for that, PyBuffer_Release() does the decref.
But PyBuffer_Release() must be used instead of calling bf_releasebuffer
directly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 15:10:29 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 24 Aug 2008 13:10:29 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

Attached is a patch to fix some pychecker complaints Neal Norwitz
uncovered.  All involved tests pass.  Submitting patch simply because
we're past beta3.

----------
assignee: nnorwitz
components: Library (Lib)
files: pychecker.diff
keywords: easy, needs review, patch
messages: 71836
nosy: nnorwitz, skip.montanaro
severity: normal
status: open
title: fix for pychecker property complaints
versions: Python 2.6
Added file: http://bugs.python.org/file11233/pychecker.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________

From report at bugs.python.org  Sun Aug 24 16:18:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 14:18:28 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1219587508.16.0.387489646044.issue3658@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It doubt many people are inheriting from the classes that are changed to
new-style in the patch, but I thought it was policy that we didn't
change that until 3.0 "just in case".

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________

From report at bugs.python.org  Sun Aug 24 16:35:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 14:35:18 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1219588518.06.0.408908353808.issue3653@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file11234/use_unraiseable_better.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3653>
_______________________________________

From report at bugs.python.org  Sun Aug 24 17:21:47 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 24 Aug 2008 15:21:47 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1219591307.76.0.878961669083.issue3658@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I can see where that might be a problem.  If that's the case I suspect 
those property attributes should be changed.  OTOH, do properties work on 
classic classes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________

From report at bugs.python.org  Sun Aug 24 18:11:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 16:11:55 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1219594315.17.0.754750450736.issue3658@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Read-only properties on old-style classes seem to work (though I don't
know if that is an implementation accident), insofar it seems harmless
not to apply this patch.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________

From report at bugs.python.org  Sun Aug 24 18:11:56 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 16:11:56 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

I'm getting the compiler warning:

Modules/_sqlite/statement.c: In function
'pysqlite_statement_bind_parameter':
Modules/_sqlite/statement.c:133: warning: enumeration value
'TYPE_STRING' not handled in switch

I tried to make sense of the code before the warning. It looks like
TYPE_STRING isn't handled at all. The warning may be sign for a design
flaw or missing feature in the code.

----------
components: Extension Modules
messages: 71839
nosy: christian.heimes
priority: release blocker
severity: normal
status: open
title: sqlite: enumeration value 'TYPE_STRING' not handled in switch
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Sun Aug 24 18:13:58 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 16:13:58 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1219594438.83.0.522634281632.issue3658@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

No, they don't work correctly. Readonly properties in old style classes
aren't readonly:

>>> class Example:
...     @property
...     def spam(self):
...         return "spam"
...
>>> example = Example()
>>> example.spam
'spam'
>>> example.spam = "egg"
>>> example.spam
'egg'

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________

From report at bugs.python.org  Sun Aug 24 18:15:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 16:15:41 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1219594541.99.0.753515428765.issue3658@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ah yes. But still, I'd call that harmless. Assigning to attributes
you're not supposed to assign to is detrimental in many cases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________

From report at bugs.python.org  Sun Aug 24 18:42:58 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 16:42:58 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219596178.16.0.212990991434.issue3642@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I've fixed both compiler warnings in trunk and py3k branch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Sun Aug 24 18:55:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 16:55:39 +0000
Subject: [issue3637] 2to3 refactoring
In-Reply-To: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>
Message-ID: <1219596939.05.0.180453617425.issue3637@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This also restores 2.5 compatibility.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3637>
_______________________________________

From report at bugs.python.org  Sun Aug 24 19:38:12 2008
From: report at bugs.python.org (Pascal Bach)
Date: Sun, 24 Aug 2008 17:38:12 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219599492.26.0.94524966892.issue3649@psf.upfronthosting.co.za>


Pascal Bach <pascal.bach at nextrem.ch> added the comment:

I have looked at utf_8.py and I think I know how to implement the
incremental de/encoder. But I don't understand the codecs.register()
function. Do I have to provide stateless, stateful and streamwriter at
the same time? 
If I implement IncrementalEncoder and IncrementalDecoder can I just give
those two to codecs.register()?

Thank you for your help.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Sun Aug 24 19:57:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Aug 2008 17:57:04 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219600624.65.0.619297673716.issue3574@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Since this is marked "release blocker", I'll provide a shallow comment:

I don't think it should be a release blocker. It's a bug in the compile
function, and there are various work-arounds (such as saving the bytes
to a temporary file and executing that one, or decoding the byte string
to a Unicode string, and then compiling the Unicode string). It is
sufficient to fix it in 3.0.1.

I don't think the patch is right: as the test had to be changed, it
means that somewhere, the detection of the encoding declaration now
fails. This is clearly a new bug, but I don't have the time to analyse
the cause further.

In principle, there is nothing wrong with the tokenizer treating latin-1
as "raw" - that only means we don't go through a codec.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 24 20:01:54 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Aug 2008 18:01:54 +0000
Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning
In-Reply-To: <1219539606.88.0.248315348847.issue2351@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808241101h56c8217fg2f06436df496d6dc@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sat, Aug 23, 2008 at 6:00 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Those changes are great; thanks for the review! Are you happy enough
> with it to let me apply?
>

Yep.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
_______________________________________

From report at bugs.python.org  Sun Aug 24 20:10:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 18:10:46 +0000
Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning
In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za>
Message-ID: <1219601446.31.0.698680754576.issue2351@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Applied in r66013.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2351>
_______________________________________

From report at bugs.python.org  Sun Aug 24 20:11:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 18:11:32 +0000
Subject: [issue3654] Duplicated test name in regex test script
In-Reply-To: <1219523298.64.0.249650635001.issue3654@psf.upfronthosting.co.za>
Message-ID: <1219601492.31.0.371752916311.issue3654@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r66014.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3654>
_______________________________________

From report at bugs.python.org  Sun Aug 24 20:12:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Aug 2008 18:12:07 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219601527.4.0.616660160577.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Actually, the tests don't have to change; if issue 3594 gets applied
then that change cascades into this issue and negates the need to change
the tests themselves.

As for treating Latin-1 as a raw encoding, how can that be theoretically
okay if the parser assumes UTF-8 and Latin-1 is not a superset of Latin-1?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:01:06 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 19:01:06 +0000
Subject: [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1219604466.2.0.329460582945.issue2744@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2744>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:05:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 19:05:14 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219604714.28.0.51601628661.issue3649@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:12:59 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 19:12:59 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>


New submission from Neal Norwitz <nnorwitz at gmail.com>:

Even after adding the current patch in http://bugs.python.org/issue3651
there are many reference leaks.  This bug can be a placeholder for all
the reference leaks returned from:  
  ./python ./Lib/test/regrtest.py -R 3:2 -uall,-bsddb 

The current list is:

test_unittest leaked [124, 124] references, sum=248
test_array leaked [110, 110] references, sum=220
test_audioop leaked [75, 75] references, sum=150
test_binascii leaked [4, 4] references, sum=8
test_binhex leaked [4, 4] references, sum=8
test_codecs leaked [3, 3] references, sum=6
test_ctypes leaked [9, 9] references, sum=18
test_dbm leaked [194, 194] references, sum=388
test_dbm_gnu leaked [2, 2] references, sum=4
test_fcntl leaked [2, 2] references, sum=4
test_file leaked [8, 8] references, sum=16
test_fileio leaked [1, 1] references, sum=2
test_memoryio leaked [3, 3] references, sum=6
test_minidom leaked [5, 5] references, sum=10
test_mmap leaked [307, 307] references, sum=614
test_ossaudiodev leaked [2, 2] references, sum=4
test_pickle leaked [130, 130] references, sum=260
test_pickletools leaked [503, 503] references, sum=1006
test_pyexpat leaked [1, 1] references, sum=2
test_re leaked [4, 4] references, sum=8
test_site leaked [88, 88] references, sum=176
test_socket leaked [13, 13] references, sum=26
test_sqlite leaked [17, 17] references, sum=34
test_ssl leaked [82, 82] references, sum=164
test_struct leaked [5, 5] references, sum=10
test_unicode leaked [2, 2] references, sum=4
test_urllib2_localnet leaked [3, 3] references, sum=6
test_xmlrpc leaked [18, 18] references, sum=36
test_xmlrpc_net leaked [1, 1] references, sum=2
test_zlib leaked [10, 10] references, sum=20

----------
components: Interpreter Core
messages: 71851
nosy: nnorwitz
priority: release blocker
severity: normal
status: open
title: reference leaks in 3.0
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:19:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Aug 2008 19:19:04 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1219601527.4.0.616660160577.issue3574@psf.upfronthosting.co.za>
Message-ID: <48B1B424.4040406@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> As for treating Latin-1 as a raw encoding, how can that be theoretically
> okay if the parser assumes UTF-8 and Latin-1 is not a superset of Latin-1?

The parser doesn't assume UTF-8, but "ascii+", i.e. it passes all
non-ASCII bytes on to the AST, which then needs to deal with them;
it then could (but apparently doesn't) take into account whether the
internal representation was UTF-8 or Latin-1: see ast.c:decode_unicode
for some remains of that.

The other case (besides string literals) where bytes > 127 matter is
tokenizer.c:verify_identifier; this indeed assumes UTF-8 only (but
could be easily extended to support Latin-1 as well).

The third case where non-ASCII bytes are allowed is comments; there
they are entirely ignored (i.e. it is not even verified that the
comment is well-formed UTF-8).

Removal of the special case should simplify the code; I would agree
that any speedup gained by not going through a codec is irrelevant.
I'm still puzzled why test_imp if the special case is removed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:29:05 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 19:29:05 +0000
Subject: [issue3661] sys.call_tracing segfaults
In-Reply-To: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
Message-ID: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

The following code causes a segfault for me:

import sys; sys.call_tracing(type,2)

Running on:
Python 3.0b3+ (py3k:66015, Aug 24 2008, 16:21:19)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

gdb output:
[New Thread -1210857280 (LWP 8823)]
python: Objects/typeobject.c:1854: type_new: Assertion `args != ((void
*)0) && ((((((PyObject*)(args))->ob_type))->tp_flags & ((1L<<26))) !=
0)' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread -1210857280 (LWP 8823)]
0xffffe410 in __kernel_vsyscall ()
(gdb) backtrace
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d67875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d69201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7d60b6e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0x0806e802 in type_new (metatype=0x81ba120, args=0x81fbda8,
kwds=0x0) at Objects/typeobject.c:1854
#5  0x0806bd0e in type_call (type=0x81ba120, args=0x81fbda8, kwds=0x0)
at Objects/typeobject.c:636
#6  0x08118ec5 in PyObject_Call (func=0x81ba120, arg=0x81fbda8, kw=0x0)
at Objects/abstract.c:2181
#7  0x080b2ac5 in _PyEval_CallTracing (func=0x81ba120, args=0x81fbda8)
at Python/ceval.c:3109
#8  0x080e7830 in sys_call_tracing (self=0xb7f073b4, args=0xb7a53bcc) at
Python/sysmodule.c:771
#9  0x081626b1 in PyCFunction_Call (func=0xb7f081bc, arg=0xb7a53bcc,
kw=0x0) at Objects/methodobject.c:81
#10 0x080b378f in call_function (pp_stack=0xbf9b6b84, oparg=2) at
Python/ceval.c:3403
#11 0x080ae8d2 in PyEval_EvalFrameEx (f=0x829bb14, throwflag=0) at
Python/ceval.c:2205
#12 0x080b1c24 in PyEval_EvalCodeEx (co=0xb7a9b9e8, globals=0xb7f0b5d4,
locals=0xb7f0b5d4, args=0x0, argcount=0, kws=0x0,
    kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2840
#13 0x080a69cb in PyEval_EvalCode (co=0xb7a9b9e8, globals=0xb7f0b5d4,
locals=0xb7f0b5d4) at Python/ceval.c:519
#14 0x080df64b in run_mod (mod=0x82a2aa0, filename=0x819e3be "<string>",
globals=0xb7f0b5d4, locals=0xb7f0b5d4,
    flags=0xbf9b6f60, arena=0x82b1060) at Python/pythonrun.c:1560
#15 0x080df393 in PyRun_StringFlags (str=0x8203fd8 "import sys;
sys.call_tracing(type,2)\n", start=257, globals=0xb7f0b5d4,
    locals=0xb7f0b5d4, flags=0xbf9b6f60) at Python/pythonrun.c:1494
#16 0x080ddd37 in PyRun_SimpleStringFlags (command=0x8203fd8 "import
sys; sys.call_tracing(type,2)\n", flags=0xbf9b6f60)
    at Python/pythonrun.c:1073
#17 0x080ef5ca in Py_Main (argc=2, argv=0xb7ede028) at Modules/main.c:533
#18 0x0805a689 in main (argc=2, argv=0xbf9b80b4) at ./Modules/python.c:57

----------
components: Interpreter Core
messages: 71853
nosy: ajaksu2
severity: normal
status: open
title: sys.call_tracing segfaults
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3661>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:37:11 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 19:37:11 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

This snippet causes a segfault from fileio_init calling PyMem_Free:
    
import _fileio; _fileio._FileIO("1",0, 0 )

Found using Fusil

[Switching to Thread -1210070848 (LWP 10184)]
0x0805f5ff in _PyObject_DebugCheckAddress (p=0xb7b2f0e8) at
Objects/obmalloc.c:1461
1461                    if (tail[i] != FORBIDDENBYTE) {
(gdb) backtrace
0  0x0805f5ff in _PyObject_DebugCheckAddress (p=0xb7b2f0e8) at
Objects/obmalloc.c:1461
1  0x0805f3c4 in _PyObject_DebugFree (p=0xb7b2f0e8) at
Objects/obmalloc.c:1375
2  0x0805de07 in PyMem_Free (p=0xb7b2f0e8) at Objects/object.c:1693
3  0x0810afa9 in fileio_init (oself=0xb7b18238, args=0xb7b815b4,
kwds=0x0) at ./Modules/_fileio.c:281
4  0x0806bdd0 in type_call (type=0x81d3760, args=0xb7b815b4, kwds=0x0)
at Objects/typeobject.c:650
5  0x08118ec5 in PyObject_Call (func=0x81d3760, arg=0xb7b815b4, kw=0x0)
at Objects/abstract.c:2181
6  0x080b42a5 in do_call (func=0x81d3760, pp_stack=0xbfab5c84, na=3,
nk=0) at Python/ceval.c:3616
7  0x080b394a in call_function (pp_stack=0xbfab5c84, oparg=3) at
Python/ceval.c:3426
8  0x080ae8d2 in PyEval_EvalFrameEx (f=0x829bb14, throwflag=0) at
Python/ceval.c:2205
9  0x080b1c24 in PyEval_EvalCodeEx (co=0xb7b5b9e8, globals=0xb7fcc5d4,
locals=0xb7fcc5d4, args=0x0, argcount=0, kws=0x0,
    kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2840
10 0x080a69cb in PyEval_EvalCode (co=0xb7b5b9e8, globals=0xb7fcc5d4,
locals=0xb7fcc5d4) at Python/ceval.c:519
11 0x080df64b in run_mod (mod=0x82a2ac0, filename=0x819e3be "<string>",
globals=0xb7fcc5d4, locals=0xb7fcc5d4,
    flags=0xbfab6060, arena=0x82b1060) at Python/pythonrun.c:1560
12 0x080df393 in PyRun_StringFlags (str=0x8203fd8 "import _fileio;
_fileio._FileIO('1',0, 0 )\n", start=257,
    globals=0xb7fcc5d4, locals=0xb7fcc5d4, flags=0xbfab6060) at
Python/pythonrun.c:1494
13 0x080ddd37 in PyRun_SimpleStringFlags (command=0x8203fd8 "import
_fileio; _fileio._FileIO('1',0, 0 )\n",
    flags=0xbfab6060) at Python/pythonrun.c:1073
14 0x080ef5ca in Py_Main (argc=2, argv=0xb7f9e028) at Modules/main.c:533
15 0x0805a689 in main (argc=2, argv=0xbfab71b4) at ./Modules/python.c:57

----------
messages: 71854
nosy: ajaksu2
severity: normal
status: open
title: _fileio._FileIO segfaults
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:44:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 19:44:50 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219607090.19.0.604165105548.issue3662@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:53:27 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Aug 2008 19:53:27 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1219607607.92.0.657266435422.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The test_imp stuff has to do with PyTokenizer_FindEncoding().
imp.find_module() only opens the file, passes the file descriptor to
PyTokenizer_FindEncoding() and then returns a file object with the found
encoding.

Problem is that (as issue 3594 points out), PyTokenizer_FindEncoding()
always fails. That means it assumes only the raw encodings are okay.
With Latin-1 being one of them, it returns the file opened as Latin-1 as
is correct. Removing that case here means PyTokenizer_FindEncoding()
fails, and thus assumes only UTF-8 as a legitimate encoding and opens
the files with the UTF-8 encoding. It took a while to find these two
bugs obviously. =)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sun Aug 24 21:58:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 19:58:20 +0000
Subject: [issue3661] sys.call_tracing segfaults
In-Reply-To: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
Message-ID: <1219607900.63.0.209616051372.issue3661@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The function call fails much earlier in debug builds. sys_call_tracing()
doesn't check the type of the second argument. It must be a tuple
because it's directly passed to the PyObject_Call() API.

Suggestion: Add an explicit type check for PyTupleType the
sys_call_tracing() function

Check 2.6, too

----------
nosy: +christian.heimes
priority:  -> release blocker
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3661>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:03:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 20:03:10 +0000
Subject: [issue3661] sys.call_tracing segfaults
In-Reply-To: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
Message-ID: <1219608190.91.0.957826943095.issue3661@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Not applicable in 2.6:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() takes 1 or 3 arguments

----------
nosy: +benjamin.peterson
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3661>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:06:59 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 20:06:59 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219608419.12.0.820933037446.issue3662@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The FileIO construct segfaults because PyArg_ParseTupleAndKeywords()
sets name to an invalid but non NULL value. PyMem_Free() tries to
deallocate name but fails.

Suggestion: Either appy this patch or change
PyArg_ParseTupleAndKeyword()'s behavior for 'e'.

Index: Modules/_fileio.c
===================================================================
--- Modules/_fileio.c   (Revision 66010)
+++ Modules/_fileio.c   (Arbeitskopie)
@@ -174,8 +174,10 @@
                if (!PyArg_ParseTupleAndKeywords(args, kwds, "et|si:fileio",
                                                 kwlist,
                                                
Py_FileSystemDefaultEncoding,
-                                                &name, &mode, &closefd))
+                                                &name, &mode, &closefd)) {
+                       name = NULL;
                        goto error;
+                       }
            }
        }

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:07:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 20:07:08 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219608428.5.0.658630870186.issue3662@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:20:30 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 20:20:30 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

The following output is very suspect: the total number of references
decreases!

Python 3.0b3+ (py3k, Aug 24 2008, 21:56:40) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f(1=1)
  File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42055 refs]
>>> f(1=1)
  File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42054 refs]
>>> f(1=1)
  File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42053 refs]
>>> f(1=1)
  File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42052 refs]
>>> f(1=1)
  File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42051 refs]
>>> f(1=1)
  File "<stdin>", line 1
SyntaxError: keyword can't be an expression
[42050 refs]

After several hundred statements, I got:
Fatal Python error: deallocating None

----------
messages: 71859
nosy: amaury.forgeotdarc
priority: deferred blocker
severity: normal
status: open
title: Extra DECREF on syntax errors
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:23:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 20:23:11 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219609392.0.0.576041785841.issue3663@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:26:35 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 20:26:35 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

This script segfaults:
##
import _pickle
obj = _pickle.Pickler(open("/bin/ls")) #can be open(__file__) for scripts
try: obj.__init__('pouet', 87)
except Exception as err: pass

obj.dump(0)
###


[Switching to Thread -1210775360 (LWP 19096)]
0xb79fbf91 in pickler_write (self=0xb7a2fe4c, s=0xbff441a1 "...", n=2)
    at /home/ajaksu/py3k/Modules/_pickle.c:442
442                 memcpy(self->write_buf + self->buf_size, s, n);
(gdb) backtrace
#0  0xb79fbf91 in pickler_write (self=0xb7a2fe4c, s=0xbff441a1 "...",
    n=2) at /home/ajaksu/py3k/Modules/_pickle.c:442
#1  0xb7a00a8c in dump (self=0xb7a2fe4c, obj=0x81fbd78) at
/home/ajaksu/py3k/Modules/_pickle.c:2288
#2  0xb7a00bb8 in Pickler_dump (self=0xb7a2fe4c, args=0xb7b30034) at
/home/ajaksu/py3k/Modules/_pickle.c:2328
#3  0x081626b1 in PyCFunction_Call (func=0xb796c3ec, arg=0xb7b30034,
kw=0x0) at Objects/methodobject.c:81
#4  0x080b378f in call_function (pp_stack=0xbff442e4, oparg=1) at
Python/ceval.c:3403
#5  0x080ae8d2 in PyEval_EvalFrameEx (f=0x829bafc, throwflag=0) at
Python/ceval.c:2205
#6  0x080b1c24 in PyEval_EvalCodeEx (co=0xb7acf2c8, globals=0xb7a9a8f4,
locals=0xb7a9a8f4, args=0x0, argcount=0, kws=0x0,
    kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:2840

Found using Fusil.

----------
messages: 71860
nosy: ajaksu2
severity: normal
status: open
title: Pickler.dump from a badly initialized Pickler segfaults
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:27:45 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 20:27:45 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1219609665.2.0.347845587859.issue3664@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> alexandre.vassalotti
nosy: +alexandre.vassalotti
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:33:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 20:33:52 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Since \u and \U aren't interpolated in raw strings anymore, the re
module should support those escapes in addition to the \x and octal ones
it already does.  Attached patch.

----------
components: Library (Lib)
files: re_unicode_escapes.diff
keywords: patch
messages: 71861
nosy: georg.brandl
priority: critical
severity: normal
status: open
title: Support \u and \U escapes in regexes
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11235/re_unicode_escapes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:39:12 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 24 Aug 2008 20:39:12 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

The following crashes the interpreter on exit:

import sys, atexit; atexit.register(lambda: 1, 0, 0, (x for x in (1,2)),
0, 0); sys.exit()

Found with Fusil.

----------
messages: 71862
nosy: ajaksu2
severity: normal
status: open
title: atexit.register with bad input segfaults on exit
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:44:12 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 20:44:12 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1219610652.08.0.164380358894.issue3664@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

pickler_write() has no check for self->write_buf == NULL

Suggested patch:
===================================================================
--- Modules/_pickle.c   (Revision 66010)
+++ Modules/_pickle.c   (Arbeitskopie)
@@ -421,6 +421,10 @@
 {
     PyObject *data, *result;

+    if (self->write_buf == NULL) {
+        PyErr_SetString(PyExc_SystemError, "Invalid write buffer");
+        return -1;
+    }
     if (s == NULL) {
         if (!(self->buf_size))
             return 0;

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:44:40 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 20:44:40 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1219610680.15.0.942968906474.issue3666@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:49:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 20:49:11 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1219610951.6.0.279342833036.issue3665@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

- Check that it also works for chars > 0xFFFF (even in UCS2 builds, at
least when the chars are not part of [character range])
- What does happen with e.g. [\U00010000-\U00010001] on an UCS build?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:49:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 20:49:34 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1219610974.43.0.375748786639.issue3665@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(in the last sentence, I meant UCS2. Sorry)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:53:24 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 20:53:24 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1219611204.1.0.326409421392.issue3666@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'm getting hundreds of lines

Fatal Python error: PyThreadState_Get: no current thread

The Python process segfaults in call_ll_exitfuncs -> atexit_cleanup() ->
atexit_clear() ->  atexit_delete_cb -> Py_DECREF(cb->args)

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:55:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 20:55:00 +0000
Subject: [issue3667] Reloading an extension module always leaks
In-Reply-To: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>
Message-ID: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

With python2.6, reloading extension modules does not always leak memory:

Python 2.6b2+ (trunk, Aug 19 2008, 23:45:24) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[34467 refs]
>>> import audioop; del sys.modules['audioop']
[34677 refs]
>>> import audioop; del sys.modules['audioop']
[34677 refs]

But with 3.0, reloading audioop leaks 60 references every time (seen in
test_unittest):

Python 3.0b3+ (py3k, Aug 24 2008, 21:56:40) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[42018 refs]
>>> import audioop; del sys.modules['audioop']
[42257 refs]
>>> import audioop; del sys.modules['audioop']
[42317 refs]
>>> import audioop; del sys.modules['audioop']
[42377 refs]
>>> import audioop; del sys.modules['audioop']
[42437 refs]
>>> import audioop; del sys.modules['audioop']
[42497 refs]

OK, many things cannot be reinitialized for C-written modules (static
variables &co), this is not the case for audioop. Furthermore, I thought
that the new module API was to support proper cleanup of modules

----------
messages: 71867
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: Reloading an extension module always leaks
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3667>
_______________________________________

From report at bugs.python.org  Sun Aug 24 22:58:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 20:58:28 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1219611508.6.0.918064592289.issue3665@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

These concerns indeed must be handled: On narrow unicode builds, chars >
0xffff must be converted to surrogates. In ranges, they should raise an
error.

Additionally, this should at least raise an error too:

>>> re.compile("[\U00100000]").match("\U00100000").group()
'\udbc0'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:01:33 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 21:01:33 +0000
Subject: [issue3610] Fix gdbinit for Python 3.0
In-Reply-To: <1219194498.13.0.487280154525.issue3610@psf.upfronthosting.co.za>
Message-ID: <1219611693.82.0.761296758636.issue3610@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

I fixed some problems in r66016.  This patch seems like it has other
things which might be useful, so I'll keep it open until it's handled.

----------
nosy: +nnorwitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3610>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:02:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 21:02:58 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

When PyArg_ParseTuple correctly parses a s* format, but raises an
exception afterwards (for a subsequent parameter), the user code will
not call PyBuffer_Release() and memory will leak.
Seen by "regrtest -R:: test_binascii"

For example:
>>> binascii.a2b_qp("", **{1:1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: keywords must be strings
[42278 refs]
>>> binascii.a2b_qp("", **{1:1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: keywords must be strings
[42279 refs]
>>> binascii.a2b_qp("", **{1:1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: keywords must be strings
[42280 refs]


The same pattern was correctly handled by the "et#" type (where the user
has to call PyMem_Free) with the help of a cleanup list (see the
addcleanup() function in getargs.c). (See issue501716)

----------
messages: 71870
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: "s*" argument parser marker leaks memory
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:03:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 21:03:48 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219611828.89.0.678231646139.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This new version of the patch modifies getargs.c and use
PyObject_GetBuffer and PyBuffer_Release in place of the raw bf_getbuffer
and bf_releasebuffer.
Also make sure that each GetBuffer is matched with a ReleaseBuffer
(except for s* and w*, where the calling code is responsible for this)

This seems to correct most of the refleaks mentioned above, except:

- test_unittest leaks 120 refs because the 'audioop' module is
re-imported many times. See issue3667, or the test case should be dropped.

- test_binascii leaks one time because of issue3668.

Added file: http://bugs.python.org/file11236/buffer-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:10:03 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 21:10:03 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1219612203.74.0.299935977244.issue3666@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I was able to trace the error to its apartment. During the cleanup
gen_del calls PyErr_Fetch() which fails in PyThreadState_GET().

Conclusion:
The atexit cleanup method must be called much earlier.
call_ll_exitfunc() is too late. I suggest a new function that calls
atexit_cleanup() right after atexit_callfuncs().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:13:26 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Sun, 24 Aug 2008 21:13:26 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1219612406.28.0.241779655738.issue3139@psf.upfronthosting.co.za>


Travis Oliphant <oliphant at enthought.com> added the comment:

I'm sorry that I was unavailable for comment during July and August as
it looks like a lot of decisions were made that have changed the
semantics a bit.  I'm still trying to figure out why the decisions were
made that were made.   

I get the impression that most of the problems are related to objects
incorrectly managing their exported buffers, but there may be some
semantic issues related to "t#" that were not conceived of during the
many discussions surrounding the design of PEP 3118.  

I'm not convinced that Py_buffer should have grown a link to an object.
 I think this is a shortcut solution due to misuse of the protocol that
may have unfortunate consequences. 

I'm not sure where PyBuffer_Release came from.  I can't find it in the
PEP and don't remember what it's purpose is.  Did I add it or did
somebody elese?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:16:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 24 Aug 2008 21:16:28 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219612588.43.0.422016094533.issue3662@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The "goto error" is not necessary here. Nothing has been allocated at
this point, and "return -1" is enough.

Index: Modules/_fileio.c
===================================================================
--- Modules/_fileio.c   (revision 65957)
+++ Modules/_fileio.c   (working copy)
@@ -175,7 +175,7 @@
                                                 kwlist,
                                                
Py_FileSystemDefaultEncoding,
                                                 &name, &mode, &closefd))
-                       goto error;
+                       return -1;
            }
        }

----------
keywords: +needs review
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:19:08 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Sun, 24 Aug 2008 21:19:08 +0000
Subject: [issue3669] sqlite3.Connection.iterdump docs pythonicity
In-Reply-To: <1219612748.54.0.0398165047003.issue3669@psf.upfronthosting.co.za>
Message-ID: <1219612748.54.0.0398165047003.issue3669@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

The `sqlite3` docs are a little unpythonic. When using `str.join` on
`Connection.iterdump`, the example in the docs manually unpacks the
generator using a LC. I propose this'd be improved.

Patch attached. Same applies to the py3k docs, it's just a few lines
above there.

----------
assignee: georg.brandl
components: Documentation
files: connection-iterdump.patch
keywords: patch
messages: 71875
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: sqlite3.Connection.iterdump docs pythonicity
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11237/connection-iterdump.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3669>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:20:10 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 21:20:10 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219612810.23.0.211886254633.issue3662@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

You are right. But I'd rather keep the name = NULL assignment or add a
comment. In the future somebody may alter the function and resurrect the
bug accidentally.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:22:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 21:22:19 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219612939.71.0.0225093436968.issue3662@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It won't be resurrected for long if we write a test. :)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:24:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 21:24:43 +0000
Subject: [issue3139] bytearrays are not thread safe
In-Reply-To: <1219612406.28.0.241779655738.issue3139@psf.upfronthosting.co.za>
Message-ID: <1219613080.5635.10.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi Travis,

Glad you're back!

> I'm not convinced that Py_buffer should have grown a link to an object.
> I think this is a shortcut solution due to misuse of the protocol that
> may have unfortunate consequences. 

What consequences are you thinking about?

Specifically, why shouldn't Py_buffer have a link to the object? It's
the best way we've found to be able to release the buffer without having
to keep a link to the originator ourselves. The concern is to simplify
the API for most of its users. Especially, the new format codes ("s*" et
al.) can just fill the Py_buffer rather than return several things at
once.

(please note that link can be NULL if you don't want to have the
associated resource management)

> I'm not sure where PyBuffer_Release came from.  I can't find it in the
> PEP and don't remember what it's purpose is.

It's a replacement for PyObject_ReleaseBuffer(). Since a Py_buffer now
has a link to its originator, there's no need to pass it separately to
the releasing function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3139>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:34:28 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Sun, 24 Aug 2008 21:34:28 +0000
Subject: [issue3101] global function _add_one_to_C
In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za>
Message-ID: <1219613668.79.0.861833222429.issue3101@psf.upfronthosting.co.za>


Travis Oliphant <oliphant at enthought.com> added the comment:

I've added comments in the code to document these functions.  I have no
opinion where they live except they should probably be available to
extensions modules. 

These routines increment an N-length counter representing a position in
an N-dimensional array with wrap-around when the counter reaches the
size of the dimension.  Thus, for a (2,3) array we have:

F-version

0,0
1,0
2,0
0,1
1,1
2,1

C-version
0,0
0,1
0,2
1,0
1,1
1,2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3101>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:35:12 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Sun, 24 Aug 2008 21:35:12 +0000
Subject: [issue3046] Locking should be removed from the new buffer protocol
In-Reply-To: <1212734828.53.0.490072473192.issue3046@psf.upfronthosting.co.za>
Message-ID: <1219613712.19.0.105363579944.issue3046@psf.upfronthosting.co.za>


Changes by Travis Oliphant <oliphant at enthought.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3046>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:36:31 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Sun, 24 Aug 2008 21:36:31 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219613791.63.0.478460169926.issue2394@psf.upfronthosting.co.za>


Travis Oliphant <oliphant at enthought.com> added the comment:

It would have been nice to finish the memoryview object for 3.0, but I
ran into time constraints.  The pieces that are left can be pushed to 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:36:51 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Sun, 24 Aug 2008 21:36:51 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219613811.05.0.331487966844.issue2394@psf.upfronthosting.co.za>


Changes by Travis Oliphant <oliphant at enthought.com>:


----------
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:37:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 21:37:32 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1219613852.85.0.644806408487.issue2394@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Great. It would be nice if you could at least do a quick review what has
been committed though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:38:03 2008
From: report at bugs.python.org (Travis Oliphant)
Date: Sun, 24 Aug 2008 21:38:03 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1219613883.46.0.413634631513.issue3132@psf.upfronthosting.co.za>


Travis Oliphant <oliphant at enthought.com> added the comment:

This can be re-targeted to 3.1 as described.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:38:22 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 21:38:22 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219613902.88.0.838183804572.issue3651@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Another PyBuffer_Release(&pin); looks necessary at @@ -805,6 +807,7 @@.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:41:26 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 21:41:26 +0000
Subject: [issue3304] invalid call to PyMem_Free() in fileio_init()
In-Reply-To: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za>
Message-ID: <1219614086.77.0.0982060379665.issue3304@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

In 3.0 the free is necessary, though see http://bugs.python.org/issue3662 .

----------
nosy: +nnorwitz
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3304>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:50:31 2008
From: report at bugs.python.org (Kent Johnson)
Date: Sun, 24 Aug 2008 21:50:31 +0000
Subject: [issue3670] Reporting bugs - no such sections
In-Reply-To: <1219614631.74.0.871671228316.issue3670@psf.upfronthosting.co.za>
Message-ID: <1219614631.74.0.871671228316.issue3670@psf.upfronthosting.co.za>


New submission from Kent Johnson <kjohnson at users.sourceforge.net>:

The "Reporting Bugs" section of the Python 2.6b3 docs
http://docs.python.org/dev/bugs.html

says,
please use either the ?Add a comment? or the ?Suggest a change? features
of the relevant page in the most recent online documentation at
http://docs.python.org/.

I don't see either of these features in the 2.6 docs or the 2.5 docs at
the link.

----------
assignee: georg.brandl
components: Documentation
messages: 71885
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: Reporting bugs - no such sections
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3670>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:51:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 21:51:36 +0000
Subject: [issue2350] Warn against importing 'exceptions'
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1219614696.57.0.885513814106.issue2350@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm not sure how we could implement a warning on import of exceptions
aside from implementing it in the compiler. I suppose 2to3 could just
remove the import...

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:52:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Aug 2008 21:52:17 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219614737.8.0.465342749563.issue3649@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think this codec should be named IA-5. IA-5 is specified in
ITU-T Rec. T.50 (International Alphabet No. 5), recently renamed to
"International Reference Alphabet", and it does *not* specify that the
characters 0..31 are printable. Instead, IA5 is identical to ISO 646
(i.e. allowing for national variants), with the International Reference
Version of IA5 (e.g. as used in ASN.1 IA5String) is identical to US-ASCII.

If GSM uses a modified version of this, it should receive a separate
name. If you were looking at section 2 (Structure of EMI messages), what
makes you think that this specification calls the encoding "IA5"? In my
copy, it says:

# Alphanumeric characters are encoded as two numeric IA5 characters,
# the higher 3 bits (0..7) first, the lower 4 bits (0..F) thereafter,
# according to the following table.

So it *uses* IA5 to hex-encode the encoding. To achieve that, one would
have to write

  text.encode("emi-section-2").encode("hex")

[Notice that the "hex" codec already uses IA-5]

In any case, I don't think this is general enough to deserve inclusion
into the standard library. The codec system is designed to be so
flexible to support additional codecs outside the core.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:53:17 2008
From: report at bugs.python.org (Kent Johnson)
Date: Sun, 24 Aug 2008 21:53:17 +0000
Subject: [issue3671] What's New in 2.6 - corrections
In-Reply-To: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>
Message-ID: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>


New submission from Kent Johnson <kjohnson at users.sourceforge.net>:

These are minor corrections to the What's New in Python 2.6[b3] doc.

Note: the PEP references are to the headers in What's New, not the
  actual PEPs

- PEP 371: The multiprocessing Package
    - "apply() or apply_async, adding a single request, and map() or
      map_async()" All four function names should link to the Pool
      docs. Currently apply and map link to the docs for the builtins
      of the same name; the other two don't link.

- PEP 3101: Advanced String Formatting
    - In the first example, "uid = 'root'" is not needed

- PEP 3112: Byte Literals
    - In the second example, the value of b should not have a space in
      the middle, i.e. bytearray(b'\xe2\x87\xaf\xe3\x89\x84') instead
      of bytearray(b'\xe2\x87\xaf \xe3\x89\x84')

- Other Language Changes
    - next(*iterator*, [*default*]) - the asterisks are not needed
    - "letting complex(repr(cmplx)) will now round-trip values" -> so
      complex(repr(cmplx)) will now round-trip values

- Interpreter Changes
    - "**encoding** or **encoding**:**errorhandler**" - Are the **
      truly part of the syntax?

- New, Improved, and Deprecated Modules
    - heapq.merge() returns a generator; the example should be
      list(heapq.merge([1, 3, 5, 9], [2, 8, 16]))
    - All the new itertools functions return iterators, not lists;
      their examples should also be wrapped in list()
    - itertools.product([1,2], repeat=3)) <- extra )
    - shutil - "ignore_patterns() takes an arbitrary number of
      glob-style patterns and will ignore any files and directories
      that match this pattern." -> ignore_patterns() takes an arbitrary
      number of glob-style patterns and returns a callable which will
      ignore any files and directories that match this pattern.
- The future_builtins module
    - I think all the ** are extraneous.

----------
assignee: georg.brandl
components: Documentation
messages: 71888
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: What's New in 2.6 - corrections
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3671>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:56:51 2008
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 24 Aug 2008 21:56:51 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

The Unicode FAQ makes it quite clear that any surrogates in UTF-8 or
UTF-32 should be treated as errors.  Lone surrogates in UTF-16 should
probably be treated as errors too (but only during encoding/decoding;
unicode objects on UTF-16 builds should allow them to be created through
slicing).

http://unicode.org/faq/utf_bom.html#30
http://unicode.org/faq/utf_bom.html#42
http://unicode.org/faq/utf_bom.html#40

Lone surrogate in UTF-8 (effectively CESU-8):
>>> '\xED\xA0\x81'.decode('utf-8')
u'\ud801'

Surrogate pair in UTF-8:
>>> '\xED\xA0\x81\xED\xB0\x80'.decode('utf-8')
u'\ud801\udc00'

On a UTF-32 build, encoding a surrogate pair with UTF-16, then decoding
again will produce the proper non-surrogate scalar value.  This has
security implications, although rare as characters outside the BMP are rare:
>>> u'\ud801\udc00'.encode('utf-16').decode('utf-16')
u'\U00010400'

Also on a UTF-32 build, decoding of a lone surrogate in UTF-16 fails
(correctly), but encoding one does not:
>>> u'\ud801'.encode('utf-16')
'\xff\xfe\x01\xd8'


I have gotten a report of a user decoding bad data using
x.decode('utf-8', 'replace'), then getting an error from Gtk+ when the
ill-formed surrogates reached it.

Fixing this would cause issue 3297 to blow up loudly, rather than silently.

----------
messages: 71889
nosy: Rhamphoryncus
severity: normal
status: open
title: Ill-formed surrogates not treated as errors during encoding/decoding

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3672>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:57:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2008 21:57:08 +0000
Subject: [issue3670] Reporting bugs - no such sections
In-Reply-To: <1219614631.74.0.871671228316.issue3670@psf.upfronthosting.co.za>
Message-ID: <1219615028.1.0.715585891619.issue3670@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Yeah. The comment system hasn't actually been implemented so I removed
the note about that in r66017.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3670>
_______________________________________

From report at bugs.python.org  Sun Aug 24 23:57:15 2008
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 24 Aug 2008 21:57:15 +0000
Subject: [issue3672] Ill-formed surrogates not treated as errors during
	encoding/decoding
In-Reply-To: <1219615011.7.0.279537729369.issue3672@psf.upfronthosting.co.za>
Message-ID: <1219615035.57.0.070107151048.issue3672@psf.upfronthosting.co.za>


Changes by Adam Olsen <rhamph at gmail.com>:


----------
components: +Unicode
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3672>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:00:40 2008
From: report at bugs.python.org (Nick Edds)
Date: Sun, 24 Aug 2008 22:00:40 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1219615240.06.0.561718686004.issue2876@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

How soon is this needed by? I probably won't have a chance to do it in
the next week, but it shouldn't take that long to make once I get a
chance to work on it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:03:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 22:03:40 +0000
Subject: [issue3671] What's New in 2.6 - corrections
In-Reply-To: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>
Message-ID: <1219615420.91.0.673836108701.issue3671@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> akuchling
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3671>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:08:24 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:08:24 +0000
Subject: [issue3662] _fileio._FileIO segfaults
In-Reply-To: <1219606630.97.0.430551791743.issue3662@psf.upfronthosting.co.za>
Message-ID: <1219615704.62.0.567739021683.issue3662@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Daniel, thanks for running the fuzzer!  It would be great if you could
keep running it and find any more problems before releasing 2.6 and 3.0.

I agree with Benjamin and Amaury.  PyArg_ParseTupleAndKeywords()
shouldn't update the pointer if it failed.  Given the test, it's
unlikely for this to create a problem in the future.  Either as a crash
or as a memory leak.

Committed revision 66018. (2.6)
Committed revision 66019. (3.0)

----------
assignee:  -> nnorwitz
components: +Interpreter Core
nosy: +nnorwitz
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3662>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:10:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Aug 2008 22:10:01 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219615801.98.0.0878602637748.issue3642@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the patch is fairly incomplete. "i" still stays at uint, so if
numarenas would ever overflow uint, the loop would never reach
numarenas, and all arenas would get discarded.

Likewise, maxarenas still stays at uint, so when numarenas overflows
uint, the additional arenas get discarded.

The compiler was right observing that the condition is always false:
this was a security check to prevent overflow, but on this specific
system, overflow couldn't occur in the first place. 

If you want to silence the warning, try casting numarenas to size_t in
the test only. If you want to properly remove the unnecessary test, put
an ifdef around it, testing whether size_t is larger than uint.

With the current code, it might be that you have disabled the security
check: numarenas <= maxarenas will not occur anymore (since numarenas is
wider than maxarenas); as a consequence, you then see the silent
truncation later on instead of the exception.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:20:37 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:20:37 +0000
Subject: [issue1375] hotshot IndexError when loading stats
In-Reply-To: <1194031021.72.0.351195403989.issue1375@psf.upfronthosting.co.za>
Message-ID: <1219616437.52.0.166090317657.issue1375@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1375>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:21:23 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:21:23 +0000
Subject: [issue2456] Make sysmodule.c compatible with Bazaar
In-Reply-To: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za>
Message-ID: <1219616483.5.0.361395646283.issue2456@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
type: crash -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2456>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:22:35 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:22:35 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1219616555.45.0.444677199642.issue1210@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Is this still a problem?

----------
nosy: +nnorwitz
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:23:09 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:23:09 +0000
Subject: [issue1658] "RuntimeError: dictionary changed size during iteration"
	in Tkinter
In-Reply-To: <1198069697.21.0.802905521155.issue1658@psf.upfronthosting.co.za>
Message-ID: <1219616589.14.0.170839328645.issue1658@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1658>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:23:51 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:23:51 +0000
Subject: [issue1840] Tools/i18n/msgfmt.py fixes for Python 3.0
In-Reply-To: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za>
Message-ID: <1219616631.28.0.0644176340012.issue1840@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Is this still a problem?

----------
nosy: +nnorwitz
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1840>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:27:23 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:27:23 +0000
Subject: [issue2747] Documentation of new gobject types fails
In-Reply-To: <1209835134.72.0.0778910402245.issue2747@psf.upfronthosting.co.za>
Message-ID: <1219616843.56.0.26725610556.issue2747@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2747>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:28:00 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:28:00 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219616880.4.0.361442873665.issue2562@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:32:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Aug 2008 22:32:28 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219617148.59.0.0107558162094.issue3663@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The culprit is Python/pythonrun.c:1245:

    tb = tb ? tb : Py_None;

Py_None needs to be INCREF'd in the else case.

----------
assignee:  -> pitrou
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:33:48 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 22:33:48 +0000
Subject: [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1219617228.27.0.959406961052.issue1838@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
assignee:  -> theller
components: +ctypes -Extension Modules
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
_______________________________________

From report at bugs.python.org  Mon Aug 25 00:45:28 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Aug 2008 22:45:28 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1219617928.91.0.131272751808.issue3642@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Good analysis Martin!

In my humble opinion it should be safe to limit the amount of arenas to
UINT_MAX instead of PY_SIZE_MAX. 4,294,967,295 arenas should be more
than sufficient for the next decade or two. Do you concur?

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Mon Aug 25 01:04:17 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 23:04:17 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1219619057.49.0.0331010262452.issue3657@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

The valgrind errors below are possibly related.

Conditional jump or move depends on uninitialised value(s)
   PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2216)
   _PyUnicode_AsString (unicodeobject.c:1417)
   save (_pickle.c:930)
   Pickler_dump (_pickle.c:2292)

Conditional jump or move depends on uninitialised value(s)
   PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2220)
   _PyUnicode_AsString (unicodeobject.c:1417)
   save (_pickle.c:930)
   Pickler_dump (_pickle.c:2292)

Conditional jump or move depends on uninitialised value(s)
   PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2227)
   _PyUnicode_AsString (unicodeobject.c:1417)
   save (_pickle.c:930)
   Pickler_dump (_pickle.c:2292)

Conditional jump or move depends on uninitialised value(s)
   PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2229)
   _PyUnicode_AsString (unicodeobject.c:1417)
   save (_pickle.c:930)
   Pickler_dump (_pickle.c:2292)

Conditional jump or move depends on uninitialised value(s)
   PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2233)
   _PyUnicode_AsString (unicodeobject.c:1417)
   save (_pickle.c:930)
   Pickler_dump (_pickle.c:2292)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Mon Aug 25 01:20:15 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 23:20:15 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219620015.48.0.454274614954.issue3651@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

With the latest patch (and the one addition PyBuffer_Release() I noted
above), valgrind is happy wrt memory leaks.  The only problem valgrind
found is a read of uninitialized memory.  See
http://bugs.python.org/issue3657 .

I don't know the buffer code to know if this is the correct fix. 
However, it fixes the problems and that's probably good enough for now.
 If you can get someone familiar with the buffer code to review, that
would be great.  If not, this patch should be applied.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Mon Aug 25 01:21:31 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 23:21:31 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219620091.22.0.894290949979.issue3651@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Also there should be a Misc/NEWS entry added. Also check the doc to see
it needs updating wrt ownership.

----------
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Mon Aug 25 01:24:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Aug 2008 23:24:43 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219620015.48.0.454274614954.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219620280.5635.13.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't know the buffer code to know if this is the correct fix. 
> However, it fixes the problems and that's probably good enough for now.
>  If you can get someone familiar with the buffer code to review, that
> would be great.

I don't know if I pass as "someone familiar with the buffer code", but
Amaury's patch is ok to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Mon Aug 25 01:39:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Aug 2008 23:39:55 +0000
Subject: [issue2350] Warn against importing 'exceptions'
In-Reply-To: <1219614696.57.0.885513814106.issue2350@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808241639r712db0d1s23491e9546eb5b5a@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Aug 24, 2008 at 2:51 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> I'm not sure how we could implement a warning on import of exceptions
> aside from implementing it in the compiler. I suppose 2to3 could just
> remove the import...
>

... and would also have to change all references. But that would
probably work out fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
_______________________________________

From report at bugs.python.org  Mon Aug 25 01:41:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Aug 2008 23:41:09 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1219615240.06.0.561718686004.issue2876@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808241641i51a7e918o9f06096a4a04d793@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Aug 24, 2008 at 3:00 PM, Nick Edds <report at bugs.python.org> wrote:
>
> Nick Edds <nedds at uchicago.edu> added the comment:
>
> How soon is this needed by? I probably won't have a chance to do it in
> the next week, but it shouldn't take that long to make once I get a
> chance to work on it.
>

rc1 is Sep. 3, with rc3 Sep 17 (at the moment). Hitting either should
be okay, although obviously the sooner the better.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Mon Aug 25 01:50:26 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 24 Aug 2008 23:50:26 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1219621826.07.0.557196460451.issue3657@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Indeed.  The problem was an incorrect conversion of str -> unicode,
instead of converting to bytes.  On getting the buffer from unicode, it
tried to read data which was uninitialized.

Hmmm, this fix is for 3.0 only, but the problem is happening in 2.6. 
Leaving open.

Committed revision 66021.

----------
assignee:  -> nnorwitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Mon Aug 25 03:15:34 2008
From: report at bugs.python.org (Kent Johnson)
Date: Mon, 25 Aug 2008 01:15:34 +0000
Subject: [issue3670] Reporting bugs - no such sections
In-Reply-To: <1219614631.74.0.871671228316.issue3670@psf.upfronthosting.co.za>
Message-ID: <1219626934.36.0.381778296728.issue3670@psf.upfronthosting.co.za>


Kent Johnson <kjohnson at users.sourceforge.net> added the comment:

You should add something like the old "About this document" footer.
AFAICT there is no information in the new docs about how to report a
problem with the docs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3670>
_______________________________________

From report at bugs.python.org  Mon Aug 25 03:50:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 01:50:19 +0000
Subject: [issue2456] Make sysmodule.c compatible with Bazaar
In-Reply-To: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za>
Message-ID: <1219629019.58.0.843255166914.issue2456@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I suggest that this option (when it is implemented) can be a configure
switch.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2456>
_______________________________________

From report at bugs.python.org  Mon Aug 25 05:42:22 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Aug 2008 03:42:22 +0000
Subject: [issue3673] bsddb module leaks memory
In-Reply-To: <1219635742.08.0.574987175435.issue3673@psf.upfronthosting.co.za>
Message-ID: <1219635742.08.0.574987175435.issue3673@psf.upfronthosting.co.za>


New submission from Neal Norwitz <nnorwitz at gmail.com>:

The attached patch against 2.6 fixes the memory leaks reported against
the bsddb module.  There are still (probably) reference leaks.

Jesus, it would be great if you can look at this before the release.

----------
assignee: jcea
components: Extension Modules
files: bsddb.patch
keywords: patch, patch
messages: 71907
nosy: jcea, nnorwitz
priority: critical
severity: normal
status: open
title: bsddb module leaks memory
type: resource usage
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11238/bsddb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3673>
_______________________________________

From report at bugs.python.org  Mon Aug 25 05:43:30 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 25 Aug 2008 03:43:30 +0000
Subject: [issue3674] test_dbm_ndbm skip is unexpected on win32?
In-Reply-To: <1219635810.63.0.758747925367.issue3674@psf.upfronthosting.co.za>
Message-ID: <1219635810.63.0.758747925367.issue3674@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently, I get following messege.

E:\PYTHON~1\py3k\Lib\test>py3k regrtest.py test_dbm_ndbm.py
test_dbm_ndbm
test_dbm_ndbm skipped -- No module named _dbm
1 test skipped:
    test_dbm_ndbm
1 skip unexpected on win32:
    test_dbm_ndbm

I don't know about dbm, but win32 buildbots are skiping this test, maybe
is this skip expected?

----------
components: Tests
files: regrtest.patch
keywords: patch
messages: 71908
nosy: ocean-city
severity: normal
status: open
title: test_dbm_ndbm skip is unexpected on win32?
versions: Python 3.0
Added file: http://bugs.python.org/file11239/regrtest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3674>
_______________________________________

From report at bugs.python.org  Mon Aug 25 06:50:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 25 Aug 2008 04:50:35 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219617928.91.0.131272751808.issue3642@psf.upfronthosting.co.za>
Message-ID: <48B23A13.7000400@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> In my humble opinion it should be safe to limit the amount of arenas to
> UINT_MAX instead of PY_SIZE_MAX. 4,294,967,295 arenas should be more
> than sufficient for the next decade or two. Do you concur?

It is certainly reasonable to limit arenas to uint. Still, the test
for SIZE_MAX must remain: it doesn't test whether numarenas overflows,
but whether numarenas*sizeof(*arenas) overflows as a parameter for
realloc. As the parameter for realloc is size_t (per C spec), the
overflow test needs to use PY_SIZE_MAX.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Mon Aug 25 08:40:01 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Aug 2008 06:40:01 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1219646401.95.0.503836718756.issue3657@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

It seems that if the tests are run in this order:

./python -E -tt ./Lib/test/regrtest.py -u all test_xmlrpc test_ctypes
test_json test_bsddb3 test_pickletools

The error will trigger consistently.  That is in 2.6 with a debug build
on a dual cpu box.  A debug build of 3.0 on the same machine did not
fail though I don't know if 3.0 has this problem. I was unable to prune
the list further.  The 3 tests (xmlrpc, ctypes and json) can be run in
any order prior to bsdb3 and then pickletools.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Mon Aug 25 10:47:42 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Aug 2008 08:47:42 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219654062.93.0.86576428309.issue3651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Updated patch with the additional PyBuffer_Release mentioned by Neal,
plus a proposition of entry for the NEWS file.

There is no doc about the new interface, so no update is needed :-( 
See issue2619.

Added file: http://bugs.python.org/file11240/buffer-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Mon Aug 25 11:31:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 09:31:27 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1219656687.49.0.257233921966.issue3160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Viktor?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Mon Aug 25 11:31:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 09:31:33 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1219656693.94.0.772936453171.issue3160@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3160>
_______________________________________

From report at bugs.python.org  Mon Aug 25 11:32:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 09:32:01 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219656721.11.0.221005399506.issue3668@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 11:32:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Aug 2008 09:32:43 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1219656763.62.0.469963999023.issue3279@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Attached patch writes the "'import site' failed" message to libc stderr
instead of sys.stderr, which does not exist at this point.

The initial problem still remains: site.py cannot use the "open" builtin.

----------
keywords: +patch
Added file: http://bugs.python.org/file11241/import-site.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 11:35:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Aug 2008 09:35:18 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219656918.71.0.723159967524.issue3663@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Agreed. PyErr_ExceptionMatches returns owned references, so the tb
variable has to remain an owned reference.
Patch attached, please review.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11242/missing-incref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Mon Aug 25 11:44:13 2008
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 25 Aug 2008 09:44:13 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1219657453.26.0.268831527623.issue600362@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

It seems like parse_multipart and parse_header are very strongly related
to parse_qs. (eg. if you want to process HTTP requests you'll want to
call parse_qs for x-www-form-urlencoded and parse_multipart for
multipart/form-data).

Should these be moved too? (They aren't part of the url syntax though,
so it doesn't make sense for them to be in urlparse).

----------
nosy: +mgiuca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue600362>
_______________________________________

From report at bugs.python.org  Mon Aug 25 12:07:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 10:07:17 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219658837.78.0.490357115145.issue3668@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 14:15:44 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 25 Aug 2008 12:15:44 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

After pickling a set of ints with Python 3.0 and pickle protocol 2:

[hagenf at chage ~]$ python3.0
Python 3.0b3 (r30b3:65927, Aug 21 2008, 11:48:29)
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> f = open("test", "wb")
>>> pickle.dump({1,2,3}, f, 2)
>>> f.close()

I get the following error when trying to read this with Python 2.6:

[hagenf at chage ~]$ python
Python 2.6b3 (r26b3:65922, Aug 21 2008, 11:42:25)
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> f = open("test", "rb")
>>> pickle.load(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1370, in load
    return Unpickler(file).load()
  File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 858, in load
    dispatch[key](self)
  File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1090, in
load_global
    klass = self.find_class(module, name)
  File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1124, in
find_class
    __import__(module)
ImportError: No module named builtins

----------
components: Library (Lib)
messages: 71916
nosy: hagen
severity: normal
status: open
title: Python 2.6 can't read sets pickled with Python 3.0
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Mon Aug 25 14:23:26 2008
From: report at bugs.python.org (Anders J. Munch)
Date: Mon, 25 Aug 2008 12:23:26 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1219667006.08.0.656980108236.issue1220212@psf.upfronthosting.co.za>


Changes by Anders J. Munch <2007 at jmunch.dk>:


----------
nosy: +andersjm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_______________________________________

From report at bugs.python.org  Mon Aug 25 14:39:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 12:39:59 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219667999.48.0.336917656421.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. Please review.

----------
keywords: +needs review, patch
type:  -> resource usage
Added file: http://bugs.python.org/file11243/argleak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 14:57:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Aug 2008 12:57:08 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219669028.41.0.487831895737.issue3668@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This patch elegantly reuses the existing cleanup list.

Only two remarks: 
- there are a few tabs/spaces inconsistencies.
- I would make the cleanup_ptr explicit:
intead of 
      addcleanup(*buffer, freelist, NULL);
I'd prefer
      addcleanup(*buffer, freelist, cleanup_ptr);

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 15:14:36 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 25 Aug 2008 13:14:36 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1219670076.87.0.729762757084.issue1462525@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Hello Paul, 
Have you beeing keeping track of urlparse changes in Python2.6? I 
anaylzed your patch and read through the RFC3986 and have the 
following comments:

1) The usage of this module is very diffirent from the current 
urlparse module's usage. It might be that this module was designed to 
co-exist with urlparse, providing certain additional functionalities. 
But inorder to replace urlparse, I find this module is "Backward 
Incompatible with the code base". 

Some comments extra features provided /claims of this module.

2) The module provides URI handling framework that includes default 
URI Parsers for common URI Schemes.
    - RFC3986 specifies that scheme handling part is left to the 
separate RFC describing the schemes. 
    - uriparse library attempts that by providing default port and 
default hostname for certain schemes, but that can be made available 
as a patch to urlparse rather than new library. The need for such a 
change in urlparse needs to be analyzed, as there has not been any 
requirement raised as such for proving default port, default host for 
schemes whenever it is applicable.

3) urlsplit, urlunsplit, spliting the authority into sub-components is
available in the current urlparse library itself and is RFC3986 
conformant.

4) urljoin in the current urlparse ( patched with fixes) is currently 
RFC3986conformant.

What urlparse further requires and this patch also lacks is ( as 
commented by John J Lee)
1) Handling of IRIs.
2) Python Unicode Strings.
3) Percent- Encodings for IRIs and Python Unicode Strings.
( There is a discussion going on on quote and unquote of unicode, and 
thatwould be basically be extended to above points as well)

- If required, we can adopt the default host and port provision 
mechanisms as  mentioned in this patch to the current urlparse. 

Other that that, I see that urlparse currently has all changes as 
mentioned inthis patch and makes the attached patch an obsolete one.

Please let me know your comments/ thoughts.

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462525>
_______________________________________

From report at bugs.python.org  Mon Aug 25 15:30:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 13:30:57 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219671057.61.0.876295187823.issue3663@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patch looks fine to me.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Mon Aug 25 15:37:48 2008
From: report at bugs.python.org (Oren Tirosh)
Date: Mon, 25 Aug 2008 13:37:48 +0000
Subject: [issue3676] Obsolete references to PEP 291 in py3k lib
In-Reply-To: <1219671468.62.0.218344277949.issue3676@psf.upfronthosting.co.za>
Message-ID: <1219671468.62.0.218344277949.issue3676@psf.upfronthosting.co.za>


New submission from Oren Tirosh <orent at hishome.net>:

The comments in the following modules contain references to PEP 291 or
to remaining compatible with version 2.x.  However, they all include non
backward compatible python 3 syntax like "except x as y".

decimal.py
modulefinder.py
pkgutil.py
subprocess.py

----------
components: Library (Lib)
messages: 71921
nosy: orent
severity: normal
status: open
title: Obsolete references to PEP 291 in py3k lib
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3676>
_______________________________________

From report at bugs.python.org  Mon Aug 25 15:40:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 13:40:56 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1219671656.97.0.273668157525.issue3279@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

We could:

1. Use _fileio._FileIO directly.
2. Use os.open.
3. Initialize the stdio streams before importing site. This seems like
the best option, although I haven't run all the tests yet.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 15:42:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 13:42:09 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219671729.1.0.296224186357.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is a new patch addressing Amaury's comments.

Added file: http://bugs.python.org/file11244/argleak2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:02:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 14:02:12 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219672932.74.0.435944988273.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, this bug affects 2.6 as well, although not in binascii since
it has not been converted to use "s*":

>>> codecs.latin_1_decode(b"", 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: latin_1_decode() argument 2 must be string or None, not int
[57425 refs]
>>> codecs.latin_1_decode(b"", 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: latin_1_decode() argument 2 must be string or None, not int
[57426 refs]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:19:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 14:19:38 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219673978.6.0.0731717097578.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch for 2.6.

Added file: http://bugs.python.org/file11245/argleak-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:27:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Aug 2008 14:27:37 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219674457.15.0.168990875928.issue3668@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Both patches look good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:31:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 14:31:43 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219674703.42.0.0992548902225.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, here is a better patch for py3k.

Added file: http://bugs.python.org/file11246/argleak3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:37:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 14:37:27 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1219675047.36.0.226955260247.issue3279@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's my patch for the problem.

Added file: http://bugs.python.org/file11247/different_order.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:39:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 14:39:57 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1219675197.95.0.586758825984.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And a similarly better patch for 2.6.

----------
versions: +Python 2.6
Added file: http://bugs.python.org/file11248/argleak2-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:45:07 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Mon, 25 Aug 2008 14:45:07 +0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1219675507.75.0.949000996252.issue2127@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Can we close this now? Did you try out a Python2.6 or Python 3.0 beta?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
_______________________________________

From report at bugs.python.org  Mon Aug 25 16:54:30 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Aug 2008 14:54:30 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1219676070.78.0.367751693262.issue3279@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, it would be interesting to know why r62778 has exactly the
opposite move.
Alexandre, do you remember doing it?

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:00:28 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 25 Aug 2008 15:00:28 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

When executing a script from a UNC path, e.g. //myhost/exports/a.py, 
r"\\myhost\exports" gets prepended to sys.path.  But it doesn't work.  
This means that in a.py, "import b" will fail even though b.py is 
present in the same directory.

The workaround is to manually prepend a backslass to the UNC path in 
sys.path.

Note the related defect: http://bugs.python.org/issue954115
This intdoruces two functions for testing UNC paths, but it appears 
that these functions are nowhere used!

----------
components: Interpreter Core
messages: 71932
nosy: krisvale
priority: normal
severity: normal
status: open
title: importing from UNC roots doesn't work
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:02:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 15:02:37 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1219676557.51.0.0187639083105.issue3279@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It was probably done so that importing _bytesio would actually work in
io. IMO, it would be better to just compile _bytesio and _stringio into
the python binary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:08:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 15:08:21 +0000
Subject: [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1219676901.96.0.585774844971.issue3218@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3218>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:11:01 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 Aug 2008 15:11:01 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219677061.43.0.521347601941.issue3649@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think what you're after is the encoding used in SMS messages:

http://en.wikipedia.org/wiki/Short_message_service

Here's an old discussion about this codec:

http://mail.python.org/pipermail/python-list/2002-October/167267.html
http://mail.python.org/pipermail/python-list/2002-October/167271.html

Note that nowadays, SMSCs and interface software such as Kannel
typically accept UTF-16 data just fine, so the need for such a codec in
Python in minimal.

I agree with Martin, that the stdlib is not the right place for such a
codec. It's easy to write your own codec package and have your
application register this package at startup time using codecs.register().

----------
nosy: +lemburg
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:11:48 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 25 Aug 2008 15:11:48 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1219677108.19.0.28444958064.issue3279@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Benjamin is right. site.py imports the io module before _bytesio and
_stringio are available for import. Thus the python version of BytesIO
and StringIO is always used. There is an old thread about the issue at
http://mail.python.org/pipermail/python-3000/2007-December/011569.html

As for compiling _bytesio and _stringio into the main binary, you should
ask python-dev or python-3000.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:16:56 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 Aug 2008 15:16:56 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219677416.92.0.557526060354.issue2562@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Is this still an issue in 2.6 ?

AFAIK, there have been a few changes both to setuptools and PyPI that
make it easy to just use Unicode objects in the setup() call for
non-ASCII values.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:17:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 15:17:40 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219677460.09.0.934214596531.issue2534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, py3k suffers from this problem too, so a similar patch
should be applied if possible.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:19:20 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 15:19:20 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219677560.6.0.343611565586.issue2534@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:25:45 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 25 Aug 2008 15:25:45 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1219677945.91.0.226401401058.issue3664@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Oh, that's nasty. Recalling __init__ with bad arguments breaks the
internal invariants as it clears the Pickler's content before parsing
the arguments. I suspect that Unpickler is vulnerable too.

Adding a NULL check in pickler_write will only fix this particular
example. I could probably find another crash example that doesn't use
pickler_write.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:31:47 2008
From: report at bugs.python.org (Pascal Bach)
Date: Mon, 25 Aug 2008 15:31:47 +0000
Subject: [issue3649] IA5 Encoding should be in the default encodings
In-Reply-To: <1219422406.98.0.675538880211.issue3649@psf.upfronthosting.co.za>
Message-ID: <1219678307.85.0.391339025744.issue3649@psf.upfronthosting.co.za>


Pascal Bach <pascal.bach at nextrem.ch> added the comment:

I currently use the codec in my ucplib already and this is not a
problem. I just thought that it might be useful for somebody else. But
maybe it is to use case specific. 
If this codec is not of general interest I think this report can be closed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3649>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:32:32 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 Aug 2008 15:32:32 +0000
Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
In-Reply-To: <1219478910.67.0.27130655522.issue1276@psf.upfronthosting.co.za>
Message-ID: <48B2D08D.2080605@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-08-23 10:08, Hye-Shik Chang wrote:
> Hye-Shik Chang <hyeshik at gmail.com> added the comment:
> 
> Committed patch "cjkmactemporary.diff" as r65988 in the py3k branch.
> I'll open another issue for cjkcodecs implementation of Mac codecs.

Thanks !

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1276>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:32:33 2008
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 25 Aug 2008 15:32:33 +0000
Subject: [issue3677] importing from UNC roots doesn't work
In-Reply-To: <1219676428.29.0.220923454973.issue3677@psf.upfronthosting.co.za>
Message-ID: <1219678353.39.0.283691782316.issue3677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Correction: The workaround is to _append_ a backslash.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3677>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:45:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 15:45:14 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219679114.79.0.447969967753.issue2534@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Aug 25 17:58:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 15:58:24 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1219679904.57.0.306318506857.issue3675@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti
priority:  -> critical
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Mon Aug 25 18:00:03 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 25 Aug 2008 16:00:03 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1219680003.98.0.321638912859.issue3664@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Unpickler looks safe as Unpickler_load() checks if Unpickler was
properly initialized. And only Pickler_dump is vulnerable right now (new
methods, if any, exposed for issue3385 will have to take into account
this vulnerability).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________

From report at bugs.python.org  Mon Aug 25 18:05:46 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 25 Aug 2008 16:05:46 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219680346.14.0.265528671761.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The problem is in distutils code, not in setuptools or PyPI.

As long as I can see, the problem remains in the trunk. It is dead
simple to reproduce : put an unicode name for the author in a plain setup.py
with a non ascii character. (for example my name ;))

Here's an up-to-date patch that includes a test that reproduces the problem.

Added file: http://bugs.python.org/file11249/distutils.unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Aug 25 18:06:01 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 25 Aug 2008 16:06:01 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219680361.24.0.670243340525.issue2562@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file9961/unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Aug 25 18:06:11 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 25 Aug 2008 16:06:11 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219680371.62.0.190848099148.issue2562@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file10065/distutils.unicode.simplified.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Aug 25 18:06:04 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 25 Aug 2008 16:06:04 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219680364.5.0.701031295121.issue2562@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file9967/unicode.metadata.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Aug 25 19:04:01 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 Aug 2008 17:04:01 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219683841.6.0.924827078845.issue2562@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Here's an updated patch that applies the same logic to all meta-data
fields, instead of just a few. This simplifies the code somewhat.

I've tested it with the test you provided and also with eGenix packages
using Unicode author names (ie. my name ;-)).

I guess we need at least one more reviewer to commit this change.

Added file: http://bugs.python.org/file11250/distutils-unicode-metadata.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Aug 25 19:28:46 2008
From: report at bugs.python.org (Eric Smith)
Date: Mon, 25 Aug 2008 17:28:46 +0000
Subject: [issue3382] Make '%F' and float.__format__('F') convert results to
	upper case.
In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za>
Message-ID: <1219685326.52.0.846777872387.issue3382@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Unfortunately, I missed the window to get these into 3.0 and 2.6. 
Better luck for 3.1 and 2.7!

----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3382>
_______________________________________

From report at bugs.python.org  Mon Aug 25 19:48:27 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Aug 2008 17:48:27 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1219671656.97.0.273668157525.issue3279@psf.upfronthosting.co.za>
Message-ID: <bbaeab100808251048m24f72289s8197f7d99d2fd12a@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Aug 25, 2008 at 6:40 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> We could:
>
> 1. Use _fileio._FileIO directly.
> 2. Use os.open.
> 3. Initialize the stdio streams before importing site. This seems like
> the best option, although I haven't run all the tests yet.
>

Or you could use _warnings which is already compiled into the binary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 19:49:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 17:49:35 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <bbaeab100808251048m24f72289s8197f7d99d2fd12a@mail.gmail.com>
Message-ID: <1afaf6160808251049n4e3b101g81160fa41daacf70@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Mon, Aug 25, 2008 at 12:48 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> Brett Cannon <brett at python.org> added the comment:
>
> On Mon, Aug 25, 2008 at 6:40 AM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>>
>> We could:
>>
>> 1. Use _fileio._FileIO directly.
>> 2. Use os.open.
>> 3. Initialize the stdio streams before importing site. This seems like
>> the best option, although I haven't run all the tests yet.
>>
>
> Or you could use _warnings which is already compiled into the binary.

How would that help the problem of site using open() when it can't?
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3279>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 19:52:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Aug 2008 17:52:22 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1afaf6160808251049n4e3b101g81160fa41daacf70@mail.gmail.com>
Message-ID: <bbaeab100808251052j4942fef9sd724f67a4f3228e8@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Aug 25, 2008 at 10:49 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> On Mon, Aug 25, 2008 at 12:48 PM, Brett Cannon <report at bugs.python.org> wrote:
>>
>> Brett Cannon <brett at python.org> added the comment:
>>
>> On Mon, Aug 25, 2008 at 6:40 AM, Benjamin Peterson
>> <report at bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>>>
>>> We could:
>>>
>>> 1. Use _fileio._FileIO directly.
>>> 2. Use os.open.
>>> 3. Initialize the stdio streams before importing site. This seems like
>>> the best option, although I haven't run all the tests yet.
>>>
>>
>> Or you could use _warnings which is already compiled into the binary.
>
> How would that help the problem of site using open() when it can't?
>>

Sorry, replied to the wrong email. It was meant as a reply to Amaury's
suggestion of writing out a comment that importing site failed to
stderr.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Mon Aug 25 19:55:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 17:55:57 +0000
Subject: [issue2350] 'exceptions' import fixer
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1219686957.97.0.0203809737274.issue2350@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's my 2to3 fixer for the job. It cleanly removes the imports and
changes the usage.

----------
assignee:  -> collinwinter
components: +2to3 (2.x to 3.0 conversion tool)
keywords: +patch
nosy: +collinwinter
title: Warn against importing 'exceptions' -> 'exceptions' import fixer
type:  -> feature request
Added file: http://bugs.python.org/file11251/exceptions_fixer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
_______________________________________

From report at bugs.python.org  Mon Aug 25 19:56:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 17:56:35 +0000
Subject: [issue2350] 'exceptions' import fixer
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1219686995.99.0.464484147848.issue2350@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review -26backport

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
_______________________________________

From report at bugs.python.org  Mon Aug 25 20:24:01 2008
From: report at bugs.python.org (djc)
Date: Mon, 25 Aug 2008 18:24:01 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219688641.48.0.324924639939.issue2534@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Aug 25 21:53:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 19:53:00 +0000
Subject: [issue2356] fixer for sys.exitfunc -> atexit
In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za>
Message-ID: <1219693980.3.0.355339077372.issue2356@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's my 2to3 fixer for the cause. It always changes assignment to
sys.exitfunc to atexit.register. It then inserts a "import atexit" after
the module's sys import. If it can't find a sys import (that should be
rare obviously :) ), it emits a warning.

----------
assignee:  -> collinwinter
components: +2to3 (2.x to 3.0 conversion tool) -Interpreter Core
keywords: +needs review, patch -26backport
nosy: +collinwinter
title: sys.exitfunc should raise a Py3K warning -> fixer for sys.exitfunc -> atexit
type:  -> feature request
Added file: http://bugs.python.org/file11252/atexit_fixer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2356>
_______________________________________

From report at bugs.python.org  Mon Aug 25 22:09:26 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 20:09:26 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219694966.74.0.0925535191539.issue2534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm currently doing the port to py3k. It makes me find interesting flaws
in the current isinstance/issubclass implementation :-))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Aug 25 22:28:09 2008
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 25 Aug 2008 20:28:09 +0000
Subject: [issue3678] Ignored LDFLAGS during linking libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

LDFLAGS are ignored during linking libpython$(VERSION).so.

(LDFLAGS are respected during linking $(BUILDPYTHON) and $(PGEN).)

----------
components: Build
files: python-respect_LDFLAGS.patch
keywords: patch
messages: 71952
nosy: Arfrever
severity: normal
status: open
title: Ignored LDFLAGS during linking libpython$(VERSION).so
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11253/python-respect_LDFLAGS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3678>
_______________________________________

From report at bugs.python.org  Mon Aug 25 22:37:16 2008
From: report at bugs.python.org (Toby Donaldson)
Date: Mon, 25 Aug 2008 20:37:16 +0000
Subject: [issue3679] pressing HOME key in IDLE editor ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>


New submission from Toby Donaldson <tjdonaldson at gmail.com>:

In IDLE 3.0b2, whenever I press the Home key in an IDLE editor window,
IDLE ends and all windows disappear.

----------
components: IDLE
messages: 71953
nosy: tjd
severity: normal
status: open
title: pressing HOME key in IDLE editor ends IDLE
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________

From report at bugs.python.org  Mon Aug 25 22:42:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Aug 2008 20:42:03 +0000
Subject: [issue3679] pressing HOME key in IDLE editor ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1219696923.52.0.731420997317.issue3679@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, 3.0b3 is out and many bugs may have been corrected.
Can you try with this newer version?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________

From report at bugs.python.org  Mon Aug 25 22:43:45 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 25 Aug 2008 20:43:45 +0000
Subject: [issue3680] Cycles with some iterator are leaking.
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

The dict, set, and deque iterators do not implement tp_traverse although
they reference container objects. This can lead to reference cycles
which will not be collected. The attached cycle.py script from Amaury
demonstrates the problem for dict iterators. The attached patch
addresses the issue for the above mentioned types. The method applied in
the demonstration script was used for test cases.

This is my first excursion into cyclic garbage collector
implementations, so please review carefully. Also, I am not sure about
tp_traverse for the deque type. Must the block member also be considered
or is the deque member sufficient?

Finally, do you consider this a show stopper?

----------
components: Interpreter Core
files: cycle.py
keywords: patch
messages: 71955
nosy: amaury.forgeotdarc, schuppenies
severity: normal
status: open
title: Cycles with some iterator are leaking.
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11254/cycle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________

From report at bugs.python.org  Mon Aug 25 22:45:04 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 25 Aug 2008 20:45:04 +0000
Subject: [issue3680] Cycles with some iterator are leaking.
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <1219697104.48.0.656723003026.issue3680@psf.upfronthosting.co.za>


Changes by Robert Schuppenies <robert.schuppenies at gmail.com>:


Added file: http://bugs.python.org/file11255/tp_traverse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________

From report at bugs.python.org  Mon Aug 25 23:10:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 21:10:19 +0000
Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer
In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za>
Message-ID: <1219698619.46.0.518431199871.issue2370@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The py3k warnings look good to me.

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2370>
_______________________________________

From report at bugs.python.org  Mon Aug 25 23:11:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 21:11:28 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219698688.07.0.616886557.issue2534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is the patch for py3k. As I said it fixes some interesting bugs
(when the second argument was a tuple, isinstance() and issubclass()
were trying to get __instancecheck__ / __subclasscheck__ on the tuple
rather than on each of the tuple items). I also had to disable
__subclasscheck__ for exception matching, otherwise there are some nasty
issues with recursion checking.

The patch for trunk should probably be reworked or regenerated from the
py3k patch.

Performance numbers:

timeit -s "val=ValueError(); cls=EOFError" "isinstance(val, cls)"
- before patch: 1.63 usec per loop
- after patch: 0.683 usec per loop

timeit -s "val=ValueError(); cls=EOFError" "isinstance(val, (cls,))"
- before patch: 1.86 usec per loop
- after patch: 0.773 usec per loop

timeit -s "val=ValueError; cls=EOFError" "issubclass(val, cls)"
- before patch: 1.95 usec per loop
- after patch: 0.624 usec per loop

timeit -s "val=ValueError; cls=EOFError" "issubclass(val, (cls,))"
- before patch: 2.35 usec per loop
- after patch: 0.721 usec per loop


pybench
-------

("this" is with patch, "other" is without)

Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other 
 diff
-------------------------------------------------------------------------------
                TryRaiseExcept:    77ms   136ms  -43.5%    77ms   137ms
 -43.5%
               WithRaiseExcept:   189ms   280ms  -32.6%   190ms   282ms
 -32.6%
-------------------------------------------------------------------------------
Totals:                           266ms   416ms  -36.1%   267ms   419ms
 -36.2%

Added file: http://bugs.python.org/file11256/isinstance3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Aug 25 23:38:45 2008
From: report at bugs.python.org (Rahul Ghosh)
Date: Mon, 25 Aug 2008 21:38:45 +0000
Subject: [issue3681] Cannot read saved csv file in a single run
In-Reply-To: <1219700325.8.0.911345891687.issue3681@psf.upfronthosting.co.za>
Message-ID: <1219700325.8.0.911345891687.issue3681@psf.upfronthosting.co.za>


New submission from Rahul Ghosh <rahul.ghosh at gmail.com>:

I am trying to save a csv file from a scope and then open it to post 
process the data.
The file is getting created currectly, but when it tries to open the 
csv file it complains about file not found. I am trying to do this in 
a single run. If I rerun the code again, the file open function works 
correctly.

It cannot see the newly created csv file till the python code stops 
and I rerun it. How can I refresh the directory on the fly so that the 
newly saved file is seen right away. I am on windows xp machine.

Appreciate your help.

Thanks.

----------
components: IDLE
messages: 71958
nosy: paul
severity: normal
status: open
title: Cannot read saved csv file in a single run
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3681>
_______________________________________

From report at bugs.python.org  Mon Aug 25 23:40:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 21:40:14 +0000
Subject: [issue3681] Cannot read saved csv file in a single run
In-Reply-To: <1219700325.8.0.911345891687.issue3681@psf.upfronthosting.co.za>
Message-ID: <1219700414.96.0.210083186642.issue3681@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Are you closing the file before trying to read it?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3681>
_______________________________________

From report at bugs.python.org  Mon Aug 25 23:42:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Aug 2008 21:42:55 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219700575.21.0.541673370849.issue2534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch with a couple of tiny fixes.

Added file: http://bugs.python.org/file11257/isinstance3k-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Mon Aug 25 23:45:16 2008
From: report at bugs.python.org (Rahul Ghosh)
Date: Mon, 25 Aug 2008 21:45:16 +0000
Subject: [issue3681] Cannot read saved csv file in a single run
In-Reply-To: <1219700325.8.0.911345891687.issue3681@psf.upfronthosting.co.za>
Message-ID: <1219700716.68.0.819844423979.issue3681@psf.upfronthosting.co.za>


Rahul Ghosh <rahul.ghosh at gmail.com> added the comment:

I wrote a python GPIB command to the scope to export the waveform as a 
csv file. Then in another function I try to read this file that I just 
saved and it cannot find the file till I rerun.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3681>
_______________________________________

From report at bugs.python.org  Mon Aug 25 23:47:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Aug 2008 21:47:36 +0000
Subject: [issue3681] Cannot read saved csv file in a single run
In-Reply-To: <1219700716.68.0.819844423979.issue3681@psf.upfronthosting.co.za>
Message-ID: <1afaf6160808251447p6a8a1d35yaf9951229b0078b4@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Mon, Aug 25, 2008 at 4:45 PM, Rahul Ghosh <report at bugs.python.org> wrote:
>
> Rahul Ghosh <rahul.ghosh at gmail.com> added the comment:
>
> I wrote a python GPIB command to the scope to export the waveform as a
> csv file. Then in another function I try to read this file that I just
> saved and it cannot find the file till I rerun.

Can you paste some code that will reproduce the problem?
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3681>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3681>
_______________________________________

From report at bugs.python.org  Tue Aug 26 02:03:49 2008
From: report at bugs.python.org (Damien Miller)
Date: Tue, 26 Aug 2008 00:03:49 +0000
Subject: [issue3682] test_math: math.log(-ninf) fails to raise exception on
	OpenBSD
In-Reply-To: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za>
Message-ID: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za>


New submission from Damien Miller <djmdjm at users.sourceforge.net>:

Hi,

On OpenBSD 4.4, the test_math.py regression test fails with the following:

Traceback (most recent call last):
  File "Lib/test/test_math.py", line 419, in testLog
    self.assertRaises(ValueError, math.log, NINF)
AssertionError: ValueError not raised

This is because libm's log function does not return NaN when passed
-INFINITY. It returns -INFINITY and sets EDOM. This behaviour seems to
be permitted by the C99 spec (ISO/IEC 9899:1999):

> 7.12.1 Treatment of error conditions
> paragraph2:
> ... On a domain error, the function returns an implementation-defined
> value; if the integer expression math_errhandling & MATH_ERRNO is 
> nonzero, the integer expression errno acquires the value EDOM; 

in mathmodule.c:math_1() errno seems to be deliberately ignored when the
result is infinite. The attached patch modified math_1() to retain EDOM
errors for infinite results.

----------
components: Library (Lib)
files: patch-Modules_mathmodule_c
messages: 71963
nosy: djmdjm
severity: normal
status: open
title: test_math: math.log(-ninf) fails to raise exception on OpenBSD
versions: Python 2.6
Added file: http://bugs.python.org/file11258/patch-Modules_mathmodule_c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3682>
_______________________________________

From report at bugs.python.org  Tue Aug 26 02:06:19 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Aug 2008 00:06:19 +0000
Subject: [issue3682] test_math: math.log(-ninf) fails to raise exception on
	OpenBSD
In-Reply-To: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za>
Message-ID: <1219709179.35.0.195441240981.issue3682@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> marketdickinson
nosy: +marketdickinson
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3682>
_______________________________________

From report at bugs.python.org  Tue Aug 26 02:52:58 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 26 Aug 2008 00:52:58 +0000
Subject: [issue3638] tkinter.mainloop() is meanling less and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1219711978.01.0.513951125006.issue3638@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Tue Aug 26 02:53:31 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 26 Aug 2008 00:53:31 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1219712011.7.0.544796246413.issue3634@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Aug 26 03:35:13 2008
From: report at bugs.python.org (Damien Miller)
Date: Tue, 26 Aug 2008 01:35:13 +0000
Subject: [issue3683] compilation --without-threads fails
In-Reply-To: <1219714513.04.0.272760224775.issue3683@psf.upfronthosting.co.za>
Message-ID: <1219714513.04.0.272760224775.issue3683@psf.upfronthosting.co.za>


New submission from Damien Miller <djmdjm at users.sourceforge.net>:

Compilation with --without-threads fails with the following error. Patch
attached.

cc -c -fno-strict-aliasing -DNDEBUG -O2 -pipe 
-DTHREAD_STACK_SIZE=0x20000 -fPIC  -I. -IInclude -I./Include 
-DPy_BUILD_CORE -o Python/import.o Python/import.c
Python/import.c: In function `PyImport_ImportModuleNoBlock':
Python/import.c:2037: error: `import_lock_thread' undeclared (first use
in this function)
Python/import.c:2037: error: (Each undeclared identifier is reported
only once
Python/import.c:2037: error: for each function it appears in.)
*** Error code 1

----------
components: Interpreter Core
files: patch-Python_import_c
messages: 71964
nosy: djmdjm
severity: normal
status: open
title: compilation --without-threads fails
versions: Python 2.6
Added file: http://bugs.python.org/file11259/patch-Python_import_c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3683>
_______________________________________

From report at bugs.python.org  Tue Aug 26 03:35:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Aug 2008 01:35:25 +0000
Subject: [issue1081824] Rewrite of docs for compiler.visitor
Message-ID: <1219714525.01.0.529919389248.issue1081824@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patch no longer applies cleanly.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1081824>
_______________________________________

From report at bugs.python.org  Tue Aug 26 04:03:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Aug 2008 02:03:31 +0000
Subject: [issue3683] compilation --without-threads fails
In-Reply-To: <1219714513.04.0.272760224775.issue3683@psf.upfronthosting.co.za>
Message-ID: <1219716211.18.0.686701363847.issue3683@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patch looks good to me.

Next time, please a a ".patch" or ".diff" extension to your patch, so it
isn't marked as binary data. Thanks!

----------
keywords: +needs review
nosy: +benjamin.peterson
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3683>
_______________________________________

From report at bugs.python.org  Tue Aug 26 04:30:26 2008
From: report at bugs.python.org (Brodie Rao)
Date: Tue, 26 Aug 2008 02:30:26 +0000
Subject: [issue3684] traceback.format_exception_only() misplaces the caret for
	certain SyntaxErrors
In-Reply-To: <1219717826.16.0.00104451287551.issue3684@psf.upfronthosting.co.za>
Message-ID: <1219717826.16.0.00104451287551.issue3684@psf.upfronthosting.co.za>


New submission from Brodie Rao <junk at dackz.net>:

>> +
  File "<stdin>", line 1
    +
    ^
SyntaxError: invalid syntax
>>> import sys
>>> import traceback
>>> traceback.print_exception(sys.last_type, sys.last_value, None)
  File "<stdin>", line 1
     +
     
^
 SyntaxError: invalid syntax
>>> sys.last_value
SyntaxError('invalid syntax', ('<stdin>', 1, 2, '+\n'))

print_error_text() effectively ignores trailing newlines when placing 
the caret, while traceback.format_exception_only() does not. For certain 
syntax errors the offset reported is sometimes at the newline, as in the 
case of a line of code that ends just with a plus sign (and in other 
similar cases).

I'm attaching a patch for trunk that fixes this issue. I know it also 
affects Python 2.5, and I'm sure it affects versions prior. I don't know 
about Python 3.0.

----------
components: Library (Lib)
files: traceback-caret.patch
keywords: patch
messages: 71967
nosy: brodierao
severity: normal
status: open
title: traceback.format_exception_only() misplaces the caret for certain SyntaxErrors
type: behavior
Added file: http://bugs.python.org/file11260/traceback-caret.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3684>
_______________________________________

From report at bugs.python.org  Tue Aug 26 08:52:34 2008
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 26 Aug 2008 06:52:34 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

I tried to compile Python 3000 under OpenBSD and the compilation fails
because of a 'MemoryError':

Fatal Python error: can't create sys.path
object  : MemoryError()
type    : MemoryError
refcount: 4
address : 0x20abfbd08
lost sys.stderr
Abort trap (core dumped) 
*** Error code 134

Stop in /home/henry/compile/py3k (line 410 of Makefile).

The command which fail is:
CC='gcc -pthread' LDSHARED='gcc -pthread -shared -fPIC ' OPT='-DNDEBUG
-g  -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build

Here is the backtrace:

(gdb) r -E ./setup.py build
Starting program: /home/henry/compile/py3k/python -E ./setup.py build
Fatal Python error: can't create sys.path
object  : MemoryError()
type    : MemoryError
refcount: 4
address : 0x2042d3d08
lost sys.stderr

Program received signal SIGABRT, Aborted.
[Switching to process 20134, thread 0x2015d4800]
0x000000020dc4432a in kill () from /usr/lib/libc.so.48.0
(gdb) bt full
#0  0x000000020dc4432a in kill () from /usr/lib/libc.so.48.0
No symbol table info available.
#1  0x000000020dc8b105 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
        p = (struct atexit *) 0x2064fd000
        cleanup_called = 1
        mask = 4294967263
#2  0x0000000000468a59 in Py_FatalError (msg=0x4ea6 <Address 0x4ea6 out
of bounds>)
    at Python/pythonrun.c:1880
No locals.
#3  0x000000000046e06c in PySys_SetPath (path=0x4ea6) at
Python/sysmodule.c:1390
        v = (PyObject *) 0x0
#4  0x0000000000466b8c in Py_InitializeEx (install_sigs=1) at
Python/pythonrun.c:213
        interp = (PyInterpreterState *) 0x20f8af900
        tstate = (PyThreadState *) 0x20adeda00
        bimod = (PyObject *) 0x2042dc128
        sysmod = (PyObject *) 0x2042dc128
        pstderr = (PyObject *) 0x2042dc128
        p = 0x0
        codeset = 0x2042dc128 "\034"
#5  0x0000000000474136 in Py_Main (argc=4, argv=0x20f0331a0) at
Modules/main.c:497
        r1 = 0
        r2 = 0
        c = 0
        sts = 4
        command = 0x0
        filename = (wchar_t *) 0x0
        module = 0x0
        fp = (FILE *) 0x964e70
        p = 0x6c05 <Address 0x6c05 out of bounds>
        unbuffered = 0
        skipfirstline = 0
        stdin_is_interactive = 1
        help = 0
        version = 0
        saw_unbuffered_flag = 0
        cf = {cf_flags = 0}
#6  0x0000000000412866 in main (argc=4, argv=0x7f7ffffc7920) at
Modules/python.c:57
        argsize = 140187732310304
        argv_copy = (wchar_t **) 0x20f0331a0
        argv_copy2 = (wchar_t **) 0x20f033140
        i = 0
        res = -231136
        oldloc = 0x20e0c1b00 "C"

I also have core file. If you are interested mail me.

----------
messages: 71968
nosy: henry.precheur
severity: normal
status: open
title: Crash while compiling Python 3000 in OpenBSD 4.4
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Tue Aug 26 08:53:46 2008
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 26 Aug 2008 06:53:46 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1219733626.97.0.685674149609.issue3685@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I forgot to mention, I made to following modification to configure.in so
I could compile Python 3000 on OpenBSD 4.4

--- configure.in        (revision 66037)
+++ configure.in        (working copy)
@@ -250,7 +250,7 @@
   # On OpenBSD, select(2) is not available if _XOPEN_SOURCE is defined,
   # even though select is a POSIX function. Reported by J. Ribbens.
   # Reconfirmed for OpenBSD 3.3 by Zachary Hamm, for 3.4 by Jason Ish.
-  OpenBSD/2.* | OpenBSD/3.@<:@0123456789@:>@ | OpenBSD/4.@<:@0123@:>@) 
+  OpenBSD*)
     define_xopen_source=no
     # OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is
     # also defined. This can be overridden by defining _BSD_SOURCE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Tue Aug 26 10:32:33 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Aug 2008 08:32:33 +0000
Subject: [issue3686] PKG-INFO file should differentiate between authors and
	maintainers
In-Reply-To: <1219739553.56.0.760950139316.issue3686@psf.upfronthosting.co.za>
Message-ID: <1219739553.56.0.760950139316.issue3686@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

The PKG-INFO file currently only provides an "Authors" field which is
mapped to the DistributionMetadata.get_contact() information.

However, the latter method is really meant to provide access to contact
information and not authorship, which is why it prefers the maintainer
infos over the actual author infos.

As a result, the maintainer can appear as author in the PKG-INFO file,
which is wrong.

Ideal would be to have both an "Author" and "Maintainer" field in the
PKG-FILE with 1-1 mappings to the setup() parameters.

----------
components: Distutils
messages: 71970
nosy: lemburg
priority: normal
severity: normal
status: open
title: PKG-INFO file should differentiate between authors and maintainers
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3686>
_______________________________________

From report at bugs.python.org  Tue Aug 26 10:48:49 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 26 Aug 2008 08:48:49 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1219740529.15.0.3568142736.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok I will ask for this on the ML

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Tue Aug 26 11:07:46 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 26 Aug 2008 09:07:46 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219741666.87.0.780347505155.issue2415@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Well, if I figured out how to use Rietveld correctly, I've left some
questions for you in the review.  It looks basically pretty good, so if
you could answer those questions, you can commit the change.

Should __bytes__ support be backported to 2.6?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Tue Aug 26 11:10:02 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 26 Aug 2008 09:10:02 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219741802.26.0.644623075834.issue3663@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Tue Aug 26 11:11:44 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 26 Aug 2008 09:11:44 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219741904.37.0.322524520691.issue3663@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Benjamin's reviewed it, so please commit it.  Is there a test for this
crasher?

----------
nosy: +barry
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Tue Aug 26 12:34:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 10:34:55 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219746895.71.0.0418446629101.issue2415@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Should __bytes__ support be backported to 2.6?

Isn't it already there in __str__?
Or do you mean just add support for the alternate method name?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Tue Aug 26 12:38:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 10:38:09 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1219747089.63.0.229269331312.issue3685@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core
priority:  -> release blocker
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Tue Aug 26 13:27:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 11:27:30 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219750050.98.0.268833863294.issue2534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is the same patch, but backported to 2.6.

Added file: http://bugs.python.org/file11261/isinstance26-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Tue Aug 26 14:27:56 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 26 Aug 2008 12:27:56 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219753676.29.0.284605158248.issue2415@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

yep, that's all i meant.  it might not be worth it though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Tue Aug 26 14:40:39 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Tue, 26 Aug 2008 12:40:39 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1219754439.44.0.575712011546.issue3685@psf.upfronthosting.co.za>


Hye-Shik Chang <hyeshik at gmail.com> added the comment:

This problem is due to OpenBSD's libc bug.
It's fixed 3 days ago. (http://www.openbsd.org/cgi-
bin/cvsweb/src/lib/libc/string/wcschr.c#rev1.4)
We can workaround by replacing use of wcschr(ws, L'\0') to ws + 
wcslen(ws).

----------
nosy: +hyeshik.chang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Tue Aug 26 15:02:32 2008
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 26 Aug 2008 13:02:32 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1219755752.39.0.957302960098.issue3548@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Hello,

I was searching for a bug in subprocess
module when I saw your patch.

I was implementing the exact same functionality
and mixed some of your ideas in what I use now,
which is attached...

Feel free to use it

----------
nosy: +vincent.legoll
Added file: http://bugs.python.org/file11262/toto.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Tue Aug 26 15:35:10 2008
From: report at bugs.python.org (Anders J. Munch)
Date: Tue, 26 Aug 2008 13:35:10 +0000
Subject: [issue1759845] subprocess.call fails with unicode strings in command
	line
Message-ID: <1219757710.7.0.571168439612.issue1759845@psf.upfronthosting.co.za>


Changes by Anders J. Munch <2007 at jmunch.dk>:


----------
nosy: +andersjm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Tue Aug 26 15:51:20 2008
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 26 Aug 2008 13:51:20 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1219758680.3.0.556549160212.issue3548@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Here's a clean version with doc & test

enjoy !

Added file: http://bugs.python.org/file11263/pipeline.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Tue Aug 26 15:55:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 13:55:48 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1219758948.19.0.654583242968.issue3548@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Tue Aug 26 16:36:56 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Aug 2008 14:36:56 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219761416.57.0.905520648545.issue2534@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 on applying this patch right away.

For 2.6 and 3.0 to be successful, we need people to prefer to upgrade 
rather than stay with 2.5.  A systemic slowdown in not in the best 
interests of the language moving forward.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Tue Aug 26 16:52:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Aug 2008 14:52:17 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219762337.12.0.873310892618.issue2534@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Both patches look correct to me, and I think they can be applied.

----------
assignee:  -> pitrou
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Tue Aug 26 17:05:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 15:05:38 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219763138.98.0.640219047907.issue3651@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury, assuming you have tested it :-), the patch is ok to me. You can
commit.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Tue Aug 26 17:57:45 2008
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 26 Aug 2008 15:57:45 +0000
Subject: [issue3687] Popen() object stdout attribute reassignment behaviour
In-Reply-To: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za>
Message-ID: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The subprocess.Popen() object documentation should indicate
that the stdout attribute should not be modified after
object construction. Because that won't work.

Or the attribute may be rendered read-only

>>> from subprocess import Popen, PIPE
>>> import sys, os
>>> p1 = Popen(["echo", "1"], stdout = PIPE)
>>> p2 = Popen(["cat"], stdin = p1.stdout, stderr = PIPE, stdout = PIPE)
>>> p2.stdout = sys.stdout
>>> print p2.communicate()

This blocks forever

----------
assignee: georg.brandl
components: Documentation
messages: 71983
nosy: georg.brandl, vincent.legoll
severity: normal
status: open
title: Popen() object stdout attribute reassignment behaviour
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3687>
_______________________________________

From report at bugs.python.org  Tue Aug 26 18:11:56 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 16:11:56 +0000
Subject: [issue3149] multiprocessing build fails on Solaris 10
In-Reply-To: <1213925912.95.0.611829708771.issue3149@psf.upfronthosting.co.za>
Message-ID: <1219767116.58.0.98022312392.issue3149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a duplicate of #3110.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3149>
_______________________________________

From report at bugs.python.org  Tue Aug 26 18:12:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 16:12:00 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1219767120.2.0.955548595587.issue3110@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

FWIW, this is what I find on a Solaris box.

./sys/param.h:#define   _SEM_VALUE_MAX          INT_MAX
./sys/sysconfig.h:#define       _CONFIG_SEM_VALUE_MAX   21      /* max.
value a semaphore may have */
./sys/unistd.h:#define  _SC_SEM_VALUE_MAX               37
./limits.h:#define      _POSIX_SEM_VALUE_MAX    32767

----------
nosy: +pitrou
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3110>
_______________________________________

From report at bugs.python.org  Tue Aug 26 18:45:38 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Tue, 26 Aug 2008 16:45:38 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1219769138.57.0.518230948577.issue2384@psf.upfronthosting.co.za>


Changes by Dwayne Litzenberger <dlitz at dlitz.net>:


----------
nosy: +dlitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Tue Aug 26 19:06:02 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Tue, 26 Aug 2008 17:06:02 +0000
Subject: [issue3688] open() rejects bytes as filename
In-Reply-To: <1219770362.29.0.73954618161.issue3688@psf.upfronthosting.co.za>
Message-ID: <1219770362.29.0.73954618161.issue3688@psf.upfronthosting.co.za>


New submission from Dwayne Litzenberger <dlitz at dlitz.net>:

On Linux/ext3, filenames are stored natively as sequences of octets.  On
Win32/NTFS, they are stored natively as sequences of Unicode code points.

In Python 2.x, the way to unambiguously open a particular file was to
pass the filename as a str object on Linux/ext3 and as a unicode object
on Win32/NTFS.  os.listdir(".") would return every filename as a str
object, and os.listdir(u".") would return every filename as a unicode
object---based on the current locale settings---*except* for filenames
that couldn't be decoded that way.

Consider this bash script (executed on Linux under a UTF-8 locale):

  export LC_CTYPE=en_CA.UTF-8   # requires the en_CA.UTF-8 locale to be
built
  mkdir /tmp/foo
  cd /tmp/foo
  touch $'UTF-8 compatible filename\xc2\xa2'
  touch $'UTF-8 incompatible filename\xc0'

Under Python 2.52, you get this:
  >>> import os
  >>> os.listdir(u".")
  ['UTF-8 incompatible filename\xc0', u'UTF-8 compatible filename\xa2']
  >>> os.listdir(".")
  ['UTF-8 incompatible filename\xc0', 'UTF-8 compatible filename\xc2\xa2']
  >>> [open(f, "r") for f in os.listdir(u".")]
  [<open file 'UTF-8 incompatible filename?, mode 'r' at 0xb7cee578>,
<open file 'UTF-8 compatible filename?', mode 'r' at 0xb7cee6e0>]

Under Python 3.0b3, you get this:
  >>> import os
  >>> os.listdir(".")
  [b'UTF-8 incompatible filename\xc0', 'UTF-8 compatible filename?']
  >>> os.listdir(b".")
  [b'UTF-8 incompatible filename\xc0', b'UTF-8 compatible filename\xc2\xa2']
  >>> [open(f, "r") for f in os.listdir(".")]
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 1, in <listcomp>
    File "/home/dwon/python3.0b3/lib/python3.0/io.py", line 284, in __new__
      return open(*args, **kwargs)
    File "/home/dwon/python3.0b3/lib/python3.0/io.py", line 184, in open
      raise TypeError("invalid file: %r" % file)
  TypeError: invalid file: b'UTF-8 incompatible filename\xc0'

This behaviour of open() makes it impossible to write code that opens
arbitrarily-named files on Linux/ext3.

----------
components: Windows
messages: 71986
nosy: dlitz
severity: normal
status: open
title: open() rejects bytes as filename
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3688>
_______________________________________

From report at bugs.python.org  Tue Aug 26 19:06:48 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Tue, 26 Aug 2008 17:06:48 +0000
Subject: [issue3688] open() rejects bytes as filename
In-Reply-To: <1219770362.29.0.73954618161.issue3688@psf.upfronthosting.co.za>
Message-ID: <1219770408.99.0.999275331617.issue3688@psf.upfronthosting.co.za>


Changes by Dwayne Litzenberger <dlitz at dlitz.net>:


----------
components: +Library (Lib) -Windows
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3688>
_______________________________________

From report at bugs.python.org  Tue Aug 26 19:08:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Aug 2008 17:08:57 +0000
Subject: [issue2415] bytes() should respect __bytes__
In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za>
Message-ID: <1219770537.72.0.154153023757.issue2415@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the review, Barry! Committed in r66038. Sort of backported in
r66039 by aliasing PyObject_Bytes to PyObject_Str.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2415>
_______________________________________

From report at bugs.python.org  Tue Aug 26 19:14:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 Aug 2008 17:14:07 +0000
Subject: [issue3688] open() rejects bytes as filename
In-Reply-To: <1219770362.29.0.73954618161.issue3688@psf.upfronthosting.co.za>
Message-ID: <1219770847.5.0.216427684874.issue3688@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is actively being discussed (and developed) in issue3187

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> os.listdir can return byte strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3688>
_______________________________________

From report at bugs.python.org  Tue Aug 26 19:37:46 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Tue, 26 Aug 2008 17:37:46 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219772266.51.0.314862740465.issue3187@psf.upfronthosting.co.za>


Changes by Dwayne Litzenberger <dlitz at dlitz.net>:


----------
nosy: +dlitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Tue Aug 26 19:50:39 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 26 Aug 2008 17:50:39 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1219773039.67.0.506791719554.issue1210@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Still fails with beta2:

>>> import imaplib
>>> mail=imaplib.IMAP4("mail.rtmq.infosathse.com")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/imaplib.py", line 185, in __init__
    self.welcome = self._get_response()
  File "/usr/local/lib/python3.0/imaplib.py", line 912, in _get_response
    if self._match(self.tagre, resp):
  File "/usr/local/lib/python3.0/imaplib.py", line 1021, in _match
    self.mo = cre.match(s)
TypeError: can't use a string pattern on a bytes-like object

----------
nosy: +cartman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Tue Aug 26 19:51:47 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 26 Aug 2008 17:51:47 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1219773107.54.0.202114637383.issue2464@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Gregory... I tried to fill the path in urlunparse, and other functions
that use this started to fail.

As we're so close to final releases, I'll leave this as it's right now,
that actually fixed the bug...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Tue Aug 26 20:15:21 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Tue, 26 Aug 2008 18:15:21 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1219774521.19.0.793476495037.issue3187@psf.upfronthosting.co.za>


Dwayne Litzenberger <dlitz at dlitz.net> added the comment:

I think Guido already understands this, but I haven't seen it stated
very clearly here:

** Different systems use different "things" to identify files. **

On Linux/ext3, all filenames are *octet strings* (i.e. bytes), and
*only* the following caveats apply:
- a filename/pathname cannot contain the zero-octet (b"\x00").
- a filename/pathname cannot be empty.
- a filename cannot contain the slash (b"/"); In a pathname, the slash
is used to separate filenames.
- the filenames b"." and b".." have special meanings; They cannot be
created, deleted, or renamed.

All filenames that meet these criteria are valid, and calling them
"invalid" amounts to plugging one's ears and shouting "LA LA LA" while
imagining Unicode having pre-dated Unix.

It is sometimes convenient to imagine filenames on Linux/ext3 as
sequences of Unicode code points (where the encoding is specified by
LC_CTYPE---it's not necessarily UTF-8), but other times (e.g. in backup
tools that need to be robust in the face of mischievous users) it is an
unnecessary abstraction that introduces bugs.

On Windows/NTFS, the situation is entirely different: Filenames are
actually sequences of Unicode code points, and if you pretend they are
octet strings, Windows will happily invent phantom filenames for you
that will show up in the output of os.listdir(), but that will return
"File not found" if you try to open them for reading (if you open them
for writing, you risk clobbering other files that happens to have the
same names).

To avoid bugs, it should be possible to work exclusively with filenames
in the platform's native representation.  It was possible in Python 2
(though you had to be very careful).  Ideally, Python 3 would recognize
and enforce the difference instead of trying to guess the translations;
"Explicit is better than implicit" and all that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Tue Aug 26 20:37:31 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 26 Aug 2008 18:37:31 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1219775851.31.0.207954419882.issue1210@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

This may not be a real release blocker, but I want to raise the
priority.  It is a regression and we should try to fix it, especially if
it's easy.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Tue Aug 26 22:17:15 2008
From: report at bugs.python.org (Jeff Hall)
Date: Tue, 26 Aug 2008 20:17:15 +0000
Subject: [issue3689] reversed() not working as intended on lists
In-Reply-To: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za>
Message-ID: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za>


New submission from Jeff Hall <hall.jeff at gmail.com>:

reversed() built in is not functioning correctly with list (specifically
with len() )

l = [1,2,3,4]
rl = reversed(l)

type(rl)
<type 'listreverseiterator'>

vs. strings and tuples which just return 'reverse' objects

listreverseiterators apparently have a len() defined that changes with
each .next() call

----------
messages: 71993
nosy: laxrulz777
severity: normal
status: open
title: reversed() not working as intended on lists
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3689>
_______________________________________

From report at bugs.python.org  Tue Aug 26 22:27:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Aug 2008 20:27:25 +0000
Subject: [issue3689] reversed() not working as intended on lists
In-Reply-To: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za>
Message-ID: <1219782445.22.0.705920157469.issue3689@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

"reversed() built in is not functioning correctly with list" is wrong --
there is no problem with reversed() on lists.

The issue here is that the listreverseiterator has a strange __len__.
Note that other (reverse) iterators have no __len__ at all, so apart
from consistency there is nothing that "does not function correctly."

----------
nosy: +georg.brandl
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3689>
_______________________________________

From report at bugs.python.org  Tue Aug 26 22:31:48 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Aug 2008 20:31:48 +0000
Subject: [issue3689] listreverseiterator has a decreasing len()
In-Reply-To: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za>
Message-ID: <1219782708.27.0.137696380237.issue3689@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
title: reversed() not working as intended on lists -> listreverseiterator has a decreasing len()
versions: +Python 2.6, Python 3.0 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3689>
_______________________________________

From report at bugs.python.org  Tue Aug 26 22:42:57 2008
From: report at bugs.python.org (Armin Ronacher)
Date: Tue, 26 Aug 2008 20:42:57 +0000
Subject: [issue3689] listreverseiterator has a decreasing len()
In-Reply-To: <1219781835.24.0.0803885539905.issue3689@psf.upfronthosting.co.za>
Message-ID: <1219783377.22.0.221976904296.issue3689@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Just for the record.  This original discussion for this bug is here:
http://article.gmane.org/gmane.comp.python.devel/96925

----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3689>
_______________________________________

From report at bugs.python.org  Tue Aug 26 22:52:03 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 26 Aug 2008 20:52:03 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

sys.getsizeof returns wrong results for bool objects in Python 3000.
Although bool objects use the same datatype as long objects, they are
allocated differently. Thus, the inherited long_sizeof implementation is
incorrect. The applied patch addresses this issue.

----------
components: Interpreter Core
files: bool_sizeof.patch
keywords: patch
messages: 71996
nosy: schuppenies
severity: normal
status: open
title: sys.getsizeof wrong for Py3k bool objects
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11264/bool_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Tue Aug 26 23:10:33 2008
From: report at bugs.python.org (David Jones)
Date: Tue, 26 Aug 2008 21:10:33 +0000
Subject: [issue3166] Make conversions from long to float correctly rounded.
In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za>
Message-ID: <1219785033.05.0.251841272286.issue3166@psf.upfronthosting.co.za>


David Jones <drj at pobox.com> added the comment:

I agree, longs should be correctly rounded when coerced to floats.

There is an ugly (but amusing) workaround while people wait for this 
patch:  Go via a string:

int(float(repr(295147905179352891391)[:-1]))

Though I assume this relies on the platform's strtod working correctly.  
Which it does for me.

----------
nosy: +drj

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3166>
_______________________________________

From report at bugs.python.org  Tue Aug 26 23:23:48 2008
From: report at bugs.python.org (Tim Hemming)
Date: Tue, 26 Aug 2008 21:23:48 +0000
Subject: [issue3691] Incorrect variable reference
In-Reply-To: <1219785828.16.0.340928364781.issue3691@psf.upfronthosting.co.za>
Message-ID: <1219785828.16.0.340928364781.issue3691@psf.upfronthosting.co.za>


New submission from Tim Hemming <timhemming at gmail.com>:

The following line is referencing a variable "d", but it should be "dict":

 logging.warning("Protocol problem: %s", "connection reset", extra=d)


Page:- http://www.python.org/doc/2.5/lib/module-logging.html

----------
assignee: georg.brandl
components: Documentation
messages: 71998
nosy: georg.brandl, timh
severity: normal
status: open
title: Incorrect variable reference
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3691>
_______________________________________

From report at bugs.python.org  Tue Aug 26 23:30:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Aug 2008 21:30:10 +0000
Subject: [issue3691] Incorrect variable reference
In-Reply-To: <1219785828.16.0.340928364781.issue3691@psf.upfronthosting.co.za>
Message-ID: <1219786210.83.0.625473170749.issue3691@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This has been fixed in the trunk.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3691>
_______________________________________

From report at bugs.python.org  Wed Aug 27 00:03:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 22:03:28 +0000
Subject: [issue3663] Extra DECREF on syntax errors
In-Reply-To: <1219609229.98.0.504787107965.issue3663@psf.upfronthosting.co.za>
Message-ID: <1219788208.62.0.135978004895.issue3663@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r66041. Thanks everyone.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3663>
_______________________________________

From report at bugs.python.org  Wed Aug 27 00:42:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Aug 2008 22:42:42 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1219790562.0.0.873324097845.issue2534@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r66042 and r66043.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2534>
_______________________________________

From report at bugs.python.org  Wed Aug 27 01:20:14 2008
From: report at bugs.python.org (kai zhu)
Date: Tue, 26 Aug 2008 23:20:14 +0000
Subject: [issue3692] improper scope in list comprehension,
	when used in class declaration
In-Reply-To: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>
Message-ID: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>


New submission from kai zhu <davidbranniganz at gmail.com>:

in 3rd line, list comprehension tries to access class_attribute1 as a
global variable (code is valid in python 2.5)

>>> class Foo(object):
...   class_attribute1 = 1
...   class_attribute2 = [class_attribute1 for x in range(8)]
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in Foo
  File "<stdin>", line 3, in <listcomp>
NameError: global name 'class_attribute1' is not defined

----------
components: Interpreter Core
messages: 72002
nosy: kaizhu
severity: normal
status: open
title: improper scope in list comprehension, when used in class declaration
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3692>
_______________________________________

From report at bugs.python.org  Wed Aug 27 01:44:23 2008
From: report at bugs.python.org (Nicolas Grilly)
Date: Tue, 26 Aug 2008 23:44:23 +0000
Subject: [issue3006] subprocess.Popen causes socket to remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1219794263.56.0.507305408617.issue3006@psf.upfronthosting.co.za>


Changes by Nicolas Grilly <nicolas.grilly at garden-paris.com>:


----------
nosy: +ngrilly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________

From report at bugs.python.org  Wed Aug 27 02:31:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 Aug 2008 00:31:54 +0000
Subject: [issue3651] eval() leaks 1 reference every time
In-Reply-To: <1219442983.37.0.0453387180652.issue3651@psf.upfronthosting.co.za>
Message-ID: <1219797114.91.0.0210360975383.issue3651@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66047.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3651>
_______________________________________

From report at bugs.python.org  Wed Aug 27 03:51:36 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Aug 2008 01:51:36 +0000
Subject: [issue3693] Obscure array.array error message
In-Reply-To: <1219801896.33.0.491668230509.issue3693@psf.upfronthosting.co.za>
Message-ID: <1219801896.33.0.491668230509.issue3693@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 2.5
>>> import array
>>> a = array.array('b', 'fox')
>>>

In 3.0
>>> import array
>>> a = array.array('b', 'fox')
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    a = array.array('b', 'fox')
TypeError: an integer is required

This puzzled me because an integer argument most certainly is not
allowed (one would raise other exceptions.)  Then I realized that 'an
integer' here actually means 'an iterator producing integers' or more
exactly, 'an iterable whose iterator yields integers in the range
implied by the type code'.  What I would like to see is something like

TypeError: for typecode 'b', the optional initializer must be an
iterable of 1 byte integers (such as bytes).

I would also like to see a minor change in the array and array.array
docstrings.  Array.__doc__ lists the typecodes, array.array.__doc__
lists all the other info needed, so that help(array) gives everything
while help(array.array) omits the needed typecode info.  So I would like
to see the typecode info moved to the class docstring with everything
else (and replaced by 'Defines one class: array') so help(array) and
help(array.array) would both give all needed info.

----------
components: Library (Lib)
messages: 72004
nosy: tjreedy
severity: normal
status: open
title: Obscure array.array error message
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3693>
_______________________________________

From report at bugs.python.org  Wed Aug 27 06:29:53 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 27 Aug 2008 04:29:53 +0000
Subject: [issue3694] Undetected error in _struct.pack_into
In-Reply-To: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>
Message-ID: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

The following code leads to XXX Undetected errors in debug builds of
trunk and 3.0:

import _struct
_struct.pack_into(b"8", bytearray(1), None)

Besides that, there's something fishy happening in non-debug builds: 

2.6:
>>> _struct.pack_into(b"8", bytearray(1), None);
>>> _struct.pack_into(b"8", bytearray(1), None);
>>> import sys
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required

3.0:
>>> _struct.pack_into(b"8", bytearray(1), None)
>>> _struct.pack_into(b"8", bytearray(1), None)
SystemError: Objects/longobject.c:433: bad argument to internal function


Found with Fusil.

----------
components: Extension Modules
messages: 72005
nosy: ajaksu2
severity: normal
status: open
title: Undetected error in _struct.pack_into
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3694>
_______________________________________

From report at bugs.python.org  Wed Aug 27 06:36:49 2008
From: report at bugs.python.org (Michel Salim)
Date: Wed, 27 Aug 2008 04:36:49 +0000
Subject: [issue3695] Source tarball for Sphinx 0.4.3 missing
In-Reply-To: <1219811808.96.0.614683444156.issue3695@psf.upfronthosting.co.za>
Message-ID: <1219811808.96.0.614683444156.issue3695@psf.upfronthosting.co.za>


New submission from Michel Salim <salimma at fedoraproject.org>:

Sphinx's website stated that 0.4.3 has been released; however, the
download site only has 0.4.2. Is 0.4.2 still the latest version, or has
the source upload been accidentally omitted?

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 72006
nosy: georg.brandl, hircus
severity: normal
status: open
title: Source tarball for Sphinx 0.4.3 missing
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3695>
_______________________________________

From report at bugs.python.org  Wed Aug 27 06:54:24 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 27 Aug 2008 04:54:24 +0000
Subject: [issue3692] improper scope in list comprehension,
	when used in class declaration
In-Reply-To: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>
Message-ID: <1219812864.57.0.863571440452.issue3692@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I believe the problem is that list comprehensions in 3.0 have scope like
that of genexprs in 2.5, but the change was deliberate (as it also
avoids leaking of temp variables).

Compare to 2.5:
>>> class Foo(object):
...    class_attribute1 = 1
...    class_attribute2 = (class_attribute1 for x in range(8))
...
>>> Foo.class_attribute2.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in <genexpr>
NameError: global name 'class_attribute1' is not defined

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3692>
_______________________________________

From report at bugs.python.org  Wed Aug 27 07:03:20 2008
From: report at bugs.python.org (Henry Precheur)
Date: Wed, 27 Aug 2008 05:03:20 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1219813400.13.0.222536620323.issue3685@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

Indeed it looks like it is the source of the problem.

I created a patch to fix it.

But it looks like there is another problem, instead of crashing the
Python interpreter goes into interactive mode instead of executing the
'setup.py' script ...

I don't think it is related, I have checked the result of ws = ws +
wcslen(ws) and it seems to be correct.

I will investigate the problem and create another entry if it is unrelated.

----------
keywords: +patch
Added file: http://bugs.python.org/file11265/fix_wcschr_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Wed Aug 27 08:20:56 2008
From: report at bugs.python.org (Henry Precheur)
Date: Wed, 27 Aug 2008 06:20:56 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1219818056.15.0.797544741114.issue3685@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

Looks like my other issue is unrelated. It is caused by a buggy mbstowcs.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Wed Aug 27 08:29:32 2008
From: report at bugs.python.org (Henry Precheur)
Date: Wed, 27 Aug 2008 06:29:32 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

The function mbstowcs is buggy on OpenBSD <= 4.4:
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/locale/multibyte_sb.c#rev1.7

Because of this the following command fails:
./python -E setup.py build

The attached patch fixes the problem.

----------
components: Build, Interpreter Core
files: fix_mbstowcs_openbsd.diff
keywords: patch
messages: 72010
nosy: henry.precheur
severity: normal
status: open
title: Error parsing arguments on OpenBSD <= 4.4
versions: Python 3.0
Added file: http://bugs.python.org/file11266/fix_mbstowcs_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 09:32:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Aug 2008 07:32:03 +0000
Subject: [issue3692] improper scope in list comprehension,
	when used in class declaration
In-Reply-To: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>
Message-ID: <1219822323.94.0.192237714639.issue3692@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This won't change -- in 3.0, list comprehensions and generator
expressions are both implemented using a function, so it's like the
following:

class Foo:
    attribute1 = 1
    def f():
        return attribute1
    attribute2 = f()

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3692>
_______________________________________

From report at bugs.python.org  Wed Aug 27 09:38:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 07:38:03 +0000
Subject: [issue3696] mbstowcs
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219822683.2.0.230863783182.issue3696@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
title: Error parsing arguments on OpenBSD <= 4.4 -> mbstowcs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 09:38:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 07:38:29 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219822709.91.0.612821953875.issue3696@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
title: mbstowcs -> Error parsing arguments on OpenBSD <= 4.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 09:53:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 07:53:35 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219823615.14.0.494930957413.issue3696@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

See also issue3626, which is exactly the same for cygwin.

Maybe a "./configure" paragraph could discover whether mbstowcs is broken.
I don't know how to do it though.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 09:53:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 07:53:56 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219823636.12.0.300651764359.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

See also issue3626

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Wed Aug 27 10:44:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Aug 2008 08:44:43 +0000
Subject: [issue3694] Undetected error in _struct.pack_into
In-Reply-To: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>
Message-ID: <1219826683.39.0.734421364883.issue3694@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The problem is that, unlike PyInt_AsSsize_t, PyLong_AsSsize_t expects
its argument to already be a long object and else raises the SystemError.

It should probably behave like PyInt_AsSsize_t and raise the TypeError
since in 3.0 it's used in many places where PyInt_AsSsize_t was used.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3694>
_______________________________________

From report at bugs.python.org  Wed Aug 27 10:47:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Aug 2008 08:47:30 +0000
Subject: [issue3694] Undetected error in _struct.pack_into
In-Reply-To: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>
Message-ID: <1219826850.8.0.608061659143.issue3694@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The attached patches at least correct the XXX undetected error.

----------
keywords: +patch
Added file: http://bugs.python.org/file11267/s26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3694>
_______________________________________

From report at bugs.python.org  Wed Aug 27 10:47:36 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Aug 2008 08:47:36 +0000
Subject: [issue3694] Undetected error in _struct.pack_into
In-Reply-To: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>
Message-ID: <1219826856.32.0.127114553421.issue3694@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Added file: http://bugs.python.org/file11268/s30.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3694>
_______________________________________

From report at bugs.python.org  Wed Aug 27 11:26:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 09:26:29 +0000
Subject: [issue3694] Undetected error in _struct.pack_into
In-Reply-To: <1219811392.29.0.37826020023.issue3694@psf.upfronthosting.co.za>
Message-ID: <1219829189.39.0.384260891399.issue3694@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Isn't PyNumber_AsSsize_t designed for this purpose?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3694>
_______________________________________

From report at bugs.python.org  Wed Aug 27 13:06:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 11:06:00 +0000
Subject: [issue3697] "Fatal Python error: Cannot recover from stack overflow"
	on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This error appears more or less regularly on the Windows py3k buildbots.
Today it has appeared following my changes to isinstance() /
issubclass(), but it had already appeared before, e.g.
http://www.python.org/dev/buildbot/3.0.stable/x86%20XP-4%203.0/builds/1093/step-test/0

What puzzles me is that the said "Fatal Python error" is computed in a
deterministic way (from the overflowing of the recursion counter),
therefore it shouldn't occur randomly on only some selected platforms.

----------
components: Interpreter Core, Windows
messages: 72017
nosy: pitrou
priority: critical
severity: normal
status: open
title: "Fatal Python error: Cannot recover from stack overflow" on Windows buildbots
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3697>
_______________________________________

From report at bugs.python.org  Wed Aug 27 13:45:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 11:45:53 +0000
Subject: [issue3697] "Fatal Python error: Cannot recover from stack overflow"
	on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1219837548.5631.3.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is because of the USE_STACKCHECK macro, which is only defined in
debug mode with Microsoft compilers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3697>
_______________________________________

From report at bugs.python.org  Wed Aug 27 13:55:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 11:55:52 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219838152.47.0.295066265172.issue3696@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is another patch, which tries to replace all problematic usages of
mbstowcs, and a new "#define HAVE_BROKEN_MBSTOWCS" to activate it.

It needs a review, especially the "configure" stuff, it's my first time
to deal with this.

Tested on cygwin.

Added file: http://bugs.python.org/file11269/mbstowcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 13:56:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 11:56:07 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219838167.98.0.316400092631.issue3696@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 13:56:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 11:56:32 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219838192.78.0.589458421823.issue3626@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Wed Aug 27 13:58:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 11:58:52 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219838332.03.0.62091122018.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

See also issue3696, and the patch provided there.

Yaakov, you should remove the _locale.dll from your build directory: for
the compilation phase, better have no locale at all than a broken "U" as
default encoding ("U" is the initial of UTF8)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Wed Aug 27 14:16:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 12:16:19 +0000
Subject: [issue3697] "Fatal Python error: Cannot recover from stack overflow"
	on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1219839379.28.0.825314279293.issue3697@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch uploaded to http://codereview.appspot.com/3276, verified to fix
the problem on a Windows XP virtual machine. Please review.

----------
keywords: +needs review, patch
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3697>
_______________________________________

From report at bugs.python.org  Wed Aug 27 14:25:36 2008
From: report at bugs.python.org (Peter Harris)
Date: Wed, 27 Aug 2008 12:25:36 +0000
Subject: [issue1840] Tools/i18n/msgfmt.py fixes for Python 3.0
In-Reply-To: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za>
Message-ID: <1219839936.8.0.946815996861.issue1840@psf.upfronthosting.co.za>


Peter Harris <scav at users.sourceforge.net> added the comment:

As far as I can tell, it is OK now.  Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1840>
_______________________________________

From report at bugs.python.org  Wed Aug 27 14:30:00 2008
From: report at bugs.python.org (Guillaume Coffin)
Date: Wed, 27 Aug 2008 12:30:00 +0000
Subject: [issue3698] incompatible arguments in warning formatting for idle
In-Reply-To: <1219840200.32.0.559754862412.issue3698@psf.upfronthosting.co.za>
Message-ID: <1219840200.32.0.559754862412.issue3698@psf.upfronthosting.co.za>


New submission from Guillaume Coffin <guillaumecoffin at gmail.com>:

In idle, the function idle_formatwarning_subproc overrides
warnings.formatwarning, however the latter in Python 2.6 is called from
warnings._show_warning with an additional "line" argument:

line 29, in _show_warning
file.write(formatwarning(message, category, filename, lineno, line))

whereas idle_formatwarning_subproc still only accepts 4 arguments. The
optional line argument should be added.

----------
components: IDLE
messages: 72023
nosy: gcoffin
severity: normal
status: open
title: incompatible arguments in warning formatting for idle
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3698>
_______________________________________

From report at bugs.python.org  Wed Aug 27 14:50:16 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 27 Aug 2008 12:50:16 +0000
Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com
In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za>
Message-ID: <1219841416.71.0.797160775944.issue2464@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

That was reason in making fix_broken in the urlparse in my patch, Facundo.
I had thought, it should be handled in urlparse module and if we make
changes in the urlparse.urlunparse/urlparse.urlparse, then we are
stepping into area which will break a lot of tests.

I am kind of +0 with the current fix in urllib2. Should we think/plan
for something in urlparse, akin to fix_broken?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2464>
_______________________________________

From report at bugs.python.org  Wed Aug 27 14:53:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 12:53:27 +0000
Subject: [issue3699] test_bigaddrspace broken
In-Reply-To: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>
Message-ID: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

./python3 Lib/test/regrtest.py -v -M 2.1Gb test_bigaddrspace
test_bigaddrspace
test_concat (test.test_bigaddrspace.StrTest) ... ERROR
test_optimized_concat (test.test_bigaddrspace.StrTest) ... ERROR

======================================================================
ERROR: test_concat (test.test_bigaddrspace.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 697, in
wrapper
    return f(self)
  File "/home/antoine/py3k/__svn__/Lib/test/test_bigaddrspace.py", line
13, in test_concat
    s1 = 'x' * MAX_Py_ssize_t
OverflowError: repeated string is too long

======================================================================
ERROR: test_optimized_concat (test.test_bigaddrspace.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 697, in
wrapper
    return f(self)
  File "/home/antoine/py3k/__svn__/Lib/test/test_bigaddrspace.py", line
18, in test_optimized_concat
    x = 'x' * MAX_Py_ssize_t
OverflowError: repeated string is too long

----------------------------------------------------------------------
Ran 2 tests in 0.019s

----------
components: Tests
messages: 72025
nosy: pitrou
priority: high
severity: normal
status: open
title: test_bigaddrspace broken
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3699>
_______________________________________

From report at bugs.python.org  Wed Aug 27 15:03:24 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 27 Aug 2008 13:03:24 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1219842204.65.0.944672305882.issue3675@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Well, this is obviously caused by renaming "__builtin__" to "builtins"
and the fact that set (as well as frozenset) doesn't have its own opcode
and therefore gets looked up in "builtins". The problem therefore
extends to all builtin objects without opcode special casing (e.g.
object, slice, property, ...) I'm afraid that means we have to pickle
"builtins" as "__builtin__" for backwards compatibility in protocols <= 2.

But aside from that, wouldn't it be more consistent to have opcodes for
set/frozenset in protocol 3?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Wed Aug 27 15:15:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 13:15:27 +0000
Subject: [issue3700] test_bigmem broken
In-Reply-To: <1219842927.03.0.0279927049136.issue3700@psf.upfronthosting.co.za>
Message-ID: <1219842927.03.0.0279927049136.issue3700@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

./python3 Lib/test/regrtest.py -v -M 2.1Gb test_bigmem 
test_bigmem

[snip skipped tests]

======================================================================
ERROR: test_center_unicode (test.test_bigmem.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 682, in
wrapper
    return f(self, maxsize)
  File "/home/antoine/py3k/__svn__/Lib/test/test_bigmem.py", line 60, in
test_center_unicode
    s = SUBSTR.center(size)
MemoryError

======================================================================
ERROR: test_encode_raw_unicode_escape (test.test_bigmem.StrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/support.py", line 682, in
wrapper
    return f(self, maxsize)
  File "/home/antoine/py3k/__svn__/Lib/test/test_bigmem.py", line 102,
in test_encode_raw_unicode_escape
    return self.basic_encode_test(size, 'raw_unicode_escape')
  File "/home/antoine/py3k/__svn__/Lib/test/test_bigmem.py", line 92, in
basic_encode_test
    s = c * size
TypeError: can't multiply sequence by non-int of type 'float'

----------------------------------------------------------------------
Ran 88 tests in 0.225s

----------
components: Tests
messages: 72027
nosy: pitrou
priority: critical
severity: normal
status: open
title: test_bigmem broken
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3700>
_______________________________________

From report at bugs.python.org  Wed Aug 27 15:18:15 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 13:18:15 +0000
Subject: [issue3700] test_bigmem broken
In-Reply-To: <1219842927.03.0.0279927049136.issue3700@psf.upfronthosting.co.za>
Message-ID: <1219843095.29.0.0566684021854.issue3700@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would be nice if at least one of the buildbots could run the bigmem
tests.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3700>
_______________________________________

From report at bugs.python.org  Wed Aug 27 15:30:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 13:30:19 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219843819.02.0.659834997528.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

cygwin has also a nasty bug:
    printf("%ls", wide_string)
fails for strings of length 1. %S has the same problem.

$ ./python.exe ab
./python: can't open file 'ab': [Errno 2] No such file or directory

$ ./python.exe a
./python

The output stops at "./python", probably because stderr has an error
flag set.

Since %ls is only used in Modules/main.c, the best is probably to
replace it with something else. And since cygwin has no function of the
family of wprintf or fputws, PyUnicode is probably the way to go.

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Wed Aug 27 15:59:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 13:59:44 +0000
Subject: [issue3701] test_ntpath.test_relpath fails when launched from a
	different Windows drive
In-Reply-To: <1219845584.1.0.97722173565.issue3701@psf.upfronthosting.co.za>
Message-ID: <1219845584.1.0.97722173565.issue3701@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

C:\>z:PCbuild\python_d.exe z:Lib\test\regrtest.py -uall -v test_ntpath
test_ntpath
test_abspath (test.test_ntpath.TestNtpath) ... ok
test_commonprefix (test.test_ntpath.TestNtpath) ... ok
test_expandvars (test.test_ntpath.TestNtpath) ... ok
test_isabs (test.test_ntpath.TestNtpath) ... ok
test_join (test.test_ntpath.TestNtpath) ... ok
test_normpath (test.test_ntpath.TestNtpath) ... ok
test_relpath (test.test_ntpath.TestNtpath) ... ERROR
test_split (test.test_ntpath.TestNtpath) ... ok
test_splitdrive (test.test_ntpath.TestNtpath) ... ok
test_splitext (test.test_ntpath.TestNtpath) ... ok
test_splitunc (test.test_ntpath.TestNtpath) ... ok

======================================================================
ERROR: test_relpath (test.test_ntpath.TestNtpath)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\py3k\__svn__\lib\test\test_ntpath.py", line 171, in test_relpath
    tester('ntpath.relpath("a")', 'a')
  File "Z:\py3k\__svn__\lib\test\test_ntpath.py", line 13, in tester
    %(str(fn), str(wantResult), str(gotResult)))
test.support.TestFailed: ntpath.relpath("a") should return: a but
returned: ..\a

----------
components: Library (Lib), Tests
messages: 72030
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_ntpath.test_relpath fails when launched from a different Windows drive
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3701>
_______________________________________

From report at bugs.python.org  Wed Aug 27 16:01:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 14:01:42 +0000
Subject: [issue3702] test_urllib2.test_trivial fails when run from another
	Windows drive
In-Reply-To: <1219845702.82.0.0720973084926.issue3702@psf.upfronthosting.co.za>
Message-ID: <1219845702.82.0.0720973084926.issue3702@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

======================================================================
ERROR: test_trivial (test.test_urllib2.TrivialTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\py3k\__svn__\lib\urllib\request.py", line 1199, in
open_local_file
    stats = os.stat(localfile)
WindowsError: [Error 3] Le chemin d'acc?s sp?cifi? est introuvable:
'\\py3k\\__s
vn__\\lib\\urllib\\request.py'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Z:\py3k\__svn__\lib\test\test_urllib2.py", line 32, in test_trivial
    f = urllib.request.urlopen(file_url)
  File "Z:\py3k\__svn__\lib\urllib\request.py", line 122, in urlopen
    return _opener.open(url, data, timeout)
  File "Z:\py3k\__svn__\lib\urllib\request.py", line 359, in open
    response = self._open(req, data)
  File "Z:\py3k\__svn__\lib\urllib\request.py", line 377, in _open
    '_open', req)
  File "Z:\py3k\__svn__\lib\urllib\request.py", line 337, in _call_chain
    result = func(*args)
  File "Z:\py3k\__svn__\lib\urllib\request.py", line 1178, in file_open
    return self.open_local_file(req)
  File "Z:\py3k\__svn__\lib\urllib\request.py", line 1213, in
open_local_file
    raise URLError(msg)
urllib.error.URLError: <urlopen error [Error 3] Le chemin d'acc?s
sp?cifi? est i
ntrouvable: '\\py3k\\__svn__\\lib\\urllib\\request.py'>

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 72031
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_urllib2.test_trivial fails when run from another Windows drive
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3702>
_______________________________________

From report at bugs.python.org  Wed Aug 27 16:04:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 14:04:14 +0000
Subject: [issue3702] test_urllib2.test_trivial fails when run from another
	Windows drive
In-Reply-To: <1219845702.82.0.0720973084926.issue3702@psf.upfronthosting.co.za>
Message-ID: <1219845854.04.0.206694937476.issue3702@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What I forgot to say is that the test was launched from the C: drive:

C:\>z:PCbuild\python_d.exe z:Lib\test\regrtest.py -uall -v test_urllib2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3702>
_______________________________________

From report at bugs.python.org  Wed Aug 27 16:26:02 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 27 Aug 2008 14:26:02 +0000
Subject: [issue3703] open() on directory raises IOError with unhelpful message
In-Reply-To: <1219847162.49.0.00805052293115.issue3703@psf.upfronthosting.co.za>
Message-ID: <1219847162.49.0.00805052293115.issue3703@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

When trying to open a directory (on Linux), Python 2.x complained with

>>> open("local")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 21] Is a directory

Python 3.0 however gives the rather unhelpful or even wrong

>>> open("local")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/MC/hagenf/local/lib/python3.0/io.py", line 284, in __new__
    return open(*args, **kwargs)
  File "/home/MC/hagenf/local/lib/python3.0/io.py", line 223, in open
    closefd)
IOError: [Errno 0] Error: 'local'

----------
components: Library (Lib)
messages: 72033
nosy: hagen
severity: normal
status: open
title: open() on directory raises IOError with unhelpful message
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3703>
_______________________________________

From report at bugs.python.org  Wed Aug 27 17:07:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 15:07:44 +0000
Subject: [issue3703] open() on directory raises IOError with unhelpful message
In-Reply-To: <1219847162.49.0.00805052293115.issue3703@psf.upfronthosting.co.za>
Message-ID: <1219849664.19.0.977682665601.issue3703@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There is a call to dircheck(), but not in the correct place.
The attached patch makes sure that the "Is a directory" message is not
overwritten.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
priority:  -> critical
Added file: http://bugs.python.org/file11270/dircheck.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3703>
_______________________________________

From report at bugs.python.org  Wed Aug 27 19:01:41 2008
From: report at bugs.python.org (Andy Kilpatrick)
Date: Wed, 27 Aug 2008 17:01:41 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>


New submission from Andy Kilpatrick <andy.kilpatrick at metaswitch.com>:

cookielib doesn't handle URLs like "http://server/script?
err=/base/error.html&ok=/base/ok.html", as 
CookieJar::_cookie_from_cookie_tuple uses rfind("/") to strip off the 
end of the URL, returning "http://server/script?
err=/base/error.html&okc=/base" instead of "http://server/script".

My suggested fix (attached, line 1465-1468) is to first strip off 
anything after "?" if present, then continue as with existing code.

----------
components: None
files: cookielib.py
messages: 72035
nosy: andyk
severity: normal
status: open
title: cookielib doesn't handle URLs with / in parameters
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11271/cookielib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Wed Aug 27 19:51:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 17:51:46 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219859506.88.0.737565457485.issue3696@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 20:05:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 18:05:41 +0000
Subject: [issue3705] py3k aborts if "-c" or "-m" is given a non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The explanation is quite simple: in Py_Main, the arguments are converted
from wide to byte strings, but the required length of the byte string is
assumed equal to that of the wide string.

Which gives:

$ ./python -c "print('?')"
Fatal Python error: not enough memory to copy -c argument
Erreur de segmentation (core dumped)
$ ./python -m ?
Fatal Python error: not enough memory to copy -m argument
Erreur de segmentation (core dumped)

----------
messages: 72036
nosy: pitrou
severity: normal
status: open
title: py3k aborts if "-c" or "-m" is given a non-ascii value
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Wed Aug 27 20:06:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 18:06:33 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219860393.01.0.685241874619.issue3696@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks fine and harmless to me (but I'm a configure newbie
too). +1 for committing it and seeing if the OpenBSD buildbot feels better.

In the process of testing this patch, I've found another bug: #3705.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 20:21:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 18:21:59 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219861319.77.0.238630054682.issue3696@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mmh, in Modules/python.c and Python/frozenmain.c, the return value of
the second call to mbstowcs() should be checked as well (since the first
one is sometimes replaced by a call to strlen(), which never fails).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Wed Aug 27 20:53:32 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 27 Aug 2008 18:53:32 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1219863212.75.0.107061592067.issue1204@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

In the configure{.in} exist another bug:
--------------
AC_CHECK_LIB(readline, readline)
if test "$ac_cv_have_readline_readline" = no
then
  AC_CHECK_LIB(termcap, readline)
fi
--------------
but "grep _readline_readline configure" show that variable in use is
$ac_cv_lib_readline_readline, so the check for function termcap in
readline can be removed safely - it is never reached.

I would like to propose another patch that don't use possible unresolved
symbol to detect presence of library. The new patch will define
HAVE_LIBREADLINE. If necessary will check for dependent library
and link it in correct order. The script print messages like next:
------
checking how to link readline libs... -lreadline -lncursesw
checking for rl_callback_handler_install in -lreadline... yes
checking for rl_pre_input_hook in -lreadline... yes
checking for rl_completion_matches in -lreadline... yes
------

The patch is for branch release25-maint.
It is without changes in configure script, i.e autoconf has to run to
recreate it after applying.
The patch can be applied to trunk as well.

----------
nosy: +rpetrov
Added file: http://bugs.python.org/file11272/python-release25-readline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Wed Aug 27 21:17:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 19:17:17 +0000
Subject: [issue3705] py3k aborts if "-c" or "-m" is given a non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1219864637.3.0.443278778908.issue3705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch which works under Linux. Under Windows it doesn't choke
when converting arguments anymore, but it fails later in the process (in
the parser for '-c', in the importing logic for '-m').

Here is an example:

$ ./python -c "print(ord('?'))"
4608
$ cat > ?.py
print(__file__)

$ ./python -m ?
/home/antoine/py3k/mbstowcs/?.py
$ ./python ?.py 
?.py

----------
keywords: +patch
Added file: http://bugs.python.org/file11273/convert_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Wed Aug 27 22:43:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 20:43:27 +0000
Subject: [issue3705] py3k aborts if "-c" or "-m" is given a non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1219869807.18.0.127928665467.issue3705@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Wed Aug 27 22:52:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Aug 2008 20:52:38 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219870358.23.0.989115062351.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Some progress:
The lines suppressed by the patch at http://bugs.python.org/msg71579
either do nothing (because e.g exc_type is already NULL or None),
or happen to be in a case similar to the script "lostcontext2.py"
(Most of the time, the flush() function in io.py).

So again, I think these lines should be suppressed.
The test suite still pass, and all the "-R::" I ran did return identical
result.
Can this patch go in?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 27 23:33:45 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Wed, 27 Aug 2008 21:33:45 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219872825.93.0.878273283038.issue3626@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

Thanks for your persistence with this.

Corinna got _wcsrtombs_r fixed in newlib, so I imagine the next Cygwin
1.7 preview will have the fix.  Unfortunately that won't help the
still-stable Cygwin 1.5.  I'm not sure what you mean by PyUnicode being
a workaround; if you could propose a patch, I'll be happy to try it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Wed Aug 27 23:36:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 21:36:17 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219872977.21.0.0963558423455.issue3611@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Can this patch go in?

I'm ok for it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Wed Aug 27 23:41:04 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Wed, 27 Aug 2008 21:41:04 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1219873264.86.0.965774186648.issue3626@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

Another thing: _bsddb does not compile with db4.7:

Modules/_bsddb.c: In function `DBSequence_get_cachesize':
Modules/_bsddb.c:5022: warning: passing arg 2 of pointer to function
from incompatible pointer type
Modules/_bsddb.c: In function `DBEnv_db_home_get':
Modules/_bsddb.c:5331: error: structure has no member named `db_home'
Modules/_bsddb.c:5334: error: structure has no member named `db_home'
Modules/_bsddb.c: In function `PyInit__bsddb':
Modules/_bsddb.c:5948: error: `DB_LOG_AUTOREMOVE' undeclared (first use
in this function)
Modules/_bsddb.c:5948: error: (Each undeclared identifier is reported
only once
Modules/_bsddb.c:5948: error: for each function it appears in.)
Modules/_bsddb.c:5949: error: `DB_DIRECT_LOG' undeclared (first use in
this function)
Modules/_bsddb.c:5957: error: `DB_LOG_INMEMORY' undeclared (first use in
this function)

4.5 and 4.6 both give the first warning, but no errors.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Wed Aug 27 23:41:53 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 27 Aug 2008 21:41:53 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1219873313.66.0.856925926254.issue3623@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Wed Aug 27 23:56:56 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Aug 2008 21:56:56 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1219874216.32.0.910110306552.issue3660@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As of r66047, I get the following results (without "-uall", though):

test_unittest leaked [124, 124] references, sum=248
test_binascii leaked [1, 1] references, sum=2
test_distutils leaked [141, 142] references, sum=283
test_logging leaked [219, 147] references, sum=366
test_multiprocessing leaked [0, 1] references, sum=1
test_pickle leaked [1, 1] references, sum=2
test_pickletools leaked [1, 1] references, sum=2
test_popen leaked [37, 0] references, sum=37
test_site leaked [88, 88] references, sum=176
test_sqlite leaked [17, 17] references, sum=34
test_unicode leaked [2, 2] references, sum=4
test_urllib2_localnet leaked [3, 3] references, sum=6
test_xmlrpc leaked [-84, 85] references, sum=1

24 tests skipped:
    test_bsddb3 test_cProfile test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dbm_gnu test_kqueue test_nis test_normalization
    test_ossaudiodev test_pep277 test_socketserver test_startfile
    test_tcl test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Thu Aug 28 00:35:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Aug 2008 22:35:07 +0000
Subject: [issue3706] Fix error message for wrong exec() argument type
In-Reply-To: <1219876507.34.0.480466354345.issue3706@psf.upfronthosting.co.za>
Message-ID: <1219876507.34.0.480466354345.issue3706@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Fixes exec() message that claims it supports file objects.

Also makes error messages from compile(), exec() and eval() more
concrete, and in the case of compile() more correct.

----------
files: bltin.diff
keywords: needs review, patch, patch
messages: 72046
nosy: georg.brandl
priority: normal
severity: normal
status: open
title: Fix error message for wrong exec() argument type
Added file: http://bugs.python.org/file11274/bltin.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3706>
_______________________________________

From report at bugs.python.org  Thu Aug 28 00:44:19 2008
From: report at bugs.python.org (Mike Speciner)
Date: Wed, 27 Aug 2008 22:44:19 +0000
Subject: [issue3707] help('finally') behaves bizarrely
In-Reply-To: <1219877059.52.0.153636497207.issue3707@psf.upfronthosting.co.za>
Message-ID: <1219877059.52.0.153636497207.issue3707@psf.upfronthosting.co.za>


New submission from Mike Speciner <speciner_michael at emc.com>:

I'm running Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC
v.1500 32 bit (Intel)] on win32.
Typing help('finally') loops, repeatedly typing the following two lines

File "C:\Python30\lib\pydoc.py", line 1777, in showtopic
  return self.showtopic(target)

----------
messages: 72047
nosy: ms
severity: normal
status: open
title: help('finally') behaves bizarrely
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3707>
_______________________________________

From report at bugs.python.org  Thu Aug 28 00:59:51 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Aug 2008 22:59:51 +0000
Subject: [issue3707] help('finally') behaves bizarrely
In-Reply-To: <1219877059.52.0.153636497207.issue3707@psf.upfronthosting.co.za>
Message-ID: <1219877991.36.0.323752882014.issue3707@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Good catch! Patch attached.

----------
keywords: +easy, needs review, patch
nosy: +georg.brandl
priority:  -> critical
Added file: http://bugs.python.org/file11275/pydoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3707>
_______________________________________

From report at bugs.python.org  Thu Aug 28 01:00:32 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 27 Aug 2008 23:00:32 +0000
Subject: [issue3521] file.readline: bad exception recovery
In-Reply-To: <1218148611.21.0.579552262714.issue3521@psf.upfronthosting.co.za>
Message-ID: <1219878032.61.0.334432539449.issue3521@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Patch attached, suggested test below.

def test_readline():
    for mode in ('r', 'rb', 'r+', 'r+b'):
        f = open(__file__, mode)
        try:
            f.readline(0.1)
        except TypeError:
            tmp = f.readline()
        f.close()
    print('OK')

test_readline()

----------
keywords: +patch
nosy: +ajaksu2
Added file: http://bugs.python.org/file11276/file.readline.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3521>
_______________________________________

From report at bugs.python.org  Thu Aug 28 01:30:12 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 27 Aug 2008 23:30:12 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Calling os.urandom(1 + float(x)) ends in a infinite loop due to a naive
condition check:

while len(bytes) < n:
    bytes += read(_urandomfd, n - len(bytes))

Trivial patch attached.

----------
components: Library (Lib)
files: urandom.diff
keywords: patch
messages: 72050
nosy: ajaksu2
severity: normal
status: open
title: os.urandom(1.1): infinite loop
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11277/urandom.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Thu Aug 28 01:43:47 2008
From: report at bugs.python.org (Yang Zhao)
Date: Wed, 27 Aug 2008 23:43:47 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>


New submission from Yang Zhao <yang at yangman.ca>:

send_header() in BaseHTTPRequestHandler currently does a write to socket
every time send_header() is called. This results in excessive number of
TCP packets being regenerated. Ideally, as much of the HTTP packet is
buffered as possible, but, at minimum, the header should be sent with a
single write as there is a convenient end_header() functional available.

Behaviour is observed under python 2.5, but the related code looks
identical in SVN trunk.

Will contribute patch if request is deemed reasonable but no one is
available to work on it; I just need a few days.

----------
components: Library (Lib)
messages: 72051
nosy: yangman
severity: normal
status: open
title: BaseHTTPRequestHandler innefficient when sending HTTP header
type: performance
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Thu Aug 28 02:09:05 2008
From: report at bugs.python.org (Ben Cottrell)
Date: Thu, 28 Aug 2008 00:09:05 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>


New submission from Ben Cottrell <tamino at wolfhut.org>:

This is a copy of a message I sent to the python-dev mailing list; it
was suggested in a reply that I file a bug for this issue. I'm
filing it against Python 2.5 because that's where I noticed it,
but it doesn't look like this code has changed much in trunk.

I noticed that thread._local can leak references if objects are
being stored inside the thread._local object whose destructors
might release the GIL.

The way this happens is that in Modules/threadmodule.c, in the
_ldict() function, it does things like this:

                Py_CLEAR(self->dict);
                Py_INCREF(ldict);
                self->dict = ldict;

If the Py_CLEAR ends up taking away the last reference to an object
contained in the dict, and a thread context switch occurs during that
object's deallocation, then self->dict might not be NULL on return
from Py_CLEAR; another thread might have run, accessed something in
the same thread._local object, and caused self->dict to be set to
something else (and Py_INCREF'ed). So when we blindly do the
assignment into self->dict, we may be overwriting a valid reference,
and not properly Py_DECREFing it.

The recent change (revision 64601 to threadmodule.c) did not address
context switches during the Py_CLEAR call; only context switches
during tp_init.

The attached patch (against trunk) is my first attempt at fixing this.
It detects if self->dict has been set to something else after the
Py_CLEAR, and retries the Py_CLEAR (because _ldict really only cares
about installing the proper value of self->dict for the currently
running thread).

However, I am still uncomfortable about the fact that local_getattro
and local_setattro discard the value returned from _ldict, and instead
hand off control to the PyObject_Generic layer and trust that by the
time self->dict is actually used, it still has the correct value for
the current thread. Would it be better to, say, inline a copy of the
PyObject_Generic* functions inside local_getattro/local_setattro,
and force the operations to be done on the actual dict returned by
_ldict()?

----------
components: Extension Modules
files: threadmodule.c.diff
keywords: patch
messages: 72052
nosy: tamino
severity: normal
status: open
title: Reference leak in thread._local
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11278/threadmodule.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Thu Aug 28 02:14:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 00:14:14 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219882454.99.0.820868734214.issue3710@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, rather than the while loop in your proposal, the proper idiom would be:

                PyObject *olddict = self->dict;
                Py_INCREF(ldict);
                self->dict = ldict;
                Py_XDECREF(olddict);

----------
nosy: +pitrou
priority:  -> high
versions: +Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Thu Aug 28 02:18:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 00:18:27 +0000
Subject: [issue3705] py3k aborts if "-c" or "-m" is given a non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1219882707.6.0.438195550933.issue3705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +needs review
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Thu Aug 28 02:19:00 2008
From: report at bugs.python.org (Ben Cottrell)
Date: Thu, 28 Aug 2008 00:19:00 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219882740.8.0.289287748562.issue3710@psf.upfronthosting.co.za>


Ben Cottrell <tamino at wolfhut.org> added the comment:

But then if there is a context switch during the last Py_XDECREF, then
it could be the case that self->dict is not set properly on return from
_ldict().

Functions like local_setattro() use _ldict() more for its side effect
(setting self->dict) than for its return value. It's possible that
this should be changed; see the last paragraph in my original report.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Thu Aug 28 02:38:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 00:38:01 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219883881.55.0.153024063208.issue3710@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But then if there is a context switch during the last Py_XDECREF, then
> it could be the case that self->dict is not set properly on return from
> _ldict().

Well, C code is effectively locked in a single thread until the GIL is
released. It means that a piece of C code which doesn't release the GIL
behaves as a critical section. So the only thing to consider, IMO, is
whether the GIL can still be released between "if (ldict == NULL)" and
"self->dict = ldict".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Thu Aug 28 02:51:21 2008
From: report at bugs.python.org (Ben Cottrell)
Date: Thu, 28 Aug 2008 00:51:21 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219884681.31.0.719150129398.issue3710@psf.upfronthosting.co.za>


Ben Cottrell <tamino at wolfhut.org> added the comment:

The specific thing that was happening for me is that an
_sqlite3.Connection object was in the dictionary. In
Modules/_sqlite/connection.c, in pysqlite_connection_dealloc(),
it uses Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS.

So it's the call to Py_DECREF that's interesting from my point
of view. I believe that if _ldict() sets self->dict to what it
should be for the current thread, and then calls Py_DECREF on
the old value, and then returns, then _ldict() is no longer
able to guarantee that self->dict will be set to the right
thing for the current thread after it returns (because if the
Py_DECREF ended up deallocating something like an sqlite3
connection, then it'd have released and reacquired the GIL).

Hence, in the patch I attached, the assignment into self->dict
is kept as the last thing that happens before _ldict() returns,
and I believe this means _ldict() can still make that guarantee.

Of course, I'd be all for changing local_getattro/local_setattro
to not need _ldict to make that guarantee! _ldict always *returns*
the correct pointer; it would be nice to make use of that somehow.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Thu Aug 28 04:36:21 2008
From: report at bugs.python.org (Henry Precheur)
Date: Thu, 28 Aug 2008 02:36:21 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219890981.89.0.468528483065.issue3696@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I removed my previous patch. It was not dealing with all broken mbstowcs
cases and yours is much better.

Some comments on the other patch:

I don't think the macro HAVE_BROKEN_MBSTOWCS alone is a perfect idea. It
won't fix the problem in the long run:

Most contributors won't be aware of this problem and might be using
mbstowcs without putting the #ifdef's. Then the problem will come back
and bite us again.

I would rather do something like this:

#ifdef HAVE_BROKEN_MBSTOWCS
size_t  __non_broken_mbstowcs(wchar_t* pwcs, const char* s, size_t n)
{
    if (pwcs == NULL)
        return strlen(s);
    else
        return mbstowcs(pwcs, s, n);
}
#define mbstowcs    __non_broken_mbstowcs
#endif

It would fix the problem everywhere, and people won't have to worry
about putting #ifdef everywhere in the future.

I attached a test program, run it on cygwin to make sure this approach
works on your side.


Another small remark; #ifdef is better then #ifndef when doing
#ifdef ...
...
#else
...
#endif

Simply because it easier to get "Be positive" than "Don't be negative".

The negative form is generally harder to get whether your are
programming, writing or talking. Use the positive form and you will have
more impact and will make things clearer.

Added file: http://bugs.python.org/file11279/test.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Thu Aug 28 04:36:31 2008
From: report at bugs.python.org (Henry Precheur)
Date: Thu, 28 Aug 2008 02:36:31 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219890991.27.0.00774086124157.issue3696@psf.upfronthosting.co.za>


Changes by Henry Precheur <henry at precheur.org>:


Removed file: http://bugs.python.org/file11266/fix_mbstowcs_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Thu Aug 28 05:41:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 28 Aug 2008 03:41:02 +0000
Subject: [issue3706] Fix error message for wrong exec() argument type
In-Reply-To: <1219876507.34.0.480466354345.issue3706@psf.upfronthosting.co.za>
Message-ID: <1219894862.15.0.477952796043.issue3706@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Looks okay, although my taste would be to let the calls to
source_as_string() be slightly more verbose and include the "string,
bytes" part. While that has a little more redundancy, it is easier to
read, and possibly easier to grep for.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3706>
_______________________________________

From report at bugs.python.org  Thu Aug 28 06:08:30 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 04:08:30 +0000
Subject: [issue3678] Ignored LDFLAGS during linking libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1219896510.42.0.511249314044.issue3678@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3678>
_______________________________________

From report at bugs.python.org  Thu Aug 28 06:26:18 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 28 Aug 2008 04:26:18 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1219897578.07.0.426743037722.issue3602@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I stumbled across this when mimetools import of test failed due to
finding a local test package, not the python test package, so I too will
be happy to see this fixed.

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3602>
_______________________________________

From report at bugs.python.org  Thu Aug 28 06:36:07 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 04:36:07 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219898167.72.0.308985161005.issue3710@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Thu Aug 28 06:37:36 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 04:37:36 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1219898256.75.0.815020933209.issue1868@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Thu Aug 28 06:39:35 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 04:39:35 +0000
Subject: [issue3678] Ignored LDFLAGS during linking libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1219898375.42.0.456419669653.issue3678@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I think this ldflags-ldlast patch (added) is whats really needed.

----------
keywords: +easy, needs review
Added file: http://bugs.python.org/file11280/ldflags-ldlast-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3678>
_______________________________________

From report at bugs.python.org  Thu Aug 28 06:44:10 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 04:44:10 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1219898650.55.0.643060382284.issue3710@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fyi - This bug and #1868 (http://bugs.python.org/issue1868) seem related.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Thu Aug 28 06:44:37 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 04:44:37 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1219898677.36.0.583441938817.issue1868@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

see also #3710

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Thu Aug 28 07:29:28 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 05:29:28 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1219901368.02.0.685046997613.issue1868@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I like Amaury's patch, it gets rid of what seems like an existing gross
hack of having localobject->dict exist at all.

I believe it may also fix #3710 by getting rid of the unnecessary
localobject->dict member.

Could someone else please review this?

threading_local.patch is available for review here:
http://codereview.appspot.com/3641

----------
keywords: +needs review
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Thu Aug 28 07:42:07 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 05:42:07 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219902127.86.0.784373285996.issue3708@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i'll fix this and add a unit test.

----------
assignee:  -> gregory.p.smith
keywords: +easy
nosy: +gregory.p.smith
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Thu Aug 28 08:00:36 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 06:00:36 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219903236.97.0.421883943408.issue3708@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

better patch with tests attached, no explicit int conversion is done.

i also wrapped the use of the fd returned by open with a try: finally:
to avoid any chance of a leak and renamed the bytes variable to bs to
match whats in py3k and avoid overriding the builtin type.

----------
keywords: +needs review
priority: low -> normal
Added file: http://bugs.python.org/file11281/urandom-float-and-close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Thu Aug 28 08:10:26 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 06:10:26 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1219903826.2.0.368018051779.issue3704@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file11282/cookielib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Thu Aug 28 08:19:51 2008
From: report at bugs.python.org (Laszlo (Laca) Peter)
Date: Thu, 28 Aug 2008 06:19:51 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1219904391.44.0.989386004175.issue3014@psf.upfronthosting.co.za>


Changes by Laszlo (Laca) Peter <laca at sun.com>:


----------
nosy: +laca

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3014>
_______________________________________

From report at bugs.python.org  Thu Aug 28 08:39:54 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 06:39:54 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1219905594.88.0.340589460762.issue3704@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

attached is a patch with the suggested fix along with a unit test.

----------
assignee:  -> gregory.p.smith
keywords: +needs review
nosy: +gregory.p.smith
priority:  -> normal
Added file: http://bugs.python.org/file11283/cookielib-querystring-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Thu Aug 28 08:47:01 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 06:47:01 +0000
Subject: [issue3647] urlparse - relative url parsing and joins to be RFC3986
	compliance
In-Reply-To: <1219409676.71.0.379802173537.issue3647@psf.upfronthosting.co.za>
Message-ID: <1219906021.04.0.153553848077.issue3647@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

given where we are in the release process at the moment I doubt this can
go into 2.6/3.0.  Bring it up on python-dev if you have compelling
reasons why it should.

Otherwise, looks good for trunk 2.7/3.1 immediately after the releases
are branched.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3647>
_______________________________________

From report at bugs.python.org  Thu Aug 28 08:48:38 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 06:48:38 +0000
Subject: [issue3703] open() on directory raises IOError with unhelpful message
In-Reply-To: <1219847162.49.0.00805052293115.issue3703@psf.upfronthosting.co.za>
Message-ID: <1219906118.42.0.336665333361.issue3703@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

looks good to me

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3703>
_______________________________________

From report at bugs.python.org  Thu Aug 28 09:58:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Aug 2008 07:58:10 +0000
Subject: [issue3706] Fix error message for wrong exec() argument type
In-Reply-To: <1219876507.34.0.480466354345.issue3706@psf.upfronthosting.co.za>
Message-ID: <1219910290.58.0.92151950065.issue3706@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I changed that and committed r66051.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3706>
_______________________________________

From report at bugs.python.org  Thu Aug 28 10:02:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 08:02:24 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219910544.2.0.744985895096.issue3696@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Another small remark; #ifdef is better then #ifndef 
> Simply because it easier to get "Be positive" than "Don't be negative".

Yes; but here, the symbol (HAVE_BROKEN_MBSTOWC) has a negative meaning.
I tried to put the optimistic (=not broken) case first.
However, if this makes the code more difficult to read, I'll change it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Thu Aug 28 11:31:57 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 28 Aug 2008 09:31:57 +0000
Subject: [issue3711] docs still say to use .dll for compiled extensions
In-Reply-To: <1219915917.83.0.610729726797.issue3711@psf.upfronthosting.co.za>
Message-ID: <1219915917.83.0.610729726797.issue3711@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

The "Extending and Embedding" document still says, in section "Building 
C and C++ Extensions on Windows":
http://docs.python.org/dev/extending/windows.html#a-cookbook-approach
that a C extension may be called spam.dll or spam_d.dll

Since version 2.5 the file must be called spam.pyd or spam_d.pyd - 
the .dll file extension isn't recognized anymore.

A proposed doc patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: windows.diff
keywords: patch
messages: 72071
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: docs still say to use .dll for compiled extensions
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11284/windows.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3711>
_______________________________________

From report at bugs.python.org  Thu Aug 28 11:34:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 09:34:07 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1219916047.62.0.822672431993.issue3014@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The title of your bug report might be misleading. Is the problem that
errno is misinterpreted in the error message, or that there is an error
message at all?

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3014>
_______________________________________

From report at bugs.python.org  Thu Aug 28 11:40:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Aug 2008 09:40:24 +0000
Subject: [issue3711] docs still say to use .dll for compiled extensions
In-Reply-To: <1219915917.83.0.610729726797.issue3711@psf.upfronthosting.co.za>
Message-ID: <1219916424.64.0.197865006975.issue3711@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66053.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3711>
_______________________________________

From report at bugs.python.org  Thu Aug 28 11:40:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 09:40:31 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219916431.95.0.489963747468.issue3708@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The explicit int() conversion looked saner to me, rather than passing a
float argument to read().
By the way, is there a reason this code still uses os.open rather than
the builtin io.open?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Thu Aug 28 11:55:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 09:55:33 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1219917333.09.0.50810202471.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- the "test_site leaked [88, 88]" is the same as problem as issue3667.

- test_unicodes leaks in PyUnicode_AsEncodedString (attached patch), and
also with:
  str(memoryview(b'character buffers are decoded to unicode'), 'utf-8')
I tried another patch, but I'm not sure: I get lost between all these
buffers... a Py_DECREF(self->view.obj) in memory_releasebuf() seems to work.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file11285/encode-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Thu Aug 28 12:14:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 10:14:32 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219917333.09.0.50810202471.issue3660@psf.upfronthosting.co.za>
Message-ID: <1219918481.48b67a91dd0af@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

>   str(memoryview(b'character buffers are decoded to unicode'), 'utf-8')
> I tried another patch, but I'm not sure: I get lost between all these
> buffers... a Py_DECREF(self->view.obj) in memory_releasebuf() seems to work.

Could you open a separate issue for the latter? Adding a DECREF in
memory_releasebuf() isn't the right thing to do, because PyBuffer_Release()
already does such a DECREF. I think the problem is rather in memory_getbuf(), it
tries to take some strange shortcuts.

Oh, and I realize that memoryobject doesn't have tp_traverse and tp_clear, which
looks quite wrong...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Thu Aug 28 12:21:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 10:21:13 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1219918873.82.0.1364940851.issue3696@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes; but here, the symbol (HAVE_BROKEN_MBSTOWC) has a negative meaning.
> I tried to put the optimistic (=not broken) case first.
> However, if this makes the code more difficult to read, I'll change it.

You could change HAVE_BROKEN_MBSTOWC for a positive flag, e.g.
HAVE_WORKING_MBSTOWC, and then the #ifdef would be the optimistic case.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3696>
_______________________________________

From report at bugs.python.org  Thu Aug 28 13:01:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 11:01:49 +0000
Subject: [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Two problems with memoryview:
- The buffer interface of memoryview leaks a reference:
    str(memoryview(b'text'), 'utf-8')

- memoryview does not implement tp_traverse and tp_clear, so reference
cycle cannot be collected, as with:

import gc
class MyBuf(bytes): pass

def f():
    buf = MyBuf(b'abc')
    m = memoryview(buf)
    buf.m = m
    gc.collect();gc.collect();gc.collect()

each call to f() leaks 6 references.

----------
messages: 72078
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: memoryview leaks references
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3712>
_______________________________________

From report at bugs.python.org  Thu Aug 28 13:04:09 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 11:04:09 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1219921449.52.0.814946264906.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue3712 tracks the memoryview issues.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Thu Aug 28 13:24:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 11:24:32 +0000
Subject: [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1219922672.61.0.822128971731.issue3712@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. I feel a bit unsafe with the intended semantics of
getting a buffer on a memoryview object, but it fixes the leak.

----------
components: +Interpreter Core
keywords: +needs review, patch
nosy: +pitrou, teoliphant
type:  -> resource usage
Added file: http://bugs.python.org/file11286/memleak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3712>
_______________________________________

From report at bugs.python.org  Thu Aug 28 13:26:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 11:26:41 +0000
Subject: [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1219922801.51.0.929392560163.issue3712@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I forgot to say, the patch is for the first problem only)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3712>
_______________________________________

From report at bugs.python.org  Thu Aug 28 13:32:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 11:32:41 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1219923161.45.0.447788497907.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

the leaks in test_pickle and test_pickletools are corrected by the
attached patch.

Added file: http://bugs.python.org/file11288/pickle-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Thu Aug 28 13:48:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Aug 2008 11:48:01 +0000
Subject: [issue3616] shutil.rmtree() fails on invalid filename
In-Reply-To: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za>
Message-ID: <1219924081.1.0.27725271232.issue3616@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 2.5 has the same problem (at least, on Linux). rmtree(<unicode 
directory name>) fails if the directory contains invalid unicode 
string. Backtrace:
---
File "shutil.py", line 163, in rmtree
   fullname = os.path.join(path, name)
File "posixpath.py", line 65, in join
   path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xac in position 
3: ordinal not in range(128)
---

The filename:
   $ ls /tmp/run-3/exitcode1/run-4/run-1/session-2/
   ?I?#??????????|?*?  Pum

The instruction was 
rmtree(u"/tmp/run-3/exitcode1/run-4/run-1/session-2").

----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3616>
_______________________________________

From report at bugs.python.org  Thu Aug 28 14:05:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 12:05:31 +0000
Subject: [issue3667] Reloading an extension module always leaks
In-Reply-To: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>
Message-ID: <1219925131.75.0.219789096089.issue3667@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The fix is actually simple: _PyImport_FindExtension() used to return a
borrowed reference, the "strong" reference being stored in the
PyImport_GetModuleDict() dictionary. All paths should behave the same.

See attached patch.

(for unit tests, run for example
    regrtest.py -R:: test_site
)

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11289/import-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3667>
_______________________________________

From report at bugs.python.org  Thu Aug 28 14:38:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 12:38:17 +0000
Subject: [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1219927097.71.0.488478952057.issue3712@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an aggregate patch addressing both problems. Please review.

Added file: http://bugs.python.org/file11290/memleak2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3712>
_______________________________________

From report at bugs.python.org  Thu Aug 28 15:05:50 2008
From: report at bugs.python.org (Andy)
Date: Thu, 28 Aug 2008 13:05:50 +0000
Subject: [issue3713] Compile warning for Objects/stringlib
In-Reply-To: <1219928750.12.0.164403487904.issue3713@psf.upfronthosting.co.za>
Message-ID: <1219928750.12.0.164403487904.issue3713@psf.upfronthosting.co.za>


New submission from Andy <flossyfriend at hotmail.com>:

Checked out the PY3K branch and built. Received a warning 
about "characters after #ifdef ignored" from Objects/stringlib/find.h

the line in question is:

#ifdef STRINGLIB_WANT_CONTAINS_OBJ && !defined(FROM_BYTEARRAY)

Which is likely to mean that it will not do what is expected.

System is Ubuntu using GCC (otoh can't remember full compiler spec will 
post in later)

Patch to follow that modifies the above line to:

#if defined(STRINGLIB_WANT_CONTAINS_OBJ) && !defined(FROM_BYTEARRAY)

and will change the comment on the closing #endif too.

hope component choice is correct

----------
components: Library (Lib)
messages: 72087
nosy: kirkshorts
severity: normal
status: open
title: Compile warning for Objects/stringlib
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3713>
_______________________________________

From report at bugs.python.org  Thu Aug 28 15:55:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 13:55:17 +0000
Subject: [issue3616] shutil.rmtree() fails on invalid filename
In-Reply-To: <1219924081.1.0.27725271232.issue3616@psf.upfronthosting.co.za>
Message-ID: <1219931399.48b6ad079e876@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon STINNER Victor <report at bugs.python.org>:
>
> Python 2.5 has the same problem (at least, on Linux). rmtree(<unicode
> directory name>) fails if the directory contains invalid unicode
> string. Backtrace:

Well, I'm not sure we should call it the same problem, although the roots are
the same. The difference is that in 2.x, using bytes strings for file and
directory names is quite normal, especially under Linux where they are just
bytes at the OS level. In 3.0 though, those strings are supposed to be unicode
at the Python level, which makes the problem much more critical.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3616>
_______________________________________

From report at bugs.python.org  Thu Aug 28 16:00:27 2008
From: report at bugs.python.org (Andy)
Date: Thu, 28 Aug 2008 14:00:27 +0000
Subject: [issue3713] Compile warning for Objects/stringlib
In-Reply-To: <1219928750.12.0.164403487904.issue3713@psf.upfronthosting.co.za>
Message-ID: <1219932027.07.0.757027165114.issue3713@psf.upfronthosting.co.za>


Andy <flossyfriend at hotmail.com> added the comment:

patch for issue attached.

gcc -v => gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

tests:

./runtests.sh =>
   0 BAD
 297 GOOD
  27 SKIPPED
 324 total

----------
keywords: +patch
Added file: http://bugs.python.org/file11291/issue3713.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3713>
_______________________________________

From report at bugs.python.org  Thu Aug 28 16:10:21 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Thu, 28 Aug 2008 14:10:21 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>


New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:

The following commands fail badly:

>>> from nntplib import NNTP
>>> s = NNTP("free-text.usenetserver.com")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/py3k/Lib/nntplib.py", line 116, in __init__
    self.welcome = self.getresp()
  File "/py3k/Lib/nntplib.py", line 215, in getresp
    resp = self.getline()
  File "/py3k/Lib/nntplib.py", line 209, in getline
    elif line[-1:] in CRLF: line = line[:-1]
TypeError: 'in <string>' requires string as left operand, not bytes

Actually there are many places in nntplib module which need to be
converted to bytes, or socket input/output values need to be converted
from/to str. I think API need to be updated to pass user defined
encoding at some stages. I can make a patch later if needed.

----------
components: Library (Lib)
messages: 72090
nosy: hdima
severity: normal
status: open
title: nntplib module broken by str to unicode conversion
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Thu Aug 28 16:21:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 14:21:55 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1219933315.12.0.9185257411.issue3714@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, the module is unusable in the current state.

----------
nosy: +amaury.forgeotdarc
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Thu Aug 28 16:41:09 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Thu, 28 Aug 2008 14:41:09 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1219934469.45.0.0810562153441.issue3714@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> 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 <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Thu Aug 28 16:56:05 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Aug 2008 14:56:05 +0000
Subject: [issue3713] Compile warning for Objects/stringlib
In-Reply-To: <1219928750.12.0.164403487904.issue3713@psf.upfronthosting.co.za>
Message-ID: <1219935365.12.0.629438806396.issue3713@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks! It was a merge glitch. Fixed in r66055

----------
nosy: +christian.heimes
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3713>
_______________________________________

From report at bugs.python.org  Thu Aug 28 18:25:32 2008
From: report at bugs.python.org (johansen)
Date: Thu, 28 Aug 2008 16:25:32 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1219940732.56.0.569136172918.issue3014@psf.upfronthosting.co.za>


johansen <johansen at sun.com> added the comment:

The problem is present in Python 2.4.4, the version that we're using
here.  I'm not familiar with the versions keyword that's used here, but
that's the version for which I'm reporting this bug.

To be clear, the problem is that when file_dealloc() sees an EOF, it
assumes that an error has occurred.  It then checks errno.  However,
it's possible for file_dealloc() to get an EOF under conditions where
errno hasn't been set.  In that case, it reports an error with a stale
value of errno.  This is explained in detail in the initial report.  I
don't think the title is misleading; it's incorrect for file_dealloc()
to assume that errno is set every time it gets an EOF.

----------
versions: +Python 2.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3014>
_______________________________________

From report at bugs.python.org  Thu Aug 28 18:39:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 16:39:03 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1219940732.56.0.569136172918.issue3014@psf.upfronthosting.co.za>
Message-ID: <1219941196.48b6d34c9c71f@imp.free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Selon johansen <report at bugs.python.org>:
>
> The problem is present in Python 2.4.4, the version that we're using
> here.  I'm not familiar with the versions keyword that's used here, but
> that's the version for which I'm reporting this bug.

The only changes that may be brought now to the 2.4 branch are security fixes
and nothing else. Bug fixes with a slight risk of changing legitimate behaviour
like the present one, on the other hand, will happen either on the 2.6 branch or
on the 2.7 one.

> To be clear, the problem is that when file_dealloc() sees an EOF, it
> assumes that an error has occurred.  It then checks errno.  However,
> it's possible for file_dealloc() to get an EOF under conditions where
> errno hasn't been set.  In that case, it reports an error with a stale
> value of errno.  This is explained in detail in the initial report.

You still haven't explained what the correct behaviour would be, though.
Must it report an error or not? If it must, then how should this specific error
be detected and how should the error message be phrased?

Thanks in advance.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3014>
_______________________________________

From report at bugs.python.org  Thu Aug 28 18:42:00 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 28 Aug 2008 16:42:00 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1219941720.54.0.256951482322.issue3675@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Hagen,
does this simple patch (against 2.6) solve it for you?

Index: Lib/pickle.py
===================================================================
--- Lib/pickle.py       (revision 66050)
+++ Lib/pickle.py       (working copy)
@@ -1121,6 +1121,8 @@

     def find_class(self, module, name):
         # Subclasses may override this
+        if module == "builtins":
+            module = "__builtin__"
         __import__(module)
         mod = sys.modules[module]
         klass = getattr(mod, name)

I think a dict mapping the moved modules would work better, perhaps
having it in PyPI would be enough?

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Thu Aug 28 18:53:26 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 28 Aug 2008 16:53:26 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1219942406.31.0.704414722039.issue3675@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Well, Python <= 2.5 still wouldn't be able to unpickle those built in
objects.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Thu Aug 28 19:05:50 2008
From: report at bugs.python.org (johansen)
Date: Thu, 28 Aug 2008 17:05:50 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1219943150.49.0.641767477373.issue3014@psf.upfronthosting.co.za>


johansen <johansen at sun.com> added the comment:

As I said before:

  check_and_flush calls ferror(3C) and then fflush(3C) on the FILE
  stream associated with the file object.  There's just one problem
  here.  If it finds an error that was previously encountered on the
  file stream, there's no guarantee that errno will be valid.
  Should an error be encountered in fflush(3C), errno will get set;
  however, the contents of errno are undefined should fflush()
  return successfully.

The problem is this:

The caller of check_and_flush() will check errno if check_and_flush
returns an error.  However, check_and_flush() checks two different error
sources.  If ferror() returns an error, you can't check errno, because
that routine doesn't set errno.  However, if fflush() returns an error,
it will set errno.

In its current form, no caller of check_and_flush() should check errno
if the check_and_flush doesn't return successfully, since there's no way
of knowing whether errno will be set or not.

That doesn't make a lot of sense to me, so I would probably re-write
this code.  However, since I'm not an expert in the inner workings of
the Python interpreter, it's hard for me to suggest just how to do this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3014>
_______________________________________

From report at bugs.python.org  Thu Aug 28 19:44:19 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 28 Aug 2008 17:44:19 +0000
Subject: [issue3715] hashlib's docstring throws exception in pydoc
In-Reply-To: <1219945459.86.0.239279043076.issue3715@psf.upfronthosting.co.za>
Message-ID: <1219945459.86.0.239279043076.issue3715@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

Hello,

I noticed that doing "pydoc3.0 hashlib" was throwing this exception:

Traceback (most recent call last):
  File "/opt/local/bin/pydoc3.0", line 5, in <module>
    pydoc.cli()
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 2237, in cli
    help.help(arg)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1714, in help
    elif request: doc(request, 'Help on %s:')
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1504, in doc
    pager(render_doc(thing, title, forceload))
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1319, in pager
    pager(text)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1339, in <lambda>
    return lambda text: pipepager(text, 'less')
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pydoc.py", line 1360, in pipepager
    pipe.write(text)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/io.py", line 1486, in write
    b = encoder.encode(s)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/encodings/mac_roman.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]


This problem is coming from this block of text:

    >>> import hashlib
    >>> m = hashlib.md5()
    >>> m.update(b"Nobody inspects")
    >>> m.update(b" the spammish repetition")
    >>> m.digest()
    b'\xbbd\x9c\x83\xdd\x1e\xa5\xc9\xd9\xde\xc9\xa1\x8d\xf0\xff\xe9'

Specifically, the last line. It seems that pydoc is interpreting the 
last line as a unicode string, and then when it tries to print it out on 
my mac it errors out.

----------
components: Library (Lib)
messages: 72099
nosy: erickt
severity: normal
status: open
title: hashlib's docstring throws exception in pydoc
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3715>
_______________________________________

From report at bugs.python.org  Thu Aug 28 19:53:00 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 28 Aug 2008 17:53:00 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1219945980.32.4.53591498273e-05.issue3675@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

FWIW, there's a mapping of 2.6:3.0 modules in lib2to3:

from lib2to3.fixes.fix_imports import MAPPING

The attached patch uses that for a quick and dirty way of loading 3.0
pickles in 2.6.

----------
keywords: +patch
Added file: http://bugs.python.org/file11293/pickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Thu Aug 28 20:11:07 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 28 Aug 2008 18:11:07 +0000
Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1219947067.12.0.99129471292.issue2501@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

ISTM that this release blocker can be solved by changing
xml.sax.xmlreader.py line 122 from:
        while buffer != "":
to
        while buffer != b"":

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2501>
_______________________________________

From report at bugs.python.org  Thu Aug 28 20:25:45 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 28 Aug 2008 18:25:45 +0000
Subject: [issue3680] Cycles with some iterator are leaking.
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <1219947945.81.0.242984996647.issue3680@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________

From report at bugs.python.org  Thu Aug 28 20:34:43 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Aug 2008 18:34:43 +0000
Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1219948483.59.0.00111686047688.issue2501@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I've a better idea:


    while buffer: 

It's faster and works for both empty bytes and str.

The patch fixes the issue and re-enables three unit tests.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11295/xmlreader_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2501>
_______________________________________

From report at bugs.python.org  Thu Aug 28 20:39:18 2008
From: report at bugs.python.org (Simon Cross)
Date: Thu, 28 Aug 2008 18:39:18 +0000
Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape
In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za>
Message-ID: <1219948758.55.0.993584179215.issue1923@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

I've just checked that the patch still applies cleanly to 2.6 and it
does and the tests still passes. It looks like the patch has already
been applied to 3.0 but without the test. The test part of the part
applies cleanly to 3.0 too.

----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1923>
_______________________________________

From report at bugs.python.org  Thu Aug 28 21:21:29 2008
From: report at bugs.python.org (Alex7564)
Date: Thu, 28 Aug 2008 19:21:29 +0000
Subject: [issue3716] mistake in 3.4.2 Customizing attribute access
In-Reply-To: <1219951289.51.0.953784677576.issue3716@psf.upfronthosting.co.za>
Message-ID: <1219951289.51.0.953784677576.issue3716@psf.upfronthosting.co.za>


New submission from Alex7564 <noname9968 at gmail.com>:

"Note that if the attribute is found through the normal mechanism,
__getattr__() is not called."
"...because otherwise __setattr__() would have no way to access other
attributes of the instance."

I think it should be __getattr__() instead of __setattr__()

----------
assignee: georg.brandl
components: Documentation
messages: 72105
nosy: Alex7564, georg.brandl
severity: normal
status: open
title: mistake in 3.4.2 Customizing attribute access
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3716>
_______________________________________

From report at bugs.python.org  Thu Aug 28 21:24:14 2008
From: report at bugs.python.org (Alex7564)
Date: Thu, 28 Aug 2008 19:24:14 +0000
Subject: [issue3716] mistake in 3.4.2 Customizing attribute access
In-Reply-To: <1219951289.51.0.953784677576.issue3716@psf.upfronthosting.co.za>
Message-ID: <1219951454.57.0.30185880264.issue3716@psf.upfronthosting.co.za>


Alex7564 <noname9968 at gmail.com> added the comment:

"Note that if the attribute is found through the normal mechanism,
__getattr__() is not called."
"because otherwise __setattr__() would have no way to access other
attributes of the instance."

I think it's __getattr__() instead of __setattr__()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3716>
_______________________________________

From report at bugs.python.org  Thu Aug 28 21:30:30 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 28 Aug 2008 19:30:30 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219951830.54.0.599883125975.issue3708@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

if i did 

 n = int(n)

that would change the API to allow bytes/unicode to be passed in which
is not something i want.  i don't even like that it allows floats.

by not doing the int conversion at all, a DeprecationWarning is raised
by the read() about the argument being a float which I figure it not a
bad thing given that the API really should only accept ints...

fwiw, daniel's patch would still cause this deprecation warning from
read so I guess using while len(bs) < int(n): isn't that bad either. 
but it would allow a string such as '0' to be passed in as an argument
without an exception...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Thu Aug 28 21:30:50 2008
From: report at bugs.python.org (Alex7564)
Date: Thu, 28 Aug 2008 19:30:50 +0000
Subject: [issue3716] mistake in 3.4.2 Customizing attribute access
In-Reply-To: <1219951289.51.0.953784677576.issue3716@psf.upfronthosting.co.za>
Message-ID: <1219951850.3.0.713819099494.issue3716@psf.upfronthosting.co.za>


Alex7564 <noname9968 at gmail.com> added the comment:

I was talking about Python Reference Manual
(http://docs.python.org/ref/attribute-access.html)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3716>
_______________________________________

From report at bugs.python.org  Thu Aug 28 21:50:55 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 28 Aug 2008 19:50:55 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219953055.78.0.141040707387.issue3708@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Gregory,
IMHO your patch is better in all aspects.

Regarding my patch, the API wouldn't change at all, as the source reads:
        while len(bytes) < int(n):
            bytes += read(_urandomfd, n - len(bytes))

So "n - len(bytes)" restricts the API to what it was before. But it
would call int() for each loop iteration :/

@Pitrou: My patch still passed the float to read (to keep the current
behavior, warning included), but if doing that can be considered a bug,
let's get rid of the DeprecationWarning by passing an int.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Thu Aug 28 22:24:50 2008
From: report at bugs.python.org (Ben Cottrell)
Date: Thu, 28 Aug 2008 20:24:50 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1219955090.73.0.662828832618.issue1868@psf.upfronthosting.co.za>


Ben Cottrell <tamino at wolfhut.org> added the comment:

I like this patch, too! I think it's a much cleaner way of implementing
the thread._local type. However, when I test it, I have problems with
subclasses of thread._local; using the class itself seems to work.

I've attached a test program that shows the issue.

----------
nosy: +tamino
Added file: http://bugs.python.org/file11296/test1868.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Thu Aug 28 22:48:51 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 28 Aug 2008 20:48:51 +0000
Subject: [issue3717] Py_InitModule* is still referenced in docs
In-Reply-To: <1219956531.21.0.0850096773002.issue3717@psf.upfronthosting.co.za>
Message-ID: <1219956531.21.0.0850096773002.issue3717@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

The docs still reference Py_InitModule*, which was removed in r64107. 
Also,  Demo/embed/demo.c still use Py_InitModule, and thus doesn't 
compile.

----------
assignee: georg.brandl
components: Documentation
messages: 72111
nosy: erickt, georg.brandl
severity: normal
status: open
title: Py_InitModule* is still referenced in docs
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3717>
_______________________________________

From report at bugs.python.org  Thu Aug 28 23:09:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Aug 2008 21:09:20 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1219957760.57.0.341752378597.issue1868@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Good catch, Ben!

The generic setattr/getattr functions don't work as expected when the
base class doesn't provide a __dict__. They are setting the attributes
in the subclass' __dict__ instead of the thread local dict.

My patch fixes the behavior. However it might be a better idea to make
the threadlocal class non subclass-able.

Added file: http://bugs.python.org/file11297/threading_local2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Thu Aug 28 23:27:25 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Thu, 28 Aug 2008 21:27:25 +0000
Subject: [issue3717] Py_InitModule* is still referenced in docs
In-Reply-To: <1219956531.21.0.0850096773002.issue3717@psf.upfronthosting.co.za>
Message-ID: <1ef034530808281427t5e979bf8p29d9b35ee936a49a@mail.gmail.com>


Erick Tryzelaar <idadesub at users.sourceforge.net> added the comment:

On Thu, Aug 28, 2008 at 1:48 PM, Erick Tryzelaar <report at bugs.python.org> wrote:
>
> New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:
>
> The docs still reference Py_InitModule*, which was removed in r64107.
> Also,  Demo/embed/demo.c still use Py_InitModule, and thus doesn't
> compile.

Here's a patch to get demo.c working, though it's acting a little
strange. Printing out sys.argv results in japanese characters for some
reason.

Index: Demo/embed/demo.c
===================================================================
--- Demo/embed/demo.c	(revision 66055)
+++ Demo/embed/demo.c	(working copy)
@@ -2,9 +2,9 @@

 #include "Python.h"

-void initxyzzy(void); /* Forward */
+PyObject* PyInit_xyzzy(void); /* Forward */

-main(int argc, char **argv)
+main(int argc, wchar_t **argv)
 {
 	/* Pass argv[0] to the Python interpreter */
 	Py_SetProgramName(argv[0]);
@@ -13,7 +13,7 @@
 	Py_Initialize();

 	/* Add a static module */
-	initxyzzy();
+	PyInit_xyzzy();

 	/* Define sys.argv.  It is up to the application if you
 	   want this; you can also let it undefined (since the Python
@@ -26,10 +26,10 @@

 	/* Execute some Python statements (in module __main__) */
 	PyRun_SimpleString("import sys\n");
-	PyRun_SimpleString("print sys.builtin_module_names\n");
-	PyRun_SimpleString("print sys.modules.keys()\n");
-	PyRun_SimpleString("print sys.executable\n");
-	PyRun_SimpleString("print sys.argv\n");
+	PyRun_SimpleString("print(sys.builtin_module_names)\n");
+	PyRun_SimpleString("print(sys.modules.keys())\n");
+	PyRun_SimpleString("print(sys.executable)\n");
+	PyRun_SimpleString("print(sys.argv)\n");

 	/* Note that you can call any public function of the Python
 	   interpreter here, e.g. call_object(). */
@@ -57,9 +57,22 @@
 	{NULL,		NULL}		/* sentinel */
 };

-void
-initxyzzy(void)
+static struct PyModuleDef xyzzymodule = {
+	{}, /* m_base */
+	"xyzzy",  /* m_name */
+	0,  /* m_doc */
+	0,  /* m_size */
+	xyzzy_methods,  /* m_methods */
+	0,  /* m_reload */
+	0,  /* m_traverse */
+	0,  /* m_clear */
+	0,  /* m_free */
+};
+
+PyObject*
+PyInit_xyzzy(void)
 {
-	PyImport_AddModule("xyzzy");
-	Py_InitModule("xyzzy", xyzzy_methods);
+	PyObject* res = PyModule_Create(&xyzzymodule);
+	if (!res) return NULL;
+	return res;
 }

With loop.c, there are issues with char*/wchar_t* and I'm not sure
what the right approach is. Finally, importexc.c is segfaulting with:

#0  0x0005b2f3 in PyDict_SetItem (op=0x0, key=0x44bed0,
value=0x17d460) at Objects/dictobject.c:712
#1  0x0005ee02 in PyDict_SetItemString (v=0x0, key=0x16e860
"last_type", item=0x17d460) at Objects/dictobject.c:2090
#2  0x0012c23a in PySys_SetObject (name=0x16e860 "last_type",
v=0x17d460) at Python/sysmodule.c:67
#3  0x00122c99 in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1254
#4  0x001228bc in PyErr_Print () at Python/pythonrun.c:1150
#5  0x001223a1 in PyRun_SimpleStringFlags (command=0x157b80 "import
sys", flags=0x0) at Python/pythonrun.c:1075
#6  0x0000243b in main () at importexc.c:13

----------
nosy: +idadesub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3717>
_______________________________________

From report at bugs.python.org  Thu Aug 28 23:48:39 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Aug 2008 21:48:39 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1219960119.06.0.38379418318.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reopening - still need to fix the Python level docs for hash() and
__hash__().

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Fri Aug 29 00:11:34 2008
From: report at bugs.python.org (Ben Cottrell)
Date: Thu, 28 Aug 2008 22:11:34 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1219961494.62.0.824530311822.issue1868@psf.upfronthosting.co.za>


Ben Cottrell <tamino at wolfhut.org> added the comment:

Christian,

Your patch works for me -- thanks!!

I made a slight modification to your patch to allow "del" to work,
and have attached my modified version.

I agree that allowing subclassing makes thread._local harder to get
right than it would otherwise be. There is code out there that uses
that feature, though -- I'm running into it in the context of django,
which (when using the sqlite database back end) keeps its sqlite
connections in a subclass of thread._local.

Added file: http://bugs.python.org/file11298/threading_local3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Fri Aug 29 00:18:52 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 28 Aug 2008 22:18:52 +0000
Subject: [issue3718] environment variable MACHDEP and python build system
In-Reply-To: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za>
Message-ID: <1219961932.19.0.767904041106.issue3718@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

A) The reason to propose this patch following paragraph
from README:
--------------------
        2) To set sys.platform to something sensible, pass the
           following environment variable to the configure script:

             MACHDEP=unicosmk
--------------------
The sentence above is not true in all cases. It don't state how to pass
as example
1) MACHDEP=abcd
   export MACHDEP
   ./configure ....
2) MACHDEP=abcd ./configure ....
3) ./configure MACHDEP=abcd ....

The Makefile.pre.in contain dependency rule "Run the configure script": 
that create config.status if file "configure" is changed as run the script.
>From above three samples for environment varaible passing only 3) will
save MACHDEP
into variable CONFIG_ARGS from generated Makefile.
The case 2) alwais lost it if config.status is created from makefile rule.
The case 1) will work only if developer don't remeber to set it every day.


B) The test case (note that MACHDEP isn't valid name!):
$ MACHDEP=linuxTEST ./configure --disable-ipv6
checking MACHDEP... linuxTEST
....
checking for build directories... done
configure: creating ./config.status
....
creating Makefile

Now lets see if "configure" script is changed:
$ touch configure; make
/bin/sh ./configure '--disable-ipv6'
checking MACHDEP... linux2                 <-- MACHDEP is lost
....
checking for build directories... done
configure: creating ./config.status
config.status: creating Makefile.pre
config.status: creating Modules/Setup.config
config.status: creating pyconfig.h
config.status: pyconfig.h is unchanged
creating Modules/Setup
creating Modules/Setup.local
creating Makefile
CONFIG_FILES=Makefile.pre CONFIG_HEADERS= /bin/sh config.status
config.status: creating Makefile.pre
make -f Makefile.pre Makefile
make[1]: Entering directory `..../python-release25-maint'
make[1]: `Makefile' is up to date.         <--- extra
make[1]: Leaving directory `..../python-release25-maint'
/bin/sh ./Modules/makesetup -c ./Modules/config.c.in \
....
The Makefile was updated, you may need to re-run make.
gcc -pthread -c ....
....

Note an extra attempt to create Makefile.


C) Next lets see after patch:
(the python configuration is the same as above):
$ touch configure; make
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure  --disable-ipv6
MACHDEP=linuxTEST  --no-create --no-recursion
checking MACHDEP... linuxTEST              <-- MACHDEP is same as at
configure time
....
checking for build directories... done
configure: creating ./config.status
creating Modules/Setup
creating Modules/Setup.local
creating Makefile
/bin/sh ./config.status Makefile.pre
config.status: creating Makefile.pre
/bin/sh ./Modules/makesetup -c ./Modules/config.c.in \
				-s Modules \
				Modules/Setup.config \
				Modules/Setup.local \
				Modules/Setup
The Makefile was updated, you may need to re-run make.
gcc -pthread -c - ....
(ignore failure here since MACHDEP=linuxTEST is used only to show problem)


D) Rerefence (from autoconf textinfo sections):
4.8.5 Automatic Remaking
7.2 Setting Output Variables (see macro AC_ARG_VAR)
16 config.status Invocation

----------
components: Build
files: python-release25-MACHDEP.patch
keywords: patch
messages: 72116
nosy: rpetrov
severity: normal
status: open
title: environment variable MACHDEP and python build system
versions: Python 2.5
Added file: http://bugs.python.org/file11299/python-release25-MACHDEP.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3718>
_______________________________________

From report at bugs.python.org  Fri Aug 29 00:27:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Aug 2008 22:27:45 +0000
Subject: [issue3014] file_dealloc() assumes errno is set when EOF is returned
In-Reply-To: <1212184451.2.0.27521352304.issue3014@psf.upfronthosting.co.za>
Message-ID: <1219962465.22.0.95600208154.issue3014@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3014>
_______________________________________

From report at bugs.python.org  Fri Aug 29 02:25:54 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 00:25:54 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219951830.54.0.599883125975.issue3708@psf.upfronthosting.co.za>
Message-ID: <1219969550.5675.6.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 28 ao?t 2008 ? 19:30 +0000, Gregory P. Smith a ?crit :
> if i did 
> 
>  n = int(n)
> 
> that would change the API to allow bytes/unicode to be passed in which
> is not something i want.

Ok, I hadn't thought about that. You convinced me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Fri Aug 29 02:40:13 2008
From: report at bugs.python.org (jfdp)
Date: Fri, 29 Aug 2008 00:40:13 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>


New submission from jfdp <joe.dipol at sun.com>:

If you install python in a location which has a space
or shell character in the path then platform.platform()
will generate an error and/or fail to get all platform
information.

For example

$ pwd
/disk0/tmp/foobar(2)/python2.4/bin
$ ./python
Python 2.4.4 (#8, Apr 11 2008, 11:42:39) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> print platform.platform()
sh: syntax error at line 1: `(' unexpected
SunOS-5.10-sun4u-sparc-32bit

Note the error from 'sh' was well as the fact that "ELF"
is missing from the platform string. If you are in a path
with a space then it silently fails to identify "ELF".

The problem is in platform.py: _syscmd_file(target,default='')
in particular this line:

f = os.popen('file %s 2> /dev/null' % target)

This should be:

f = os.popen('file "%s" 2> /dev/null' % target)

Note the double quotes to protect the path from the shell.

I've examined the 2.5, 2.6 and 3.0 source and they all
have this same problem.

----------
components: Library (Lib)
messages: 72118
nosy: jfdp
severity: normal
status: open
title: platform.py: _syscmd_file() can't handle target path with space or special shell character
type: behavior
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3719>
_______________________________________

From report at bugs.python.org  Fri Aug 29 06:19:32 2008
From: report at bugs.python.org (Gideon Smeding)
Date: Fri, 29 Aug 2008 04:19:32 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>


New submission from Gideon Smeding <gideon.smeding at gmail.com>:

The attached example crashes python. The crash is caused by an evil 
iterator that removes its own next function.

----------
files: baditerator.py
messages: 72119
nosy: gideon
severity: normal
status: open
title: segfault in for loop with evil iterator
type: crash
versions: Python 2.5, Python 3.0
Added file: http://bugs.python.org/file11300/baditerator.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 09:14:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 07:14:25 +0000
Subject: [issue3611] invalid exception context
In-Reply-To: <1219199600.1.0.689468244189.issue3611@psf.upfronthosting.co.za>
Message-ID: <1219994065.81.0.148854919585.issue3611@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed as r66056.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3611>
_______________________________________

From report at bugs.python.org  Fri Aug 29 09:35:26 2008
From: report at bugs.python.org (ivo)
Date: Fri, 29 Aug 2008 07:35:26 +0000
Subject: [issue3721] invalid literal for int() with base 16: ''
In-Reply-To: <1219995326.44.0.411202937388.issue3721@psf.upfronthosting.co.za>
Message-ID: <1219995326.44.0.411202937388.issue3721@psf.upfronthosting.co.za>


New submission from ivo <xhomol11 at stud.fit.vutbr.cz>:

I tested metode urllib2.read() on 2000 web_pages and there was a
exception ValueError in only one case, here is short code:

import urllib2
req = urllib2.urlopen('http://www.peachbit.org/')
req.read()


Traceback (most recent call last):
  File "httplib_bug.py", line 6, in <module>
    req.read()
  File "/usr/lib/python2.5/socket.py", line 291, in read
    data = self._sock.recv(recv_size)
  File "/usr/lib/python2.5/httplib.py", line 509, in read
    return self._read_chunked(amt)
  File "/usr/lib/python2.5/httplib.py", line 548, in _read_chunked
    chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: ''

----------
components: Installation
messages: 72121
nosy: xhomol11
severity: normal
status: open
title: invalid literal for int() with base 16: ''
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3721>
_______________________________________

From report at bugs.python.org  Fri Aug 29 11:12:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 09:12:20 +0000
Subject: [issue3721] invalid literal for int() with base 16: ''
In-Reply-To: <1219995326.44.0.411202937388.issue3721@psf.upfronthosting.co.za>
Message-ID: <1220001140.03.0.795272776825.issue3721@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is already fixed in trunk. (see issue900744)
Can you try with a 2.6 version?

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3721>
_______________________________________

From report at bugs.python.org  Fri Aug 29 12:00:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 10:00:06 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1220004006.81.0.860180140663.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury, are these patches ok to check in?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Fri Aug 29 12:54:13 2008
From: report at bugs.python.org (Chris Withers)
Date: Fri, 29 Aug 2008 10:54:13 +0000
Subject: [issue3722] print followed by exception eats print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

Here's an example from a python interpreter session:

Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> def test():
... print "hello"
... raise Exception()
...
 >>> test()
hello
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 3, in test
Exception

Now, turning this into a doctests gives:

"""
>>> def test():
...   print "hello"
...   raise Exception()
...
>>> test()
hello
Traceback (most recent call last):
...
Exception
"""

Which when run gives:

**********************************************************************
File "C:\Projects\doctestbug.py", line 6, in __main__
Failed example:
    test()
Exception raised:
    Traceback (most recent call last):
      File "C:\Python25\lib\doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest __main__[1]>", line 1, in <module>
        test()
      File "<doctest __main__[0]>", line 3, in test
        raise Exception()
    Exception
**********************************************************************
1 items had failures:
   1 of   2 in __main__
***Test Failed*** 1 failures.

The problem is that the function prints output before raising the
exception. If I take the printed output away, the doctest passes fine.
However, especially with dummy fixtures common in doctests, that printed
output needs to be seen to test that things are happening as they should
prior to the exception being raised.

----------
components: Library (Lib)
messages: 72124
nosy: cjw296
severity: normal
status: open
title: print followed by exception eats print with doctest
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3722>
_______________________________________

From report at bugs.python.org  Fri Aug 29 12:55:06 2008
From: report at bugs.python.org (Chris Withers)
Date: Fri, 29 Aug 2008 10:55:06 +0000
Subject: [issue3722] print followed by exception eats print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1220007306.9.0.215337189927.issue3722@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Here's the full test file.

Added file: http://bugs.python.org/file11301/doctestbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3722>
_______________________________________

From report at bugs.python.org  Fri Aug 29 13:50:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 11:50:52 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1220010652.87.0.256189162301.issue3668@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, let them go in!

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Fri Aug 29 14:11:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 12:11:10 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

The example Demo/embed/importexc.c crashes, because Py_NewInterpreter
cannot reimport builtins and sys modules. This problem seems important
for embedding applications like mod_python, for example.

(the "import exceptions" statement does not work with python 3.0, but
replacing with e.g. "import types" does not change anything: the
interpreter is not correctly renewed)

I tried to put "-1" in the m_size structure of these modules, and they
seem to import correctly. However, "builtins" comes with its original
dictionary - without the standard exceptions.

I think that these modules should be made re-importable, with specific
functions.

Maybe two related problems:
- once you've done
    del sys.modules['sys']
it's not possible to get it back, "import sys" raises an error...

- the usual trick to call sys.setdefaultencoding will not work, since it
needs to "imp.reload(sys)"

----------
components: Extension Modules
messages: 72127
nosy: amaury.forgeotdarc, loewis
priority: release blocker
severity: normal
status: open
title: Py_NewInterpreter does not work
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Fri Aug 29 14:11:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 12:11:46 +0000
Subject: [issue3717] Py_InitModule* is still referenced in docs
In-Reply-To: <1219956531.21.0.0850096773002.issue3717@psf.upfronthosting.co.za>
Message-ID: <1220011906.78.0.178972837055.issue3717@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In your patch, it is not correct to declare main as
    main(int argc, wchar_t **argv)
It is simply not the correct signature: the OS only supports "char** argv".

You have to perform the conversion yourself. Look for example at
Modules/python.c.

The problem with importexc.c is more serious; I've filled issue3723 for
this.

----------
nosy: +amaury.forgeotdarc
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3717>
_______________________________________

From report at bugs.python.org  Fri Aug 29 14:32:20 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 29 Aug 2008 12:32:20 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

I have found out that the result of math.log(x, 10) is slightly more
inaccurate than the one of math.log10(x). Probably the best example is
math.log(1000, 10) and math.log10(1000). I have attached a patch that
forces math.log to internally use log10 when it gets the base 10. Patch
is against revision 66056. Also adds 3 tests to test_math.py to test new
behaviour implemented.

----------
files: log.patch
keywords: patch
messages: 72129
nosy: segfaulthunter
severity: normal
status: open
title: math.log(x, 10) gives different result than math.log10(x)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11302/log.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3724>
_______________________________________

From report at bugs.python.org  Fri Aug 29 14:34:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 12:34:31 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220013271.65.0.33921679021.issue3720@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Good catch! Here is a patch for 3.0.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
priority:  -> release blocker
Added file: http://bugs.python.org/file11303/baditer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 14:43:46 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 12:43:46 +0000
Subject: [issue3725] telnetlib module broken by str to unicode conversion
In-Reply-To: <1220013826.6.0.647840298479.issue3725@psf.upfronthosting.co.za>
Message-ID: <1220013826.6.0.647840298479.issue3725@psf.upfronthosting.co.za>


New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:

Simple example:

>>> from telnetlib import Telnet
>>> t = Telnet("google.com", 80)
>>> t.write("GET / HTTP/1.1\r\n")        
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/py3k/Lib/telnetlib.py", line 280, in write
    self.sock.sendall(buffer)
TypeError: sendall() argument 1 must be string or buffer, not str
>>> t.write(b"GET / HTTP/1.1\r\n")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/py3k/Lib/telnetlib.py", line 277, in write
    if IAC in buffer:
TypeError: Type str doesn't support the buffer API

----------
components: Library (Lib)
messages: 72131
nosy: hdima
severity: normal
status: open
title: telnetlib module broken by str to unicode conversion
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3725>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:01:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 13:01:15 +0000
Subject: [issue3725] telnetlib module broken by str to unicode conversion
In-Reply-To: <1220013826.6.0.647840298479.issue3725@psf.upfronthosting.co.za>
Message-ID: <1220014875.84.0.292688148604.issue3725@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3725>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:22:48 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 13:22:48 +0000
Subject: [issue3725] telnetlib module broken by str to unicode conversion
In-Reply-To: <1220013826.6.0.647840298479.issue3725@psf.upfronthosting.co.za>
Message-ID: <1220016168.77.0.402898730389.issue3725@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

I think only bytes need to be allowed for write() and read*() because of
low-level nature of Telnet. I can create a patch later.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3725>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:33:08 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 29 Aug 2008 13:33:08 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220016788.48.0.971496696416.issue3720@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Maybe do a s/"object is no more an iterator"/"is no longer an iterator"

----------
nosy: +cartman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:44:43 2008
From: report at bugs.python.org (Will Maier)
Date: Fri, 29 Aug 2008 13:44:43 +0000
Subject: [issue3726] Allow ',
	<whitespace>' delimiters in logging.config.fileConfig()
In-Reply-To: <1220017483.8.0.409780209991.issue3726@psf.upfronthosting.co.za>
Message-ID: <1220017483.8.0.409780209991.issue3726@psf.upfronthosting.co.za>


New submission from Will Maier <willmaier at ml1.net>:

Currently, logging.config.fileConfig() inconsistently handles lines like:

[handlers]
keys = spam, eggs

[formatters]
keys = foo, bar

It does, however, correctly handle the ', ' delimiter in the [loggers]
section. This is because the various _install_*() functions in
logging.config aren't consistent about whether (and when) or not they
strip whitespace when generating key names.

Though the stdlib documentation only includes examples in the [handlers]
and [formatters] section with ',' delimiters, it seems reasonable to
expect that logging.config.fileConfig() should handle ', '. The attached
test demonstrates the failure and suggests a solution.

Thanks!
whitespace

----------
components: Library (Lib)
files: logging.diff
keywords: patch
messages: 72134
nosy: wcmaier
severity: normal
status: open
title: Allow ',<whitespace>' delimiters in logging.config.fileConfig()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11304/logging.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3726>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:58:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 13:58:22 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220018302.86.0.32635827766.issue3720@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file11303/baditer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:58:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 13:58:39 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220018319.77.0.243057981945.issue3720@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Added file: http://bugs.python.org/file11305/baditer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:59:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 13:59:38 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220018378.78.0.535863377857.issue3720@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

New patches, with the suggested spelling.
For 3.0 and 2.6.

Added file: http://bugs.python.org/file11306/baditer-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 15:59:50 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 13:59:50 +0000
Subject: [issue3727] poplib module broken by str to unicode conversion
In-Reply-To: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>
Message-ID: <1220018390.31.0.482710376741.issue3727@psf.upfronthosting.co.za>


New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:

Example:

>>> from poplib import POP3
>>> p = POP3("localhost")
>>> p.user("user")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/py3k/Lib/poplib.py", line 179, in user
    return self._shortcmd('USER %s' % user)
  File "/py3k/Lib/poplib.py", line 151, in _shortcmd
    self._putcmd(line)
  File "/py3k/Lib/poplib.py", line 98, in _putcmd
    self._putline(line)
  File "/py3k/Lib/poplib.py", line 91, in _putline
    self.sock.sendall('%s%s' % (line, CRLF))
TypeError: sendall() argument 1 must be string or buffer, not str
>>> p.user(b"user")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/py3k/Lib/poplib.py", line 179, in user
    return self._shortcmd('USER %s' % user)
  File "/py3k/Lib/poplib.py", line 151, in _shortcmd
    self._putcmd(line)
  File "/py3k/Lib/poplib.py", line 98, in _putcmd
    self._putline(line)
  File "/py3k/Lib/poplib.py", line 91, in _putline
    self.sock.sendall('%s%s' % (line, CRLF))
TypeError: sendall() argument 1 must be string or buffer, not str

----------
components: Library (Lib)
messages: 72136
nosy: hdima
severity: normal
status: open
title: poplib module broken by str to unicode conversion
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3727>
_______________________________________

From report at bugs.python.org  Fri Aug 29 16:05:33 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 14:05:33 +0000
Subject: [issue3728] imaplib module broken by str to unicode conversion
In-Reply-To: <1220018733.89.0.00018896297534.issue3728@psf.upfronthosting.co.za>
Message-ID: <1220018733.89.0.00018896297534.issue3728@psf.upfronthosting.co.za>


New submission from Dmitry Vasiliev <dima at hlabs.spb.ru>:

Example:

>>> from imaplib import IMAP4
>>> m = IMAP4("localhost")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/py3k/Lib/imaplib.py", line 185, in __init__
    self.welcome = self._get_response()
  File "/py3k/Lib/imaplib.py", line 912, in _get_response
    if self._match(self.tagre, resp):
  File "/py3k/Lib/imaplib.py", line 1021, in _match
    self.mo = cre.match(s)
TypeError: can't use a string pattern on a bytes-like object
>>> m = IMAP4(b"localhost")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/py3k/Lib/imaplib.py", line 185, in __init__
    self.welcome = self._get_response()
  File "/py3k/Lib/imaplib.py", line 912, in _get_response
    if self._match(self.tagre, resp):
  File "/py3k/Lib/imaplib.py", line 1021, in _match
    self.mo = cre.match(s)
TypeError: can't use a string pattern on a bytes-like object

----------
components: Library (Lib)
messages: 72137
nosy: hdima
severity: normal
status: open
title: imaplib module broken by str to unicode conversion
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3728>
_______________________________________

From report at bugs.python.org  Fri Aug 29 16:14:12 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 29 Aug 2008 14:14:12 +0000
Subject: [issue3728] imaplib module broken by str to unicode conversion
In-Reply-To: <1220018733.89.0.00018896297534.issue3728@psf.upfronthosting.co.za>
Message-ID: <1220019252.27.0.0713546045128.issue3728@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

This seems to be duplicate of #1210.

----------
nosy: +draghuram
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3728>
_______________________________________

From report at bugs.python.org  Fri Aug 29 16:17:43 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 29 Aug 2008 14:17:43 +0000
Subject: [issue3728] imaplib module broken by str to unicode conversion
In-Reply-To: <1220018733.89.0.00018896297534.issue3728@psf.upfronthosting.co.za>
Message-ID: <1220019463.4.0.875663560587.issue3728@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Ah, yes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3728>
_______________________________________

From report at bugs.python.org  Fri Aug 29 16:52:24 2008
From: report at bugs.python.org (Tim Peters)
Date: Fri, 29 Aug 2008 14:52:24 +0000
Subject: [issue3722] print followed by exception eats print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1220021544.39.0.929715897069.issue3722@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

As the doctest docs say,

    Examples containing both expected output and an exception
    are not supported.  Trying to guess where one ends and
    the other begins is too error-prone, and that also makes
    for a confusing test.

Since this is working as designed and as documented, it's not "a bug". 
You could call it a feature request.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3722>
_______________________________________

From report at bugs.python.org  Fri Aug 29 16:59:08 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 29 Aug 2008 14:59:08 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

On Python 3.0:

>>> class C:
...     def __len__(self): return "foo"
...
>>> len(C())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/longobject.c:433: bad argument to internal function


On Python 2.6 the behaviour is different for old and new-style classes,
with old-style classes giving the more informative error message and
both accepting (and truncating) floats.

I attached a patch for Python 3.0, which refuses everything but ints and
gives an informative error message. Or does the float-truncating
behaviour of Python 2.x need to be preserved?

----------
files: len_check.diff
keywords: patch
messages: 72141
nosy: hagen
severity: normal
status: open
title: SystemError on calling len() if __len__() doesn't return an int
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11307/len_check.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Fri Aug 29 17:15:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 15:15:28 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220022928.81.0.536809829625.issue3729@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What about using PyNumber_AsSsize_t? it uses PyNumber_Index to accept
integral-like types, and refuses floats.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Fri Aug 29 17:28:41 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 29 Aug 2008 15:28:41 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220023721.87.0.289533574213.issue3729@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Sounds ok, but then you get a more generic "object cannot be interpreted
as an integer" at the point where len() is called, instead of the
clearer "__len__() should return an int". I'm not sure if this could be
confusing.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Fri Aug 29 17:54:00 2008
From: report at bugs.python.org (Chris AtLee)
Date: Fri, 29 Aug 2008 15:54:00 +0000
Subject: [issue3730] Update BaseHTTPServer docs
In-Reply-To: <1220025240.46.0.36189752437.issue3730@psf.upfronthosting.co.za>
Message-ID: <1220025240.46.0.36189752437.issue3730@psf.upfronthosting.co.za>


New submission from Chris AtLee <chris at atlee.ca>:

The BaseHTTPServer docs don't mention 'server' as an instance variable
in the instance variable section for BaseHTTPRequestHandler.  It is
mentioned in passing a few paragraphs above in the BaseHTTPServer class
description, but it's too easy to miss there.

Index: basehttpserver.rst
===================================================================
--- basehttpserver.rst	(revision 66056)
+++ basehttpserver.rst	(working copy)
@@ -68,6 +68,11 @@
       address.
 
 
+   .. attribute:: server
+
+      Contains the server instance.
+
+
    .. attribute:: command
 
       Contains the command (request type). For example, ``'GET'``.

----------
assignee: georg.brandl
components: Documentation
messages: 72144
nosy: catlee, georg.brandl
severity: normal
status: open
title: Update BaseHTTPServer docs
type: feature request
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3730>
_______________________________________

From report at bugs.python.org  Fri Aug 29 18:18:57 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 29 Aug 2008 16:18:57 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220026737.67.0.684948716956.issue3729@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Of course we can do both: Accept integral-like types and reset the
exception text. The new patch does this and adds a test for the new
behaviour.

Review carefully - I'm a newbie! ;-)

Added file: http://bugs.python.org/file11308/len_check2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Fri Aug 29 20:15:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 18:15:37 +0000
Subject: [issue3731] import warning in multiprocessing
In-Reply-To: <1220033737.12.0.773803477499.issue3731@psf.upfronthosting.co.za>
Message-ID: <1220033737.12.0.773803477499.issue3731@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following when running "regrtest.py -uall" under trunk:

/home/antoine/cpython/__svn__/Lib/multiprocessing/__init__.py:82:
ImportWarning: Not importing directory
'/home/antoine/cpython/__svn__/Modules/_multiprocessing': missing
__init__.py
  import _multiprocessing

----------
assignee: jnoller
components: Library (Lib)
messages: 72146
nosy: jnoller, pitrou
severity: normal
status: open
title: import warning in multiprocessing
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3731>
_______________________________________

From report at bugs.python.org  Fri Aug 29 20:28:33 2008
From: report at bugs.python.org (James Antill)
Date: Fri, 29 Aug 2008 18:28:33 +0000
Subject: [issue3066] FD leak in urllib2
In-Reply-To: <1213009389.23.0.132424094421.issue3066@psf.upfronthosting.co.za>
Message-ID: <1220034513.64.0.75942053304.issue3066@psf.upfronthosting.co.za>


James Antill <james.antill at redhat.com> added the comment:

So if I add a:

class _WrapForRecv:
    def __init__(self, obj):
        self.__obj = obj

    def __getattr__(self, name):
        if name == "recv": name = "read"
        return getattr(self.__obj, name)

...and then change:

        r.recv = r.read

...into:

        r = _WrapForRecv(r)

...it stops the leak, and afaics nothing bad happens.

----------
nosy: +nevyn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3066>
_______________________________________

From report at bugs.python.org  Fri Aug 29 20:33:21 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Aug 2008 18:33:21 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220034801.63.0.38667387395.issue3720@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It would be a damned shame to slow down the entire language to save 
code that is intentionally shooting itself in the foot.  EVERYONE will 
pay a cost -- NO ONE will benefit.  My two cents.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 20:42:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 18:42:01 +0000
Subject: [issue3668] "s*" argument parser marker leaks memory
In-Reply-To: <1219611778.13.0.51285980437.issue3668@psf.upfronthosting.co.za>
Message-ID: <1220035321.27.0.595067435411.issue3668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r66057 and r66058.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3668>
_______________________________________

From report at bugs.python.org  Fri Aug 29 21:09:02 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 19:09:02 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220036942.34.0.353714006722.issue3660@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury, I believe the first part of encode-leak.patch is wrong, you
should Py_DECREF the bytearray after it has been converted to bytes, not
before. Here is an alternate patch.

Added file: http://bugs.python.org/file11309/encode-leak2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Aug 29 21:28:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 19:28:23 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220038103.35.0.666760507285.issue3729@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Not bad! some remarks though:
- It's better to avoid the "expensive" call to PyErr_Occurred() when
possible. Here, an exception is set if (and only if) len==-1.
For example, it is enough to add these lines after the "__len__() should
return >= 0" message:

+		else if (PyErr_ExceptionMatches(PyExc_TypeError))
+			PyErr_SetString(PyExc_TypeError, 
+					"__len__() should return an int");

- Please clarify (that is: add tests for) the case where __len__ returns
1<<50 or -1<<50. If I remember correctly, PyNumber_AsSsize_t(res, NULL)
clips the values to MAXINT. Is this wanted?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Fri Aug 29 21:33:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 19:33:17 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220038397.63.0.650949188666.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Oops, you are right of course.
I remove my patch so we don't get confused.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Aug 29 21:33:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 19:33:23 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220038403.5.0.215038982749.issue3660@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file11285/encode-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Aug 29 21:37:05 2008
From: report at bugs.python.org (Ali Polatel)
Date: Fri, 29 Aug 2008 19:37:05 +0000
Subject: [issue3678] Ignored LDFLAGS during linking libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1220038625.19.0.741209392637.issue3678@psf.upfronthosting.co.za>


Changes by Ali Polatel <hawking at gentoo.org>:


----------
nosy: +hawking

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3678>
_______________________________________

From report at bugs.python.org  Fri Aug 29 21:56:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Aug 2008 19:56:45 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220039805.95.0.912114357074.issue3729@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That is *not* wanted. We had a discussion on the list about changing the
return value of the sq_length slot to allow larger lengths to be
reported, and while I don't recall why this wasn't done, I do recall
that the consensus was that if Py_ssize_t remains, len() should raise
rather than lie for larger values-

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Fri Aug 29 21:58:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 19:58:40 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220039920.5.0.0026771703277.issue3660@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

With the two patches applied, we are now at:

test_unittest leaked [124, 124] references, sum=248
test_distutils leaked [141, 142] references, sum=283
test_docxmlrpc leaked [85, -85] references, sum=0
test_logging leaked [366, -366] references, sum=0
test_os leaked [37, 0] references, sum=37
test_site leaked [88, 88] references, sum=176
test_smtplib leaked [0, 87] references, sum=87
test_sqlite leaked [17, 17] references, sum=34
test_telnetlib leaked [151, -151] references, sum=0
test_unicode leaked [1, 1] references, sum=2
test_urllib2_localnet leaked [3, 3] references, sum=6
test_xmlrpc leaked [-85, 0] references, sum=-85

24 tests skipped:
    test_bsddb3 test_cProfile test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dbm_gnu test_kqueue test_nis test_normalization
    test_ossaudiodev test_pep277 test_socketserver test_startfile
    test_tcl test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
2 skips unexpected on linux2:

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Aug 29 22:18:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 20:18:06 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220041086.04.0.678238374968.issue3720@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here are some timings, on winXP, vs2008 release build:

# t.py
def f(l=range(5000)): 
    for x in l: pass

# before the patch
> python -m timeit -s "from t import f" "f()"
10000 loops, best of 3: 159 usec per loop

# after the patch
> python -m timeit -s "from t import f" "f()"
10000 loops, best of 3: 160 usec per loop

and these figures are pretty stable on my machine.
Is it too much to pay? Some may consider that potential crashes are more
expensive.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 22:20:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Aug 2008 20:20:40 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220041240.86.0.208964541773.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did you look at the patch for issue3667 ? it should at least correct
test_site.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Aug 29 22:29:47 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 29 Aug 2008 20:29:47 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220041787.29.0.767741373284.issue3724@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Removed file: http://bugs.python.org/file11302/log.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3724>
_______________________________________

From report at bugs.python.org  Fri Aug 29 22:29:50 2008
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 29 Aug 2008 20:29:50 +0000
Subject: [issue3678] Ignored LDFLAGS during linking libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1220041790.34.0.900627297429.issue3678@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm confirming that the newer patch also fixes this bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3678>
_______________________________________

From report at bugs.python.org  Fri Aug 29 22:31:20 2008
From: report at bugs.python.org (Florian Mayer)
Date: Fri, 29 Aug 2008 20:31:20 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220041880.92.0.73335763219.issue3724@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Added file: http://bugs.python.org/file11310/log.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3724>
_______________________________________

From report at bugs.python.org  Fri Aug 29 22:34:42 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Aug 2008 20:34:42 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220042082.95.0.716782617483.issue3720@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Go for it.  There's really no question about fixing possible 
segfaulters.  Was just voicing my displeasure at this sort of 
exercise.  The code has been around since at least 2.2 and hasn't 
caused the slightest problem.  It bugs me to put cruft in the middle of 
otherwise tight loops.  Fortunately, the check is cheap and branch 
predictable.

BTW, your timings are domained by the function call and the range(5000) 
step.  To cleanly time for-loop overhead, use:

   python -m timeit "pass"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 23:23:13 2008
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 29 Aug 2008 21:23:13 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220044993.73.0.237443314685.issue3720@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

The same approach can be used to segfault many more places.  See
http://svn.python.org/projects/python/trunk/Lib/test/crashers/iter.py .

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Aug 29 23:24:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 21:24:14 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220045054.52.0.262295964745.issue3660@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, after the two patches plus the patch in #3667, I get the following:

test_asyncore leaked [84, -84] references, sum=0
test_distutils leaked [141, 142] references, sum=283
test_docxmlrpc leaked [-85, 0] references, sum=-85
test_logging leaked [219, -219] references, sum=0
test_sqlite leaked [17, 17] references, sum=34
test_unicode leaked [1, 1] references, sum=2
test_urllib2_localnet leaked [3, 3] references, sum=6
test_xmlrpc leaked [-6, -79] references, sum=-85

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Aug 29 23:33:11 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2008 21:33:11 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1220045591.76.0.520722098503.issue3297@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"Just to clarify: Python can be built as UCS2 or UCS4 build (not UTF-16
vs. UTF-32)"

I recently read most of the Unicode 5 standard and as near as I could
tell it no longer uses the term UCS, if it ever did.  Chapter 3 has only
the following 3 hits.

1. "D79 A Unicode encoding form assigns each Unicode scalar value to a
unique code unit sequence.
? For historical reasons, the Unicode encoding forms are also referred
to as Unicode (or UCS) transformation formats (UTF). That term is
actually ambiguous between its usage for encoding forms and encoding
schemes."

2. "For a discussion of the relationship between UTF-32 and UCS-4
encoding form defined in ISO/IEC 10646, see Section C.2, Encoding Forms
in ISO/IEC 10646."

Section C.2 says "UCS-4 can now be taken effectively as an alias for the
Unicode encoding form UTF-32" and mentions the restriction of UCS-2 to
the BMP.

3. "ISO/IEC 10646 specifies an equivalent UTF-16 encoding form.
For details, see Section C.3, UCS Transformation Formats."

U5 has 3 coding formats which it names UTF-8,16,32 and 7 serialization
formats of the same name with plus the latter two with 'BE' or 'LE'
append.  So, to me, use of 'UCS' is either confusing or misleading.

----------------------
"If it really was UCS-2, the repr wouldn't be u'\U00010123' on windows. 
It'd be a pair of ill-formed code units instead."

On WinXP,IDLE 3.0b2     
>>> repr('\U00010123') # u prefix no longer needed or valid
"'??'"
>>> repr('\ud800\udd23')
"'??'"
# Interesting: what I cut from IDLE has 2 empty boxes instead of the one
larger square with 010 and 123 I see on FireFox.  len(repr('\U0010123'))
is 4, not 3, so FireFox recognizes the surrogate and displays one symbol.

Entering either directly into the interpreter gives
Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on win32
>>> c='\U00010123'
>>> len(c)
2
>>> repr(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\Python30\lib\io.py", line 1428, in write
    b = encoder.encode(s)
  File "C:\Program Files\Python30\lib\encodings\cp437.py", line 19, in
encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position
2-3: character maps to <undefined> 

2.5 gives instead "u'\\U00010123'" as reported, so I added 3.0 to the
list of versions with a problem.

I do wonder how can repr() work on IDLE but not the underlying
interpreter?  Could IDLE change self.errors so that <undefined> is left
as is instead of raising an exception?  With the display then replacing
those with empty boxes?

----------
nosy: +tjreedy
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Fri Aug 29 23:42:51 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Aug 2008 21:42:51 +0000
Subject: [issue3732] bdist_msi gives a deprecation warning when run with
	Python 2.6
In-Reply-To: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>
Message-ID: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

d:\Python26\lib\msilib\__init__.py:5: DeprecationWarning: the sets
module is deprecated
  import sets, os, string, re

Should be easy to solve.

----------
components: Distutils, Library (Lib)
keywords: easy
messages: 72162
nosy: lemburg
priority: normal
severity: normal
status: open
title: bdist_msi gives a deprecation warning when run with Python 2.6
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3732>
_______________________________________

From report at bugs.python.org  Fri Aug 29 23:53:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 21:53:48 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1220046828.18.0.886780485234.issue2548@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The crashers which were deleted in rev58032 should at least have been
turned into unittests... well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Fri Aug 29 23:54:37 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2008 21:54:37 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1220046877.05.0.692073266563.issue3675@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Was it really intended that 3.0 pickles unpickle on 2.6?
What about other changes like moving something from one module to
another (reduce from built-in to functools), changing all classes to new
style (several examples), or adding methods to a built-in class (floats)?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Sat Aug 30 00:02:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2008 22:02:12 +0000
Subject: [issue3675] Python 2.6 can't read sets pickled with Python 3.0
In-Reply-To: <1219666544.55.0.587307324969.issue3675@psf.upfronthosting.co.za>
Message-ID: <1220047332.96.0.61583458611.issue3675@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Was it really intended that 3.0 pickles unpickle on 2.6?

He used protocol 2, so he explicitly asked for something inpickleable
with 2.6. If it's not the intended behaviour, then protocols < 3 should
be deprecated.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3675>
_______________________________________

From report at bugs.python.org  Sat Aug 30 00:05:19 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2008 22:05:19 +0000
Subject: [issue3679] pressing HOME key in IDLE editor ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1220047519.27.0.3408786011.issue3679@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Things like this tend to be system specific, and sometimes even machine
specific, so please include platform/os with reports, even I you do not
think it relevant.

In this case, Home works as it should on my WinXP 3.0b2
(which is fortunate since there is no b3 installer, and may not be).

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________

From report at bugs.python.org  Sat Aug 30 00:16:53 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 29 Aug 2008 22:16:53 +0000
Subject: [issue3733] Adding bin and Scripts folder into PATH
In-Reply-To: <1220048213.92.0.257328590649.issue3733@psf.upfronthosting.co.za>
Message-ID: <1220048213.92.0.257328590649.issue3733@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

The windows installer could add two entries in the PATH environment
variable. This would make "Python.exe" and other binaries available from
the command prompt without having to change PATH manually.

----------
components: Installation, Windows
messages: 72167
nosy: mhammond, tarek
severity: normal
status: open
title: Adding bin and Scripts folder into PATH
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3733>
_______________________________________

From report at bugs.python.org  Sat Aug 30 00:20:12 2008
From: report at bugs.python.org (Toby Donaldson)
Date: Fri, 29 Aug 2008 22:20:12 +0000
Subject: [issue3679] pressing HOME key in IDLE editor ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1220048412.9.0.248705093508.issue3679@psf.upfronthosting.co.za>


Toby Donaldson <tjdonaldson at gmail.com> added the comment:

I am using (x86) Python 3.0b2 on Windows XP Home Edition (SP 3) on an
AMD 64 X2 Dual Core Processor 6400+, 2.41 GHz, with 2 GB of RAM.

Just to be clear, its when I press HOME in the *editor* window when the
crash occurs. There's no problem if I press HOME in the shell window.

As soon as the 3.0b3 (or later) installer is released for Windows, I'll
check it out again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________

From report at bugs.python.org  Sat Aug 30 00:39:10 2008
From: report at bugs.python.org (Blair)
Date: Fri, 29 Aug 2008 22:39:10 +0000
Subject: [issue3734] subclassing complex
In-Reply-To: <1220049550.4.0.0881969750537.issue3734@psf.upfronthosting.co.za>
Message-ID: <1220049550.4.0.0881969750537.issue3734@psf.upfronthosting.co.za>


New submission from Blair <bidihall at gmail.com>:

The following is quoted from the Python docs (ref/numeric_types):

"Note: If the right operand's type is a subclass of the left operand's
type and that subclass provides the reflected method for the operation,
this method will be called before the left operand's non-reflected
method. This behavior allows subclasses to override their ancestors'
operations."

My issue is that the built-in complex type does not respect this rule
(see code below). Note that float can be subclassed using the method
shown below and the rules are applied correctly. It seems that it is
only a problem with complex.

class xcomplex( complex ):

    def __new__(cls,*args,**kwargs):
        return complex.__new__(cls,*args,**kwargs)

    def __coerce__(self,other):
        t = complex.__coerce__(self,other)
        try:
            return (self,xcomplex(t[1]))
        except TypeError:
            return t

    def __add__(self,x):
        return xcomplex( complex.__add__(self,x) )

    def __radd__(self,x):
        return xcomplex( complex.__radd__(self,x) ) 

print type(z + xz)  # gives complex when xcomplex is required

----------
components: None
messages: 72169
nosy: gumtree
severity: normal
status: open
title: subclassing complex
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3734>
_______________________________________

From report at bugs.python.org  Sat Aug 30 01:07:09 2008
From: report at bugs.python.org (David Decotigny)
Date: Fri, 29 Aug 2008 23:07:09 +0000
Subject: [issue3735] allow multiple threads to efficiently send the same
	requests to a processing.Pool without incurring duplicate processing
In-Reply-To: <1220051229.09.0.236623735385.issue3735@psf.upfronthosting.co.za>
Message-ID: <1220051229.09.0.236623735385.issue3735@psf.upfronthosting.co.za>


New submission from David Decotigny <com.d2 at free.fr>:

I posted a recipe on ASPN: http://code.activestate.com/recipes/576462/
and Jesse, cheerleader for the inclusion of (multi)processing into
python-core, suggested that it could be interesting to add this feature
to the next pythons.
This recipe is based on version 0.52 of the standalone "processing"
package, and allows to avoid redundancy when multiple threads send the
same job requests to a pool of background worker processes. The recipe
details the why and the how.
Some notes on the implementation, though:
 - There is a "Begin/End workaround" section in the code, which aims at
working around a limitation of processing 0.52 (see comments and
docstring for details). I sent issue #014431 to the issue tracker for
processing on berlios, this would allow to get rid of this workaround
 - Read my comment #2 to the recipe, dealing with my thoughts of using
weak references

----------
components: Library (Lib)
messages: 72170
nosy: DavidDecotigny, jnoller
severity: normal
status: open
title: allow multiple threads to efficiently send the same requests to a processing.Pool without incurring duplicate processing
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3735>
_______________________________________

From report at bugs.python.org  Sat Aug 30 01:11:20 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 29 Aug 2008 23:11:20 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220051480.12.0.587521180036.issue3720@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This patch fixes Armin's list of crashers for trunk. Looking for others
like them.

----------
nosy: +ajaksu2
versions: +Python 2.6
Added file: http://bugs.python.org/file11311/itercrashers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sat Aug 30 01:16:20 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 29 Aug 2008 23:16:20 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220051780.8.0.666166365745.issue3720@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


Removed file: http://bugs.python.org/file11311/itercrashers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sat Aug 30 01:17:48 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 29 Aug 2008 23:17:48 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220051868.36.0.261520482992.issue3720@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Hopefully the right patch this time :/

Added file: http://bugs.python.org/file11312/itercrashers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sat Aug 30 01:38:52 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Aug 2008 23:38:52 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220053132.05.0.1863078475.issue3720@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Amaury, if you decide to go forward with this, please clean-up the 
patches to eliminate common subexpressions. 

Wonder if there is an alternate solution that keeps the next slot 
filled with something that raises an Attribute error.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sat Aug 30 01:46:30 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 29 Aug 2008 23:46:30 +0000
Subject: [issue3736] super is a built-in type
In-Reply-To: <1220053590.33.0.225544185622.issue3736@psf.upfronthosting.co.za>
Message-ID: <1220053590.33.0.225544185622.issue3736@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

super is defined as a built-in function

http://docs.python.org/dev/library/functions.html

but it is a type, shouldn't it be replaced ?

----------
assignee: georg.brandl
components: Documentation
messages: 72174
nosy: georg.brandl, tarek
severity: normal
status: open
title: super is a built-in type
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3736>
_______________________________________

From report at bugs.python.org  Sat Aug 30 01:56:38 2008
From: report at bugs.python.org (Kevin Watters)
Date: Fri, 29 Aug 2008 23:56:38 +0000
Subject: [issue836035] strftime month name is encoded somehow
Message-ID: <1220054198.05.0.209622332047.issue836035@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue836035>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:03:42 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2008 00:03:42 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220054622.17.0.786490064651.issue3720@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I share Raymond's annoyance.  The ultimate solution for segfaults is for
bad pointer references to be catchable (trappable) the same as math
errors are are now.  I remember when 1/0 was fatal, not EDOM.  Then the
interpreter could print a traceback and SegfaultException message ;-)

For this problem, I think there are alternatives to the current patch,
which as Armin points out, would need to be extended to every built-in
use of iterators.

Is there any (sensible) way to make .__next__ (or the underlying
tp_iternext slot) undelete-able?  We already cannot change methods of
built-ins.  Or replace with def __next__(self): raise StopIteration.

Or could iter() temporarily lock iterators in some way similar to what
happens to dict during iteration?  (Modifying actually does the action,
and then raises RuntimeError).  Modifying an active iterator strikes me
as even less sane than modifying an underlying dict.

The basic problem is that C code (unnecessarily?) does the same pointer
tracing each iteration.  Why not calculate np = *v->ob_type->tp_iternext
just once?  and just (more quickly) call np(v) each iteration?

One could claim this is a semantic change, but so was the change to dicts.  

The equivalent in Python would be

class BadIterator() :
	def __iter__(self) :
		return self
	def __next__(self) : # should be __next__ for python 3.0
		del BadIterator.__next__
		return 1

itnext = BadIterator().__next__
print(itnext())
print(itnext())

The second itnext call only fails because the del statement fails with
AttributeError: __next__.  I presume it would do the same if called from C.

(My annoyance with Py3 changing .next to .__next__ is that it makes it
harder to do the 'right thing' when iterating explicitly, which to me it
to use a bound method.  I wish next(it) returned it.__next__ instead of
calling it.)

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:05:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Aug 2008 00:05:46 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1220054746.41.0.123882814625.issue2548@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is a patch which seems to cover all bases. It fixes the present
bug, adds tests for the aforementioned ex-crashers, backports the
somewhat smarter recursion checking from py3k, and improves the latter
by fixing a nasty recursion bug when exceptions are ignored by C code.

I have to explain the latter problem a bit. Some functions like
PyDict_GetItem() are designed to silence all exceptions. If a
RuntimeError is raised because of a recursion overflow, however, a flag
(named "overflowed") is additionally set in the thread state structure;
this flag temporarily bumps the recursion_limit by 50, so that the  code
which caught the exception can perform some cleanup without itself
getting into the recursion limit. However, if recursion_limit + 50 is in
turned reached, the interpreter aborts with a fatal error.

Now, if the RuntimeError is discarded by PyDict_GetItem(), the
"overflowed" flag must also be reset, because the caller won't know that
there was a recursion overflow and that it must clean up. Instead, it
will simply assume the requested value is not in the dict, and will
continue happily... until it overflows the recursion limit again, which
will trigger the aforementioned fatal error if "overflowed" has not been
reset.

Consequently, PyErr_Clear() now resets the "overflowed" flag if the
current recursion count has gone back below the recursion limit. This
improvement must also be merged back to py3k.

Of course, we may also decide that all those subtle changes are not
worth the risk, just to fix a few obscure glitches.

----------
keywords: +patch
Added file: http://bugs.python.org/file11313/excrecurse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:05:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Aug 2008 00:05:58 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1220054758.97.0.86953640414.issue2548@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:09:12 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 30 Aug 2008 00:09:12 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220054952.6.0.564831788497.issue3720@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Raymond, I think a different solution would be great, as the performance
penalty might become nasty in tight loops if we miss some detail. 

Regarding the possible impact, I hope we can get a better estimate since
the other examples of segfaulting that look like Armin's I've found are
in itertools. I imagine you have the right tests to check the effect of
any changes there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:09:16 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Aug 2008 00:09:16 +0000
Subject: [issue3736] super is a built-in type
In-Reply-To: <1220053590.33.0.225544185622.issue3736@psf.upfronthosting.co.za>
Message-ID: <1220054956.7.0.189914175304.issue3736@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am already working on the docs for super().

----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3736>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:14:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Aug 2008 00:14:33 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1220055273.94.0.596145079747.issue2548@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file11313/excrecurse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:15:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Aug 2008 00:15:13 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1220055313.81.0.29028132299.issue2548@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ouch, there were a couple of useless lines in ceval.h. New patch.

Added file: http://bugs.python.org/file11314/excrecurse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:21:38 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Aug 2008 00:21:38 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220055698.87.0.268580942541.issue3720@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It's not just performance -- the patch code is grotesque.  Lots of code 
would need to be changed just before the release candidate (usually a 
bad idea).  And the underlying problem doesn't seem to be one that has 
*ever* affected a real user since 2.2.  I have a hard time caring much 
about this problem.  

The minor performance hit only bugs me because it affects the inner-
loops of just about every piece of real python code -- everyone will 
pay a cost for this change.

Since the "problem" has existed so long with no ill effect, am 
unmarking the "release blocker" priority.  Would rather have a 
thoughtful discussion on alternatives along with a careful, thorough, 
efficient patch for a bug release version.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sat Aug 30 02:40:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Aug 2008 00:40:03 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1220056803.28.0.723990462849.issue2548@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After thinking about it a bit, I think the whole recursion checking
thing has gone a bit mad. It probably deserves proper discussion on the
mailing-list. In the meantime, I'm downgrading this bug to critical.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2548>
_______________________________________

From report at bugs.python.org  Sat Aug 30 03:25:56 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 30 Aug 2008 01:25:56 +0000
Subject: [issue3732] bdist_msi gives a deprecation warning when run with
	Python 2.6
In-Reply-To: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>
Message-ID: <1220059556.79.0.854821395362.issue3732@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This patch will partialy backport r53335

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file11315/fix_deprecated_sets.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3732>
_______________________________________

From report at bugs.python.org  Sat Aug 30 06:47:11 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Sat, 30 Aug 2008 04:47:11 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1220071631.28.0.744565027933.issue2384@psf.upfronthosting.co.za>


Dwayne Litzenberger <dlitz at dlitz.net> added the comment:

Could "-*- coding: ascii -*-" and other equivalent encodings be fixed,
at least, before the release?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Sat Aug 30 09:41:36 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2008 07:41:36 +0000
Subject: [issue3679] pressing HOME key in IDLE editor ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1220082096.12.0.0837135846674.issue3679@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The only system difference is that I have an older Athlon cpu.
And I did try Home (key above End) in the editor window and it moves
cursor to beginning of line.  My options/configure/key bindings starts
beginning-of-line <Key-Home>.  So this might be a peculiar interaction
with your system.  In .a5, I had a crash problem (which someone else
reproduced) that disappeared in .b1 without anyone claiming to have done
anything to fix the problem, so it seems IDLE can a bit fragile.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________

From report at bugs.python.org  Sat Aug 30 11:45:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 09:45:16 +0000
Subject: [issue3695] Source tarball for Sphinx 0.4.3 missing
In-Reply-To: <1219811808.96.0.614683444156.issue3695@psf.upfronthosting.co.za>
Message-ID: <1220089516.84.0.148748409526.issue3695@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The website is in error; it takes sphinx.__version__ which in the repo
is the next version to be released, so that easy_install works correctly.

Fixed in r66061.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3695>
_______________________________________

From report at bugs.python.org  Sat Aug 30 11:49:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 09:49:45 +0000
Subject: [issue3730] Update BaseHTTPServer docs
In-Reply-To: <1220025240.46.0.36189752437.issue3730@psf.upfronthosting.co.za>
Message-ID: <1220089785.3.0.834608122299.issue3730@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed as r66062.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3730>
_______________________________________

From report at bugs.python.org  Sat Aug 30 11:53:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 09:53:08 +0000
Subject: [issue3716] mistake in 3.4.2 Customizing attribute access
In-Reply-To: <1219951289.51.0.953784677576.issue3716@psf.upfronthosting.co.za>
Message-ID: <1220089988.53.0.566831289027.issue3716@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66063.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3716>
_______________________________________

From report at bugs.python.org  Sat Aug 30 11:58:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 09:58:53 +0000
Subject: [issue3577] Interpreter name: python vs. python-3.0
In-Reply-To: <1218975329.44.0.7329421423.issue3577@psf.upfronthosting.co.za>
Message-ID: <1220090333.73.0.666167373155.issue3577@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66064.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3577>
_______________________________________

From report at bugs.python.org  Sat Aug 30 12:04:56 2008
From: report at bugs.python.org (John Smith)
Date: Sat, 30 Aug 2008 10:04:56 +0000
Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
In-Reply-To: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za>
Message-ID: <1220090696.74.0.17019786157.issue1276@psf.upfronthosting.co.za>


John Smith <ebgssth at gmail.com> added the comment:

Confirmed now I can build Python on Mac OS X with Japanese locale.
I tested the followings. 

Python 2.6b3+ trunk:66060
Python 3.0b3+ py3k:66060

Thank you very much.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1276>
_______________________________________

From report at bugs.python.org  Sat Aug 30 12:47:48 2008
From: report at bugs.python.org (zouzhile)
Date: Sat, 30 Aug 2008 10:47:48 +0000
Subject: [issue3737] An error in Python Library Reference document
In-Reply-To: <1220093268.84.0.83776548912.issue3737@psf.upfronthosting.co.za>
Message-ID: <1220093268.84.0.83776548912.issue3737@psf.upfronthosting.co.za>


New submission from zouzhile <zouzhile at 126.com>:

Problem:
On the page http://docs.python.org/lib/built-in-funcs.html, there is a
description about "super(type[,object-or-type])": Return the superclass
of type. If the second argument....
This is NOT true. it will actually return an instance of the type
"super", instead of "the superclass of type".

Suggested fix:
Return a new instance of the type "super".

----------
messages: 72190
nosy: zouzhile
severity: normal
status: open
title: An error in Python Library Reference document

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3737>
_______________________________________

From report at bugs.python.org  Sat Aug 30 14:13:14 2008
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 30 Aug 2008 12:13:14 +0000
Subject: [issue3738] logging.Handler.close does something
In-Reply-To: <1220098393.98.0.954077896829.issue3738@psf.upfronthosting.co.za>
Message-ID: <1220098393.98.0.954077896829.issue3738@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

Library documents claim that logging.Handler.close does nothing, but 
the source code shows otherwise---it removes itself from the internal 
handler list.  The error propagates treelike through the subclasses.  
(I found references to close in stream handler flush and 
NTEventLogHandler subclass).  I have source code for version 2.5, but 
the error likely persists through version 3.03b which 

http://docs.python.org/dev/3.0/library/logging.html#logging.StreamHandl
er

claims,

"flush()? 
Flushes the stream by calling its flush() method. Note that the close
() method is inherited from Handler and so does nothing, so an 
explicit flush() call may be needed at times.
"

Actually, before reading the manual I tried

del streamHandler_on_my_stream; my_stream.close()

which didn't fix subsequent log messages that reported failure writing 
to closed stream.  __del__ might be easy to implement, and it seems 
natural.

Respectfully,
Dave

----------
assignee: georg.brandl
components: Documentation
messages: 72191
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: logging.Handler.close does something
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3738>
_______________________________________

From report at bugs.python.org  Sat Aug 30 14:47:18 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 12:47:18 +0000
Subject: [issue3569] Glitch in eval() doc
In-Reply-To: <1218919187.91.0.149398237755.issue3569@psf.upfronthosting.co.za>
Message-ID: <1220100438.67.0.950276950639.issue3569@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r66065.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3569>
_______________________________________

From report at bugs.python.org  Sat Aug 30 15:05:19 2008
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Sat, 30 Aug 2008 13:05:19 +0000
Subject: [issue3739] unicode-internal encoder reports wrong length
In-Reply-To: <1220101519.85.0.185335325424.issue3739@psf.upfronthosting.co.za>
Message-ID: <1220101519.85.0.185335325424.issue3739@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

The encoder for the "unicode-internal" codec reports the wrong length:

Python 3.0b3+ (py3k, Aug 30 2008, 11:55:21) 
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> codecs.getencoder("unicode-internal")("a")
(b'a\x00', 2)

I would have expected it to output:

(b'a\x00', 1)

instead.

----------
components: Unicode
messages: 72193
nosy: doerwalter
severity: normal
status: open
title: unicode-internal encoder reports wrong length
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3739>
_______________________________________

From report at bugs.python.org  Sat Aug 30 15:16:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 13:16:05 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220102165.77.0.00360017562104.issue3724@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> marketdickinson
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3724>
_______________________________________

From report at bugs.python.org  Sat Aug 30 15:18:04 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 13:18:04 +0000
Subject: [issue3737] An error in Python Library Reference document
In-Reply-To: <1220093268.84.0.83776548912.issue3737@psf.upfronthosting.co.za>
Message-ID: <1220102284.35.0.125184565973.issue3737@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be clarified in r66067.

In the future, please choose a more specific title for your bug reports :)

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3737>
_______________________________________

From report at bugs.python.org  Sat Aug 30 15:34:07 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 30 Aug 2008 13:34:07 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1220103247.66.0.32050343939.issue2723@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


----------
nosy: +hagen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
_______________________________________

From report at bugs.python.org  Sat Aug 30 15:36:26 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 30 Aug 2008 13:36:26 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220103386.66.0.8744567276.issue3729@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

In the latest list message I could find Guido wanted len() to lie:

http://mail.python.org/pipermail/python-3000/2008-May/013387.html

Has this been resolved in issue 2723?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Sat Aug 30 16:42:06 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 14:42:06 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220107326.51.0.322280279724.issue3729@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

True. However, it's no pronouncement either. I suggest bringing it up on
the list again; probably other people would want to voice their opinions
too.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3729>
_______________________________________

From report at bugs.python.org  Sat Aug 30 17:14:49 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Sat, 30 Aug 2008 15:14:49 +0000
Subject: [issue3740] PEP 3121 --- module state is not nul-initalized as
	claimed in the PEP
In-Reply-To: <1220109289.56.0.0975805859845.issue3740@psf.upfronthosting.co.za>
Message-ID: <1220109289.56.0.0975805859845.issue3740@psf.upfronthosting.co.za>


New submission from Paul Pogonyshev <pogonyshev at gmx.net>:

PEP 3121 states that: "The module state will be null-initialized".  This
is not the case as it seems.

----------
components: Interpreter Core
messages: 72197
nosy: _doublep
severity: normal
status: open
title: PEP 3121 --- module state is not nul-initalized as claimed in the PEP
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3740>
_______________________________________

From report at bugs.python.org  Sat Aug 30 17:34:08 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Sat, 30 Aug 2008 15:34:08 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1220110448.54.0.258871817936.issue2723@psf.upfronthosting.co.za>


Paul Pogonyshev <pogonyshev at gmx.net> added the comment:

I'm also absolutely against having len() lying to me.  This would be a
welcome to bump into some other hideous error later, e.g. discarding
part of data as I'd think it wasn't there.  Better raise an exception as
now, at least then programmers will know something is wrong and have a
chance to workaround, etc.

----------
nosy: +_doublep

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
_______________________________________

From report at bugs.python.org  Sat Aug 30 19:18:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 17:18:13 +0000
Subject: [issue3667] Reloading an extension module always leaks
In-Reply-To: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>
Message-ID: <1220116693.42.0.573160171009.issue3667@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3667>
_______________________________________

From report at bugs.python.org  Sat Aug 30 21:00:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Aug 2008 19:00:33 +0000
Subject: [issue3707] help('finally') behaves bizarrely
In-Reply-To: <1219877059.52.0.153636497207.issue3707@psf.upfronthosting.co.za>
Message-ID: <1220122833.8.0.968075324907.issue3707@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch is ok on trunk. It should also be merged to py3k.

----------
nosy: +pitrou
resolution:  -> accepted
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3707>
_______________________________________

From report at bugs.python.org  Sat Aug 30 21:02:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 19:02:30 +0000
Subject: [issue3683] compilation --without-threads fails
In-Reply-To: <1219714513.04.0.272760224775.issue3683@psf.upfronthosting.co.za>
Message-ID: <1220122950.66.0.631576265636.issue3683@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The patch needs an #else that does ImportModule anyway... see attached.

----------
keywords: +patch
nosy: +georg.brandl
Added file: http://bugs.python.org/file11316/import.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3683>
_______________________________________

From report at bugs.python.org  Sat Aug 30 21:04:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Aug 2008 19:04:02 +0000
Subject: [issue3707] help('finally') behaves bizarrely
In-Reply-To: <1219877059.52.0.153636497207.issue3707@psf.upfronthosting.co.za>
Message-ID: <1220123042.04.0.351392075409.issue3707@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for reviewing! Committed trunk r66076.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3707>
_______________________________________

From report at bugs.python.org  Sun Aug 31 00:55:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 30 Aug 2008 22:55:40 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220136940.43.0.85229512945.issue3720@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Amaury, if you decide to go forward with this, please clean-up the 
> patches to eliminate common subexpressions. 
I already considered this, but generated machine code was identical, so
I chose the more readable code.

> Wonder if there is an alternate solution that keeps the next slot 
> filled with something that raises an Attribute error.

That's an interesting idea, and not difficult to implement, see attached
patch. The penalty here is an extra comparison in PyIter_Check(). And no
change in the event loop...
Armin's crashers now correctly raise a TypeError (and the final patch
should convert them as unit tests)

Added file: http://bugs.python.org/file11317/next-nevernull.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sun Aug 31 05:09:46 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Aug 2008 03:09:46 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220152186.31.0.0277410437483.issue3720@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It was the ajaksu2 patches that needed clean-up.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sun Aug 31 05:20:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Aug 2008 03:20:25 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220152825.37.0.308715741099.issue3720@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The next-nevernull patch is much cleaner than I expected.  Nice work.

The assertion in abstract.c can be changed to:
   assert(iter==PyObject_NextNotImplemented || PyIter_Check(iter));

Armin, are you happy with the new approach?  Though "del obj.next" 
isn't doing exactly what you would expect, that seems harmless to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sun Aug 31 11:21:33 2008
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 31 Aug 2008 09:21:33 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220174493.89.0.0542740879342.issue3720@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Hacking at typeobject.c should always be done extremely carefully.  I
don't have time to review this patch as thouroughly as I think it needs
to be.  (A quick issue is that it seems to break PyIter_Check() which
will always return true now, but I'd recommend a much more thourough
review.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Sun Aug 31 14:46:06 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Aug 2008 12:46:06 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1220186766.38.0.996260550402.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Docs updated for 3.0 in r66084 (and I was right in thinking the
automatic merge didn't have a hope of getting this right - there were
conflicts all the way through the file).

Closing this issue after a mere 5 years and 9 months - any requests for
better proxying/special method delegation support in the standard
library should be raised in a new tracker issue as a feature request for
2.7/3.1.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
_______________________________________

From report at bugs.python.org  Sun Aug 31 15:23:05 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Aug 2008 13:23:05 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1220188985.78.0.252831148619.issue2235@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

__hash__() documentation fixed for 2.6 in r66085 and for 3.0 in r66086.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________

From report at bugs.python.org  Sun Aug 31 17:42:40 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 31 Aug 2008 15:42:40 +0000
Subject: [issue3715] hashlib's docstring throws exception in pydoc
In-Reply-To: <1219945459.86.0.239279043076.issue3715@psf.upfronthosting.co.za>
Message-ID: <1220197360.53.0.659814827807.issue3715@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3715>
_______________________________________

From report at bugs.python.org  Sun Aug 31 18:36:51 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 31 Aug 2008 16:36:51 +0000
Subject: [issue3715] hashlib's docstring throws exception in pydoc
In-Reply-To: <1219945459.86.0.239279043076.issue3715@psf.upfronthosting.co.za>
Message-ID: <1220200611.02.0.760983149629.issue3715@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r66093, py3k r66094, release25-maint r66095

----------
keywords: +easy
resolution:  -> fixed
status: open -> closed
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3715>
_______________________________________

From report at bugs.python.org  Sun Aug 31 19:14:49 2008
From: report at bugs.python.org (Paul "TBBle" Hampson)
Date: Sun, 31 Aug 2008 17:14:49 +0000
Subject: [issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an
	exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>


New submission from Paul "TBBle" Hampson <Paul.Hampson at Pobox.com>:

Basically, if DISTUTILS_USE_SDK is set in the environment and an
extension is attempted to be built from within the Windows SDK shell
(ie. MSSdk is set in the environment as well), msvc9compiler.py will
raise an exception due to a reference to the undefined self.__paths in
MSVCCompiler.find_exe class, called from MSVCCompiler.initialize.

self.__paths is used both in MSVCCompiler.find_exe and further through
MSVCCompiler.initialize, but only exists if the else branch of the
DISTUTILS_USE_SDK if/else is taken.

I've attached a patch which trivially fixes this by setting self.__paths
to [] before the test for DISTUTILS_USE_SDK.

However, the use of MSVCCompiler.find_exe in this test might be wrong.
Short of raising an exception, MSVCCompiler.find_exe always returns what
it is supplied if it can't find anything better. So testing the truth of
this value is likely incorrect. (I assume that find_exe used to return a
false value if the requested program could not be found on the path or
in self.__paths[]...)

If the find_exe is removed from the test, then the setting of
self.__paths can be done inside the if branch, paralleling the else branch.

----------
components: Distutils
files: msvc9compiler-windowssdk.diff
keywords: patch
messages: 72209
nosy: TBBle
severity: normal
status: open
title: DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an exception
versions: Python 2.6
Added file: http://bugs.python.org/file11318/msvc9compiler-windowssdk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________

From report at bugs.python.org  Sun Aug 31 19:25:35 2008
From: report at bugs.python.org (Paul "TBBle" Hampson)
Date: Sun, 31 Aug 2008 17:25:35 +0000
Subject: [issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an
	exception
In-Reply-To: <1220202889.53.0.172923498575.issue3741@psf.upfronthosting.co.za>
Message-ID: <1220203535.18.0.352665722427.issue3741@psf.upfronthosting.co.za>


Paul "TBBle" Hampson <Paul.Hampson at Pobox.com> added the comment:

The line my patch adds was present originally, and lost when
msvccompiler.py was duplicated into msvc9compiler.py in revision 59290.

http://svn.python.org/view?rev=59290&view=rev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3741>
_______________________________________

From report at bugs.python.org  Sun Aug 31 21:43:38 2008
From: report at bugs.python.org (Joshua Logan)
Date: Sun, 31 Aug 2008 19:43:38 +0000
Subject: [issue3742] Parsing XML file with Unicode characters causes problem
In-Reply-To: <1220211818.88.0.0185485536041.issue3742@psf.upfronthosting.co.za>
Message-ID: <1220211818.88.0.0185485536041.issue3742@psf.upfronthosting.co.za>


New submission from Joshua Logan <dear.jay.logan at gmail.com>:

Python 3.0b2 will not parse the XML file located at
http://rubyquiz.com/SongLibrary.xml.gz

It complains of a UnicodeEncodeError 
'charmap' codec can't encode character '\xc8' in position 45: ch
aracter maps to <undefined>

I included a sample program, just in case I was doing something wrong
while coding.

Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

----------
components: XML
files: read_song_xml.py
messages: 72211
nosy: jaylogan
severity: normal
status: open
title: Parsing XML file with Unicode characters causes problem
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11319/read_song_xml.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3742>
_______________________________________

From report at bugs.python.org  Sun Aug 31 22:40:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 31 Aug 2008 20:40:38 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

test_deque fails on win64 buildbot:
  AssertionError: 'deque([7, 8, 9], maxlen=%Id)' != 'deque([7, 8, 9],
maxlen=3)'

A PY_FORMAT_SIZE_T format is incorrectly used with PyUnicode_FromFormat.
The correct format here is "%zd". PY_FORMAT_SIZE_T should be reserved
for the OS printf routines, PyOS_snprintf, PySys_WriteStderr.

The attached patch replaces 
   "%" PY_FORMAT_SIZE_T "%d" 
with
   "%zd"

----------
files: fromformat.patch
keywords: patch
messages: 72212
nosy: amaury.forgeotdarc
severity: normal
status: open
title: PY_FORMAT_SIZE_T is not for PyString_FromFormat
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11320/fromformat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Sun Aug 31 22:59:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 Aug 2008 20:59:03 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220216343.9.0.630000964151.issue3743@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good to me.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Sun Aug 31 23:17:59 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 31 Aug 2008 21:17:59 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220217479.37.0.506588013191.issue3743@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

O

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Sun Aug 31 23:45:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 Aug 2008 21:45:03 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220219103.99.0.766069182793.issue3743@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You're right, Chris, I didn't think of that...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________