From report at bugs.python.org  Mon Jun  1 00:05:16 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 May 2009 22:05:16 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1243807516.51.0.306768869554.issue2919@psf.upfronthosting.co.za>


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

Thanks for the code, Jean. With Python 3.1 about to go out the door this
will have to be a 3.2 thing. But I plan to start looking at this module
merge some time in July so I should get to looking at what you did then
(unless someone beats me to it).

----------
stage:  -> patch review

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

From report at bugs.python.org  Mon Jun  1 00:08:04 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 May 2009 22:08:04 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243807684.88.0.135671977017.issue6154@psf.upfronthosting.co.za>


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

I do have intl installed through MacPorts so I am sure Mark's right that
having intl installed as well as running on OS X is triggering this.

----------

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

From report at bugs.python.org  Mon Jun  1 00:13:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 May 2009 22:13:15 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1243807995.69.0.251693473915.issue2919@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Mon Jun  1 00:32:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 May 2009 22:32:16 +0000
Subject: [issue6158] test_aifc failing on 32bit windows in python 3.1 rc 1
In-Reply-To: <1243809136.07.0.631093381949.issue6158@psf.upfronthosting.co.za>
Message-ID: <1243809136.07.0.631093381949.issue6158@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Martin, the test is failing because the dist is missing the file: 
Lib/test/Sine-1000Hz-300ms.aif .  That file is in SVN and was included
in the rc1 tarball.

----------
assignee: loewis
components: Tests
messages: 88616
nosy: loewis, rhettinger
priority: high
severity: normal
status: open
title: test_aifc failing on 32bit windows in python 3.1 rc 1
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun  1 00:58:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 May 2009 22:58:04 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1243810684.84.0.59574496897.issue1731717@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have confirmed that none of the original test cases referenced here or
in the referenced issues fails on python 2.5.4, 2.6.2, trunk, or py3k on
linux.

The test case attached to this ticket I cannot test as I don't
understand how one would run it (and exim appears to be involved).

Given the discussion (specifically msg32219) I think this ticket should
be closed as fixed; unless, Yonas, you can provide a reproducible test
case that does not involve third party software, or someone else can
reproduce your exim case.

If someone wants to propose a patch to refactor subprocess, IMO that
should be opened as a new feature request ticket.

----------
nosy: +r.david.murray
resolution:  -> fixed
status: open -> pending

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

From report at bugs.python.org  Mon Jun  1 01:09:09 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 31 May 2009 23:09:09 +0000
Subject: [issue4152] ihooks module cannot handle absolute imports
In-Reply-To: <1224524202.33.0.257355673326.issue4152@psf.upfronthosting.co.za>
Message-ID: <1243811349.62.0.628846210333.issue4152@psf.upfronthosting.co.za>


Neil Schemenauer <nas-pythonbugs at arctrix.com> added the comment:

Adding a patch that adds support for relative imports based on the
import.c code. I've tested it by hacking the test_import.py test module.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file14132/ihooks_relative.txt

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

From report at bugs.python.org  Mon Jun  1 01:22:57 2009
From: report at bugs.python.org (Yonas)
Date: Sun, 31 May 2009 23:22:57 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1243812177.26.0.865615403534.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

To test with exim4 is easy. To reproduce on Ubuntu Jaunty:

1. apt-get install exim4-daemon-heavy

2. echo "local_scan = /usr/lib/exim4/local_scan/libpyexim.so" >
/etc/exim4/conf.d/main/15_py-exim_plugin_path

3. cd /usr/lib/exim4/local_scan

4. Compile mylib, output will be "libpyexim.so":

gcc `python2.6-config --cflags` -c -fPIC mylib.c -o mylib.o 
gcc -Xlinker -export-dynamic -lpython2.6 -lnsl -lpthread -ldl -lutil -lm
-lz -shared -Wl,-soname,libpyexim.so -o libpyexim.so  mylib.o

5. Restart server:
/etc/init.d/exim4 restart

6. Send some mail:
cat mail.txt | sendmail -t

(contents of mail.txt):
Content-type: text/plain
To: your_username at localhost
From: foobar at example.com
Subject: test

Hello world.

----------
status: pending -> open

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

From report at bugs.python.org  Mon Jun  1 01:28:02 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 31 May 2009 23:28:02 +0000
Subject: [issue6159] Tkinter.PanedWindow: docstring fixes,
	change in paneconfigure and removed some returns
In-Reply-To: <1243812482.01.0.481805459937.issue6159@psf.upfronthosting.co.za>
Message-ID: <1243812482.01.0.481805459937.issue6159@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

The attached patch removes the return statements from proxy_forget and
proxy_place since these methods aren't supposed to return anything.

It also fixes the docstring for the identify and paneconfigure methods.
While fixing the docstring in paneconfigure I considered as important to
rename "tagOrId" to "window", so the documentation and the method
signature get in agreement and also makes sense.

----------
components: Tkinter
files: PanedWindow_docstring_and_return_fixes.diff
keywords: patch
messages: 88620
nosy: gpolo
severity: normal
status: open
title: Tkinter.PanedWindow: docstring fixes, change in paneconfigure and removed some returns
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14133/PanedWindow_docstring_and_return_fixes.diff

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

From report at bugs.python.org  Mon Jun  1 01:28:35 2009
From: report at bugs.python.org (Yonas)
Date: Sun, 31 May 2009 23:28:35 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1243812515.82.0.819923802494.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

Also, copy exim_local_scan2.py to /usr/lib/python2.6/

----------
Added file: http://bugs.python.org/file14134/exim_local_scan2.py

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

From report at bugs.python.org  Mon Jun  1 01:39:27 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 31 May 2009 23:39:27 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1243813167.21.0.371753019021.issue2281@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Another thought on the hires timer to make the hires time and hires time 
units available as 2 other functions in the time module.

For example, function time.ticks() returns the hires time stamp as an 
int.  Function time.ticks2secs(t) converts a given number of ticks to 
seconds.

To avoid duplicating the hires time code in both the time and profile 
modules, it would be necessary to move the hpTimer and hpTimerUnit 
functions to some place inside the Python core accessible for the time 
and profile modules.  Perhaps to a new file, say Python/gethptime.c.

That new file can handle other platform-specific idiosyncrasies with 
respect to hires time.  In particular, it could implement a different 
(and better) way to determine the resolution of a hires tick, e.g. on 
Linux and BSD Unix.

----------

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

From report at bugs.python.org  Mon Jun  1 01:46:01 2009
From: report at bugs.python.org (Yonas)
Date: Sun, 31 May 2009 23:46:01 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1243813561.12.0.872933215074.issue1731717@psf.upfronthosting.co.za>


Yonas <yonas.y at gmail.com> added the comment:

I'm assuming that exim4 is reading config files from /etc/exim4/conf.d/*.

To make sure, you can enforce "split file mode" by running `sudo
dpkg-reconfigure exim4-config`. It should be one of the last questions
present to you.

----------

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

From report at bugs.python.org  Mon Jun  1 01:50:45 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 31 May 2009 23:50:45 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1243813845.49.0.43338996969.issue2919@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

I just added another comment about the high-resolution timer in <http://bugs.python.org/issue2281>.

----------

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

From report at bugs.python.org  Mon Jun  1 02:17:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 00:17:04 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1243815424.74.0.90608531796.issue1731717@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm afraid I'm not going to be installing exim in order to test this. 
Perhaps someone else will be interested enough to do so, perhaps not :)

Copying files into /usr/lib/pythonx.x is a very odd thing to do, by the
way (though it should have no impact on the bug).

----------
priority: critical -> normal
status: open -> pending

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

From report at bugs.python.org  Mon Jun  1 02:44:33 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 00:44:33 +0000
Subject: [issue6158] test_aifc failing on 32bit windows in python 3.1 rc 1
In-Reply-To: <1243809136.07.0.631093381949.issue6158@psf.upfronthosting.co.za>
Message-ID: <1243817073.12.0.585998236651.issue6158@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm the one who added that file.  I can see by analogy to, eg,
audiotest.au that it needs to go in Tools/msi/msi.py (patch for trunk
attached), but I don't know if anything else is needed.

----------
keywords: +patch
nosy: +r.david.murray
Added file: http://bugs.python.org/file14135/issue6158.patch

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

From report at bugs.python.org  Mon Jun  1 03:00:29 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 01:00:29 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243818029.33.0.786659602155.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

I've written a patch.
Hope you like it :)

----------
keywords: +patch
nosy: +conf
Added file: http://bugs.python.org/file14136/pydocs.diff

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

From report at bugs.python.org  Mon Jun  1 03:20:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 01:20:44 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243819244.42.0.715613097939.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks :)

PEP 8 recommends spaces after commas in a list.

Also, we should have a unit tests before we commit the fix.  If you feel
like writing them that would be most welcome.

----------
components: +Library (Lib)
nosy: +r.david.murray
stage: needs patch -> test needed
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jun  1 03:34:50 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 01:34:50 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243820090.52.0.86912600293.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

The same patch with whitespaces. Is it ok now?

----------
Added file: http://bugs.python.org/file14137/pydocs.diff

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

From report at bugs.python.org  Mon Jun  1 03:35:02 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 01:35:02 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243820102.78.0.477647406062.issue5230@psf.upfronthosting.co.za>


Changes by Lucas Prado Melo <lukepadawan at gmail.com>:


Removed file: http://bugs.python.org/file14136/pydocs.diff

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

From report at bugs.python.org  Mon Jun  1 03:49:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 01:49:01 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243820941.1.0.874331176935.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are still missing a space between 'module' and 'named' ;)

----------

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

From report at bugs.python.org  Mon Jun  1 04:10:56 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 02:10:56 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243822256.39.0.133730607724.issue5230@psf.upfronthosting.co.za>


Changes by Lucas Prado Melo <lukepadawan at gmail.com>:


Removed file: http://bugs.python.org/file14137/pydocs.diff

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

From report at bugs.python.org  Mon Jun  1 04:10:39 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 02:10:39 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243822239.8.0.88742533781.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

A new patch with an unit test and with whitespaces.

----------
Added file: http://bugs.python.org/file14138/pydocs.diff

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

From report at bugs.python.org  Mon Jun  1 04:43:04 2009
From: report at bugs.python.org (Alex James)
Date: Mon, 01 Jun 2009 02:43:04 +0000
Subject: [issue6147] multithreading.Pool.map() crashes Windows computer
In-Reply-To: <1243641888.16.0.0893563302083.issue6147@psf.upfronthosting.co.za>
Message-ID: <1243824184.67.0.677450408875.issue6147@psf.upfronthosting.co.za>


Alex James <ac.james at shaw.ca> added the comment:

Ok Jesse, that did stop the bomb problem.  
Unfortunately the real code belongs in a scientific research
distributable module that is called by another function in the module
where both have been imported into the script that is run.  So it isn't
being called by __main__ in the first place.  So we'll have to make sure
client scripts are encapsulated with the if __name__ == '__main__' by
our collegues running windows.  Aka I expect to recieve this same bug
report.  
I'll go through the docs again, but I didn't find any built-in way to
get the recursion level of an operation (other than the 0 = __main__
level).    

Looking like this just turned into a feature request.

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

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

From report at bugs.python.org  Mon Jun  1 05:05:39 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Jun 2009 03:05:39 +0000
Subject: [issue6147] multithreading.Pool.map() crashes Windows computer
In-Reply-To: <1243641888.16.0.0893563302083.issue6147@psf.upfronthosting.co.za>
Message-ID: <1243825539.65.0.636829278521.issue6147@psf.upfronthosting.co.za>


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

Hey Alex; This isn't a bug, or a feature request. On win32, the way 
multiprocessing fakes a fork() is by creating a special subprocess which 
essentially imports and executes the function/process to be run, 
communication is handled through pickling and pipes.

For more information, see:
http://svn.python.org/view/python/trunk/Lib/multiprocessing/forking.py?
view=markup

Search for "# Windows" in that file, you'll see the basic process we use 
to "fork" on windows. Without a completely different implementation, 
this can not be changed. This probably will not change for some time, as 
such, I'm going to close this issue.

----------
resolution:  -> wont fix

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

From report at bugs.python.org  Mon Jun  1 05:09:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Jun 2009 03:09:25 +0000
Subject: [issue6147] multithreading.Pool.map() crashes Windows computer
In-Reply-To: <1243641888.16.0.0893563302083.issue6147@psf.upfronthosting.co.za>
Message-ID: <1243825765.05.0.645212608533.issue6147@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Mon Jun  1 05:11:35 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Jun 2009 03:11:35 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243825895.37.0.604660614371.issue6142@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> tarek
components: +Library (Lib)
nosy: +tarek
priority:  -> normal

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

From report at bugs.python.org  Mon Jun  1 05:22:10 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 01 Jun 2009 03:22:10 +0000
Subject: [issue6160] Tkinter.Spinbox: fix for bbox and removed some
	uninteresting returns
In-Reply-To: <1243826530.3.0.945381049334.issue6160@psf.upfronthosting.co.za>
Message-ID: <1243826530.3.0.945381049334.issue6160@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

The current bbox method for Tkinter.Spinbox is very likely to never
return a tuple. The attached patch uses _getints to always return a
tuple of integers.

The other changes in the patch are about removing unneeded return
statements.

----------
components: Tkinter
files: Spinbox_fixes.diff
keywords: patch
messages: 88634
nosy: gpolo
severity: normal
status: open
title: Tkinter.Spinbox: fix for bbox and removed some uninteresting returns
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14139/Spinbox_fixes.diff

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

From report at bugs.python.org  Mon Jun  1 06:20:20 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Jun 2009 04:20:20 +0000
Subject: [issue6158] test_aifc failing on 32bit windows in python 3.1 rc 1
In-Reply-To: <1243809136.07.0.631093381949.issue6158@psf.upfronthosting.co.za>
Message-ID: <1243830020.28.0.741393155082.issue6158@psf.upfronthosting.co.za>


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

Indeed, listing it in msi.py is all that needs to be done here. Fixed in
r73101, r73102, r73103, r73104, r73105.

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

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

From report at bugs.python.org  Mon Jun  1 06:23:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Jun 2009 04:23:29 +0000
Subject: [issue6150] test_unicode fails in wide unicode build
In-Reply-To: <1243716302.52.0.46548419038.issue6150@psf.upfronthosting.co.za>
Message-ID: <1243830209.83.0.741837649196.issue6150@psf.upfronthosting.co.za>


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

Thanks for the report. Fixed in r73106

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

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

From report at bugs.python.org  Mon Jun  1 12:09:13 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 01 Jun 2009 10:09:13 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243850953.44.0.513276539985.issue6142@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The clean command cleans up temporary files from 'build' command.

Your patch removes files that are not generated by the build command only
but by a normal usage of Python modules.

Why do you need to remove them precisely ?

----------
components: +Distutils -Library (Lib)
versions: +Python 2.7, Python 3.1 -Python 2.5

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

From report at bugs.python.org  Mon Jun  1 13:45:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 11:45:20 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243856720.82.0.944572115621.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  The unit tests don't pass, though, at least not when I apply
the patch to trunk.  I get three failures.  So the patch isn't correct
as it stands.  'path' is the full module path (test.i_am_not_here in the
case of one of the test failures), but what appears in the error message
is just the name of the module that wasn't found.

Also consider the case where the import is 'import some.nested.module',
and the module that isn't found is 'nested'.  In fact it may be worth
writing an additional test for that case.

Also I'd recommend renaming badimport_module.py pydoc_badimport.py so as
to be parallel to the other pydoc auxiliary test files.

----------

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

From report at bugs.python.org  Mon Jun  1 14:09:17 2009
From: report at bugs.python.org (Brodie Rao)
Date: Mon, 01 Jun 2009 12:09:17 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243858157.0.0.150010240347.issue6154@psf.upfronthosting.co.za>


Changes by Brodie Rao <junk at dackz.net>:


----------
nosy: +brodie

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

From report at bugs.python.org  Mon Jun  1 14:29:26 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 12:29:26 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243859366.57.0.132384434029.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Ok.
New patch that passes the unit tests and with a new unit test covering
inexistant nested modules.

----------
Added file: http://bugs.python.org/file14140/pydocs.diff

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

From report at bugs.python.org  Mon Jun  1 14:29:34 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 12:29:34 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243859374.49.0.873706815328.issue5230@psf.upfronthosting.co.za>


Changes by Lucas Prado Melo <lukepadawan at gmail.com>:


Removed file: http://bugs.python.org/file14138/pydocs.diff

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

From report at bugs.python.org  Mon Jun  1 14:36:12 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Mon, 01 Jun 2009 12:36:12 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1243859772.78.0.849277896436.issue6137@psf.upfronthosting.co.za>


Matthias Kievernagel <mkiever at web.de> added the comment:

Applied the patch
  http://bugs.python.org/file14124/compat_pickle.diff
to rev. 73106.
Patch applies fine, 'make test' passes
and it solves my problem.
(which is far from a complete test case though
 - only 5 small pickles)

Thanks,
Matthias Kievernagel

----------

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

From report at bugs.python.org  Mon Jun  1 14:40:46 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 12:40:46 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243860046.27.0.888029004006.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

by the way, I was not acquainted with this unit test thing... sorry

----------

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

From report at bugs.python.org  Mon Jun  1 15:11:48 2009
From: report at bugs.python.org (James)
Date: Mon, 01 Jun 2009 13:11:48 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243861908.47.0.4683049952.issue6142@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

Hi, the patch only removes them if one adds the --pyc option.
I think it is a good idea to have some option or target somewhere to
remove the types of files that can be regenerated because often
developers want to "get them out of the way". Example: I'll be working
on a project in my code directory, and it's nice to be able to do an "$
ls" without seeing extra files lying that clutter up the view. Perhaps
different people want to remove them for different reasons. I remember
searching for "remove .pyc" or something like it and it returned some
hits from other people wanting similar functionality. Thanks for your
time, I hope you include something like this patch in upstream.

_J

----------

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

From report at bugs.python.org  Mon Jun  1 15:37:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 13:37:23 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243863443.9.0.890946061602.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No need to apologize, and thank you for taking the time to learn this
stuff.  (Six months ago I didn't know how the python unit test suite
worked either...and I keep learning new things.)

For me your new test fails...and it isn't quite the one I had in mind.
The test fails because with your patch pydoc correctly reports that
there is no documentation for the non-existent temrinal module, while
your test is expecting it to report a missing module.

(This makes me wonder...is the existing behavior of pydoc optimal?  With
this patch in place would it be better to report that there is no such
module rather than that there is no documentation found?  But let's
ignore that issue for the moment since this patch is required even if we
were to change that message.)

The test I had in mind would be a file pydoc_badimport2.py containing:

    import test.i_dont_exist.neither_do_i

In that case, your patch will fail, because the error message will
report that "i_dont_exist" can't be found.

It's funny how these seemingly simple things turn out to be not quite so
simple.  Perhaps we could extract the last token (the module name) from
the error message, and only do the "no doc" message if it is equal to
the last element of the path name.

----------

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

From report at bugs.python.org  Mon Jun  1 15:43:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 13:43:27 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243863807.75.0.577928084978.issue6142@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It seems to me that this functionality is similar to what a 'distclean'
target would do in a typical makefile.  Don't know if that perspective
helps any :)

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Jun  1 16:32:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jun 2009 14:32:08 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243866728.26.0.569579886044.issue6142@psf.upfronthosting.co.za>


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

I don't think distutils should host whetever functionality useful to
developers. Distutils is for packaging and distributing Python software.

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

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

From report at bugs.python.org  Mon Jun  1 17:54:04 2009
From: report at bugs.python.org (Mykola Kharechko)
Date: Mon, 01 Jun 2009 15:54:04 +0000
Subject: [issue6156] Error compiling valid regex
In-Reply-To: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>
Message-ID: <1243871644.8.0.951262872561.issue6156@psf.upfronthosting.co.za>


Mykola Kharechko <crchemist at gmail.com> added the comment:

tests for this issue.

----------
keywords: +patch
nosy: +crchemist
Added file: http://bugs.python.org/file14141/test_re.py.patch

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

From report at bugs.python.org  Mon Jun  1 17:57:39 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 01 Jun 2009 15:57:39 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243871859.92.0.36953471336.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

I didn't understand what you mean: what should be shown when pydoc tries
to generate documentation for a module with the bad import 'import
test.i_dont_exist.neither_do_i'?
I am not a native english speaker, so please excuse me if you don't
understand something I've written or the other way around.

----------

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

From report at bugs.python.org  Mon Jun  1 17:59:28 2009
From: report at bugs.python.org (Guthur)
Date: Mon, 01 Jun 2009 15:59:28 +0000
Subject: [issue6161] HTTPResponse not storing response body
In-Reply-To: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>
Message-ID: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>


New submission from Guthur <guthur at hotmail.com>:

HTTPResponse does not store the HTTP response body while it does store 
the response headers, which in my opinion makes it rather useless as a 
HTTP response abstraction object. 

The only way to obtain the response body is to call HTTPResponse.Read
([amt]) and store the body seperately, this must also be carried out 
before the connection is closed, which makes no sense as the server 
serves both HEADERs and BODY together.

I can think of no real reason why this should be the case HTTP already 
provides a method for receiving just the headers with the HEAD request 
type.

Keynotes: HTTPResponse should store the body, if received, as well as 
the headers.

----------
components: Library (Lib)
messages: 88648
nosy: Guthur
severity: normal
status: open
title: HTTPResponse not storing response body
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun  1 17:59:38 2009
From: report at bugs.python.org (Mykola Kharechko)
Date: Mon, 01 Jun 2009 15:59:38 +0000
Subject: [issue6156] Error compiling valid regex
In-Reply-To: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>
Message-ID: <1243871978.43.0.983951430871.issue6156@psf.upfronthosting.co.za>


Mykola Kharechko <crchemist at gmail.com> added the comment:

patch that fix this

----------
Added file: http://bugs.python.org/file14142/sre_compile.py.patch

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

From report at bugs.python.org  Mon Jun  1 18:01:33 2009
From: report at bugs.python.org (Mark Florisson)
Date: Mon, 01 Jun 2009 16:01:33 +0000
Subject: [issue6162] What should happen to signals when the main thread dies?
In-Reply-To: <1243872093.9.0.639774045025.issue6162@psf.upfronthosting.co.za>
Message-ID: <1243872093.9.0.639774045025.issue6162@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

As signals are only delivered to the main thread, what should happen
when the main thread dies? Currently, the signal mask is not unset in
any other thread, so when the main thread dies, all signals set in the
mask are simply ignored. Perhaps an other thread could be selected as
the main thread?

The accompanied file demonstrates this behavior.

----------
components: Interpreter Core
files: ignore_signals.py
messages: 88650
nosy: eggy
severity: normal
status: open
title: What should happen to signals when the main thread dies?
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14143/ignore_signals.py

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

From report at bugs.python.org  Mon Jun  1 18:07:43 2009
From: report at bugs.python.org (James)
Date: Mon, 01 Jun 2009 16:07:43 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243872463.36.0.573063957565.issue6142@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

I could agree with R. David Murray, and I think that it's fine that this
be included under a dist clean command.
Ultimately I'm writing an application and I'm trying to use distutils
with it. I'll potentially run a: "$ setup.py build_ext -i" or whatever
it may be, and then I'll want to get rid of all the mess. So I'll want
to run a clean. If that clean won't get rid of .pyc for me in one
command, then i have to run a second shell script to clean my dir,
instead of sticking the two together. Which is why i think a clean --pyc
option is useful (off by default) and which I can easily enable in
setup.cfg with [clean] pyc=1
I think this is harmless. Anyone agree?

thanks!
_J

----------

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

From report at bugs.python.org  Mon Jun  1 18:11:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jun 2009 16:11:50 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243872463.36.0.573063957565.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243872843.5319.2.camel@localhost>


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

I'm not sure why you call it a "mess". Generating a pyc file is the
normal way of operating when importing a Python module from source. It's
not just distutils.

And the fact that it's "harmless" does not justify adding a distutils
option for something which doesn't seem to have anything to do with
distutils...

----------

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

From report at bugs.python.org  Mon Jun  1 18:39:18 2009
From: report at bugs.python.org (Clay McClure)
Date: Mon, 01 Jun 2009 16:39:18 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1243874358.68.0.0596239737622.issue3959@psf.upfronthosting.co.za>


Clay McClure <clay at daemons.net> added the comment:

Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late 
to
continue this discussion. I have no vested interest in either ipaddr or
netaddr, but I am interested in seeing a well-designed and usable IP 
address
library included in the stdlib.

>From reading the comments in this issue, it seems most of the discussion
focused on netaddr's API. There seems to have been little discussion 
about
the merits of ipaddr's API, which is unfortunate given that ipaddr is 
the
library being included in the stdlib. There was some technical 
discussion on
the ipaddr and netaddr lists, but it amounted to each developer 
defending his
library, and neither party seemed willing to compromise on key design
decisions. At the end of the reconciliation period, ipaddr looks much 
the
same as it did before, albeit with prettier indentation.

When looking for an IP address library for use in a network scanning and
discovery application I wrote last year, I decided against ipaddr 
because of
its conflation of address and network -- it seems strange to me to have 
one
class modeling both concepts.

After reading the technical discussion on the ipaddr and netaddr lists, 
it is
clear to me that ipaddr's designers have a somewhat limited 
understanding of
IP addressing, and have not designed an API that articulates IP concepts
particularly well. For example, see pmoody's earlier comments in this 
ticket:

> all addresses have a subnet, even if its an implied /32

This is not only incorrect, but it demonstrates a deep misunderstanding 
of
how IP works. IP addresses most certainly do not have a "subnet", or a 
mask
of any sort. An IPv4 address is simply a 32-bit number.

IPv4 *networks* have masks, of course, hence the name "netmask". These
network masks are used by the routing process to lookup the next hop (or
directly connected network) for an IP datagram by matching the 
datagram's
destination address against the networks and masks defined in the 
routing
table.

> specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
> off-putting than "1.1.1.0/24".

Since networks are commonly represented in at least three forms, the API
should support at least these:

CIDR/prefix notation: "192.168.1.0/24"
address+mask notation: "192.168.1.0/255.255.255.0"
range notation: "192.168.1.0-192.168.1.255"

> I guess I don't see the utility in an address range of .1 - .22 
> (or something arbitrary, something which doesn't fall on a power-of-2
> boundary); when dealing with ranges of addresses, i've always only 
> wanted to/needed to manipulate sub-networks of addresses.

This statement demonstrates an extremely narrow view of the problem 
domain.
Access lists and DHCP pools are two common examples of where arbitrary
address ranges are useful.

At least three concepts deserve first-class treatment in any meaningful 
IP
address library:

* addresses
* ranges of addresses
* networks

To conflate these is a mistake.

My hope is that now that a library has been selected, it can be improved 
before Python 2.7 and 3.1 ship. Now is the best time to make
backwards-incompatible API changes; once ipaddr ships with the stdlib, 
we're
stuck with it. If it remains as-is, it will be deadweight for those app
developers like myself who prefer an API that more accurately reflects 
the
problem domain.

To this end, now that ipaddr is moving to Python stdlib, will Google's
contributor license agreement restriction be lifted? I would like to
contribute, but have not been able to secure a corporate CLA from my
employer.

Cheers,

Clay

----------
nosy: +claymation

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

From report at bugs.python.org  Mon Jun  1 18:57:49 2009
From: report at bugs.python.org (Guthur)
Date: Mon, 01 Jun 2009 16:57:49 +0000
Subject: [issue6161] httplib: HTTPResponse not storing response body
In-Reply-To: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>
Message-ID: <1243875469.71.0.935850909094.issue6161@psf.upfronthosting.co.za>


Changes by Guthur <guthur at hotmail.com>:


----------
title: HTTPResponse not storing response body -> httplib: HTTPResponse not storing response body

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

From report at bugs.python.org  Mon Jun  1 19:00:52 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 01 Jun 2009 17:00:52 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1243874358.68.0.0596239737622.issue3959@psf.upfronthosting.co.za>
Message-ID: <52dc1c820906011000s6df94269hb6495c6c93a0ccc7@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

On Mon, Jun 1, 2009 at 9:39 AM, Clay McClure <report at bugs.python.org> wrote:
>
> Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late
> to continue this discussion. I have no vested interest in either ipaddr or
> netaddr, but I am interested in seeing a well-designed and usable IP
> address library included in the stdlib.

Python 3.1 is as good as shipped.  It is in the release candidate
stage which means no code changes other than bug fixes can go in.

Improvements will have to wait for 2.7 and 3.2.  In the mean time I
suggest writing up improvements as either subclasses of the existing
ipaddr module (so that they can be used both with this standalone
project and with the version shipped in python 3.1).

>> specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
>> off-putting than "1.1.1.0/24".
>
> Since networks are commonly represented in at least three forms, the API
> should support at least these:
>
> CIDR/prefix notation: "192.168.1.0/24"
> address+mask notation: "192.168.1.0/255.255.255.0"
> range notation: "192.168.1.0-192.168.1.255"

I think range notation parsing could be implemented pretty easily.

> Access lists and DHCP pools are two common examples of where arbitrary
> address ranges are useful.
>
> At least three concepts deserve first-class treatment in any meaningful
> IP address library:
>
> * addresses
> * ranges of addresses
> * networks
>
> To conflate these is a mistake.
>
> My hope is that now that a library has been selected, it can be improved
> before Python 2.7 and 3.1 ship. Now is the best time to make
> backwards-incompatible API changes; once ipaddr ships with the stdlib,
> we're stuck with it. If it remains as-is, it will be deadweight for those app
> developers like myself who prefer an API that more accurately reflects
> the problem domain.

Too late for 3.1.  But I see no reason for the existing API to be
considered bad.  There is always room for improvement.  I believe you
could add support for network address ranges on top of it without too
much difficulty.

Subclass the existing classes and inherit from a mixin that keeps
track of a start and end of range and extends the 'in' operator to
check if the comparison address is >= and <= the start and end
addresses.

> To this end, now that ipaddr is moving to Python stdlib, will Google's
> contributor license agreement restriction be lifted? I would like to
> contribute, but have not been able to secure a corporate CLA from my
> employer.

You can sign a Python Software Foundation contributor agreement
instead.  http://www.python.org/psf/contrib/contrib-form/  We've been
a bit relaxed on requiring these from people at times but it is a good
thing to do for Python's sake.

No Google CLA will ever be required to make changes to anything in the
python project itself.

----------

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

From report at bugs.python.org  Mon Jun  1 19:09:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Jun 2009 17:09:21 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1243874358.68.0.0596239737622.issue3959@psf.upfronthosting.co.za>
Message-ID: <4A240B3E.5070408@v.loewis.de>


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

> My hope is that now that a library has been selected, it can be improved 
> before Python 2.7 and 3.1 ship.

That is fairly unlikely. The 3.1 release candidate has been produced,
so the only options possible at this point are to either go ahead with
what is in the code, or withdraw the library from 3.1 if it can be
demonstrated to have severe flaws.

----------

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

From report at bugs.python.org  Mon Jun  1 19:13:50 2009
From: report at bugs.python.org (Mykola Kharechko)
Date: Mon, 01 Jun 2009 17:13:50 +0000
Subject: [issue6161] httplib: HTTPResponse not storing response body
In-Reply-To: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>
Message-ID: <1243876430.25.0.960476698324.issue6161@psf.upfronthosting.co.za>


Mykola Kharechko <crchemist at gmail.com> added the comment:

HTTPResponse can't store body because it can be huge (some film or
something else).

----------
nosy: +crchemist

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

From report at bugs.python.org  Mon Jun  1 19:20:59 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 01 Jun 2009 17:20:59 +0000
Subject: [issue6163] [HP-UX] ld: Unrecognized argument: +s -L<dir>
In-Reply-To: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>
Message-ID: <1243876859.78.0.253879711884.issue6163@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

this is also applicable to 3.1 (albeit the source is slightly changed)

Return a *list* of options otherwise these may be improperly interpreted as
one option with an embedded space. On /usr/bin/ld on a HP-UX/IA64 box this
results in:
    ld: Unrecognized argument: +s -L<dir>

----------
assignee: tarek
components: Distutils
files: distutils_hpux_libdir_option.patch
keywords: patch
messages: 88657
nosy: srid, tarek, trentm
severity: normal
status: open
title: [HP-UX] ld: Unrecognized argument: +s -L<dir>
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14144/distutils_hpux_libdir_option.patch

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

From report at bugs.python.org  Mon Jun  1 19:22:38 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 01 Jun 2009 17:22:38 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

This is being successfully used in ActivePython.

----------
assignee: tarek
components: Distutils
files: distutils_aix_blibpath.patch
keywords: patch
messages: 88658
nosy: srid, tarek, trentm
severity: normal
status: open
title: [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs'
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14145/distutils_aix_blibpath.patch

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

From report at bugs.python.org  Mon Jun  1 19:38:21 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 01 Jun 2009 17:38:21 +0000
Subject: [issue6165] strftime incorrectly processes DST flag when passed time
	touples
In-Reply-To: <1243877901.36.0.141304844828.issue6165@psf.upfronthosting.co.za>
Message-ID: <1243877901.36.0.141304844828.issue6165@psf.upfronthosting.co.za>


New submission from Jonathan <jonathan.cervidae at gmail.com>:

>>> import time
>>> time.strftime("%FT%T%z")
'2009-06-01T18:35:42+0100'
>>> # Expect to see +0100
>>> time.strftime("%FT%T%z",time.localtime())
'2009-06-01T18:35:42+0000'
>>> time.strftime("%FT%T%Z",time.localtime())
'2009-06-01T18:35:42BST'
>>> made_up_time = list(time.localtime())
>>> made_up_time
[2009, 6, 1, 18, 35, 48, 0, 152, 1]
>>> made_up_time[1] = 2
>>> made_up_time=tuple(made_up_time)
>>> time.strftime("%FT%T%z",made_up_time)
'2009-02-01T18:35:48+0000'
>>> # Expect to see GMT or UTC, whatever strftime wants to call it.
>>> time.strftime("%FT%T%Z",made_up_time)
'2009-02-01T18:35:48BST'
>>>

----------
components: Extension Modules
messages: 88659
nosy: jonathan.cervidae
severity: normal
status: open
title: strftime incorrectly processes DST flag when passed time touples
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun  1 19:39:59 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 01 Jun 2009 17:39:59 +0000
Subject: [issue6165] strftime incorrectly processes DST flag when passed time
	touples
In-Reply-To: <1243877901.36.0.141304844828.issue6165@psf.upfronthosting.co.za>
Message-ID: <1243877999.34.0.894517791339.issue6165@psf.upfronthosting.co.za>


Jonathan <jonathan.cervidae at gmail.com> added the comment:

Actually, I didn't change the DST flag in the second test, the second
commented bug is invalid, only the first one is correct.

----------

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

From report at bugs.python.org  Mon Jun  1 19:53:27 2009
From: report at bugs.python.org (Jonathan)
Date: Mon, 01 Jun 2009 17:53:27 +0000
Subject: [issue6165] strftime incorrectly processes DST flag when passed time
	touples
In-Reply-To: <1243877901.36.0.141304844828.issue6165@psf.upfronthosting.co.za>
Message-ID: <1243878807.6.0.994219655627.issue6165@psf.upfronthosting.co.za>


Jonathan <jonathan.cervidae at gmail.com> added the comment:

kludged_zone = ("+" if time.altzone < 0 else '-') +
time.strftime("%H%M",time.gmtime(abs(time.altzone)))
time_zone_format_string = time_zone_format.replace("%z", kludged_zone)

----------

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

From report at bugs.python.org  Mon Jun  1 20:01:49 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 01 Jun 2009 18:01:49 +0000
Subject: [issue6156] Error compiling valid regex
In-Reply-To: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>
Message-ID: <1243879309.95.0.908205874571.issue6156@psf.upfronthosting.co.za>


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

Just taking out the "raise" seems questionable to me; are you sure there
are no valid errors that can be caught there?

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Mon Jun  1 20:23:55 2009
From: report at bugs.python.org (Guthur)
Date: Mon, 01 Jun 2009 18:23:55 +0000
Subject: [issue6161] httplib: HTTPResponse not storing response body
In-Reply-To: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>
Message-ID: <1243880635.0.0.414262815091.issue6161@psf.upfronthosting.co.za>


Guthur <guthur at hotmail.com> added the comment:

But it must be somewhere, you don't make a seperate request to the 
server for the body, you just make the single HTTP request and the 
server serves that request.

Also this is surely aimed at developers, we can make the decision 
whether or not it is too large, and simply to, by making a HEAD request 
and checking the content-length header, and if its not available then 
don't continue with the request if we chose to take that action.

The point is that with out a body its not a HTTP response.

Admittedly some sort of streaming to file facility might be needed for 
the large requests, and that may require a significant effort to add.

Even if this can not be changed I think it should be clearly stated in 
the documentation that the request body needs to be explicitly read; I 
was trying to access it after making my request but of course it wasn't 
available, but the headers were and all status pointed to the request 
being served, which was rather confusing.

Thanks for the reply

----------

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

From report at bugs.python.org  Mon Jun  1 20:32:27 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 01 Jun 2009 18:32:27 +0000
Subject: [issue6166] encoding error for 'setup.py --author' when read via
	subprocess pipe
In-Reply-To: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>
Message-ID: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I ran 'python setup.py --author' for the pypi package "ll-orasql-0.6"
(whose author name has non-ascii characters) under subprocess.Popen and
this is what I get:

Traceback (most recent call last):
  File "/home/sridharr/as/pypm/bin/python", line 39, in <module>
    execfile(sys.argv[0])
  File "setup.py", line 50, in <module>
    package_dir={"ll": ""}
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/core.py", line
138, in setup
    ok = dist.parse_command_line()
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
456, in parse_command_line
    if self.handle_display_options(option_order):
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
704, in handle_display_options
    print value
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in
position 8: ordinal not in range(128)

When ran under the console, this exception is not seen. Otherwise, the
return code is 1 and nothing (apart from the above exception) is printed.

How to reproduce?
=================

Download `ll-orasql-0.6` from PyPI and run the following in the Python
shell:

>>> subprocess.Popen('python setup.py --author', stdout=subprocess.PIPE,
shell=True).stdout.read()

----------
assignee: tarek
components: Distutils
messages: 88664
nosy: srid, tarek
severity: normal
status: open
title: encoding error for 'setup.py --author' when read via subprocess pipe
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun  1 20:47:52 2009
From: report at bugs.python.org (James)
Date: Mon, 01 Jun 2009 18:47:52 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243882072.92.0.955907987278.issue6142@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

ps: included is a platform independent version of the code, so that it
doesn't depend on os.system() specific commands.

HTH,
_J

----------
Added file: http://bugs.python.org/file14146/clean.py.patch

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

From report at bugs.python.org  Mon Jun  1 20:56:26 2009
From: report at bugs.python.org (James)
Date: Mon, 01 Jun 2009 18:56:26 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243882586.13.0.629004085749.issue6142@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

Antoine: Okay sorry not a mess then.
I just figure that if i'm using the distutils tool for doing all the fun
things to my local source directory that I potentially used to do with
say a makefile, then would it not be beneficial to have a useful
-option- (as included in the patch). It won't affect any previous
distutils setups, and can only benefit future users. Why not?

_J

----------

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

From report at bugs.python.org  Mon Jun  1 21:35:05 2009
From: report at bugs.python.org (Mykola Kharechko)
Date: Mon, 01 Jun 2009 19:35:05 +0000
Subject: [issue6156] Error compiling valid regex
In-Reply-To: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>
Message-ID: <1243884905.82.0.151687801311.issue6156@psf.upfronthosting.co.za>


Mykola Kharechko <crchemist at gmail.com> added the comment:

> are you sure there are no valid errors that can be caught there?
Sorry, No. See
http://svn.python.org/view/python/trunk/Lib/sre_compile.py?r1=17949&r2=17948&pathrev=17949
and http://osdir.com/ml/python.bugs/2000-10/msg00010.html links.

----------

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

From report at bugs.python.org  Mon Jun  1 21:36:41 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 01 Jun 2009 19:36:41 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243885001.91.0.0516799548466.issue6142@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The only reason I would see to clean .pyc file in distutils clean
command is if the build command (or any other command) would generate
them in the source tree, which is not the case.

That said, build_ext -i *does* create .so files in the source tree, so
we should provide a way to remove them I think.

----------

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

From report at bugs.python.org  Mon Jun  1 22:06:00 2009
From: report at bugs.python.org (Fergus Henderson)
Date: Mon, 01 Jun 2009 20:06:00 +0000
Subject: [issue967161] pty.spawn() enhancements
Message-ID: <1243886760.22.0.113851355585.issue967161@psf.upfronthosting.co.za>


Fergus Henderson <fergus.henderson at gmail.com> added the comment:

#1 is a duplicate of issue 2489 <http://bugs.python.org/issue2489>,
which has a patch attached.

According to the other discussion in this thread, #2 was a misunderstanding.

So I think we could close this bug as a duplicate.

----------
nosy: +fergushenderson

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

From report at bugs.python.org  Mon Jun  1 22:11:32 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 01 Jun 2009 20:11:32 +0000
Subject: [issue6167] Tkinter.Scrollbar: the activate method needs to return a
	value, and set should take only two args
In-Reply-To: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za>
Message-ID: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Hi,

I've noticed some minor problems in Tkinter.Scrollbar that would be good
to be addressed. The activate method never returns a value and it also
doesn't accept to be called without an element -- which is accepted by
tcl. When an element is not especified, the current active element
should be returned. It's signature is also a bit strange, I don't see
why it has a parameter named "index" while it never takes an index but
an element.

The second problem is about the set method. It accepts any amount of
arguments, but it only needs to accept two. Passing a tuple in the form
of (number, number) to it isn't accepted, so I don't see much reason to
continue with an *args there.

----------
components: Tkinter
files: Scrollbar_fixes.diff
keywords: patch
messages: 88670
nosy: gpolo
severity: normal
status: open
title: Tkinter.Scrollbar: the activate method needs to return a value, and set should take only two args
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14147/Scrollbar_fixes.diff

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

From report at bugs.python.org  Mon Jun  1 22:12:16 2009
From: report at bugs.python.org (Petr Splichal)
Date: Mon, 01 Jun 2009 20:12:16 +0000
Subject: [issue2489] Patch for bugs in pty.py
In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
Message-ID: <1243887136.74.0.71861102876.issue2489@psf.upfronthosting.co.za>


Changes by Petr Splichal <psssssss at gmail.com>:


----------
nosy: +psss

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

From report at bugs.python.org  Mon Jun  1 22:19:56 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 20:19:56 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243887596.33.0.870414615578.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It should generate:

  problem in pydoc_badimport2 - <type 'exceptions.ImportError'>: No
module named i_dont_exist"

If you'd like I can do the final fixup and apply the patch.  I'm happy
to let you get it working if you want, though, and I appreciate the work
you've done so far either way.

----------
stage: test needed -> patch review

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

From report at bugs.python.org  Mon Jun  1 22:33:16 2009
From: report at bugs.python.org (Clay McClure)
Date: Mon, 01 Jun 2009 20:33:16 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <4A240B3E.5070408@v.loewis.de>
Message-ID: <8657ee3f0906011333p28c10403p803ba5dcda563442@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Mon, Jun 1, 2009 at 1:09 PM, Martin v. L?wis <report at bugs.python.org> wrote:

>> My hope is that now that a library has been selected, it can be improved
>> before Python 2.7 and 3.1 ship.
>
> That is fairly unlikely. The 3.1 release candidate has been produced,
> so the only options possible at this point are to either go ahead with
> what is in the code, or withdraw the library from 3.1 if it can be
> demonstrated to have severe flaws.

False
>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
True

ipaddr makes no distinction between two fundamentally different
concepts -- to my mind, that is a serious flaw.

ipaddr has many other quirks that, while not technically flaws, are
design warts that deserve to be fixed before its target audience is
amplified by its inclusion in the stdlib.

To those arguing for ipaddr's inclusion in the stdlib, how many of you
will actually use ipaddr to develop software? As an actual developer
of network scanning and discovery software, I can tell you that I
would rather roll my own library than use ipaddr as it exists today.

Clay

----------

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

From report at bugs.python.org  Mon Jun  1 22:41:46 2009
From: report at bugs.python.org (Clay McClure)
Date: Mon, 01 Jun 2009 20:41:46 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1243888906.61.0.20804574968.issue3959@psf.upfronthosting.co.za>


Clay McClure <clay at daemons.net> added the comment:

Strangely, the leading line of my last response was eaten by the bug 
tracker. It read:

>>> 1 == (1,)

----------

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

From report at bugs.python.org  Mon Jun  1 22:41:49 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 01 Jun 2009 20:41:49 +0000
Subject: [issue6166] encoding error for 'setup.py --author' when read via
	subprocess pipe
In-Reply-To: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>
Message-ID: <1243888909.28.0.00108155484758.issue6166@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This is not a bug in distutils, but how print works when executed
through subprocess. 

here's a demo:

Create a file called "test.py" with:

  # -*- coding: utf8 -*-
  print u'????'

Now another one called "test2.py" with:

  import subprocess

  subprocess.Popen('python test.py', stdout=subprocess.PIPE,
shell=True).stdout.read()

Now launch test2:

  $ python test2.py 
  Traceback (most recent call last):
  File "test.py", line 2, in <module>
    print u'????'
  UnicodeEncodeError: 'ascii' codec can't encode characters in position 
0-3: ordinal not in range(128)

I don't know about the internals of print, and I am not sure this is a
bug, so I'll put Marc-Andr? in the loop.

----------
assignee: tarek -> 
components: +Unicode -Distutils
nosy: +lemburg

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

From report at bugs.python.org  Mon Jun  1 22:51:30 2009
From: report at bugs.python.org (pmoody)
Date: Mon, 01 Jun 2009 20:51:30 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011333p28c10403p803ba5dcda563442@mail.gmail.com>
Message-ID: <8517e9350906011351v53086feo30c43efde3b4dfe6@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

On Mon, Jun 1, 2009 at 1:33 PM, Clay McClure <report at bugs.python.org> wrote:
>
> Clay McClure <clay at daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 1:09 PM, Martin v. L?wis <report at bugs.python.org> wrote:
>
>>> My hope is that now that a library has been selected, it can be improved
>>> before Python 2.7 and 3.1 ship.
>>
>> That is fairly unlikely. The 3.1 release candidate has been produced,
>> so the only options possible at this point are to either go ahead with
>> what is in the code, or withdraw the library from 3.1 if it can be
>> demonstrated to have severe flaws.
>
> False
>>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True
>
> ipaddr makes no distinction between two fundamentally different
> concepts -- to my mind, that is a serious flaw.

I don't see these a fundamentally different, I guess.  can you
demonstrate how this equivalency makes ipaddr unusable?

> ipaddr has many other quirks that, while not technically flaws, are
> design warts that deserve to be fixed before its target audience is
> amplified by its inclusion in the stdlib.

I haven't seen any new issues on code.google.com (and I haven't heard
of any being reported on the python bugtracker), so since you're using
this thread to report issues, can you elaborate?

> To those arguing for ipaddr's inclusion in the stdlib, how many of you
> will actually use ipaddr to develop software? As an actual developer
> of network scanning and discovery software, I can tell you that I
> would rather roll my own library than use ipaddr as it exists today.

have used it to develop software and will continue to use it to
develop software.

Cheers,
/peter

> Clay
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3959>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jun  1 22:54:55 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Jun 2009 20:54:55 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011333p28c10403p803ba5dcda563442@mail.gmail.com>
Message-ID: <4A24401B.7080901@v.loewis.de>


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

> ipaddr makes no distinction between two fundamentally different
> concepts -- to my mind, that is a serious flaw.

Do you have an application in mind where this lack of distinction
would prevent writing the application in a straight-forward way?
IOW, could you do something if they were distinct that you can't
do because they are not?

----------

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

From report at bugs.python.org  Mon Jun  1 22:59:44 2009
From: report at bugs.python.org (Jason Gervich)
Date: Mon, 01 Jun 2009 20:59:44 +0000
Subject: [issue6168] Missing Shell menu in Linux IDLE
In-Reply-To: <1243889984.38.0.346185167721.issue6168@psf.upfronthosting.co.za>
Message-ID: <1243889984.38.0.346185167721.issue6168@psf.upfronthosting.co.za>


New submission from Jason Gervich <gervich at sbcglobal.net>:

The Shell menu is missing from the menu bar in the Edit Window of Ubuntu
Linux IDLE. It is described in the help but is not implemented. It is
there is the various windows versions I've seen.

Why is this missing and will it be fixed?

----------
components: IDLE
messages: 88677
nosy: sirgimp
severity: normal
status: open
title: Missing Shell menu in Linux IDLE
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Mon Jun  1 23:02:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 21:02:06 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011333p28c10403p803ba5dcda563442@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0906011642160.32513@kimball.webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True

As a network engineer I don't see any inherent problem with that equality.
In fact I make use of that conceptual equality on a regular basis.

Further, if you were to add a specifically 'address-without-netmask'
type, the above equality would still be true, because then the above
would be comparing two addresses-with-netmasks and you would want to
apply the hostmask to a bare address for convenience.  To get inequality,
you'd be comparing two different object types...which comparison would
be False by default.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Jun  1 23:16:54 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Jun 2009 21:16:54 +0000
Subject: [issue5735] Segfault when loading not recompiled module
In-Reply-To: <1239448122.29.0.383715698899.issue5735@psf.upfronthosting.co.za>
Message-ID: <1243891014.62.0.144242944693.issue5735@psf.upfronthosting.co.za>


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

Fixed with r73116

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

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

From report at bugs.python.org  Mon Jun  1 23:19:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Jun 2009 21:19:48 +0000
Subject: [issue6109] IDLE rendering issue with oriental characters on OSX
In-Reply-To: <1243320601.7.0.852822077156.issue6109@psf.upfronthosting.co.za>
Message-ID: <1243891188.52.0.255486192079.issue6109@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

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

From report at bugs.python.org  Mon Jun  1 23:31:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Jun 2009 21:31:53 +0000
Subject: [issue3022] mailbox module, two small fixes
In-Reply-To: <1212355773.67.0.369854949727.issue3022@psf.upfronthosting.co.za>
Message-ID: <1243891913.85.0.706296805986.issue3022@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The iteritems problem was fixed in r71046 from issue2625.  The tests in
mailbox.patch all pass at this point, though it doesn't look like the
line with blanks issue has been addressed in the code.

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Jun  2 00:09:44 2009
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 01 Jun 2009 22:09:44 +0000
Subject: [issue6168] Missing Shell menu in Linux IDLE
In-Reply-To: <1243889984.38.0.346185167721.issue6168@psf.upfronthosting.co.za>
Message-ID: <1243894184.95.0.808256385006.issue6168@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Running IDLE from the Applications menu under Ubuntu will not have the
Shell menu. If you bring up a terminal and enter "idle", you will have
the Shell menu.

IDLE, when selected from the Application menu, is being run with the
"-n" command line by default in Ubuntu. You can remove this option by
editing the menu item for IDLE.

----------
nosy: +serwy

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

From report at bugs.python.org  Tue Jun  2 00:23:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Jun 2009 22:23:56 +0000
Subject: [issue4547] Long jumps with frame_setlineno
In-Reply-To: <1228482308.72.0.125764742892.issue4547@psf.upfronthosting.co.za>
Message-ID: <1243895036.51.0.315494474673.issue4547@psf.upfronthosting.co.za>


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

Fixed with r73114 (trunk), r73117 (py3k), r73119 (2.6) and r73120 (3.0)

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

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

From report at bugs.python.org  Tue Jun  2 00:40:33 2009
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 01 Jun 2009 22:40:33 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1243896033.01.0.863791796742.issue6132@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/issue6132>
_______________________________________

From report at bugs.python.org  Tue Jun  2 00:52:02 2009
From: report at bugs.python.org (Fergus Henderson)
Date: Mon, 01 Jun 2009 22:52:02 +0000
Subject: [issue2489] Patch for bugs in pty.py
In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
Message-ID: <1243896722.07.0.748583957334.issue2489@psf.upfronthosting.co.za>


Fergus Henderson <fergus.henderson at gmail.com> added the comment:

The spawn change (the last hunk of the original patch) is a bug fix, not
an RFE.
It has two parts that fix two bugs:
  (1) a coding bug: spawn() would not wait for the invoked process to
finish.  This is fixed by the line that adds the call to os.waitpid().
  (2) a design bug: because previously spawn() didn't return a value,
there is no way to tell if the invoked process failed.  This is fixed by
the "return status" line.

Now I guess you can argue that (2) is an RFE.
But (1) is just a bug fix, not an RFE, IMHO.

Those are both separate from the other bug fixed in the patch:
  (3) Another coding bug: the bug in the _copy() loop that caused
    it to spin using 100% CPU rather than blocking

It's a little tricky to write a test of the _copy() loop bug, for
several reasons.
(a) There currently isn't any test for pty.spawn, apparently since
"Cannot do extensive 'do or fail' testing because pty code is not too
portable."
(b) Also, for this bug the symptom is just that the code spins (using
100% CPU, if available) rather than blocking.  It's difficult to detect
that situation using portable code.

I can maybe figure out how deal with (a), but I'm not sure how to
address (b), especially since I don't know the intended portability goals.

I will split the patch up into two patches, one of which addresses
(1)+(2), and the other of which addresses (3).

I have addressed Guilherme Polo's suggestion about using "if not data".

----------
Added file: http://bugs.python.org/file14148/pty.py.patch3

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

From report at bugs.python.org  Tue Jun  2 00:53:42 2009
From: report at bugs.python.org (Fergus Henderson)
Date: Mon, 01 Jun 2009 22:53:42 +0000
Subject: [issue2489] Patch for bugs in pty.py
In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za>
Message-ID: <1243896822.19.0.219003648455.issue2489@psf.upfronthosting.co.za>


Changes by Fergus Henderson <fergus.henderson at gmail.com>:


Added file: http://bugs.python.org/file14149/pty.py.patch2

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

From report at bugs.python.org  Tue Jun  2 01:11:53 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jun 2009 23:11:53 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1243897913.45.0.481341027976.issue6137@psf.upfronthosting.co.za>


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

Some comments on the patch:
- I don't understand why you create a static "twotuple" object rather
than simply using Py_BuildValue("(OO)", ...). Mutating tuples is bad.
- I don't think you need to call PyDict_Contains() before
PyDict_GetItem(). The latter will simply return NULL if the key isn't found.
- You should check whether the item fetched from the dictionary has the
right datatype (tuple for name_mapping, str for import_mapping). Anyone
can change (monkeypatch) _pickle_compat and make the interpreter crash.

----------

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

From report at bugs.python.org  Tue Jun  2 01:13:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Jun 2009 23:13:14 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1243897994.37.0.443821102576.issue6137@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib) -None
priority:  -> critical
type:  -> behavior

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

From report at bugs.python.org  Tue Jun  2 01:18:30 2009
From: report at bugs.python.org (Michael Shields)
Date: Mon, 01 Jun 2009 23:18:30 +0000
Subject: [issue6169] Important comparison bug in ipaddr
In-Reply-To: <1243898305.94.0.945300464283.issue6169@psf.upfronthosting.co.za>
Message-ID: <1243898305.94.0.945300464283.issue6169@psf.upfronthosting.co.za>


New submission from Michael Shields <shields at msrl.com>:

The open source version of ipaddr had an important comparison bug in 
which it was possible for x > y and x < y.  The fix for this should be 
applied to the Python standard library version as well.

http://code.google.com/p/ipaddr-py/source/detail?r=77

----------
components: Library (Lib)
messages: 88685
nosy: shields
severity: normal
status: open
title: Important comparison bug in ipaddr
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Jun  2 01:41:20 2009
From: report at bugs.python.org (Clay McClure)
Date: Mon, 01 Jun 2009 23:41:20 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <Pine.LNX.4.64.0906011642160.32513@kimball.webabinitio.net>
Message-ID: <8657ee3f0906011641n1fb547d0of55ba87e720effee@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray <report at bugs.python.org> wrote:

>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>> True
>
> As a network engineer I don't see any inherent problem with that equality.
> In fact I make use of that conceptual equality on a regular basis.

For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
than ifconfig:

# ifconfig en0 192.168.1.1/32
# ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
        ...

# ifconfig en0 192.168.1.1
# ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        ...

Can you provide an example of when 192.168.1.1 does in fact equal
192.168.1.1/32?

> Further, if you were to add a specifically 'address-without-netmask'
> type, the above equality would still be true, because then the above
> would be comparing two addresses-with-netmasks and you would want to
> apply the hostmask to a bare address for convenience. ?To get inequality,
> you'd be comparing two different object types...which comparison would
> be False by default.

I don't follow. Assuming hypothetical Address and Network classes, as
accurately models the problem domain, we would have:

False

That seems to me the correct behavior, since an address is in fact not
the same thing as a network.

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 01:42:15 2009
From: report at bugs.python.org (Guthur)
Date: Mon, 01 Jun 2009 23:42:15 +0000
Subject: [issue6161] httplib: HTTPResponse not storing response body
In-Reply-To: <1243871968.86.0.721781511059.issue6161@psf.upfronthosting.co.za>
Message-ID: <1243899735.37.0.943491556802.issue6161@psf.upfronthosting.co.za>


Changes by Guthur <guthur at hotmail.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Tue Jun  2 01:49:42 2009
From: report at bugs.python.org (Jason Gervich)
Date: Mon, 01 Jun 2009 23:49:42 +0000
Subject: [issue6168] Missing Shell menu in Linux IDLE
In-Reply-To: <1243894184.95.0.808256385006.issue6168@psf.upfronthosting.co.za>
Message-ID: <1243900174.6510.5.camel@jason-desktop>


Jason Gervich <gervich at sbcglobal.net> added the comment:

Thank you. I tried it from the command line and you are right. IDLE runs
with the Shell menu.

1.Do you know why this is being done in Ubuntu? That is, why are they
setting up the menu this way?

2. Is it a bug or a "feature?" Should be reported a an Ubuntu bug?

How do I edit the IDLE menu item?

Thanks again, 

Roger

On Mon, 2009-06-01 at 22:09 +0000, Roger Serwy wrote:

> Roger Serwy <roger.serwy at gmail.com> added the comment:
> 
> Running IDLE from the Applications menu under Ubuntu will not have the
> Shell menu. If you bring up a terminal and enter "idle", you will have
> the Shell menu.
> 
> IDLE, when selected from the Application menu, is being run with the
> "-n" command line by default in Ubuntu. You can remove this option by
> editing the menu item for IDLE.
> 
> ----------
> nosy: +serwy
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6168>
> _______________________________________

----------
Added file: http://bugs.python.org/file14150/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6168>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
Thank you. I tried it from the command line and you are right. IDLE runs with the Shell menu.<BR>
<BR>
1.Do you know why this is being done in Ubuntu? That is, why are they setting up the menu this way?<BR>
<BR>
2. Is it a bug or a &quot;feature?&quot; Should be reported a an Ubuntu bug?<BR>
<BR>
How do I edit the IDLE menu item?<BR>
<BR>
Thanks again, <BR>
<BR>
Roger<BR>
<BR>
On Mon, 2009-06-01 at 22:09 +0000, Roger Serwy wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Roger Serwy &lt;<A HREF="mailto:roger.serwy at gmail.com">roger.serwy at gmail.com</A>&gt; added the comment:

Running IDLE from the Applications menu under Ubuntu will not have the
Shell menu. If you bring up a terminal and enter &quot;idle&quot;, you will have
the Shell menu.

IDLE, when selected from the Application menu, is being run with the
&quot;-n&quot; command line by default in Ubuntu. You can remove this option by
editing the menu item for IDLE.

----------
nosy: +serwy

_______________________________________
Python tracker &lt;<A HREF="mailto:report at bugs.python.org">report at bugs.python.org</A>&gt;
&lt;<A HREF="http://bugs.python.org/issue6168">http://bugs.python.org/issue6168</A>&gt;
_______________________________________
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

From report at bugs.python.org  Tue Jun  2 01:51:36 2009
From: report at bugs.python.org (pmoody)
Date: Mon, 01 Jun 2009 23:51:36 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011641n1fb547d0of55ba87e720effee@mail.gmail.com>
Message-ID: <8517e9350906011651o4290790bm26a08e0552fc3602@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

On Mon, Jun 1, 2009 at 4:41 PM, Clay McClure <report at bugs.python.org> wrote:
>
> Clay McClure <clay at daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray <report at bugs.python.org> wrote:
>
>>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>>> True
>>
>> As a network engineer I don't see any inherent problem with that equality.
>> In fact I make use of that conceptual equality on a regular basis.
>
> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
> than ifconfig:
>
> # ifconfig en0 192.168.1.1/32
> # ifconfig en0
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> ? ? ? ?inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
> ? ? ? ?...
>
> # ifconfig en0 192.168.1.1
> # ifconfig en0
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> ? ? ? ?inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> ? ? ? ?...
>
> Can you provide an example of when 192.168.1.1 does in fact equal
> 192.168.1.1/32?

what this shows is that your copy of darwin defaults to a /24
prefixlen; ipaddr assumes a /32 prefixlen.  I don't see anything
particularly *more* intuitive with darwin, but in any event, it seems
to provide support for assuming a prefixlen when none is supplied.

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

----------

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

From report at bugs.python.org  Tue Jun  2 02:00:41 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:00:41 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

$ make frameworkinstall DESTDIR=[...]/py3_1rc1-macosx-apy31-rrun/image
running install_scripts
[...]
copying build/scripts-3.1/2to3 ->
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
error:
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
Too many levels of symbolic links
make: *** [sharedinstall] Error 1


!
!

this appears to be a regression in 3.1rc1 (used to work with 3.1b2).
need to investigate further. will update this bug if I find anything
useful. (quick observation .. 'install_scripts' seem to be run twice)

----------
assignee: tarek
components: Distutils
files: apy31-anole.log
messages: 88689
nosy: srid, tarek
severity: normal
status: open
title: Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file14151/apy31-anole.log

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

From report at bugs.python.org  Tue Jun  2 02:00:48 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:00:48 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243900848.8.0.336513541602.issue6170@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Removed file: http://bugs.python.org/file14151/apy31-anole.log

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

From report at bugs.python.org  Tue Jun  2 02:01:29 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:01:29 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243900889.81.0.103787846288.issue6170@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

To explain further, the following section of script is run *twice* .. 
and thus explains the error "Too many levels of symbolic links"

mv 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3" 
"[...]]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1"
ln -sf 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1" 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3"

The entire log file is here: http://double.activestate.com/t/apy31-anole.log

On 09-06-01 04:46 PM, Sridhar Ratnakumar wrote:
> >
> > make: [image_python] PythonLauncher build attempt 1 of 2 (see bug 44709)
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstallapps
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstall frameworkinstallextras
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> >
> >
> > Note: the second make attempt uses 'frameworkinstallextras' as the extra
> > argument.
> >
> > .
> > .
> >
> > This appears to be breaking 3.1rc1 on Mac ("Too many levels of symbolic
> > links"):
> >
> > running install_scripts
> > [...]
> > copying build/scripts-3.1/2to3 ->
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
> > error:
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
> > Too many levels of symbolic links
> > make: *** [sharedinstall] Error 1

----------

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

From report at bugs.python.org  Tue Jun  2 02:02:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:02:33 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243900953.49.0.829705241801.issue6170@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Tarek, are you perchance aware of any change that went into distutils
since the last beta release that could have influenced the make behavior?

----------

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

From report at bugs.python.org  Tue Jun  2 02:05:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jun 2009 00:05:16 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1243901115.61.0.214333760642.issue3959@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address
made sense.  Nowadays it is better not to make that assumption.  So I
find ipaddr's default of 32 to be "safer" than using a class based default.

The larger point, however, is that there _is_ a mask associated with the
address in ifconfig.  There _must_ be one.  So that is not an example
that shows that a separate address class is useful.

As for the == thing, I agreed with you that address compared to network,
if you had an address class, would yield false.  My point was that

    HypotheticalNetworkClass('192.168.1.1') ==
HypotheticalNetworkClass('192.168.1.1/32')

should yield True, because, as I said above, in a CIDR world using a
default of a hostmask for an otherwise unadorned address makes the most
sense.

As for an example of when the equivalence is useful, it is useful every
time I set up an access rule or route that applies to a single host. 
Otherwise, I _must_ give a specific netmask, because in real life the
classfull default is often not the correct netmask.  Most networking
software that I've dealt with requires explicit netmasks (often with a
shorthand to specify an ip/hostmask pair).  It is true that when a
netmask isn't required it generally defaults to the classful netmask,
but having such a default is becoming more rare with time, in my
experience (because of CIDR).

----------

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

From report at bugs.python.org  Tue Jun  2 02:10:14 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 02 Jun 2009 00:10:14 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243901414.35.0.797584342951.issue6170@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

No, but I am running frameworkinstall right now under Mac to see if I
can reproduce the problem

----------

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

From report at bugs.python.org  Tue Jun  2 02:12:12 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:12:12 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243901532.86.0.394885984261.issue6170@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

To help with the repro, may I suggest running the following in the same
order:

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image

----------

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

From report at bugs.python.org  Tue Jun  2 02:14:29 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Jun 2009 00:14:29 +0000
Subject: [issue6169] Important comparison bug in ipaddr
In-Reply-To: <1243898305.94.0.945300464283.issue6169@psf.upfronthosting.co.za>
Message-ID: <1243901669.49.0.748199474645.issue6169@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

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

From report at bugs.python.org  Tue Jun  2 02:17:20 2009
From: report at bugs.python.org (Greg Ward)
Date: Tue, 02 Jun 2009 00:17:20 +0000
Subject: [issue1704474] test_optparse.py mod. for jython
Message-ID: <1243901840.51.0.0963345730661.issue1704474@psf.upfronthosting.co.za>


Greg Ward <greg at gerg.ca> added the comment:

I just took a look at the original patch uploaded by drtimcouper.  IMHO
it would be cleaner and simpler to modify optparse.py so that it behaves
as consistently as possible under Jython and CPython.  For example,
optparse should catch the ValueError raised when a user supplies a bad
integer input and raise a new exception with a consistent error message.
 That sort of thing.

drtimcouper: if you're still out there and reading this, would you mind
submitting a new patch?

----------

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

From report at bugs.python.org  Tue Jun  2 02:18:01 2009
From: report at bugs.python.org (Greg Ward)
Date: Tue, 02 Jun 2009 00:18:01 +0000
Subject: [issue1704474] optparse tests fail under Jython
Message-ID: <1243901881.02.0.705341009034.issue1704474@psf.upfronthosting.co.za>


Changes by Greg Ward <greg at gerg.ca>:


----------
components: +Library (Lib) -Tests
title: test_optparse.py mod. for jython -> optparse tests fail under Jython

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

From report at bugs.python.org  Tue Jun  2 02:24:31 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 02 Jun 2009 00:24:31 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243902271.64.0.595610831091.issue6170@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I'll try tomorrow asap (sorry it's 2:30 am now here)

----------

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

From report at bugs.python.org  Tue Jun  2 02:27:34 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:27:34 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243902454.17.0.090220118707.issue6170@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

also related to issue 5756

----------
components: +2to3 (2.x to 3.0 conversion tool), Build

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

From report at bugs.python.org  Tue Jun  2 02:45:58 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 02 Jun 2009 00:45:58 +0000
Subject: [issue1704474] optparse tests fail under Jython
Message-ID: <1243903558.61.0.669894809544.issue1704474@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

This looks like it was against Jython 2.2? Jython 2.5 passes 2.5's 
test_optparse with only fixing __builtins__ and disabling the weakref test

So uses of __builtins__ should should be importing __builtin__ and use 
that instead. sys.platform.startswith('java') should be 
test_support.is_jython instead. And on 2.6/3.2 you can now decorate 
test_refleak with @test_support.impl_check('Relies on sys.getrefcount', 
cpython=True) to skip it

----------
nosy: +pjenvey

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

From report at bugs.python.org  Tue Jun  2 02:46:53 2009
From: report at bugs.python.org (Jason Gervich)
Date: Tue, 02 Jun 2009 00:46:53 +0000
Subject: [issue6171] Class Browser selection in Ubuntu
In-Reply-To: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za>
Message-ID: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za>


New submission from Jason Gervich <gervich at sbcglobal.net>:

When sing IDLE in Ubuntu (Jaunty) if you open the Class Browser and
double click on a class or function name, the corresponding section is
highlighted in the code in the Editor Window. 

If you again double click on another class or function name, the new
code section should be highlighted in the Editor Window but isn't.
Nothing happens. You have to first close the Class Browser window,
reopen it and double click on another name to select it the Editor Window.

In the Windows versions, successive double clicking will highlight the
desired selection in the Class Browser window.

----------
messages: 88699
nosy: sirgimp
severity: normal
status: open
title: Class Browser selection in Ubuntu
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Tue Jun  2 02:47:45 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 00:47:45 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <4A24401B.7080901@v.loewis.de>
Message-ID: <8657ee3f0906011747u213e7727w205f568189960636@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Mon, Jun 1, 2009 at 4:54 PM, Martin v. L?wis <report at bugs.python.org> wrote:

> Do you have an application in mind where this lack of distinction
> would prevent writing the application in a straight-forward way?
> IOW, could you do something if they were distinct that you can't
> do because they are not?

Consider applications that use ipaddr.IPv4 objects to configure
network interfaces:

ifconfig: 255.255.255.0/32: bad value

That's because ipaddr wrongly appends a prefix length to all
ipaddr.IPv4 objects, even those representing addresses, which do not
have prefix lengths.

Consider applications that need to validate addresses (or networks,
but not both) supplied as user input:

address = ipaddr.IP(input)

if isinstance(address, ipaddr.IPv4):
    if address.prefixlen != 32:
        raise TypeError("Expecting IP address, not network")
elif isinstance(address, ipaddr.IPv6):
    if address.prefixlen != 128:
        raise TypeError("Expecting IP address, not network")

Given its myriad quirks, it is really rather surprising that ipaddr is
being considered for inclusion in the Python stdlib.

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 02:53:32 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 02 Jun 2009 00:53:32 +0000
Subject: [issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1:
	No such file or directory)
In-Reply-To: <1243904012.22.0.551945189195.issue6172@psf.upfronthosting.co.za>
Message-ID: <1243904012.22.0.551945189195.issue6172@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

This happens with 3.1rc1

$ make frameworkinstallframework DESTDIR=image1
[...]
cc  -o pythonw ./Tools/pythonw.c \
               
-DPYTHONWEXECUTABLE='"/Library/Frameworks/Python.framework/Versions/3.1/Resources/Python.app/Contents/MacOS/Python"'
/usr/bin/install -c -s pythonw
"image1/Library/Frameworks/Python.framework/Versions/3.1/bin/pythonw3.1"
install:
image1/Library/Frameworks/Python.framework/Versions/3.1/bin/pythonw3.1:
No such file or directory
make[1]: *** [install_pythonw] Error 71
make: *** [frameworkinstallapps] Error 2
$

----------
components: Build, Macintosh
messages: 88701
nosy: srid
severity: normal
status: open
title: 'make framework...' fails on Mac ([...]/bin/pythonw3.1: No such file or directory)
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun  2 02:53:51 2009
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 02 Jun 2009 00:53:51 +0000
Subject: [issue6168] Missing Shell menu in Linux IDLE
In-Reply-To: <1243889984.38.0.346185167721.issue6168@psf.upfronthosting.co.za>
Message-ID: <1243904031.88.0.967637860733.issue6168@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

You'll need to modify the IDLE menu item to remove the "-n" using
Ubuntu's menu modification tool, usually found under System->Preferences.

Presently, using a subprocess only allows for one instance of IDLE
running on a machine, whereas running with no subprocess allows for many
instances of IDLE. This architecture is by design.

Check out Ubuntu bug 338379.

----------

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

From report at bugs.python.org  Tue Jun  2 03:03:20 2009
From: report at bugs.python.org (pmoody)
Date: Tue, 02 Jun 2009 01:03:20 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011747u213e7727w205f568189960636@mail.gmail.com>
Message-ID: <8517e9350906011803x155ae6cfj2b718ba37f7cc1ee@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

On Mon, Jun 1, 2009 at 5:47 PM, Clay McClure <report at bugs.python.org> wrote:
>
> Clay McClure <clay at daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 4:54 PM, Martin v. L?wis <report at bugs.python.org> wrote:
>
>> Do you have an application in mind where this lack of distinction
>> would prevent writing the application in a straight-forward way?
>> IOW, could you do something if they were distinct that you can't
>> do because they are not?
>
> Consider applications that use ipaddr.IPv4 objects to configure
> network interfaces:
>
> ifconfig: 255.255.255.0/32: bad value
>
> That's because ipaddr wrongly appends a prefix length to all
> ipaddr.IPv4 objects, even those representing addresses, which do not
> have prefix lengths.

I'm not sure what you're trying to do here, can you elaborate?

> Consider applications that need to validate addresses (or networks,
> but not both) supplied as user input:
>
> address = ipaddr.IP(input)
>
> if isinstance(address, ipaddr.IPv4):
> ? ?if address.prefixlen != 32:
> ? ? ? ?raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
> ? ?if address.prefixlen != 128:
> ? ? ? ?raise TypeError("Expecting IP address, not network")

i'm not sure what's onerous about this code.  you're missing a
try/except around ipaddr.IP(), but otherwise it seems fine.

> Given its myriad quirks, it is really rather surprising that ipaddr is
> being considered for inclusion in the Python stdlib.

it's actually already been included, but that's beside the point.  I'm
now asking you a second time to submit bug reports if there are issues
which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
not.  yelling here doesn't actually do anything productive.

> Clay
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3959>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Jun  2 03:18:21 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Tue, 02 Jun 2009 01:18:21 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243905501.76.0.573863431392.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Thanks :)
It seems that the error message carried by the ImportError object comes
from Python/import.c:1504.
What should we do:
a) Edit Python/import.c
b) Change the ImportError object
c) Anything else.

----------

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

From report at bugs.python.org  Tue Jun  2 03:27:44 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 01:27:44 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8517e9350906011351v53086feo30c43efde3b4dfe6@mail.gmail.com>
Message-ID: <8657ee3f0906011827i66102aecg65dadebe1e443dd7@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Mon, Jun 1, 2009 at 4:51 PM, pmoody <report at bugs.python.org> wrote:

>>>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>> True
>>
>> ipaddr makes no distinction between two fundamentally different
>> concepts -- to my mind, that is a serious flaw.
>
> I don't see these a fundamentally different, I guess. ?can you
> demonstrate how this equivalency makes ipaddr unusable?

Fortunately, it's not up for debate: RFC-791 defines an IP address as
a 32-bit number, with no provision for a mask. Networks are defined by
their address and their mask. To correctly model them in an
object-oriented system, we would say that a Network has-a Address,
certainly not that a Network is-a Address.

> I haven't seen any new issues on code.google.com (and I haven't heard
> of any being reported on the python bugtracker), so since you're using
> this thread to report issues, can you elaborate?

I will go ahead and open issues on code.google.com.

> have used it to develop software and will continue to use it to
> develop software.

I'd like to hear from application developers outside of Google. The
two that have commented on this issue seem not to prefer ipaddr's API.

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 04:03:10 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 02:03:10 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8517e9350906011651o4290790bm26a08e0552fc3602@mail.gmail.com>
Message-ID: <8657ee3f0906011903o521ba1feo6a8d543b5f9ee130@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Mon, Jun 1, 2009 at 7:51 PM, pmoody <report at bugs.python.org> wrote:

>> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
>> than ifconfig:
>>
>> # ifconfig en0 192.168.1.1/32
>> # ifconfig en0
>> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>> ? ? ? ?inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
>> ? ? ? ?...
>>
>> # ifconfig en0 192.168.1.1
>> # ifconfig en0
>> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>> ? ? ? ?inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>> ? ? ? ?...
>
> what this shows is that your copy of darwin defaults to a /24
> prefixlen; ipaddr assumes a /32 prefixlen. ?I don't see anything
> particularly *more* intuitive with darwin, but in any event, it seems
> to provide support for assuming a prefixlen when none is supplied.

The example demonstrates one case where the strings '192.168.1.1' and
'192.168.1.1/32' are not equivalent -- it wouldn't be hard to find
other examples -- yet you seem to think that (a) this is
Darwin-specific behavior, and that (b) this discrepancy is acceptable
and does not constitute a design flaw.

You're wrong on both fronts, since in fact all IP implementations
understand classful addressing (as per RFC-791), not just Darwin, and
your insistence on the equality of '192.168.1.1' and '192.168.1.1/32'
means that your library is unusable in applications that pass
ipaddr.IPv4 objects to ifconfig.

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 04:15:30 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 02:15:30 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1243901115.61.0.214333760642.issue3959@psf.upfronthosting.co.za>
Message-ID: <8657ee3f0906011915i524de178x4cfd89c424b46fd7@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Mon, Jun 1, 2009 at 8:05 PM, R. David Murray <report at bugs.python.org> wrote:

> In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address
> made sense. ?Nowadays it is better not to make that assumption. ?So I
> find ipaddr's default of 32 to be "safer" than using a class based default.

Sorry, but why should you determine what is better for my application?

> The larger point, however, is that there _is_ a mask associated with the
> address in ifconfig. ?There _must_ be one. ?So that is not an example
> that shows that a separate address class is useful.

Again, you're wrong. The mask that you see in ifconfig is associated
with the network to which the interface is attached, not the interface
address. You also see a broadcast address in the ifconfig output, but
certainly you don't believe that the broadcast address is a property
of the interface address? No, of course not; it's a property of the
network to which the interface is attached -- just like the mask.

That's why we call it a "netmask".

> As for an example of when the equivalence is useful, it is useful every
> time I set up an access rule or route that applies to a single host.

Host routes are routes like all others -- they have a destination
address and a mask. That a host route has a prefix length of 32 does
not imply that the host route is equivalent to the host address.
You're confusing the two concepts.

> Most networking
> software that I've dealt with requires explicit netmasks (often with a
> shorthand to specify an ip/hostmask pair).

By "ip/hostmask" pair, you actually mean "ip/netmask" pair, and yes,
this is a convenient notation for expressing two distinct but related
concepts: an address, and a mask. Addresses do not have masks;
networks do. I am not sure how to be any more clear about that point,
yet you still seem not to understand.

> It is true that when a
> netmask isn't required it generally defaults to the classful netmask,
> but having such a default is becoming more rare with time, in my
> experience (because of CIDR).

I'm not advocating classful routing, I'm merely stating (emphatically
and without ambiguity) that addresses and networks are different:
networks have masks; addresses do not. The ipaddr library forces a
mask on me every time I specify an address. In my view, that is a
design flaw.

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 04:29:18 2009
From: report at bugs.python.org (Jason Gervich)
Date: Tue, 02 Jun 2009 02:29:18 +0000
Subject: [issue6168] Missing Shell menu in Linux IDLE
In-Reply-To: <1243904031.88.0.967637860733.issue6168@psf.upfronthosting.co.za>
Message-ID: <1243909749.6510.63.camel@jason-desktop>


Jason Gervich <gervich at sbcglobal.net> added the comment:

Again, thanks for your prompt explanation.

It's odd, but when I went to use Ubuntu's menu modification tool, the
command displayed in the dialog didn't show the -n option.

But when I added the Python launcher to the panel and viewed the launch
command via the properties dialog, the -n was there and I was easily
able to remove it. 

So if I run Python from the modified icon in the panel, it launches
without the -n option. But if I run it from the Application Menu, it
runs without the -n option. It seems to me that the -n option should be
available when viewing it from the menu modification tool, but it's not.

I guess Windows doesn't have this problem with running IDLE with a
subprocess. I was able to run several instances of the IDLE shell with
the Shell menu displayed.

On Tue, 2009-06-02 at 00:53 +0000, Roger Serwy wrote:

> Roger Serwy <roger.serwy at gmail.com> added the comment:
> 
> You'll need to modify the IDLE menu item to remove the "-n" using
> Ubuntu's menu modification tool, usually found under System->Preferences.
> 
> Presently, using a subprocess only allows for one instance of IDLE
> running on a machine, whereas running with no subprocess allows for many
> instances of IDLE. This architecture is by design.
> 
> Check out Ubuntu bug 338379.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6168>
> _______________________________________

----------
Added file: http://bugs.python.org/file14152/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6168>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
Again, thanks for your prompt explanation.<BR>
<BR>
It's odd, but when I went to use Ubuntu's menu modification tool, the command displayed in the dialog didn't show the -n option.<BR>
<BR>
<B><I>But</I></B> when I added the Python launcher to the panel and viewed the launch command via the properties dialog, the -n <B><I>was there</I></B> and I was easily able to remove it. <BR>
<BR>
So if I run Python from the modified icon in the panel, it launches without the -n option. But if I run it from the Application Menu, it runs without the -n option. It seems to me that the -n option should be available when viewing it from the menu modification tool, but it's not.<BR>
<BR>
I guess Windows doesn't have this problem with running IDLE with a subprocess. I was able to run several instances of the IDLE shell with the Shell menu displayed.<BR>
<BR>
<BR>
<BR>
On Tue, 2009-06-02 at 00:53 +0000, Roger Serwy wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Roger Serwy &lt;<A HREF="mailto:roger.serwy at gmail.com">roger.serwy at gmail.com</A>&gt; added the comment:

You'll need to modify the IDLE menu item to remove the &quot;-n&quot; using
Ubuntu's menu modification tool, usually found under System-&gt;Preferences.

Presently, using a subprocess only allows for one instance of IDLE
running on a machine, whereas running with no subprocess allows for many
instances of IDLE. This architecture is by design.

Check out Ubuntu bug 338379.

----------

_______________________________________
Python tracker &lt;<A HREF="mailto:report at bugs.python.org">report at bugs.python.org</A>&gt;
&lt;<A HREF="http://bugs.python.org/issue6168">http://bugs.python.org/issue6168</A>&gt;
_______________________________________
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

From report at bugs.python.org  Tue Jun  2 04:38:41 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 02:38:41 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8517e9350906011803x155ae6cfj2b718ba37f7cc1ee@mail.gmail.com>
Message-ID: <8657ee3f0906011938i2f5144qa15be8c2ad11edf@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Mon, Jun 1, 2009 at 9:03 PM, pmoody <report at bugs.python.org> wrote:

>> ifconfig: 255.255.255.0/32: bad value
>>
>> That's because ipaddr wrongly appends a prefix length to all
>> ipaddr.IPv4 objects, even those representing addresses, which do not
>> have prefix lengths.
>
> I'm not sure what you're trying to do here, can you elaborate?

Let's say I have a UI that prompts users for two pieces of
information: interface address, and network mask. I then take those
two strings and make ipaddr.IPv4 objects out of them. This lets me
validate their correctness, and lets me perform convenient
calculations and tests (things the ipaddr library has done well).
Next, I take the IPv4 objects, coerce them to strings, and pass them
to ifconfig to configure an interface.

Assuming the user has supplied this information:

Interface address = '192.168.1.1'
Network mask = '255.255.255.0'

the following would get passed to ifconfig:

ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32

Clearly this is not what we expect, nor even legal. The principle of
least surprise is violated here, if nothing else.

We could work around this, of course, but why should we have to work
around our libraries when simply fixing them isn't that hard?

>> if isinstance(address, ipaddr.IPv4):
>> ? ?if address.prefixlen != 32:
>> ? ? ? ?raise TypeError("Expecting IP address, not network")
>> elif isinstance(address, ipaddr.IPv6):
>> ? ?if address.prefixlen != 128:
>> ? ? ? ?raise TypeError("Expecting IP address, not network")
>
> i'm not sure what's onerous about this code. ?you're missing a
> try/except around ipaddr.IP(), but otherwise it seems fine.

Your definition of onerous apparently differs from mine :)

In my own applications, when I'm expecting a network, I use an
IPNetwork class, and when I'm expecting an address, I use an IPAddress
class. This means I can simply rely on the class constructors to do
the type checking for me. With ipaddr, I have to do the validation
myself. Simple isinstance() testing and duck typing don't work because
networks and addresses are represented (wrongly) by the same class.

> it's actually already been included, but that's beside the point. ?I'm
> now asking you a second time to submit bug reports if there are issues
> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
> not. ?yelling here doesn't actually do anything productive.

Rest assured, I've opened one issue and will open one or two more
before the night is out.

I'm sorry that you think "yelling" is unproductive. I happen to think
that healthy debate breeds better code.

Cheers,

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 05:00:25 2009
From: report at bugs.python.org (pmoody)
Date: Tue, 02 Jun 2009 03:00:25 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011938i2f5144qa15be8c2ad11edf@mail.gmail.com>
Message-ID: <8517e9350906012000n1d1bfcc8gcaa4731238fe1319@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure <report at bugs.python.org> wrote:
>
> Clay McClure <clay at daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 9:03 PM, pmoody <report at bugs.python.org> wrote:
>
>>> ifconfig: 255.255.255.0/32: bad value
>>>
>>> That's because ipaddr wrongly appends a prefix length to all
>>> ipaddr.IPv4 objects, even those representing addresses, which do not
>>> have prefix lengths.
>>
>> I'm not sure what you're trying to do here, can you elaborate?
>
> Let's say I have a UI that prompts users for two pieces of
> information: interface address, and network mask. I then take those
> two strings and make ipaddr.IPv4 objects out of them. This lets me
> validate their correctness, and lets me perform convenient
> calculations and tests (things the ipaddr library has done well).
> Next, I take the IPv4 objects, coerce them to strings, and pass them
> to ifconfig to configure an interface.
>
> Assuming the user has supplied this information:
>
> Interface address = '192.168.1.1'
> Network mask = '255.255.255.0'
>
> the following would get passed to ifconfig:
>
> ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32

I suppose that might be the case if you didn't know how to use ipaddr.
 knowing that ipaddr accepts an ipaddress/netmask, I'd pass it

my_ip = ipaddr.IP('%s/%s' % (ipaddress, netmask))

and then check for any exceptions.  I'd then ifconfig en0 str(my_ip)

> Clearly this is not what we expect, nor even legal. The principle of
> least surprise is violated here, if nothing else.
>
> We could work around this, of course, but why should we have to work
> around our libraries when simply fixing them isn't that hard?
>
>>> if isinstance(address, ipaddr.IPv4):
>>> ? ?if address.prefixlen != 32:
>>> ? ? ? ?raise TypeError("Expecting IP address, not network")
>>> elif isinstance(address, ipaddr.IPv6):
>>> ? ?if address.prefixlen != 128:
>>> ? ? ? ?raise TypeError("Expecting IP address, not network")
>>
>> i'm not sure what's onerous about this code. ?you're missing a
>> try/except around ipaddr.IP(), but otherwise it seems fine.
>
> Your definition of onerous apparently differs from mine :)
>
> In my own applications, when I'm expecting a network, I use an
> IPNetwork class, and when I'm expecting an address, I use an IPAddress
> class. This means I can simply rely on the class constructors to do
> the type checking for me. With ipaddr, I have to do the validation
> myself. Simple isinstance() testing and duck typing don't work because
> networks and addresses are represented (wrongly) by the same class.

so ipaddr doing this validation for the user actually could make some
sense, but this could be fixed by something as easy

  ipaddr.IP(ip, network=False)
or
  ipaddr.IP(net, network=True)

anyway (more below)...

>> it's actually already been included, but that's beside the point. ?I'm
>> now asking you a second time to submit bug reports if there are issues
>> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
>> not. ?yelling here doesn't actually do anything productive.
>
> Rest assured, I've opened one issue and will open one or two more
> before the night is out.

cool, I see that you did that. as an aside, this probably isn't the
best place for continued discussion on ipaddr. ipaddr has already been
shipped with python, so i'm not sure that debate on it's inclusion is
able to influence that decision.  All of the folks who've worked on
ipaddr + the python committer are on ipaddr-py-dev at googlegroups.com
(looks like you are too), so might I suggest we continue this
discussion there?

> I'm sorry that you think "yelling" is unproductive. I happen to think
> that healthy debate breeds better code.

I think debate is healthy, too.  but I measure my success at a debate
by my ability to convince other people of my side. I find I have
better success when I listen other people and respond with respect.
yelling promotes neither of those.

Cheers,
/peter

> Cheers,
>
> Clay
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3959>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Jun  2 05:10:50 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Jun 2009 03:10:50 +0000
Subject: [issue6169] Important comparison bug in ipaddr
In-Reply-To: <1243898305.94.0.945300464283.issue6169@psf.upfronthosting.co.za>
Message-ID: <1243912250.32.0.213965365173.issue6169@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun  2 05:12:46 2009
From: report at bugs.python.org (Evan Behar)
Date: Tue, 02 Jun 2009 03:12:46 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1243912366.68.0.881207994943.issue6081@psf.upfronthosting.co.za>


Changes by Evan Behar <behare at gmail.com>:


----------
nosy: +ebehar

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

From report at bugs.python.org  Tue Jun  2 07:20:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 02 Jun 2009 05:20:02 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011747u213e7727w205f568189960636@mail.gmail.com>
Message-ID: <4A24B627.6060307@v.loewis.de>


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

> Consider applications that need to validate addresses (or networks,
> but not both) supplied as user input:
> 
> address = ipaddr.IP(input)

If that is a frequent need, it would be reasonable to add an API

address = ipaddr.IP(input, allow_mask=False)

which would raise an exception if a mask was specified (as an
old-style bit mask, or in CIDR form).

> if isinstance(address, ipaddr.IPv4):
>    if address.prefixlen != 32:
>        raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
>    if address.prefixlen != 128:
>        raise TypeError("Expecting IP address, not network")

With the current API, you don't need to write it in such a quirky
way. Instead

if address.numhosts != 1:
   raise TypeError("Expecting IP address, not network")

would do as well.

> Given its myriad quirks

Well, you deliberately make it appear more quirky than it actually is.

----------

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

From report at bugs.python.org  Tue Jun  2 07:21:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 02 Jun 2009 05:21:06 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011827i66102aecg65dadebe1e443dd7@mail.gmail.com>
Message-ID: <4A24B69C.50700@v.loewis.de>


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

> I will go ahead and open issues on code.google.com.

If you want to see them fixed in Python, please report them to this
tracker.

----------

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

From report at bugs.python.org  Tue Jun  2 07:30:16 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 05:30:16 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <4A24B69C.50700@v.loewis.de>
Message-ID: <8657ee3f0906012229r5f778c72t259fe05dfdfe8560@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Tue, Jun 2, 2009 at 1:21 AM, Martin v. L?wis <report at bugs.python.org> wrote:

>> I will go ahead and open issues on code.google.com.
>
> If you want to see them fixed in Python, please report them to this
> tracker.

I'd like to see the issues fixed upstream, and the library removed
from Python until it is satisfactory to the developers who will
actually use it. To my knowledge, every developer (outside of Google)
who has commented on the issue has indicated a preference for a
different API.

Thanks,

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 07:30:22 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Jun 2009 05:30:22 +0000
Subject: [issue6169] Important comparison bug in ipaddr
In-Reply-To: <1243898305.94.0.945300464283.issue6169@psf.upfronthosting.co.za>
Message-ID: <1243920622.09.0.243098795842.issue6169@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks!

Fixed in trunk r73135 and py3k r73136.

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

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

From report at bugs.python.org  Tue Jun  2 07:51:40 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Tue, 02 Jun 2009 05:51:40 +0000
Subject: [issue6173] Minor typo in socket.py
In-Reply-To: <1243921892.02.0.394666822319.issue6173@psf.upfronthosting.co.za>
Message-ID: <1243921892.02.0.394666822319.issue6173@psf.upfronthosting.co.za>


New submission from Pablo Torres Navarrete <tn.pablo at gmail.com>:

Index: socket.py
===================================================================
--- socket.py	(revision 73134)
+++ socket.py	(working copy)
@@ -16,7 +16,7 @@
 gethostbyname() -- map a hostname to its IP number
 gethostbyaddr() -- map an IP number or hostname to DNS info
 getservbyname() -- map a service name and a protocol name to a port number
-getprotobyname() -- mape a protocol name (e.g. 'tcp') to a number
+getprotobyname() -- map a protocol name (e.g. 'tcp') to a number
 ntohs(), ntohl() -- convert 16, 32 bit int from network to host byte order
 htons(), htonl() -- convert 16, 32 bit int from host to network byte order
 inet_aton() -- convert IP addr string (123.45.67.89) to 32-bit packed
format

----------
components: Library (Lib)
files: socket.patch
keywords: patch
messages: 88715
nosy: ptn
severity: normal
status: open
title: Minor typo in socket.py
versions: Python 2.6
Added file: http://bugs.python.org/file14153/socket.patch

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

From report at bugs.python.org  Tue Jun  2 07:53:47 2009
From: report at bugs.python.org (Joe Amenta)
Date: Tue, 02 Jun 2009 05:53:47 +0000
Subject: [issue6174] What's new in 2.6, wrong indentation in code sample
In-Reply-To: <1243922024.28.0.772489700519.issue6174@psf.upfronthosting.co.za>
Message-ID: <1243922024.28.0.772489700519.issue6174@psf.upfronthosting.co.za>


New submission from Joe Amenta <amentajo at msu.edu>:

In the final example in the multiprocessing package on
http://docs.python.org/3.0/whatsnew/2.6.html#pep-371-the-multiprocessing-package
a part of the code is not properly indented.  There should be one more
level of indentation starting at "#Mark pool as closed".

Patch adds that level of indentation.

----------
assignee: georg.brandl
components: Documentation
files: docdiff.patch
keywords: patch
messages: 88716
nosy: georg.brandl, joe.amenta
severity: normal
status: open
title: What's new in 2.6, wrong indentation in code sample
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14154/docdiff.patch

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

From report at bugs.python.org  Tue Jun  2 08:12:40 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Jun 2009 06:12:40 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011747u213e7727w205f568189960636@mail.gmail.com>
Message-ID: <52dc1c820906012311k16a478d0i3d6a10dfcde7eaff@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

> Consider applications that need to validate addresses (or networks,
> but not both) supplied as user input:
>
> address = ipaddr.IP(input)
>
> if isinstance(address, ipaddr.IPv4):
> ? ?if address.prefixlen != 32:
> ? ? ? ?raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
> ? ?if address.prefixlen != 128:
> ? ? ? ?raise TypeError("Expecting IP address, not network")

Support for this can be added (its too late for Python 3.1).  User
input validation is a good use case.  For now I suggest the simpler
code:

if '/' in input:
    raise TypeError("Expecting IP address")
address = ipaddr.IP(input)

Or for a more pedantic test prior to calling ipaddr.IP.

if re.match('^[0-9a-fA-F:.]+$', input):
    raise TypeError("Invalid characters in IP address")

Please file a feature request on bugs.python.org for this one if you
haven't already.  We could add optional parameter(s) to ipaddr.IP to
enable only accepting host addresses or network addresses in the
future.

----------

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

From report at bugs.python.org  Tue Jun  2 08:18:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 02 Jun 2009 06:18:30 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906012229r5f778c72t259fe05dfdfe8560@mail.gmail.com>
Message-ID: <4A24C407.4010305@v.loewis.de>


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

> I'd like to see the issues fixed upstream, and the library removed
> from Python until it is satisfactory to the developers who will
> actually use it. To my knowledge, every developer (outside of Google)
> who has commented on the issue has indicated a preference for a
> different API.

That's not true - I'm outside of Google, and have not indicated such
a preference.

----------

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

From report at bugs.python.org  Tue Jun  2 08:25:46 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Tue, 02 Jun 2009 06:25:46 +0000
Subject: [issue6173] Minor typo in socket.py
In-Reply-To: <1243921892.02.0.394666822319.issue6173@psf.upfronthosting.co.za>
Message-ID: <1243923945.94.0.559763427482.issue6173@psf.upfronthosting.co.za>


Changes by Pablo Torres Navarrete <tn.pablo at gmail.com>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Tue Jun  2 08:35:40 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 06:35:40 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <4A24C407.4010305@v.loewis.de>
Message-ID: <8657ee3f0906012334h2653205fo73c5182be43db795@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Tue, Jun 2, 2009 at 2:18 AM, Martin v. L?wis <report at bugs.python.org> wrote:

>> I'd like to see the issues fixed upstream, and the library removed
>> from Python until it is satisfactory to the developers who will
>> actually use it. To my knowledge, every developer (outside of Google)
>> who has commented on the issue has indicated a preference for a
>> different API.
>
> That's not true - I'm outside of Google, and have not indicated such
> a preference.

You've indicated no preference either way, and have said:

"I personally have no plans for using this library, or any other IP
address library"

I should think you would seek the opinion of those developers who
actually do have plans to use an IP address library. As far as I can
tell, every developer in that category, outside of Google, that has
commented on this issue here or in python-dev has advocated a
different API.

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 08:51:54 2009
From: report at bugs.python.org (pmoody)
Date: Tue, 02 Jun 2009 06:51:54 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906012334h2653205fo73c5182be43db795@mail.gmail.com>
Message-ID: <8517e9350906012350qbf035fboabb37390e920f700@mail.gmail.com>


pmoody <python at hda3.com> added the comment:

> I should think you would seek the opinion of those developers who
> actually do have plans to use an IP address library.

That's what this has been doing for the last 8 1/2 months.

> As far as I can
> tell, every developer in that category, outside of Google, that has
> commented on this issue here or in python-dev has advocated a
> different API.

Is there some sort of conspiracy theory-ish reason that a google
software engineer might be somehow unfairly influenced?

Cheers,
/peter

----------

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

From report at bugs.python.org  Tue Jun  2 09:19:20 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Jun 2009 07:19:20 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243927160.96.0.257080571403.issue6170@psf.upfronthosting.co.za>


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

The URL you provide for the log doesn't seem to be accessible externally 
so it is difficult to guess exactly what was being done.  However, there 
were changes between 3.1b2 and 3.1rc1 to the top-level Makefile 
(Makefile.pre.in) and to the Mac/Makefile.in affecting framework builds 
and installs.

----------
nosy: +nad, ronaldoussoren

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

From report at bugs.python.org  Tue Jun  2 09:21:46 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Jun 2009 07:21:46 +0000
Subject: [issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1:
	No such file or directory)
In-Reply-To: <1243904012.22.0.551945189195.issue6172@psf.upfronthosting.co.za>
Message-ID: <1243927306.92.0.430459515484.issue6172@psf.upfronthosting.co.za>


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

See also Issue6170.

----------
nosy: +nad, ronaldoussoren

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

From report at bugs.python.org  Tue Jun  2 09:43:07 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Jun 2009 07:43:07 +0000
Subject: [issue6173] Minor typo in socket.py
In-Reply-To: <1243921892.02.0.394666822319.issue6173@psf.upfronthosting.co.za>
Message-ID: <1243928587.61.0.730238175483.issue6173@psf.upfronthosting.co.za>


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

Thanks!  Fixed in r73138, r71739, r71740, r71741.

----------
nosy: +marketdickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jun  2 09:44:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 02 Jun 2009 07:44:52 +0000
Subject: [issue6173] Minor typo in socket.py
In-Reply-To: <1243921892.02.0.394666822319.issue6173@psf.upfronthosting.co.za>
Message-ID: <1243928692.45.0.980736630509.issue6173@psf.upfronthosting.co.za>


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

Sorry.  Those revision numbers should be:

r73138, r73139, r73140, r73141.

----------

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

From report at bugs.python.org  Tue Jun  2 10:06:07 2009
From: report at bugs.python.org (Daniel Svensson)
Date: Tue, 02 Jun 2009 08:06:07 +0000
Subject: [issue6175] inet_aton documentation kind of lies
In-Reply-To: <1243929967.67.0.34945506806.issue6175@psf.upfronthosting.co.za>
Message-ID: <1243929967.67.0.34945506806.issue6175@psf.upfronthosting.co.za>


New submission from Daniel Svensson <dsvensson at gmail.com>:

The documentation for inet_aton specifically says that it's used to
"Convert an IPv4 address from dotted-quad string format". This however
is not really true, it does accept dotted-quad, but not dotted-quad
alone, but also these forms from inet(3) man page:

       a.b.c.d   Each of the four numeric parts specifies a byte of the
address; the bytes are assigned in left-to-right order to produce the
binary address.

       a.b.c     Parts a and b specify the first two bytes of the binary
address.  Part c is interpreted as a 16-bit value that defines the
rightmost two bytes of the binary address.  This notation is suitable
for specifying (outmoded) Class B network addresses.

       a.b       Part a specifies the first byte of the binary address.
 Part b is interpreted as a 24-bit value that defines the rightmost
three bytes of the binary address.  This notation is suitable for
specifying (outmoded) Class C network addresses.

       a         The value a is interpreted as a 32-bit value that is
stored directly into the binary address without any byte rearrangement.

Sure, it references the man-page, but if anything it should say among
the formats it supports, dotted-quad is *one* of them.

http://docs.python.org/library/socket.html#socket.inet_aton

----------
assignee: georg.brandl
components: Documentation
messages: 88725
nosy: dsvensson, georg.brandl
severity: normal
status: open
title: inet_aton documentation kind of lies
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  2 11:01:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 02 Jun 2009 09:01:02 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243933262.54.0.201421921766.issue6170@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Sorry I can't reproduce it,

can you tell me how you run configure precisely ?
eg the whole set of commands after a fresh checkout

----------

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

From report at bugs.python.org  Tue Jun  2 11:02:31 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jun 2009 09:02:31 +0000
Subject: [issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1:
	No such file or directory)
In-Reply-To: <1243904012.22.0.551945189195.issue6172@psf.upfronthosting.co.za>
Message-ID: <1243933351.71.0.201382105187.issue6172@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I cannot reproduce this with the py3k branch, I'm currently building 
r31rc1 to check if I can reproduce the issue with that.

----------

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

From report at bugs.python.org  Tue Jun  2 11:07:36 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jun 2009 09:07:36 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243933656.27.0.00220704332843.issue6170@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I also cannot reproduce this, using both the py3k branch and the r31rc1 
tag. 

My build procedure:

* cd r31rc1
* mkdir build
* cd build
* ../configure --enable-framework --enable-universalsdk
* make
* make install DESTDIR=$PWD/image

The resulting framework in the $DESTDIR seems to be complete, and I 
don't get errors while building it.

----------

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

From report at bugs.python.org  Tue Jun  2 11:15:07 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jun 2009 09:15:07 +0000
Subject: [issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1:
	No such file or directory)
In-Reply-To: <1243904012.22.0.551945189195.issue6172@psf.upfronthosting.co.za>
Message-ID: <1243934107.57.0.0726753727691.issue6172@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The build was quicker than expected. I also cannot reproduce using 
r31rc1.


Or rather, I can reproduce this using "make frameworkinstallframework", 
but not using "make install".

The latter is the correct way to install the framework, the former is an 
internal makefile target that is used during installation but should not 
be used on its own.

Closing this as won't fix.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Jun  2 11:16:45 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 02 Jun 2009 09:16:45 +0000
Subject: [issue6153] email parsing - Rare Failure
In-Reply-To: <1243746885.91.0.189696323445.issue6153@psf.upfronthosting.co.za>
Message-ID: <1243934205.96.0.375673112054.issue6153@psf.upfronthosting.co.za>


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

This is a duplicate of issue1555570.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> email parser incorrectly breaks headers with a CRLF at 8192

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

From report at bugs.python.org  Tue Jun  2 11:17:49 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jun 2009 09:17:49 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243934269.96.0.4345338791.issue6170@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Now I'm really confused, I tried  to install a second time and this time I 
do get an error. 

Time to start hunting down an issue...

----------

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

From report at bugs.python.org  Tue Jun  2 11:19:45 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 02 Jun 2009 09:19:45 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243934385.05.0.883730754181.issue6170@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ronald, did you try Sridar precise sequence after Pyhon was built ?

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image

----------

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

From report at bugs.python.org  Tue Jun  2 11:21:41 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jun 2009 09:21:41 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243934501.44.0.915236871707.issue6170@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Manually running "make frameworkinstallframework" (and the other ones) is 
not supported, those are internal makefile targets that are are used to 
implement "make install". 

"make framworkinstall" is supported as an alias for "make install" because 
the former was the only way to install a framework for a long time.

----------

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

From report at bugs.python.org  Tue Jun  2 11:46:06 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 02 Jun 2009 09:46:06 +0000
Subject: [issue4829] confusing error for file("foo", "w++")
In-Reply-To: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>
Message-ID: <1243935966.21.0.526616193866.issue4829@psf.upfronthosting.co.za>


Ulrich Eckhardt <eckhardt at satorlaser.com> added the comment:

Good catch, it just took me a while to actually figure out myself where
the bug is. Try the following instead:

  import io
  io.FileIO('foo.text', 'w++')

This will yield "ValueError: Must have exactly one of read/write/append
mode" with 2.6 on win32. I haven't tested on the latest 2.x or 3.x
branches, but looking at the 2.7 branch, I see the faulty code is still
there.

BTW:
Using io.open('foo.text', 'w++') yields "ValueError: invalid mode:
'w++'", I would have expected the same error as for io.FileIO() above.
Using open('foo.text', 'w++') works.
Using open('foo.text', 'ww++') yields "IOError: [Errno 22] invalid mode
('ww++') or filename: 'foo.text')".

In other words, Python 2.6 is behaving a bit inconsistent here. The
patch only fixes one of those issues, the others and the necessary unit
tests remain.

----------

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

From report at bugs.python.org  Tue Jun  2 11:51:21 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 02 Jun 2009 09:51:21 +0000
Subject: [issue6176] Reference to a wrong version of flock's documentation
In-Reply-To: <1243936280.77.0.510370484524.issue6176@psf.upfronthosting.co.za>
Message-ID: <1243936280.77.0.510370484524.issue6176@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

It seems that the "flock" wrapped by the fcntl module is the one
descriebd in "flock(2)", not "flock(3)" (just in case this might confuse
people...)

Quote : 
"""
fcntl.flock(fd, op)
Perform the lock operation op on file descriptor fd (file objects
providing a fileno() method are accepted as well). See the Unix manual
flock(3) for details. (On some systems, this function is emulated using
fcntl.)
"""

Regards, 
Pascal

----------
assignee: georg.brandl
components: Documentation
messages: 88735
nosy: georg.brandl, pakal
severity: normal
status: open
title: Reference to a wrong version of flock's documentation
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  2 12:12:51 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jun 2009 10:12:51 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243937571.03.0.994273453921.issue6170@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I found the issue.

In r72899 antoine.pitrou checked in a change that adds these two lines 
to the bininstall target in Makefile.pre.in:

   -rm -f $(DESTDIR)$(LIBPC)/python3.pc
   (cd $(DESTDIR)$(LIBPC); $(LN) -s python-$(VERSION).pc python3.pc)

This exposes a bug in the configure script, which causes target 
'bininstall' to run before 'libainstall' when your doing a framework 
install.  The latter target is the one that creates python-
$(VERSION).pc, which is why we get build failures.

What I don't understand is why I've been able to install frameworks all 
along and didn't notice this before. 

I'm working on a patch, and will check that in after I've full tested 
it.

The important bit of the patch is this change to configure.in:

-		FRAMEWORKALTINSTALLFIRST="frameworkinstallstructure 
bininstall maninstall"
+		FRAMEWORKALTINSTALLFIRST="frameworkinstallstructure "

----------
components: +Macintosh -2to3 (2.x to 3.0 conversion tool), Distutils

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

From report at bugs.python.org  Tue Jun  2 12:56:40 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 02 Jun 2009 10:56:40 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243940200.6.0.807817893604.issue6170@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This should be fixed in r73142, please test.

----------
resolution:  -> fixed
status: open -> pending

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

From report at bugs.python.org  Tue Jun  2 13:48:43 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 02 Jun 2009 11:48:43 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1243943323.73.0.528151994758.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Re. point (a): The configuration logic assumes that if you put things in
the configuration file, you want them included - that means
instantiating handlers, which will generally open their output files
(uness the delay parameter is set) and sockets. If you use append
semantics for files and configure levels as you want them, the files are
opened but not written to (and closed when the handlers are closed or
the application exits). This is not a bug, as it was designed to work
like this.

Re. point (b): Agreed that the presence of the sections may not seem
necessary as you could achieve the same with loggers=, handlers= etc.
The sections were originally placed there as a place to hang other
settings which could apply across loggers, handlers etc. - which never
materialised. In any case, it's not a big problem and not worth breaking
backward compatibility for. The qualname is not always the same as the
value in the section header - see the documentation for an example of
this, search for "compiler.parser". The values in e.g. the section
header and the handlers= section are just names to allow the
configuration to cross-refer different parts of the configuration - so
you could use h1, h2 etc. as handler names.

Re. point (c): there are alternative ways of configuring logging; for
one example, see http://www.red-dove.com/python_config.html and look at
"logconfig.cfg" and "logconfig.py" in the linked tarball/zip.

----------

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

From report at bugs.python.org  Tue Jun  2 13:54:35 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Tue, 02 Jun 2009 11:54:35 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243943675.56.0.995768002585.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Take a look at the output:
$ python pydoc.py test.pydoc_badimport2
problem in test.pydoc_badimport2 - <type 'exceptions.ImportError'>: No
module named i_dont_exist.neither_do_i

This is different from what you expected. How do we change this output?
(I was talking about this issue in the last message)

----------

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

From report at bugs.python.org  Tue Jun  2 15:10:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jun 2009 13:10:48 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1243948248.59.0.259362728161.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm sorry, I mistyped.  That is the error message I was expecting (it's
derived from the one 'import' gives in that case).   If the test were
like this:

    elif exc is ImportError and str(value).endswith(path.split('.')[-1]):

then I think the tests would pass (but I haven't checked yet).

----------

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

From report at bugs.python.org  Tue Jun  2 15:24:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 02 Jun 2009 13:24:48 +0000
Subject: [issue6117] Fix O(n**2) performance problem in socket._fileobject
In-Reply-To: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>
Message-ID: <1243949088.06.0.346753089982.issue6117@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Checked into trunk as r73145

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
resolution:  -> accepted

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

From report at bugs.python.org  Tue Jun  2 15:27:22 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 02 Jun 2009 13:27:22 +0000
Subject: [issue6117] Fix O(n**2) performance problem in socket._fileobject
In-Reply-To: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>
Message-ID: <1243949242.44.0.982687103826.issue6117@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jun  2 15:38:49 2009
From: report at bugs.python.org (Clay McClure)
Date: Tue, 02 Jun 2009 13:38:49 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8517e9350906012350qbf035fboabb37390e920f700@mail.gmail.com>
Message-ID: <8657ee3f0906020638j6af37b22m3ef36ca5d3c1d958@mail.gmail.com>


Clay McClure <clay at daemons.net> added the comment:

On Tue, Jun 2, 2009 at 2:52 AM, pmoody <report at bugs.python.org> wrote:

>> As far as I can
>> tell, every developer in that category, outside of Google, that has
>> commented on this issue here or in python-dev has advocated a
>> different API.
>
> Is there some sort of conspiracy theory-ish reason that a google
> software engineer might be somehow unfairly influenced?

>From reading your comments and the code, it is clear that concepts
that aren't relevant at Google have been neglected. For that reason,
developers at Google who are already familiar with ipaddr might
consider its API quite natural because of their institutionalized
thinking. But since this library is now intended for general purpose
use outside Google, I should think it is important to consult
developers outside Google who have been exposed to a broader range of
IP addressing issues. I don't believe that "good enough for Google"
ought to be our acid test.

The fact that developers outside Google seem to prefer a different API
is not new -- comments in this issue dating back several months
reflect that fact. What I don't see is a comment that explains why
their concerns were not considered.

Clay

----------

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

From report at bugs.python.org  Tue Jun  2 15:42:59 2009
From: report at bugs.python.org (James)
Date: Tue, 02 Jun 2009 13:42:59 +0000
Subject: [issue6142] Distutils doesn't remove .pyc files
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1243950179.54.0.762930502516.issue6142@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

Currently, I have (had) a make file with a clean target that would
remove these files. Would you recommend keeping this file and it's
associated functionality, or is the idea to be able to integrate this
into distutils and be able to do away with makefiles for python projects?

I'm aware that I can subclass Command and make my own "target"... I've
done this, but it seems to me it's better suited upstream.

----------

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

From report at bugs.python.org  Tue Jun  2 15:46:47 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Jun 2009 13:46:47 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243723272.11.0.154600236805.issue1943@psf.upfronthosting.co.za>
Message-ID: <4A252D43.2000106@egenix.com>


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

Jim Jewett wrote:
> Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:
> 
> There were a number of patches to support sharing of data between 
> unicode objects.  (By Larry Hastings?)  They were rejected because (a)  
> they were complicated, and (b)  it was possible to provoke pathological 
> memory retention.

Right, but the patches were targeting the main Unicode type implementation.

It would certainly be possible to implement these features on a Unicode
sub-type.

Note that the Unicode type implementation on which the Python type
is based did in fact use references to other objects in order to
implement sharing.

This part was removed from the base type due to the issues with
unwillingly keeping alive large reference objects. However, the
implementation can be used as basis for writing a Unicode sub-type
which does implement data sharing.

If you're looking for application space where such data sharing
types are useful, have a look at parsing engines or routines
that split larger chunks of data in multiple smaller pieces.
Shared memory is another use case where such types would enable
sharing of Unicode data between processes... but I'm repeating
myself.

----------

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

From report at bugs.python.org  Tue Jun  2 15:53:37 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Jun 2009 13:53:37 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243723809.16867.4.camel@localhost>
Message-ID: <4A252EDC.8020209@egenix.com>


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

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> There were a number of patches to support sharing of data between 
>> unicode objects.  (By Larry Hastings?)  They were rejected because (a)  
>> they were complicated, and (b)  it was possible to provoke pathological 
>> memory retention.
> 
> Yes, it's the "lazy strings" patches by Larry Hastings (it was for str,
> not unicode, though). Issues are #1590352 and #1569040 (and perhaps
> others).
> 
> In any case, as I said, it is easy to switch back to the old
> representation, so I don't think it is an argument to block this patch.

That's not the case.

The patch breaks C API + binary compatibility for an essential Python
type - that's not something you can easily undo.

----------

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

From report at bugs.python.org  Tue Jun  2 16:12:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jun 2009 14:12:50 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A252EDC.8020209@egenix.com>
Message-ID: <1243952101.5426.15.camel@localhost>


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

> The patch breaks C API + binary compatibility for an essential Python
> type - that's not something you can easily undo.

I don't see how it breaks C API compatibility. No officially documented
function has changed, and the accessor macros still work. Am I missing
something?

As for binary compatibility, yes, it does break it, which isn't an
exceptional situation in the development process. We have changed other
"essential types" too -- for example, recently, the PyLong object got
30-bit digits on some systems. Why you think it is hard to undo, I don't
understand.

As for the future ABI PEP, which has not yet been accepted, it does not
mention PyUnicodeObject as part of the structures which are guaranteed
to remain binary-compatible :
http://www.python.org/dev/peps/pep-0384/#structures

----------

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

From report at bugs.python.org  Tue Jun  2 16:17:14 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 02 Jun 2009 14:17:14 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243952234.34.0.405072921143.issue1943@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Tue Jun  2 16:38:17 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Jun 2009 14:38:17 +0000
Subject: [issue6177] unittest.main testRunner default argument changed from
	None
In-Reply-To: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>
Message-ID: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

In Python 2.6 the testRunner keyword argument to unittest.main
(TestProgram) changed from None to TextTestRunner.

This breaks test suites (like the setuptools tests) which pass in None
when not wanting to override the default.

This is easy to fix without breaking anything (but hard to test). I will
be fixing this and backporting to 2.6-maint unless there are objections.

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 88747
nosy: michael.foord
severity: normal
status: open
title: unittest.main testRunner default argument changed from None
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun  2 16:41:06 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 02 Jun 2009 14:41:06 +0000
Subject: [issue6177] unittest.main testRunner default argument changed from
	None
In-Reply-To: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>
Message-ID: <1243953666.63.0.591889683688.issue6177@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +tarek

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

From report at bugs.python.org  Tue Jun  2 17:36:13 2009
From: report at bugs.python.org (Tim Savannah)
Date: Tue, 02 Jun 2009 15:36:13 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>


New submission from Tim Savannah <tsavanna at arinc.com>:

I'm getting many segmentation faults (about 1 per half hour) from within
the core of python 2.6.2 on 64-bit machines.

(examples from dmesg:
pythonLaunch.py[13307]: segfault at 0000000000000058 rip
00002b845cfb3550 rsp 0000000041809930 error 4
pythonLaunch.py[27589]: segfault at 0000000000000058 rip
00002b4112287906 rsp 0000000042dab930 error 4
pythonLaunch.py[14436]: segfault at 0000000000000058 rip
00002ae0a4f68550 rsp 0000000042cd9930 error 4
pythonLaunch.py[10374]: segfault at 0000000000000058 rip
00002af43f966906 rsp 000000004214b930 error 4
pythonLaunch.py[17656]: segfault at 0000000000000058 rip
00002aed0cfe8906 rsp 00000000417f0930 error 4
)
pythonLaunch.py is a symbolic link to python 2.6.2 binary.
>From disassembling the python binary, I've found the corrosponding line
in source to be ceval.c:2717

if (tstate->frame->f_exc_type != NULL)

tstate->frame is null, and an access on f_exc_type causes a segfault
(trying to access memory 0x58, see above segfaults).

I can't find any clear code path that could cause tstate->frame to go
null, any suggestions? This is preventing us from moving from python 2.4
32-bit to python 2.6 64-bit.

----------
components: Interpreter Core
messages: 88748
nosy: tsavannah
severity: normal
status: open
title: Core error in Py_EvalFrameEx 2.6.2
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  2 18:07:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jun 2009 16:07:05 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243958825.71.0.154162587026.issue6178@psf.upfronthosting.co.za>


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

Have you compiled Python yourself?
Are you using any third-party C extensions?

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

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

From report at bugs.python.org  Tue Jun  2 18:11:44 2009
From: report at bugs.python.org (Tim Savannah)
Date: Tue, 02 Jun 2009 16:11:44 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243959104.99.0.50369642296.issue6178@psf.upfronthosting.co.za>


Tim Savannah <tsavanna at arinc.com> added the comment:

Yes I compiled python myself, using ./configure
--prefix=/usr/local/python2.6/ --with-pth --enable-shared

It is a 64-bit compile.

I've done this with both standard config and a config that I modded
which produces optimizations options as -ggdb3 -O0. Both contain the
segfault error.

We are including some external site packages, but there is no consistent
site package import or usage that causes the segfault, it just seems
that heavy stress with many threads going off has a race chance to cause it.

I can send any additional info that can help debug this issue

----------

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

From report at bugs.python.org  Tue Jun  2 18:38:55 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Jun 2009 16:38:55 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243952101.5426.15.camel@localhost>
Message-ID: <4A25559B.8090001@egenix.com>


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

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> The patch breaks C API + binary compatibility for an essential Python
>> type - that's not something you can easily undo.
> 
> I don't see how it breaks C API compatibility. No officially documented
> function has changed, and the accessor macros still work. Am I missing
> something?

Yes: The layout and object type of the PyUnicodeObject object.

You cannot simply recompile your code and have it working. Instead,
you have to provide different sub-typing implementations depending
on whether PyUnicodeObject is a PyVarObject or PyObject, since
these are inherently different in their structure.

Please note that all type objects documented in the header files
not explicitly declared for private use only, are in fact
public APIs. You need access to those type objects in order to
be able to subclass them.

> As for binary compatibility, yes, it does break it, which isn't an
> exceptional situation in the development process. We have changed other
> "essential types" too -- for example, recently, the PyLong object got
> 30-bit digits on some systems. Why you think it is hard to undo, I don't
> understand.

That's a different kind of change. Even though it's very hard to
sub-type longs due to their PyVarObject nature and the fact that
longs even dig into the PyObject_VAR_HEAD, you can still recompile
your code and it will continue to work. The change was to a typedef -
the name of the typedef itself has not changed.

This is similar to compiling Python as UCS2 or UCS4 version - Py_UNICODE
will stay the same typedef, but on a UCS2 system it maps to 16 bits,
whereas on a UCS4 system it is set to 32 bits.

Note that the Unicode implementation takes great care not to hide
this binary incompatibility - by remapping all APIs to include the
UCS2/UCS4 hint in the exported name. As an side: The long implementation
does not.

> As for the future ABI PEP, which has not yet been accepted, it does not
> mention PyUnicodeObject as part of the structures which are guaranteed
> to remain binary-compatible :
> http://www.python.org/dev/peps/pep-0384/#structures

That's fine, but please note that the ABI PEP only addresses
applications that wish to benefit from the binary compatibility
across Python versions.

It has no implications on applications that don't want to use
the ABI or cannot, since they are too low-level, such as extensions
wishing to sub-class built-in types.

----------

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

From report at bugs.python.org  Tue Jun  2 18:41:26 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Jun 2009 16:41:26 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1243960886.79.0.638471035649.issue3959@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This issue is closed.

Please take discussion up on a mailing list.

----------

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

From report at bugs.python.org  Tue Jun  2 19:00:27 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 02 Jun 2009 17:00:27 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>
Message-ID: <1243962027.69.0.48604627626.issue3959@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Jun  2 19:17:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jun 2009 17:17:42 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A25559B.8090001@egenix.com>
Message-ID: <1243963193.5426.42.camel@localhost>


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

> You cannot simply recompile your code and have it working.

Who is "you"?
People doing mundane things with PyUnicodeObjects certainly can,
assuming they use the macros for any member access.

> Please note that all type objects documented in the header files
> not explicitly declared for private use only, are in fact
> public APIs.

If the datatype layout is not publicly documented in the API reference,
it certainly seems to be a non-public part of the API. That's why we
have macros for member access, instead of letting people access members
directly.

The fact that my patch doesn't touch any part of the C sources except
for the unicode implementation itself seems to support this view as
well: people have been using the macros because they understand the
actual layout shouldn't be relied upon.

> You need access to those type objects in order to
> be able to subclass them.

As is needed for every other core object whose layout is nevertheless
changed now and then... I think it should be expected that any code
relying on low-level implementation specifics can break now and then.
Changing low-level implementation specifics is often a prerequisite for
improving things and it would be foolish to make a promise that we
guarantee 100% compatibility at that level.

(we could of course strengthen the rules for unicode if it was
demonstrated that there are several popular instances of subclassing
unicode in a C extension. However, I haven't seen any such examples)

> Note that the Unicode implementation takes great care not to hide
> this binary incompatibility - by remapping all APIs to include the
> UCS2/UCS4 hint in the exported name.

That's because there are UCS2 and UCS4 builds *of the same interpreter
version*, and people are not necessarily aware of there being a
difference. Such variability is not what we are talking about here.

----------

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

From report at bugs.python.org  Tue Jun  2 19:22:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jun 2009 17:22:50 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243963370.93.0.361666441208.issue6178@psf.upfronthosting.co.za>


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

If the third-party packages include some C extensions, have they been
recompiled with the new Python build?

Also, does the segfault disappear if you disable optimizations?
Have you tried with another compiler version?

(I'm asking all this because to my knowledge it's the first time such
random crashes happen in the Python core with 2.6, which was released
quite a while ago)

----------

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

From report at bugs.python.org  Tue Jun  2 19:31:09 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Jun 2009 17:31:09 +0000
Subject: [issue6156] Error compiling valid regex
In-Reply-To: <1243787162.44.0.999226480683.issue6156@psf.upfronthosting.co.za>
Message-ID: <1243963869.43.0.679317427955.issue6156@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 3.0

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

From report at bugs.python.org  Tue Jun  2 19:32:31 2009
From: report at bugs.python.org (Tim Savannah)
Date: Tue, 02 Jun 2009 17:32:31 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243963951.77.0.346294554614.issue6178@psf.upfronthosting.co.za>


Tim Savannah <tsavanna at arinc.com> added the comment:

All site-packages were compiled against python 2.6.1, and python was
upgraded later to 2.6.2 (but upon running a make install with python
2.6.2, it seemed to recompile site-packages on a byte-code level).

And no, there is still segfaults without optimizations, I've tried at
-O2 -O and -O0 ( -O0 being no optimization). Judging by the invalid read
always being on 0x58, and the line of assembly accessing 0x58 offset
from a register, tstate->frame must be being initilized to NULL (or
always being corrupted to point to other NULL data)

The compiler used is gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)

The setup we are using is 8-core xeon 64-bit servers. (We have about 14
of these, Centos based systems, all are experiencing the segfaults).

----------

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

From report at bugs.python.org  Tue Jun  2 19:37:31 2009
From: report at bugs.python.org (Eric Promislow)
Date: Tue, 02 Jun 2009 17:37:31 +0000
Subject: [issue6126] Python 3 pdb: shows internal code, breakpoints don't work
In-Reply-To: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>
Message-ID: <1243964251.97.0.313158032192.issue6126@psf.upfronthosting.co.za>


Eric Promislow <ericp at activestate.com> added the comment:

Similar problem with 3.1rc1:

C:\...>c:\Python31rc1\python.exe -m  pdb hello01.py
--Return--
> c:\python31rc1\lib\encodings\cp437.py(19)encode()->b'Hello'
-> return codecs.charmap_encode(input,self.errors,encoding_map)[0]
(Pdb) b 2
*** Blank or comment
(Pdb) b hello01.py:2
Breakpoint 1 at c:\...\hello01.py:2

(Pdb) b
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at c:\...\hello01.py:2
(Pdb) c
Hello
here
bye
The program finished and will be restarted
--Return--
> c:\python31rc1\lib\encodings\cp437.py(19)encode()->b'Hello'
-> return codecs.charmap_encode(input,self.errors,encoding_map)[0]
(Pdb)

----------

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

From report at bugs.python.org  Tue Jun  2 19:46:24 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Jun 2009 17:46:24 +0000
Subject: [issue6177] unittest.main testRunner default argument changed from
	None
In-Reply-To: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>
Message-ID: <1243964784.57.0.868076456778.issue6177@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file14155/fix_unittest_main.patch

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

From report at bugs.python.org  Tue Jun  2 19:50:56 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Jun 2009 17:50:56 +0000
Subject: [issue1244929] hide tests from TestProgram
Message-ID: <1243965056.98.0.265006964325.issue1244929@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

A module can now define load_tests (used by loadTestsFromModule) and
exclude certain classes itself.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Jun  2 20:04:52 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Jun 2009 18:04:52 +0000
Subject: [issue6177] unittest.main testRunner default argument changed from
	None
In-Reply-To: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>
Message-ID: <1243965892.85.0.560463679479.issue6177@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Feel free to apply this to 2.6.

----------
nosy: +barry
resolution:  -> accepted

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

From report at bugs.python.org  Tue Jun  2 20:23:09 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Jun 2009 18:23:09 +0000
Subject: [issue6177] unittest.main testRunner default argument changed from
	None
In-Reply-To: <1243953497.61.0.923685301175.issue6177@psf.upfronthosting.co.za>
Message-ID: <1243966989.43.0.409845946554.issue6177@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed to trunk in revision 73151 and revision 73152.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Jun  2 20:25:34 2009
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Jun 2009 18:25:34 +0000
Subject: [issue1207] Load tests from path (patch included)
In-Reply-To: <1190834704.12.0.956914269209.issue1207@psf.upfronthosting.co.za>
Message-ID: <1243967134.22.0.0244900894655.issue1207@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Similar functionality is now in TestLoader.discover.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jun  2 20:40:16 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Tue, 02 Jun 2009 18:40:16 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1243968016.78.0.130025200854.issue2919@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Fixed a couple of typos in the README and _profile_hires.c files of the 
attached profile_module2.tgz tar ball.

----------
Added file: http://bugs.python.org/file14156/profile_module2.tgz

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

From report at bugs.python.org  Tue Jun  2 20:40:27 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Tue, 02 Jun 2009 18:40:27 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1243968027.17.0.357051105022.issue2919@psf.upfronthosting.co.za>


Changes by Jean Brouwers <MrJean1 at Gmail.com>:


Removed file: http://bugs.python.org/file14131/profile_module.tgz

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

From report at bugs.python.org  Tue Jun  2 21:34:18 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 02 Jun 2009 19:34:18 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1243971258.25.0.471580043201.issue6136@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

a) What is the point of opening files that will never be written to and
sockets that will never be used? 

A large application might have a great many loggers for debugging which
are off by default, and this means you have to either put up with lots
of empty files being created all the time, or tell everyone that they
need to change the configuration in two places each time they enable or
disable a logger.

Logging config files need to be easy to tweak, even for people who
aren't coders: it should be quick and obvious how to enable or disable a
logger.

b) I don't see why making those sections optional would break backward
compatibility. It would be easy to just silently ignore them if they
were present (or call today's code that uses them). 

I'm aware that "qualname" isn't always the same as the section name. My
point is that it should not be *compulsory*, not that it shouldn't
exist. It has an obvious default value so it's wrong to fail with a
python stack if it isn't present.

c) I know there are other packages out there. I've been using log4py for
years, which is now abandoned. But Python now has an official way to do
logging and I think it should be more user-friendly for simple usage
than it is. I can write my own config file format without too much
difficulty but it seems a shame if everyone ends up doing this.

(The one you linked to seemed to have wider ambitions than logging and
its format seemed even more unwieldy. Curly braces in Python?!)

----------

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

From report at bugs.python.org  Tue Jun  2 21:34:22 2009
From: report at bugs.python.org (Marshall Roach)
Date: Tue, 02 Jun 2009 19:34:22 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243971262.12.0.864027053369.issue6178@psf.upfronthosting.co.za>


Changes by Marshall Roach <mroach at arinc.com>:


----------
nosy: +mroach

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

From report at bugs.python.org  Tue Jun  2 22:21:48 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 02 Jun 2009 20:21:48 +0000
Subject: [issue6179] Documentation of for statement in Reference says that
	range() returns a list
In-Reply-To: <1243974108.3.0.443832431096.issue6179@psf.upfronthosting.co.za>
Message-ID: <1243974108.3.0.443832431096.issue6179@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of the for statement in Section 7 of the Python 3
Reference states "range(3) returns the list [0, 1, 2]". Since range() no
longer returns a list, shouldn't this statement be made more precise?
(since this is the reference it should be technically accurate)

----------
assignee: georg.brandl
components: Documentation
messages: 88764
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of for statement in Reference says that range() returns a list
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jun  2 22:59:57 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Jun 2009 20:59:57 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243976397.85.0.865756663069.issue6154@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch

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

From report at bugs.python.org  Tue Jun  2 23:21:07 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 02 Jun 2009 21:21:07 +0000
Subject: [issue6180] Tkinter.Entry: fix for xview and some doc clarifications
In-Reply-To: <1243977667.14.0.414043606697.issue6180@psf.upfronthosting.co.za>
Message-ID: <1243977667.14.0.414043606697.issue6180@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

The xview method in Tkinter.Entry doesn't indicate that index may be
None, which is used to query the Entry xview. I also considered that the
 docstrings in the selection_range and selection_present methods needed
some clarifications, so the attached patch also fixes this.

----------
components: Tkinter
files: Entry_fixes.diff
keywords: patch
messages: 88765
nosy: gpolo
severity: normal
status: open
title: Tkinter.Entry: fix for xview and some doc clarifications
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14157/Entry_fixes.diff

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

From report at bugs.python.org  Tue Jun  2 23:24:59 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 02 Jun 2009 21:24:59 +0000
Subject: [issue6181] Tkinter.Listbox several minor issues
In-Reply-To: <1243977899.25.0.845872446641.issue6181@psf.upfronthosting.co.za>
Message-ID: <1243977899.25.0.845872446641.issue6181@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Hi there,

I've found several minor issues in Tkinter.Listbox which are all fixed
by the attached patch.

I'm considering the bbox method should be clear in relation to the
amount of accepted arguments, which is always one. So I dropped the
*args usage there.
The curselection method has a reminder about applying getints on it, I
have done it now. I think it is fine to finally fix it, since we have
some tests for it now (at least in the tk_and_idle_maintenance branch).
The remaining changes in the patch are all about fixing docstring of
several methods in Listbox.

----------
components: Tkinter
files: Listbox_fixes.diff
keywords: patch
messages: 88766
nosy: gpolo
severity: normal
status: open
title: Tkinter.Listbox several minor issues
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14158/Listbox_fixes.diff

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

From report at bugs.python.org  Wed Jun  3 00:07:01 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Jun 2009 22:07:01 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243980421.3.0.00495300085586.issue1943@psf.upfronthosting.co.za>


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

Here's an example implementation of a Unicode sub-type that allows
referencing other Unicode objects:

http://downloads.egenix.com/python/unicoderef-0.0.1.tar.gz

As you can see, it's pretty straight-forward to write and I want to keep
it that way.

----------

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

From report at bugs.python.org  Wed Jun  3 00:25:58 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Jun 2009 22:25:58 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243963193.5426.42.camel@localhost>
Message-ID: <4A25A6EE.9020505@egenix.com>


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

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> You cannot simply recompile your code and have it working.
> 
> Who is "you"?
> People doing mundane things with PyUnicodeObjects certainly can,
> assuming they use the macros for any member access.

As soon as they want to do C-level sub-typing, a change from
PyObject to PyVarObject will break their code in non-trivial ways.

>> Please note that all type objects documented in the header files
>> not explicitly declared for private use only, are in fact
>> public APIs.
> 
> If the datatype layout is not publicly documented in the API reference,
> it certainly seems to be a non-public part of the API. That's why we
> have macros for member access, instead of letting people access members
> directly.

Header files *are* the API reference.

There are many instances where they include things that are only
meant to be used internally by the interpreter, but these are
carefully documented in the header files.

>> You need access to those type objects in order to
>> be able to subclass them.
> 
> As is needed for every other core object whose layout is nevertheless
> changed now and then... I think it should be expected that any code
> relying on low-level implementation specifics can break now and then.
> Changing low-level implementation specifics is often a prerequisite for
> improving things and it would be foolish to make a promise that we
> guarantee 100% compatibility at that level.

It would be foolish to break such compatibility for the sake of some
really minor performance win.

Python's main focus is flexibility, not speed. Your proposed change
makes it a lot harder to tap into the available flexibility, since
sub-typing of PyVarObjects is non-trivial.

> (we could of course strengthen the rules for unicode if it was
> demonstrated that there are several popular instances of subclassing
> unicode in a C extension. However, I haven't seen any such examples)

Well, since you don't appear to count the many attempts to get
slicing-by-reference into the base type as proof that such ideas
do have use-cases, I've posted an example implementation which
provides such a sub-type.

It's easy to extend to all the use cases I've mentioned so far.

----------

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

From report at bugs.python.org  Wed Jun  3 00:42:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Jun 2009 22:42:18 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243982538.01.0.118685885381.issue6154@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here's another patch.

----------
Added file: http://bugs.python.org/file14159/locale_fix.patch

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

From report at bugs.python.org  Wed Jun  3 00:43:02 2009
From: report at bugs.python.org (Kenneth Arnold)
Date: Tue, 02 Jun 2009 22:43:02 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1243982582.68.0.101215364693.issue4806@psf.upfronthosting.co.za>


Kenneth Arnold <kenneth.arnold at gmail.com> added the comment:

I can confirm that (a) this exact behavior is happening and (b) it quite
confused me (most of the time it works!). What would be a "good"
TypeError? I'd vote for generators to be explicitly supported even if it
required a special case. Thanks!

----------
nosy: +kcarnold

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

From report at bugs.python.org  Wed Jun  3 00:46:14 2009
From: report at bugs.python.org (Evan Behar)
Date: Tue, 02 Jun 2009 22:46:14 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243982774.56.0.050517109456.issue6154@psf.upfronthosting.co.za>


Evan Behar <behare at gmail.com> added the comment:

I think I've found the problem.

In configure:

  13830 if test "${ac_cv_lib_intl_textdomain+set}" = set; then
  13831   echo $ECHO_N "(cached) $ECHO_C" >&6
  13832 else
  13833   ac_check_lib_save_LIBS=$LIBS
  13834 LIBS="-lintl  $LIBS"

but then 

  13883 rm -f core conftest.err conftest.$ac_objext
conftest_ipa8_conftest.oo \
  13884       conftest$ac_exeext conftest.$ac_ext
  13885 LIBS=$ac_check_lib_save_LIBS

ac_check_lib_save_LIBS is assigned before -lintl is added to LIBS, and
then LIBS is unconditionally re-assigned to ac_check_lib_save_LIBS a
little bit further down, which then doesn't have -lintl in it.

I've included a patch that changes this to be:

  ...

  13880         ac_cv_lib_intl_textdomain=no
  13881         LIBS=$ac_check_lib_save_LIBS
  13882 fi
  13883 
  13884 rm -f core conftest.err conftest.$ac_objext
conftest_ipa8_conftest.oo \
  13885       conftest$ac_exeext conftest.$ac_ext
  13886 fi

So that LIBS is only restored to the saved state if the check fails.

I'm not sure if mucking with the configure file directly is a great
idea, but this was the simplest thing I could think of that would work.

----------
nosy: +ebehar
Added file: http://bugs.python.org/file14160/configure_lintl.patch

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

From report at bugs.python.org  Wed Jun  3 00:48:00 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 02 Jun 2009 22:48:00 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1243982880.11.0.927062088446.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

a) Loggers don't have a one-to-one correspondence to files that are
opened, so I don't quite understand your point. Perhaps you are
conflating loggers with handlers. The common way of using logging is to
have a small number of file-based handlers and perhaps a socket handler
and console handler, working with a potentially much larger number of
loggers.

b) If you want to propose a patch (incl. tests and docs) which maintains
backward compatibility, I'll certainly look at it.

the qualname *is* compulsory as it determines exactly which logger is
instantiated. So I don't understand your statement.

c) Having used log4py (which I'm not familiar with), it may be that you
have to consider that Python's logging package might do some things
differently. You are of course free to use your own configuration format
- it's one of those areas where personal taste is more of a factor. I
don't know of any alternative formats which have a lot of traction for
configuring logging specifically, though the programmatic API for
configuring logging is pretty simple and almost any other configuration
approach could be made to fit.

It's funny to hear you comment on the inappropriateness of curly braces
in Python, how do you manage without dict literals? ;-)

It's probably best not to continue this discussion on the issue tracker
- it's not the best place as it's not its intended purpose, and also the
audience here will be much smaller than, say, comp.lang.python. Before
rolling your own config format, I would suggest posting on c.l.py with
your difficulties with logging configuration and see how others have
coped with those or similar problems.

----------

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

From report at bugs.python.org  Wed Jun  3 00:50:27 2009
From: report at bugs.python.org (Evan Behar)
Date: Tue, 02 Jun 2009 22:50:27 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243983027.05.0.890748894384.issue6154@psf.upfronthosting.co.za>


Evan Behar <behare at gmail.com> added the comment:

I applied Benjamin's new patch to the original files, but I receive the
same error, and the LIBS in the Makefile still only has -ldl and not -lintl.

----------

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

From report at bugs.python.org  Wed Jun  3 01:09:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Jun 2009 23:09:41 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243984181.43.0.571264141153.issue1943@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, I'm inclined to agree that this would be a destabilizing change.

Guido, do you care to pronounce on whether it is okay to change the struct?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum, rhettinger

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

From report at bugs.python.org  Wed Jun  3 01:25:45 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 02 Jun 2009 23:25:45 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243985145.08.0.537124652882.issue1943@psf.upfronthosting.co.za>


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

If this is not yet in 3.1, it's clearly too late to add it (now that RC1
was already released).  If was in already (hard to tell from the long
bug), I think it should be kept in (removing it would destabilize more
than keeping it).

----------

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

From report at bugs.python.org  Wed Jun  3 01:30:31 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Jun 2009 23:30:31 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243985431.86.0.643668801154.issue1943@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It's not in 3.1.  It is a proposal for 3.2 that changes the struct from
what it is in 3.0 and 3.o.

----------

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

From report at bugs.python.org  Wed Jun  3 01:32:55 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Jun 2009 23:32:55 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243985575.28.0.221727402694.issue1943@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Correction:  It is a proposal for 3.2 that changes the struct used in
3.0 and 3.1.

----------

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

From report at bugs.python.org  Wed Jun  3 01:33:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Jun 2009 23:33:08 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243985588.77.0.464583217574.issue1943@psf.upfronthosting.co.za>


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


----------

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

From report at bugs.python.org  Wed Jun  3 01:35:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Jun 2009 23:35:03 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243963951.77.0.346294554614.issue6178@psf.upfronthosting.co.za>
Message-ID: <1243985837.5888.36.camel@localhost>


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

> And no, there is still segfaults without optimizations, I've tried at
> -O2 -O and -O0 ( -O0 being no optimization).

Then you can try rebuilding Python after "./configure --with-pydebug".
It will add some runtime checks, perhaps it will find the cause of the
problem.

----------

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

From report at bugs.python.org  Wed Jun  3 01:51:47 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 02 Jun 2009 23:51:47 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1243986707.72.0.514977063082.issue1943@psf.upfronthosting.co.za>


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

That's unfortunate; it would clearly have been easier to change this in 3.1.

That said, I'm not sure anyone *should* be subclassing PyUnicode.  Maybe
Marc-Andre can explain why he is doing this (or point to the message in
this thread where he explained this before)?  If it's a viable use case,
it should be possible to have some symbol or a few symbols whose
presence can be tested in the preprocessor by code that needs to
subclass; we should design the patch with that in mind and Marc-Andre
could help testing it.

All this is assuming the speed-up is important enough to bother.  Has
anyone run a comparison benchmark using the Unladen Swallow benchmarks?
 I trust those much more than micro-benchmarks (including, I assume,
stringbench.py).  I do expect that reducing the number of allocations
for short-to-medium-size strings from 2 to 1 would be a significant
speed-up, but I can't guess how much.

----------

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

From report at bugs.python.org  Wed Jun  3 02:17:22 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 00:17:22 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243988242.41.0.220854651991.issue6154@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file14161/locale_fix2.patch

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

From report at bugs.python.org  Wed Jun  3 02:59:03 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Jun 2009 00:59:03 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243990743.39.0.13284643043.issue6154@psf.upfronthosting.co.za>


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

@Evan -- You need to edit configure.in and use autoconf to regenerate
configure.

@Benjamin -- your second patch leads to an infinite recursion or
something with 'y\n' being printed out constantly.

----------

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

From report at bugs.python.org  Wed Jun  3 03:04:05 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 01:04:05 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243991045.08.0.526533919887.issue6154@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

What about the third?

----------

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

From report at bugs.python.org  Wed Jun  3 03:21:10 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Jun 2009 01:21:10 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243992070.83.0.821732311647.issue6154@psf.upfronthosting.co.za>


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

I meant locale_fix2.patch causes the infinite output.

Regardless, I now have my own patch that solves the problem. I simply
make sure that if the check for intl passes it also added "-lintl" to
$LIBS. You will need to run autoconf/autoheader yourself as when I ran
it svn diff complained about different line endings on configure.

----------
Added file: http://bugs.python.org/file14162/add_lintl.patch

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

From report at bugs.python.org  Wed Jun  3 03:25:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 01:25:09 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243992309.7.0.154060510565.issue6154@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Does that fix framework builds, too?

----------

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

From report at bugs.python.org  Wed Jun  3 03:57:59 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 01:57:59 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1243994279.45.0.586719823814.issue6170@psf.upfronthosting.co.za>


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

That seems to work.  However, while testing that, I found another, minor 
problem in that same area.  In Makefile.pre.in bininstall target just 
before the lines you cite, there is also this added in r71935:

-rm -f $(DESTDIR)$(BINDIR)/python3-config
(cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)-config python3-
config)

Prior to that, though, the Mac Makefile target install_versionedtools is 
mucking in the same area:

if [ ! -h "$(DESTDIR)$(prefix)/bin/python3-config" ]; then \
  mv "$(DESTDIR)$(prefix)/bin/python3-config" 
"$(DESTDIR)$(prefix)/bin/python$(VERSION)-config" ;\
  ln -sf "python$(VERSION)-config" "$(DESTDIR)$(prefix)/bin/python3-
config" ; \
fi

and, in fact, the mv fails with an error because (1) the python3-config 
hasn't been created yet and (2) the test is incorrect: ! -h is also true 
if the file doesn't exist.  With the code in bininstall, I think these 
lines can be safely removed from install_versionedtools.

----------
status: pending -> open

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

From report at bugs.python.org  Wed Jun  3 04:03:03 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Jun 2009 02:03:03 +0000
Subject: [issue6182] Remove ipaddr library from py3k before 3.1rc2
In-Reply-To: <1243994583.57.0.193467275614.issue6182@psf.upfronthosting.co.za>
Message-ID: <1243994583.57.0.193467275614.issue6182@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Do not use this bug for discussion of the topic.  Use the python-dev 
mailing list.

This bug is here to track its removal (or not) of the ipaddr library 
pending the outcome of the mailing list discussion.  Resolving this is a 
release blocker either way.

According to http://www.python.org/dev/peps/pep-0375/ 3.1rc2 goes out on 
June 13, 2009.

----------
assignee: gregory.p.smith
messages: 88785
nosy: gregory.p.smith
priority: release blocker
severity: normal
status: open
title: Remove ipaddr library from py3k before 3.1rc2
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  3 04:19:30 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Jun 2009 02:19:30 +0000
Subject: [issue6183] test_time fails on VC6
In-Reply-To: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>
Message-ID: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

test_time fails on VC6 with following message.

======================================================================
FAIL: test_strptime (__main__.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_time.py", line 246, in <module>
    test_main()
  File "test_time.py", line 243, in test_main
    support.run_unittest(TimeTestCase, TestLocale)
  File "e:\python-dev\py3k\lib\test\support.py", line 879, in run_unittest
    _run_suite(suite)
  File "e:\python-dev\py3k\lib\test\support.py", line 854, in _run_suite
    result = runner.run(suite)
  File "e:\python-dev\py3k\lib\unittest.py", line 1490, in run
    result.printErrors()
  File "e:\python-dev\py3k\lib\unittest.py", line 1451, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "e:\python-dev\py3k\lib\unittest.py", line 1458, in printErrorList
    self.stream.writeln("%s" % err)
  File "e:\python-dev\py3k\lib\unittest.py", line 1367, in writeln
    self.write(arg)
UnicodeEncodeError: 'cp932' codec can't encode character '\x93' in
position 453:
 illegal multibyte sequence


Here is quotation from 
http://msdn.microsoft.com/en-us/library/fe06s4ak%28VS.71%29.aspx

> Note   Before this version of Visual C++, the documentation described
> the format parameter of wcsftime as having the datatype const wchar_t
> *, but the actual implementation of the format datatype was const
> char *. In this version, the implementation of the format datatype
> has been updated to reflect the previous and current documentation, 
> that is: const wchar_t *.


Can I apply attached patch? Thank you.

----------
components: Extension Modules
files: patch_for_under_71.patch
keywords: patch
messages: 88786
nosy: ocean-city
severity: normal
status: open
title: test_time fails on VC6
versions: Python 3.1
Added file: http://bugs.python.org/file14163/patch_for_under_71.patch

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

From report at bugs.python.org  Wed Jun  3 04:59:19 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 02:59:19 +0000
Subject: [issue6184] py3k build gets spurious errors from libinstall target
	compile of lib2to3 files
In-Reply-To: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>
Message-ID: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

[...]
Compiling 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/__init__.py ...
Listing 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data ...
Compiling 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data/crlf.py ...
***   File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3
/tests/data/crlf.py", line 1
    print "hi"
             ^
SyntaxError: invalid syntax

Compiling 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data/different_encoding.py ...
***   File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3
/tests/data/different_encoding.py", line 3
    
print(u'??????????????????????????????????????????????????????????????')
                                                                           
^
SyntaxError: invalid syntax

Listing 
/tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.
1/lib2to3/tests/data/fixers ...
[...]


Seen during build on OSX 10.5:
  ./configure --enable-framework --enable-
universalsdk=/Developer/SDKs/MacOSX10.4u.sdk
  make
  make install DESTDIR=/tmp/image

----------
components: 2to3 (2.x to 3.0 conversion tool), Build
messages: 88787
nosy: nad
severity: normal
status: open
title: py3k build gets spurious errors from libinstall target compile of lib2to3 files
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  3 05:09:45 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 03:09:45 +0000
Subject: [issue6184] py3k build gets spurious errors from libinstall target
	compile of lib2to3 files
In-Reply-To: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>
Message-ID: <1243998585.17.0.335146052451.issue6184@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks! Fixed in r73160.

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

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

From report at bugs.python.org  Wed Jun  3 05:13:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 03:13:47 +0000
Subject: [issue6179] Documentation of for statement in Reference says that
	range() returns a list
In-Reply-To: <1243974108.3.0.443832431096.issue6179@psf.upfronthosting.co.za>
Message-ID: <1243998827.81.0.554706565677.issue6179@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73161.

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

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

From report at bugs.python.org  Wed Jun  3 05:14:20 2009
From: report at bugs.python.org (Evan Behar)
Date: Wed, 03 Jun 2009 03:14:20 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1243998860.21.0.379032730507.issue6154@psf.upfronthosting.co.za>


Evan Behar <behare at gmail.com> added the comment:

It works fine for my framework build on 10.4.11

----------

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

From report at bugs.python.org  Wed Jun  3 05:40:28 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 03:40:28 +0000
Subject: [issue6184] py3k build gets spurious errors from libinstall target
	compile of lib2to3 files
In-Reply-To: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>
Message-ID: <1244000428.43.0.488868038681.issue6184@psf.upfronthosting.co.za>


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

r73160 does make the spurious errors go away - along with the compiles 
of all the other modules!  Suggest removing the spurious "!"'s:

926c926
< 		-x 'bad_coding|badsyntax|site-
packages|py2_test_grammar|crlf|different_encoding|' \
---
> 		-x 'bad_coding|badsyntax|site-
packages|py2_test_grammar|crlf|different_encoding' \
931c931
< 		-x 'bad_coding|badsyntax|site-
packages|py2_test_grammar|crlf|different_encoding|' \
---
> 		-x 'bad_coding|badsyntax|site-
packages|py2_test_grammar|crlf|different_encoding' \

----------
status: closed -> open

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

From report at bugs.python.org  Wed Jun  3 05:42:39 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 03:42:39 +0000
Subject: [issue6184] py3k build gets spurious errors from libinstall target
	compile of lib2to3 files
In-Reply-To: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>
Message-ID: <1244000559.33.0.183939469153.issue6184@psf.upfronthosting.co.za>


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

er, spurious "|"'s

----------

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

From report at bugs.python.org  Wed Jun  3 06:30:45 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 03 Jun 2009 04:30:45 +0000
Subject: [issue6183] test_time fails on VC6
In-Reply-To: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>
Message-ID: <4A25FC57.7080801@v.loewis.de>


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

> Can I apply attached patch? Thank you.

Looks fine to me, go ahead.

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

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

From report at bugs.python.org  Wed Jun  3 07:20:39 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Jun 2009 05:20:39 +0000
Subject: [issue6183] test_time fails on VC6
In-Reply-To: <1243995570.35.0.0241749249605.issue6183@psf.upfronthosting.co.za>
Message-ID: <1244006439.48.0.882054718109.issue6183@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, committed in r73162.

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

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

From report at bugs.python.org  Wed Jun  3 07:36:25 2009
From: report at bugs.python.org (Joe Amenta)
Date: Wed, 03 Jun 2009 05:36:25 +0000
Subject: [issue6185] 2to3 misses buffer slicing
In-Reply-To: <1244007385.35.0.333960656606.issue6185@psf.upfronthosting.co.za>
Message-ID: <1244007385.35.0.333960656606.issue6185@psf.upfronthosting.co.za>


New submission from Joe Amenta <amentajo at msu.edu>:

Found this bug while writing the backwards version of this fix for
3to2... there is no test for it, so it went undetected.  The PATTERN
does not match a buffer() invocation if there is a token after the
rparen, i.e. slicing.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: buffertest.patch
keywords: patch
messages: 88795
nosy: joe.amenta
severity: normal
status: open
title: 2to3 misses buffer slicing
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14164/buffertest.patch

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

From report at bugs.python.org  Wed Jun  3 07:37:12 2009
From: report at bugs.python.org (Joe Amenta)
Date: Wed, 03 Jun 2009 05:37:12 +0000
Subject: [issue6185] 2to3 misses buffer slicing
In-Reply-To: <1244007385.35.0.333960656606.issue6185@psf.upfronthosting.co.za>
Message-ID: <1244007432.67.0.423306775784.issue6185@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

Patch that will fix the problem (and make the test pass)

----------
Added file: http://bugs.python.org/file14165/bufferfix.patch

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

From report at bugs.python.org  Wed Jun  3 08:59:00 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Jun 2009 06:59:00 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244012339.7.0.313739614488.issue6154@psf.upfronthosting.co.za>


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

Didn't work when I turned on --enable-framework, but I have no clue how
the framework build works so I am of no help with that.

----------

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

From report at bugs.python.org  Wed Jun  3 09:41:38 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 07:41:38 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244014898.45.0.50085262383.issue5798@psf.upfronthosting.co.za>


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

Still happening on 3.1rc1.

Should this be considered a release blocker for 3.1?

----------
nosy: +benjamin.peterson, nad

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

From report at bugs.python.org  Wed Jun  3 10:03:04 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 08:03:04 +0000
Subject: [issue6186] test_thread occasionally reports unhandled exceptions on
	OS X
In-Reply-To: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>
Message-ID: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

I've recently started seeing occasional regression test error messages 
on OS X from test_thread.  The test reports running OK but tracebacks 
are displayed.  It's not reproducible at will but has shown up on both 
10.5 Intel and 10.5 PPC machines with various recent top of py3k builds.  
Here are two examples:

nad at pbg4:/Library/Frameworks/Python.framework/Versions/3.1$ 
./bin/python3.1 -S ./lib/python3.1/test/regrtest.py -w test_thread
test_thread
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_starting_threads>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
1 test OK.

and

nad at fimt:/Library/Frameworks/Python.framework/Versions/3.1$ 
./bin/python3.1 -S ./lib/python3.1/test/regrtest.py -w test_thread
test_thread
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_stack_size>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
Unhandled exception in thread started by <bound method 
ThreadRunningTests.task of <test.test_thread.ThreadRunningTests 
testMethod=test_starting_threads>>
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/test/te
st_thread.py", line 49, in task
    self.done_mutex.release()
_thread.error: release unlocked lock
1 test OK.


Are the tracebacks from a harmless race condition and, if so, can the 
test be modified to eliminate them?  Or is there some new real problem?

----------
components: Tests
messages: 88799
nosy: nad
severity: normal
status: open
title: test_thread occasionally reports unhandled exceptions on OS X
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  3 11:13:43 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 03 Jun 2009 09:13:43 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1244020423.47.0.569917733774.issue4806@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I added a simple check for iterables. This is not very elegant, but
performance is only affected in the case of an exception. Patch and
corresponsing test are attached as "TypeError.patch".

As I pointed out above, the actual error message "must be a sequence" is
also inconsistent with the implementation (and tests) which allows any
kind of iterable. The attached and independent patch
"message_and_docs.patch" changes this to "must be an iterable" and
corrects docs and tests accordingly.

----------
keywords: +patch
versions: +Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14166/TypeError.patch

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

From report at bugs.python.org  Wed Jun  3 11:14:33 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 03 Jun 2009 09:14:33 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1244020473.02.0.0887711514066.issue4806@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


Added file: http://bugs.python.org/file14167/message_and_docs.patch

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

From report at bugs.python.org  Wed Jun  3 11:36:20 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 03 Jun 2009 09:36:20 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243986707.72.0.514977063082.issue1943@psf.upfronthosting.co.za>
Message-ID: <4A264408.30404@egenix.com>


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

> That's unfortunate; it would clearly have been easier to change this in 3.1.
> 
> That said, I'm not sure anyone *should* be subclassing PyUnicode. Maybe
> Marc-Andre can explain why he is doing this (or point to the message in
> this thread where he explained this before)? 

The Unicode type was designed to be a basic useful type with as
much functionality as needed, but no more. Since it was clear that
we would get sub-typing at the time, the aim was to move special
use cases into such sub-types.

One such example was the referencing logic used in Fredrik's
implementation and often requested by the Python community.

I removed that logic from the implementation due to the issues this
would have caused by accidentally keeping alive large referenced
Unicode objects due to references pointing to them.

However, it's easy to add it back by sub-typing the Unicode type:

http://downloads.egenix.com/python/unicoderef-0.0.1.tar.gz

Other special use cases:

* sub-types which hold a reference to the original bytes string, e.g.
to implement a round-trip safe storage even of broken text data or
text that uses multiple encodings

* sub-types that get their data from a memory mapped file or a
shared memory area without copying

* sub-types that implement indexing based on glyphs (ie. the human
recognizable notion of a character) rather than code points

* sub-types that implement special extra methods or provide case
insensitive operations

* sub-types that implement special text data forms, such as URLs,
OS paths, UID strings, etc. and custom operations on those

Sub-typing is also encouraged by the documentation:

http://docs.python.org/library/userdict.html#module-UserString

... and after all: one of the main points in making all built-in
types sub-typeable was to actually do it :-)

> If it's a viable use case,
> it should be possible to have some symbol or a few symbols whose
> presence can be tested in the preprocessor by code that needs to
> subclass; we should design the patch with that in mind and Marc-Andre
> could help testing it.
> 
> All this is assuming the speed-up is important enough to bother.  Has
> anyone run a comparison benchmark using the Unladen Swallow benchmarks?
>
>  I trust those much more than micro-benchmarks (including, I assume,
> stringbench.py).  I do expect that reducing the number of allocations
> for short-to-medium-size strings from 2 to 1 would be a significant
> speed-up, but I can't guess how much.

While the Unladen Swallow aims at providing high-level benchmarks,
it's current state doesn't really implement that promise (yet).

If you look at the list of benchmarks they use, most appear to be
dealing with pickling. That doesn't strike me as particularly useful
for testing real life Python usage.

If a high level benchmark is indeed what's wanted, then they should
setup pre-configured Django and Zope instances and run those through
a series of real-life usage scenarios to cover the web application
use space. For scientific use cases, it would be good to have similar
setups using BioPython, NumPy and matplotlib. And so on. Much like
the high level benchmarks you have in the Windows world.

Depending on the use case, the results of benchmarks for this
particular change are difficult to predict or interpret.

Here's a summary message with my reasoning for rejecting the patch:

http://bugs.python.org/issue1943#msg88307

Instead of changing PyUnicodeObject from a PyObject to a PyVarObject,
making sub-typing a lot harder, I'd much rather apply a single change
for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and
motivated here:

http://bugs.python.org/issue1943#msg64215

That's a simple non-disruptive change which makes a lot of sense
due to the advances in CPU designs in the last 9 years. I determined
the original value of 9 using benchmarks and similar statistics in
1999/2000.

It's probably also a good time to remove the warning, now that the
implementation has proven itself for so many years...

/* Limit for the Unicode object free list stay alive optimization.

   The implementation will keep allocated Unicode memory intact for
   all objects on the free list having a size less than this
   limit. This reduces malloc() overhead for small Unicode objects.

   At worst this will result in PyUnicode_MAXFREELIST *
   (sizeof(PyUnicodeObject) + KEEPALIVE_SIZE_LIMIT +
   malloc()-overhead) bytes of unused garbage.

   Setting the limit to 0 effectively turns the feature off.

   Note: This is an experimental feature ! If you get core dumps when
   using Unicode objects, turn this feature off.

*/

#define KEEPALIVE_SIZE_LIMIT       9

----------

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

From report at bugs.python.org  Wed Jun  3 12:15:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 10:15:51 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A264408.30404@egenix.com>
Message-ID: <1244024284.4960.26.camel@localhost>


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

> Instead of changing PyUnicodeObject from a PyObject to a PyVarObject,
> making sub-typing a lot harder, I'd much rather apply a single change
> for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and
> motivated here:

You make it sound like an alternative to this patch, while it is quite
independent. You could open a separate entry about it, together with
benchmarks results etc.

----------

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

From report at bugs.python.org  Wed Jun  3 13:10:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 03 Jun 2009 11:10:16 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1244027416.39.0.313288314379.issue4806@psf.upfronthosting.co.za>


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

This patch leaks a reference on each call to PyObject_GetIter(). And I'm
not sure it is a good idea to call this function again: it may be very
expensive! I'd prefer a simple check on the tp_iter member.

----------

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

From report at bugs.python.org  Wed Jun  3 13:16:59 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 03 Jun 2009 11:16:59 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1244024284.4960.26.camel@localhost>
Message-ID: <4A265BA6.6010902@egenix.com>


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

Antoine Pitrou wrote:
>> Instead of changing PyUnicodeObject from a PyObject to a PyVarObject,
>> making sub-typing a lot harder, I'd much rather apply a single change
>> for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and
>> motivated here:
> 
> You make it sound like an alternative to this patch, while it is quite
> independent. You could open a separate entry about it, together with
> benchmarks results etc.

You're right, I could open a separate ticket for it, but it does fit
the title of the ticket and was also discussed at length on this
ticket, since part of your original patch included changes to the
free list management in the Unicode implementation.

----------

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

From report at bugs.python.org  Wed Jun  3 13:27:48 2009
From: report at bugs.python.org (Jon Blubinger)
Date: Wed, 03 Jun 2009 11:27:48 +0000
Subject: [issue6187] Improvement in doc of "Extending and Embedding the Python
	Interpreter, 5.3 Beyond Very High Level Embedding: An overview"
In-Reply-To: <1244028468.87.0.409088876389.issue6187@psf.upfronthosting.co.za>
Message-ID: <1244028468.87.0.409088876389.issue6187@psf.upfronthosting.co.za>


New submission from Jon Blubinger <blubdiebla at gmail.com>:

It should me mentioned, that the Python variable PYTHONPATH has to be
set to the directory where the multiply.py file is. This can be achieved
via export in Linux or via the PySys_SetPath() function in C (see
attachment)

It should also be mentioned that otherwise the program will have
following output:

ImportError: No module named multiply
Failed to load "multiply"

----------
assignee: georg.brandl
components: Documentation
files: interp3.c
messages: 88805
nosy: blubdiebla, georg.brandl
severity: normal
status: open
title: Improvement in doc of "Extending and Embedding the Python Interpreter, 5.3 Beyond Very High Level Embedding: An overview"
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14168/interp3.c

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

From report at bugs.python.org  Wed Jun  3 13:32:33 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 03 Jun 2009 11:32:33 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1244028753.77.0.0711207654675.issue1943@psf.upfronthosting.co.za>


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

Let's apply simple and noncontroversial patches first, and then see if
the bigger changes are still worth it.
Please open a new ticket.

----------

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

From report at bugs.python.org  Wed Jun  3 13:42:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 11:42:27 +0000
Subject: [issue6185] 2to3 misses buffer slicing
In-Reply-To: <1244007385.35.0.333960656606.issue6185@psf.upfronthosting.co.za>
Message-ID: <1244029347.67.0.589947313855.issue6185@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
priority:  -> normal

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

From report at bugs.python.org  Wed Jun  3 13:46:35 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 03 Jun 2009 11:46:35 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1244029595.14.0.685686829998.issue4806@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Sorry, I had meant to use PyIter_Check instead of PyObject_GetIter.
Don't know why I didn't do so... ;-)

I corrected the patch.

----------
Added file: http://bugs.python.org/file14169/TypeError2.patch

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

From report at bugs.python.org  Wed Jun  3 13:46:39 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 03 Jun 2009 11:46:39 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1244029599.68.0.476866331985.issue4806@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


Removed file: http://bugs.python.org/file14166/TypeError.patch

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

From report at bugs.python.org  Wed Jun  3 14:00:10 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Jun 2009 12:00:10 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1244030410.93.0.115295268513.issue1943@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/issue1943>
_______________________________________

From report at bugs.python.org  Wed Jun  3 15:20:03 2009
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Wed, 03 Jun 2009 13:20:03 +0000
Subject: [issue6188] Error Evaluating float(x) ** float(y)
In-Reply-To: <1244035203.68.0.223995405838.issue6188@psf.upfronthosting.co.za>
Message-ID: <1244035203.68.0.223995405838.issue6188@psf.upfronthosting.co.za>


New submission from Stephen Paul Chappell <Noctis.Skytower at gmail.com>:

This is what I get while the interactive interpreter (IDLE 3.0.1) on the 
platform
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit 
(Intel)] on win32

>>> a = -6.276479035564047
>>> b = -5.7974497499584849
>>> a ** b != -6.276479035564047 ** -5.7974497499584849
True
>>> 

Something is wrong. The float values are the same but not evaluated as 
being equal.
After writing an automated testing program, these sample numbers were 
generated
and found  to create erroneous symptoms in the system being 
automatically tested.

----------
components: Interpreter Core
messages: 88808
nosy: Zero
severity: normal
status: open
title: Error Evaluating float(x) ** float(y)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun  3 15:27:19 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 03 Jun 2009 13:27:19 +0000
Subject: [issue6188] Error Evaluating float(x) ** float(y)
In-Reply-To: <1244035203.68.0.223995405838.issue6188@psf.upfronthosting.co.za>
Message-ID: <1244035639.05.0.406822523489.issue6188@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Have you checked to see what the result of a ** b is?

----------
nosy: +exarkun

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

From report at bugs.python.org  Wed Jun  3 15:27:55 2009
From: report at bugs.python.org (Israel Tsadok)
Date: Wed, 03 Jun 2009 13:27:55 +0000
Subject: [issue6189] subprocess module not compatible with python 2.5
In-Reply-To: <1244035675.71.0.776263383534.issue6189@psf.upfronthosting.co.za>
Message-ID: <1244035675.71.0.776263383534.issue6189@psf.upfronthosting.co.za>


New submission from Israel Tsadok <itsadok at gmail.com>:

According to PEP 291, the subprocess module is supposed to be compatible 
with python 2.2 and up.

rev 60097 introduced the use of os.closerange(), which is new in python 
2.6.

Either PEP-291 needs to be revised, rev 60097 be reverted, or some sort of 
fallback mechanism needs to be added.

----------
components: Library (Lib)
files: subprocess.patch
keywords: patch
messages: 88810
nosy: itsadok
severity: normal
status: open
title: subprocess module not compatible with python 2.5
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14170/subprocess.patch

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

From report at bugs.python.org  Wed Jun  3 15:30:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Jun 2009 13:30:51 +0000
Subject: [issue6188] Error Evaluating float(x) ** float(y)
In-Reply-To: <1244035203.68.0.223995405838.issue6188@psf.upfronthosting.co.za>
Message-ID: <1244035851.86.0.415821085282.issue6188@psf.upfronthosting.co.za>


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

This is not a bug:  Python's operator precedence rules mean that the 
expression

  -6.276479035564047 ** -5.7974497499584849

is treated as:

  -(6.276479035564047 ** -5.7974497499584849).

>>> a = -6.276479035564047
>>> b = -5.7974497499584849
>>> a ** b != -6.276479035564047 ** -5.7974497499584849
True
>>> a ** b == (-6.276479035564047) ** -5.7974497499584849
True

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

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

From report at bugs.python.org  Wed Jun  3 15:31:31 2009
From: report at bugs.python.org (BULOT)
Date: Wed, 03 Jun 2009 13:31:31 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1244035891.65.0.310866535474.issue1208304@psf.upfronthosting.co.za>


BULOT <stephane at bulot.org> added the comment:

Hello, 

I'm facing a urllib2 memory leak issue in one of my scripts that is not
threaded. I made a few tests in order to check what was going on and I
found this already existing bug thread (but old).

I'm not able to figure out what is the issue yet, but here are a few
informations:
Platform: Debian
Python version 2.5.4

I made a script (2 attached files) in order to make access to a web page
(http://www.google.com) every second, that monitors number of file
descriptors and memory footprint.
I also introduced the gc module (Garbage Collector) in order to retrieve
numbers of objects that are not freed (like already proposed in this
thread but more focussed on gc.DEBUG_LEAK flag)

Here are my results:
First acces output:
gc: collectable <dict 0xb793c604>
gc: collectable <HTTPResponse instance at 0xb7938f6c>
gc: collectable <dict 0xb793c4f4>
gc: collectable <HTTPMessage instance at 0xb793d0ec>
gc: collectable <dict 0xb793c02c>
gc: collectable <list 0xb7938e8c>
gc: collectable <list 0xb7938ecc>
gc: collectable <instancemethod 0xb79cf824>
gc: collectable <dict 0xb793c79c>
gc: collectable <HTTPResponse instance at 0xb793d2cc>
gc: collectable <instancemethod 0xb79cf874>
unreachable objects:  11
File descriptors number: 32
Memory: 4612

Thenth access:
gc: collectable <dict 0xb78f14f4>
gc: collectable <HTTPResponse instance at 0xb78f404c>
gc: collectable <dict 0xb78f13e4>
gc: collectable <HTTPMessage instance at 0xb78f462c>
gc: collectable <dict 0xb78e5f0c>
gc: collectable <list 0xb78eeb4c>
gc: collectable <list 0xb78ee2ac>
gc: collectable <instancemethod 0xb797b7fc>
gc: collectable <dict 0xb78f168c>
gc: collectable <HTTPResponse instance at 0xb78f442c>
gc: collectable <instancemethod 0xb78eaa7c>
unreachable objects:  110
File descriptors number: 32
Memory: 4680

After hundred access:
gc: collectable <dict 0x89e2e84>
gc: collectable <HTTPResponse instance at 0x89e3e2c>
gc: collectable <dict 0x89e2d74>
gc: collectable <HTTPMessage instance at 0x89e3ccc>
gc: collectable <dict 0x89db0b4>
gc: collectable <list 0x89e3cac>
gc: collectable <list 0x89e32ec>
gc: collectable <instancemethod 0x89d8964>
gc: collectable <dict 0x89e60b4>
gc: collectable <HTTPResponse instance at 0x89e50ac>
gc: collectable <instancemethod 0x89ddb1c>
unreachable objects:  1100
File descriptors number: 32
Memory: 5284

Each call to urllib2.urlopen() gives 11 new unreachable objects,
increases memory footprint without giving new open files.

Do you have any idea?
With the hack proposed in message
http://bugs.python.org/issue1208304#msg60751, number of unreachable
objects goes down to 8 unreachable objects remaining, but still memory
increases.

Regards.

stephbul

PS
My urlib2leak.py test calls monitor script (not able to attach it):
#! /bin/sh

PROCS='urllib2leak.py'

RUNPID=`ps aux | grep "$PROCS" | grep -v "grep" | awk '{printf $2}'`
FDESC=`lsof -p $RUNPID | wc -l`
MEM=`ps aux | grep "$PROCS" | grep -v "grep" | awk '{printf $6 }'`

echo "File descriptors number: "$FDESC
echo "Memory: "$MEM

----------
nosy: +stephbul
versions:  -Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14171/urllib2leak.py

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

From report at bugs.python.org  Wed Jun  3 16:38:28 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 03 Jun 2009 14:38:28 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1244039908.15.0.699145676679.issue1856@psf.upfronthosting.co.za>


Changes by Floris Bruynooghe <floris.bruynooghe at gmail.com>:


----------
nosy: +flub

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

From report at bugs.python.org  Wed Jun  3 17:03:10 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 03 Jun 2009 15:03:10 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244041390.93.0.892257553172.issue5798@psf.upfronthosting.co.za>


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

If it's failing, and asyncore is still in 3.1, then I would argue yes.

I'll submit a fix to trunk and 3.1 based on my version below (unless 
anyone has any outstanding concerns, or believes that it doesn't work for 
them).

----------

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

From report at bugs.python.org  Wed Jun  3 17:27:11 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Wed, 03 Jun 2009 15:27:11 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1244042831.14.0.660542343208.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

I had lots of stuff to do lately, sorry it took me so long to answer.
Here is the patch as we intended, but there is a bug yet.
What if the non-existent imported module has the same name of the module
itself?

$ cat pydoc_badimport3.py
import this_doesnt_exist.pydoc_badimport3
$ pydoc pydoc_badimport3

I tested this possibility, and I found out that there is a bug in this
situation yet: pydoc still tells the user that the module couldn't be found.

----------
Added file: http://bugs.python.org/file14172/pydocs.diff

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

From report at bugs.python.org  Wed Jun  3 17:30:46 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Wed, 03 Jun 2009 15:30:46 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1244043046.29.0.339162652285.issue5230@psf.upfronthosting.co.za>


Changes by Lucas Prado Melo <lukepadawan at gmail.com>:


Removed file: http://bugs.python.org/file14140/pydocs.diff

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

From report at bugs.python.org  Wed Jun  3 18:55:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 16:55:47 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244048147.18.0.0906823809423.issue5798@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: high -> release blocker

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

From report at bugs.python.org  Wed Jun  3 18:56:32 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 16:56:32 +0000
Subject: [issue6184] py3k build gets spurious errors from libinstall target
	compile of lib2to3 files
In-Reply-To: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>
Message-ID: <1244048192.36.0.582412241129.issue6184@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

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

From report at bugs.python.org  Wed Jun  3 18:57:11 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 16:57:11 +0000
Subject: [issue6184] py3k build gets spurious errors from libinstall target
	compile of lib2to3 files
In-Reply-To: <1243997958.63.0.926663545814.issue6184@psf.upfronthosting.co.za>
Message-ID: <1244048231.65.0.586158265481.issue6184@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed those in r73177.

----------

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

From report at bugs.python.org  Wed Jun  3 19:06:45 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 03 Jun 2009 17:06:45 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1244048805.07.0.393821899189.issue1943@psf.upfronthosting.co.za>


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

Hm, so the extra pointer is a feature.  I guess a compromise would be to
keep the extra indirection but make it point into the same object in the
base class.  Thinking about how memory caching in modern CPUs work, this
would probably be quite fast but it would still cost 8 bytes on most
future (i.e., 64-bit) architectures.

Still, I expect that a vanishingly small number of users will actually
use that feature.  Is it worth to make everyone pay for that
flexibility, for what must be the first- or second-most commonly used
type in Python 3.x (the other being int), which is still significantly
slower than the common (8-bit) string type in 2.x?

----------

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

From report at bugs.python.org  Wed Jun  3 19:13:20 2009
From: report at bugs.python.org (Tim Savannah)
Date: Wed, 03 Jun 2009 17:13:20 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1244049200.71.0.46298196128.issue6178@psf.upfronthosting.co.za>


Tim Savannah <tsavanna at arinc.com> added the comment:

recompiled with pydebug enabled, and recompiled all site-packages. Still
getting exceptions, however they are occuring within the python binary
now and not libpython2.6.1 .

pythonLaunch.py[25914]: segfault at 0000000000000068 rip
00000000004c7694 rsp 000000004181a4c0 error 4
pythonLaunch.py[1421]: segfault at 0000000000000068 rip 00000000004c7694
rsp 00000000432914c0 error 4
pythonLaunch.py[2552]: segfault at 0000000000000068 rip 00000000004c7694
rsp 0000000041f7d4c0 error 4

----------

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

From report at bugs.python.org  Wed Jun  3 19:14:50 2009
From: report at bugs.python.org (Tim Savannah)
Date: Wed, 03 Jun 2009 17:14:50 +0000
Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2
In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za>
Message-ID: <1244049290.35.0.203978015329.issue6178@psf.upfronthosting.co.za>


Tim Savannah <tsavanna at arinc.com> added the comment:

to update, no additional output was seen from pydebug.

----------

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

From report at bugs.python.org  Wed Jun  3 19:35:15 2009
From: report at bugs.python.org (Collin Winter)
Date: Wed, 03 Jun 2009 17:35:15 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A264408.30404@egenix.com>
Message-ID: <43aa6ff70906031035g1fc779fayd1d00181051cb58@mail.gmail.com>


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

On Wed, Jun 3, 2009 at 2:36 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>> All this is assuming the speed-up is important enough to bother. ?Has
>> anyone run a comparison benchmark using the Unladen Swallow benchmarks?
>>
>> ?I trust those much more than micro-benchmarks (including, I assume,
>> stringbench.py). ?I do expect that reducing the number of allocations
>> for short-to-medium-size strings from 2 to 1 would be a significant
>> speed-up, but I can't guess how much.
>
> While the Unladen Swallow aims at providing high-level benchmarks,
> it's current state doesn't really implement that promise (yet).
>
> If you look at the list of benchmarks they use, most appear to be
> dealing with pickling. That doesn't strike me as particularly useful
> for testing real life Python usage.

I would take issue with your characterization of those benchmarks.
There are several benchmarks for cPickle, true, both macro and micro
benchmarks, but I would not describe their number as "most of [our]
benchmarks". For example, "slowpickle" and "slowunpickle" both use the
pure-Python pickle.py, and are testing how close we can get that
implementation to the tuned cPickle version.

Regardless, I don't know that any of our benchmarks really stress
unicode performance. We so far haven't cared about improving the
performance of unicode objects. 2to3 uses unicode internally, so that
might be a good benchmark to run.

> If a high level benchmark is indeed what's wanted, then they should
> setup pre-configured Django and Zope instances and run those through
> a series of real-life usage scenarios to cover the web application
> use space.

We have a benchmark for Django and Spitfire templates, both of which
are heavily used in the web application use space. We focused on
template languages because in talking to Google's web app teams, they
found their primary CPU bottlenecks to be templating systems, not ORMs
or other components.

> For scientific use cases, it would be good to have similar
> setups using BioPython, NumPy and matplotlib. And so on. Much like
> the high level benchmarks you have in the Windows world.

We have NumPy in our correctness test suite, but no benchmarks based
on it. Looking at all the packages you just named, they make heavy use
of C/C++ extensions (with BioPython and matplotpib both depending on
NumPy) or large C libraries (matplotlib can depend on Cairo, I see).
We've been focusing on pure-Python performance, so I'm skeptical that
benchmarks with such large C components would be a useful guide for
our work. I'm happy to talk about this further outside of this thread,
though.

Collin

----------

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

From report at bugs.python.org  Wed Jun  3 20:08:43 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 03 Jun 2009 18:08:43 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244052523.05.0.00824060625728.issue6136@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

OK, I'll take point (c) further on comp.lang.python. As for the others,
it would be useful if you could at least understand my points.

a) I'm aware that there isn't necessarily a one-to-one correspondence
between loggers and files, don't see why that's relevant. I have no idea
what the "common" way of using logging is, if there is one. Having lots
of files in a logging set up doesn't seem to me in any way unusual, even
if the number of loggers is potentially even larger.

The main question is the one I posed before: what is the point of
opening files that will never be written to and sockets that will never
be used? Or to put it another way, if I submitted a patch that only
created handlers that were used by at least one logger, would you look
at it?

b) "compulsory" as in "compulsory as an entry in the config file". The
code would be

if "qualname" in opts:
    qn = cp.get(sectname, "qualname")
else:
    qn = log

To make life easier for those of us who don't see the point in naming
loggers differently in the config file and in the code...

----------

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

From report at bugs.python.org  Wed Jun  3 20:10:24 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 18:10:24 +0000
Subject: [issue6185] 2to3 misses buffer slicing
In-Reply-To: <1244007385.35.0.333960656606.issue6185@psf.upfronthosting.co.za>
Message-ID: <1244052624.72.0.676995991996.issue6185@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Fixed in r73179.

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

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

From report at bugs.python.org  Wed Jun  3 21:49:05 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 03 Jun 2009 19:49:05 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244058545.83.0.147319391957.issue5798@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch

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

From report at bugs.python.org  Wed Jun  3 21:49:31 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 03 Jun 2009 19:49:31 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244058571.01.0.0965775319014.issue5798@psf.upfronthosting.co.za>


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

Fixed in trunk in 73182, fixed in py3k in 73183.

Closing as fixed.

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

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

From report at bugs.python.org  Wed Jun  3 22:05:03 2009
From: report at bugs.python.org (Michael Markert)
Date: Wed, 03 Jun 2009 20:05:03 +0000
Subject: [issue6190] Tutorial 3.1.2 (Strings) has duplicate lines
In-Reply-To: <1244059503.11.0.172911990378.issue6190@psf.upfronthosting.co.za>
Message-ID: <1244059503.11.0.172911990378.issue6190@psf.upfronthosting.co.za>


New submission from Michael Markert <markert.michael at gmail.com>:

Lines 242 - 246 of `introduction.rst` are the exact duplicate of 202 -
206 in the same file. 246+247 resemble 206+207.

The attached patch deletes the second notion.

----------
assignee: georg.brandl
components: Documentation
files: introduction.rst.patch
keywords: patch
messages: 88823
nosy: cofi, georg.brandl
severity: normal
status: open
title: Tutorial 3.1.2 (Strings) has duplicate lines
versions: Python 3.1
Added file: http://bugs.python.org/file14173/introduction.rst.patch

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

From report at bugs.python.org  Wed Jun  3 22:41:36 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 20:41:36 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1244048805.07.0.393821899189.issue1943@psf.upfronthosting.co.za>
Message-ID: <1244061829.5505.23.camel@localhost>


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

> Still, I expect that a vanishingly small number of users will actually
> use that feature. 

Apart from the example Marc-Andr? just posted (and which is a 0.0.1
proof of concept he apparently just wrote), the number of users is,
AFAICT, zero.
Unless there's some closed source extension which happens to extend
unicode as a C subtype.

Now, as for easing the subclassing of unicode in C, there are probably
several possibilities which range from devising a clever set of macros
to abusing the ob_size field for a tagged pointer. People who really
care should do a concrete proposal (and I don't know who these people
are, apart from Marc-Andr?).

----------

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

From report at bugs.python.org  Wed Jun  3 22:42:26 2009
From: report at bugs.python.org (Evan Behar)
Date: Wed, 03 Jun 2009 20:42:26 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244061746.04.0.972388442398.issue6154@psf.upfronthosting.co.za>


Evan Behar <behare at gmail.com> added the comment:

Nevermind, my bad.  With Brett's patch, the build does not work with
--enable-framework

It appears that configure.in makes no assignment to FRAMEWORKLINK or
AC_SUBST call with it, and so it is deposited in the final Makefile
verbatim as @FRAMEWORKLINK@

If --enable-framework is defined, then this compiler command in
Makefile.pre:461 gets executed:

                $(CC) -o $(LDLIBRARY)  -dynamiclib \
                        -isysroot "${UNIVERSALSDK}" \
                        -all_load $(LIBRARY) -Wl,-single_module \
                        -install_name
$(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)
\
                        -compatibility_version $(VERSION) \
                        -current_version $(VERSION) \
                        $(FRAMEWORKLINK);

Which expands $(FRAMEWORKLINK) to @FRAMEWORKLINK@ because of this.

This makes no use of LIBS or any other environment variable that might
contain -lintl or -framework CoreFoundation, and the build will fail
with linker errors citing undefined intl and CFString symbols.

Attached is a patch that fixes this issue; it combines brett's lintl
patch with the fix for --enable-framework.

----------
Added file: http://bugs.python.org/file14174/darwin_lintl_framework.patch

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

From report at bugs.python.org  Wed Jun  3 22:45:45 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 03 Jun 2009 20:45:45 +0000
Subject: [issue6189] subprocess module not compatible with python 2.5
In-Reply-To: <1244035675.71.0.776263383534.issue6189@psf.upfronthosting.co.za>
Message-ID: <1244061945.5.0.850105232298.issue6189@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/issue6189>
_______________________________________

From report at bugs.python.org  Wed Jun  3 22:54:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 20:54:43 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244062483.54.0.742376729485.issue6137@psf.upfronthosting.co.za>


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

Unpickling e.g. StringIO objects doesn't seem to work:

>>> s = pickle.load(open("stringio.pickle", "rb"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/picklecompat-6137/Lib/pickle.py", line 1351,
in load
    encoding=encoding, errors=errors).load()
AttributeError: '_io.BytesIO' object has no attribute '__dict__'
>>>

----------

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

From report at bugs.python.org  Wed Jun  3 23:01:14 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 03 Jun 2009 21:01:14 +0000
Subject: [issue6190] Tutorial 3.1.2 (Strings) has duplicate lines
In-Reply-To: <1244059503.11.0.172911990378.issue6190@psf.upfronthosting.co.za>
Message-ID: <1244062874.61.0.999498404719.issue6190@psf.upfronthosting.co.za>


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

Thanks, fixed in r73185.

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

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

From report at bugs.python.org  Wed Jun  3 23:21:23 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 03 Jun 2009 21:21:23 +0000
Subject: [issue6174] What's new in 2.6, wrong indentation in code sample
In-Reply-To: <1243922024.28.0.772489700519.issue6174@psf.upfronthosting.co.za>
Message-ID: <1244064083.09.0.701964481295.issue6174@psf.upfronthosting.co.za>


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

Thanks, fixed in r73186.

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

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

From report at bugs.python.org  Wed Jun  3 23:26:13 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 03 Jun 2009 21:26:13 +0000
Subject: [issue2713] Py3k warn on unicode escapes in raw strings
In-Reply-To: <1209418975.28.0.733174226817.issue2713@psf.upfronthosting.co.za>
Message-ID: <1244064373.11.0.184137996601.issue2713@psf.upfronthosting.co.za>


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

Why was this patch rejected?
with python2.6,
     len(ur'\u1234') == 1
with python3.0,
     len( r'\u1234') == 6

This is worth a warning IMO.
See also issue2570.

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

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

From report at bugs.python.org  Wed Jun  3 23:31:26 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 03 Jun 2009 21:31:26 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1244061829.5505.23.camel@localhost>
Message-ID: <ca471dc20906031431h79b8e6ia9ac8db280d2d079@mail.gmail.com>


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

On Wed, Jun 3, 2009 at 1:41 PM, Antoine Pitrou <report at bugs.python.org> wrote:
> Apart from the example Marc-Andr? just posted (and which is a 0.0.1
> proof of concept he apparently just wrote), the number of users is,
> AFAICT, zero.

IIUC Marc-Andre extracted that from a larger code base (MX) which he
owns and has been maintaining for a decade or so.

> Unless there's some closed source extension which happens to extend
> unicode as a C subtype.

I believe part of MX is closed source.

> Now, as for easing the subclassing of unicode in C, there are probably
> several possibilities which range from devising a clever set of macros
> to abusing the ob_size field for a tagged pointer. People who really
> care should do a concrete proposal (and I don't know who these people
> are, apart from Marc-Andr?).

Not really if the core code uses a macro that depends on the layout of
the object (i.e. the data immediately following the header, like old
8-bit strings), unless you change the core (or the macro) to only use
this if the type matches exactly, and for subtypes use a more
expensive API. But that would slow down unnecessarily for subclasses
written in Python (of which there are plenty).

But I would like to point out that few people if any have ever
complained about the contiguous allocation for 8-bit strings in Python
[0-2].x. And we certainly wouldn't have given in. Now that Unicode is
no longer some fancy-schmancy advanced concept but the basis for *all*
Python string processing I think we should apply the same policy.

----------

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

From report at bugs.python.org  Wed Jun  3 23:32:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 21:32:39 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244064759.61.0.65221314305.issue6137@psf.upfronthosting.co.za>


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

An improved patch with tests.
It has no tests for fix_imports=False, though.

----------
Added file: http://bugs.python.org/file14175/compat_pickle2.diff

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

From report at bugs.python.org  Wed Jun  3 23:42:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 03 Jun 2009 21:42:47 +0000
Subject: [issue2590] S_unpack_from() Read Access Violation
In-Reply-To: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>
Message-ID: <1244065367.29.0.309361924516.issue2590@psf.upfronthosting.co.za>


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

All expressions are of type Py_ssize_t, which is signed.
buffer_len is positive; the subtraction (buffer_len - offset) can 
overflow only if offset is a (large) negative number, but then the first 
part of the test is already fulfilled.

Closing unless more evidence is given.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Thu Jun  4 00:10:05 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Jun 2009 22:10:05 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244067005.98.0.0512528243523.issue6154@psf.upfronthosting.co.za>


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

So Evan's patch didn't work for me. But I did take Evan's point that
LIBS was not being used in the framework build step and simply added
$(LIBS) to Makefile.pre.in where the linking for the Python executable
happens (attached a new patch with that in it). That got
``--with-pydebug --enable-framework`` working, but the build still fails
under ``--with-pydebug --enable-framework --enable-universalsdk``. Why
does it fail? Well because ``-lintl`` ends up not being set in $(LIBS),
that's why! =)

I have burned way too much time on this to finish debugging this
autoconf crap. This is getting hairy enough that either a) get more help
from python-dev, b) revert the static linking of _locale, c) get Ronald
involved.

----------
Added file: http://bugs.python.org/file14176/lintl_for_frameworks.patch

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

From report at bugs.python.org  Thu Jun  4 00:20:03 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 22:20:03 +0000
Subject: [issue5267] Subversion problem with PythonLauncher after building 3.0
	or 3.1 on Mac
In-Reply-To: <1234657992.73.0.432074420703.issue5267@psf.upfronthosting.co.za>
Message-ID: <1244067603.95.0.0508395453983.issue5267@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed for 3.1 in r73187, and for 3.0 in r73188.

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

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

From report at bugs.python.org  Thu Jun  4 00:24:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 22:24:03 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244067843.36.0.137587430853.issue6154@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I take it the build problem is because intl isn't a universal library?
In that case, I think the best solution is to not define WITH_INTL if
--enable-universalsdk is passed. Ronald, do you have an opinion?

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Thu Jun  4 00:25:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 22:25:00 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244067900.02.0.642590748217.issue6154@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
title: Python 3.1 rc1 will not build on OS X 10.5.7 -> Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl

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

From report at bugs.python.org  Thu Jun  4 00:32:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 22:32:49 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244068369.75.0.676015485861.issue6137@psf.upfronthosting.co.za>


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

A new patch which also includes reverse mappings, so that protocol <= 2
pickles created with 3.x can also work under 2.x.
(that is, it also solves #3675)

----------
dependencies: +Python 2.6 can't read sets pickled with Python 3.0
Added file: http://bugs.python.org/file14177/compat_pickle3.diff

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

From report at bugs.python.org  Thu Jun  4 00:37:11 2009
From: report at bugs.python.org (Evan Behar)
Date: Wed, 03 Jun 2009 22:37:11 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244068631.8.0.0159586420721.issue6154@psf.upfronthosting.co.za>


Evan Behar <behare at gmail.com> added the comment:

Curiously, if I define --with-pydebug I get

ld: Undefined symbols:
___eprintf

If I don't define --with-pydebug but I do use --enable-universalsdk I
get a whole different problem:

gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE  -c
./Modules/_localemodule.c -o Modules/_localemodule.o
./Modules/_localemodule.c:28:21: error: libintl.h: No such file or directory

This leads to whole bunch of other crap.

libintl.h is used in other forms of the build, so I'm not sure why this
is cropping up.

I also have no idea what ___eprintf is.

----------

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

From report at bugs.python.org  Thu Jun  4 00:39:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 22:39:38 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244068778.33.0.87974080448.issue6137@psf.upfronthosting.co.za>


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

Updated patch with a couple of documentation and function prototype fixes.

----------
dependencies:  -Python 2.6 can't read sets pickled with Python 3.0
Added file: http://bugs.python.org/file14178/compat_pickle4.diff

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

From report at bugs.python.org  Thu Jun  4 00:45:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 22:45:19 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244069119.76.0.418156952379.issue6154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Do you have a copy of libintl in /usr/local or ~brett//local/lib? If so, 
could you run 'file' on that library to check if it is a universal 
library?

All system libraries on OSX are universal binaries and work just fine 
with a universal build of Python, that's why I believe you have a non-
universal copy of some libraries on your systems and those won't work 
when you try to do a universal build.

Removing -lintl for a universal build would not be a valid solution, 
unless -lintl is completely unnecessary on OSX.

And for the record: I cannot reproduce this on my system, the end of 
build with --enable-universalsdk:

Python build finished, but the necessary bits to build these modules 
were not found:
_gdbm              ossaudiodev        readline        
spwd                                                  
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.


Failed to build these modules:
_gestalt           _tkinter                           


And the output of file:

file python.exe
python.exe: Mach-O universal binary with 2 architectures
python.exe (for architecture ppc):	Mach-O executable ppc
python.exe (for architecture i386):	Mach-O executable i386

Al of this is with a fresh checkout (r73188) of the py3k branch.


P.S. I'd love to know a clean way to exclude /usr/local/{include,lib} 
from the search paths of GCC, I've had a number of bugreports for other 
projects where the compiler picked up a non-universal library in 
/usr/local that the user didn't even know they had installed and didn't 
want to use.

----------

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

From report at bugs.python.org  Thu Jun  4 00:47:51 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 22:47:51 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244069271.26.0.991545075072.issue6154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I have two procedural questions:

1) Who should I contact to get e-mail for all bugs that get tagged with 
the Macintosh component?

2) Please tag all mac-related bugs with the 'Macintosh' component, that's 
the one I most often check for new issues.

----------

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

From report at bugs.python.org  Thu Jun  4 00:49:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 22:49:48 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244069388.74.0.0464959668813.issue6137@psf.upfronthosting.co.za>


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

Sorry, last patch had a couple of minor issues

----------
Added file: http://bugs.python.org/file14179/compat_pickle5.diff

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

From report at bugs.python.org  Thu Jun  4 00:50:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 22:50:14 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244069414.69.0.219835041874.issue6137@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14177/compat_pickle3.diff

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

From report at bugs.python.org  Thu Jun  4 00:50:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Jun 2009 22:50:18 +0000
Subject: [issue6137] Pickle migration: Should pickle map "copy_reg" to
	"copyreg"?
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244069418.88.0.825849031364.issue6137@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14178/compat_pickle4.diff

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

From report at bugs.python.org  Thu Jun  4 00:51:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 22:51:42 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1244069271.26.0.991545075072.issue6154@psf.upfronthosting.co.za>
Message-ID: <1afaf6160906031551s50915ad2t12332c0b3514bff7@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/6/3 Ronald Oussoren <report at bugs.python.org>:
>
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> I have two procedural questions:
>
> 1) Who should I contact to get e-mail for all bugs that get tagged with
> the Macintosh component?

Create an issue on the meta tracker:
http://psf.upfronthosting.co.za/roundup/meta
>
> 2) Please tag all mac-related bugs with the 'Macintosh' component, that's
> the one I most often check for new issues.

I will tell the bug triage people that.

----------

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

From report at bugs.python.org  Thu Jun  4 00:56:09 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 22:56:09 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244069769.14.0.322246988651.issue6154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I just noticed the update of the title.

I propose to close this issue if this is caused by a non-universal version 
of libintl that's installed by macports.

Macports can install universal binaries of its packages (the +universal 
variant), use that if you want to link a universal build of python with 
macports libraries (and if you don't want to link with macports you 
shouldn't add the macports $prefix to the search path of the compiler)

----------

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

From report at bugs.python.org  Thu Jun  4 00:58:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 22:58:59 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1244069769.14.0.322246988651.issue6154@psf.upfronthosting.co.za>
Message-ID: <1afaf6160906031558s46509701q6b5c76b5c7771cc4@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/6/3 Ronald Oussoren <report at bugs.python.org>:
>
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> I just noticed the update of the title.
>
> I propose to close this issue if this is caused by a non-universal version
> of libintl that's installed by macports.

Actually, it can happen with regular builds, but the attached patches
fix that issue.

>
> Macports can install universal binaries of its packages (the +universal
> variant), use that if you want to link a universal build of python with
> macports libraries (and if you don't want to link with macports you
> shouldn't add the macports $prefix to the search path of the compiler)

That sounds reasonable.

----------

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

From report at bugs.python.org  Thu Jun  4 00:59:47 2009
From: report at bugs.python.org (Evan Behar)
Date: Wed, 03 Jun 2009 22:59:47 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244069987.97.0.00290883500628.issue6154@psf.upfronthosting.co.za>


Evan Behar <behare at gmail.com> added the comment:

I haven't got any library issues using --enable-universalsdk, it won't
get to the linking stage becaue it doesn't find libintl.h

And with --with-pydebug still doesn't build because it won't find
___eprintf, whatever that is.

The only version of libintl on my system is universal, so I don't think
that's related.

----------

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

From report at bugs.python.org  Thu Jun  4 01:20:32 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 23:20:32 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
	with	macports libintl
In-Reply-To: <1244069987.97.0.00290883500628.issue6154@psf.upfronthosting.co.za>
Message-ID: <6FC003DE-0119-41D2-9E08-0C0181BB8114@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 4 Jun, 2009, at 0:59, Evan Behar wrote:

>
> Evan Behar <behare at gmail.com> added the comment:
>
> I haven't got any library issues using --enable-universalsdk, it won't
> get to the linking stage becaue it doesn't find libintl.h
>
> And with --with-pydebug still doesn't build because it won't find
> ___eprintf, whatever that is.
>
> The only version of libintl on my system is universal, so I don't  
> think
> that's related.

The --with-pydebug issue is unrelated to this one, and IIRC there is  
already a tracker item for that, at least when you're running OSX  
10.4.  I don't have problems with --with-pydebug on 10.5

----------
title: Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl -> Python 3.1 rc1 will not build on OS X 10.5.7 with	macports libintl
Added file: http://bugs.python.org/file14180/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090603/11dadf80/attachment.bin>

From report at bugs.python.org  Thu Jun  4 01:20:46 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 23:20:46 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
	with	macports libintl
In-Reply-To: <1afaf6160906031558s46509701q6b5c76b5c7771cc4@mail.gmail.com>
Message-ID: <3A7FC05D-F2CE-4A76-A9D6-2C6358C984F2@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote:

>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> 2009/6/3 Ronald Oussoren <report at bugs.python.org>:
>>
>> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>>
>> I just noticed the update of the title.
>>
>> I propose to close this issue if this is caused by a non-universal  
>> version
>> of libintl that's installed by macports.
>
> Actually, it can happen with regular builds, but the attached patches
> fix that issue.

How can it happen with regular builds?  This can only happen if there  
is a non-universal copy of used libraries on the compiler search-path,  
or rather if there are libraries with incompatible architectures on  
the search-path. This would also happen with readline, or if you have  
a ppc-only library on an intel machine.

Not having the right archtectures of libraries is IMHO in "don't do  
that then" territory.

Ronald

----------
Added file: http://bugs.python.org/file14181/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090603/629f95f9/attachment.bin>

From report at bugs.python.org  Thu Jun  4 01:20:49 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 23:20:49 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
	with	macports libintl
In-Reply-To: <1afaf6160906031558s46509701q6b5c76b5c7771cc4@mail.gmail.com>
Message-ID: <9089D5AA-974C-41BF-B66C-CBC489E9E1CF@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 4 Jun, 2009, at 0:59, Benjamin Peterson wrote:

>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> 2009/6/3 Ronald Oussoren <report at bugs.python.org>:
>>
>> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>>
>> I just noticed the update of the title.
>>
>> I propose to close this issue if this is caused by a non-universal  
>> version
>> of libintl that's installed by macports.
>
> Actually, it can happen with regular builds, but the attached patches
> fix that issue.

How can it happen with regular builds?  This can only happen if there  
is a non-universal copy of used libraries on the compiler search-path,  
or rather if there are libraries with incompatible architectures on  
the search-path. This would also happen with readline, or if you have  
a ppc-only library on an intel machine.

Not having the right archtectures of libraries is IMHO in "don't do  
that then" territory.

Ronald

----------
Added file: http://bugs.python.org/file14182/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090603/b8469dcf/attachment-0001.bin>

From report at bugs.python.org  Thu Jun  4 01:31:53 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Jun 2009 23:31:53 +0000
Subject: [issue5649] OS X Installer: only include PythonSystemFixes package if
	target includes 10.3
In-Reply-To: <1238600445.94.0.804009523794.issue5649@psf.upfronthosting.co.za>
Message-ID: <1244071913.2.0.834456682838.issue5649@psf.upfronthosting.co.za>


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

Further investigation reveals that the underlying script Mac/Tools/fixapplepython23.py is broken on 3.x:

1. the version test using platform.mac_ver is incorrect
Traceback (most recent call last):
  File "fixapplepython23.py", line 131, in <module>
    main()
  File "fixapplepython23.py", line 103, in main
    if osver != '10.3' and os.ver < '10.3.':
AttributeError: 'module' object has no attribute 'ver'

2. and, even if the typo is corrected, osver returns a tuple
      >>> osver =  platform.mac_ver()
      >>> osver
        ('10.5.7', ('', '', ''), 'PowerPC')

The above are only seen on PPC builds since the script bails out earlier 
if running on an Intel platform.

At this point, it is a minor issue and the number of users who might be 
impacted must be few and getting fewer; eventually PythonSystemFixes 
should be removed when or before 10.3 is no longer supported.

----------

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

From report at bugs.python.org  Thu Jun  4 01:37:14 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 23:37:14 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
	with	macports libintl
In-Reply-To: <1244069987.97.0.00290883500628.issue6154@psf.upfronthosting.co.za>
Message-ID: <97F4CD0F-3DDB-4837-985F-431D54C24717@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 4 Jun, 2009, at 0:59, Evan Behar wrote:

>
> Evan Behar <behare at gmail.com> added the comment:
>
> I haven't got any library issues using --enable-universalsdk, it won't
> get to the linking stage becaue it doesn't find libintl.h
>
> And with --with-pydebug still doesn't build because it won't find
> ___eprintf, whatever that is.
>
> The only version of libintl on my system is universal, so I don't  
> think
> that's related.

The --with-pydebug issue is unrelated to this one, and IIRC there is  
already a tracker item for that, at least when you're running OSX  
10.4.  I don't have problems with --with-pydebug on 10.5

----------
Added file: http://bugs.python.org/file14183/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090603/309cbbed/attachment.bin>

From report at bugs.python.org  Thu Jun  4 01:38:07 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 03 Jun 2009 23:38:07 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1244072287.37.0.635048966024.issue6170@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ronald, a quick note - your fix unfortunately did not solve the issue.

[quote]'To help with the repro, may I suggest running the following in
the same
order:

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image
'[endquote[

----------

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

From report at bugs.python.org  Thu Jun  4 01:41:24 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Jun 2009 23:41:24 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1244072484.37.0.748264565973.issue6170@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Don't do that, use 'make install DESTDIR=$PWD/image'. As I mentioned 
earlier 'make frameworkinstallframework' is an internal step that 
shouldn't be used on its own.

----------

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

From report at bugs.python.org  Thu Jun  4 01:44:31 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Jun 2009 23:44:31 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
	with	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244072671.36.0.80106660782.issue6154@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

There's a broader issue than just the non-universal intl problem. If
intl.h is defined, then configure causes _localemodule.c to use
functions from it, but it wasn't being linked to.

----------

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

From report at bugs.python.org  Thu Jun  4 02:06:09 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Jun 2009 00:06:09 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244073969.98.0.454735584043.issue5798@psf.upfronthosting.co.za>


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

Verified test_asynchat no longer fails in trunk nor py3k.  Thanks!

----------

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

From report at bugs.python.org  Thu Jun  4 02:22:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Jun 2009 00:22:29 +0000
Subject: [issue6182] Remove ipaddr library from py3k before 3.1rc2
In-Reply-To: <1243994583.57.0.193467275614.issue6182@psf.upfronthosting.co.za>
Message-ID: <1244074949.36.0.381027043488.issue6182@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido approved the removal today.
http://mail.python.org/pipermail/python-dev/2009-June/089882.html

----------
nosy: +rhettinger
resolution:  -> accepted

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

From report at bugs.python.org  Thu Jun  4 02:24:17 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Jun 2009 00:24:17 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
	with	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244075057.44.0.532913417066.issue6154@psf.upfronthosting.co.za>


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

As Benjamin said, this was failing on non-universal framework builds and
just a regular build because '-lintl' was not getting added to LIBS in
configure.in and LIBS was not being passed into the framework compile
rule (for both universal and non-universal).

As for my copy of libintl.dylib, 'file' says::

  /unix/macports/lib/libintl.dylib: Mach-O dynamically linked shared
library i386

>From my reading of that it means gettext was not built as a universal
library (which I will go fix and so for other libraries I have through
MacPorts).

Ronald, can you look at the changes I proposed on Makefile.pre.in to
make sure LIBS from configure get used in the framework builds? If you
do then that change with the configure.in change I suggested should
solve all of this.

----------

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

From report at bugs.python.org  Thu Jun  4 02:24:46 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Jun 2009 00:24:46 +0000
Subject: [issue5839] RegOpenKeyEx key failed on Vista 64Bit with return 2
In-Reply-To: <1240663838.43.0.625551571341.issue5839@psf.upfronthosting.co.za>
Message-ID: <1244075086.54.0.953168520167.issue5839@psf.upfronthosting.co.za>


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

I don't understand what "2.6.2 source(32bit)" is.
Did you install a binary distribution (.msi), or did you compile the 
source files?

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

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

From report at bugs.python.org  Thu Jun  4 02:28:22 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Jun 2009 00:28:22 +0000
Subject: [issue5648] OS X Installer: do not install obsolete documentation
	within Python.app bundle
In-Reply-To: <1238596647.54.0.611757278193.issue5648@psf.upfronthosting.co.za>
Message-ID: <1244075302.95.0.395882819831.issue5648@psf.upfronthosting.co.za>


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

Verified fixed by r72779 in trunk and r72791 in py3k. Can be closed.

----------

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

From report at bugs.python.org  Thu Jun  4 02:43:36 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 04 Jun 2009 00:43:36 +0000
Subject: [issue5373] TypeError when '\x00' in docstring
In-Reply-To: <1235641346.54.0.44421310191.issue5373@psf.upfronthosting.co.za>
Message-ID: <1244076216.6.0.620594136562.issue5373@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Patch committed in r73195.

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

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

From report at bugs.python.org  Thu Jun  4 03:18:58 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 04 Jun 2009 01:18:58 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244078338.83.0.368374964017.issue6137@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here is an updated patch based on Antoine's latest patch.

Summary of changes:
 * Updated docstrings of Pickler and Unpickler in the pickle module.
 * Fixed pickle._Pickler to consider fix_imports only for protocol < 3
 * Made module name remapping in _pickle more robust:
    - added PyUnicode_Check on global_name and module_name;
    - used PyDict_GetItemWithError instead of PyDict_GetItem
 * Changed Py_BuildValue("(OO)", ...) to its faster equivalent
   PyTuple_Pack(2, ...).

I don't really the idea of remapping names generated by Pickler, since
it breaks the identity guarantee in save_global(). However, I agree this
is an example where practicality beats purity. So, I do not oppose to
the change.

----------
assignee:  -> alexandre.vassalotti
title: Pickle migration: Should pickle map "copy_reg" to "copyreg"? -> Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Added file: http://bugs.python.org/file14184/compat_pickle6.diff

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

From report at bugs.python.org  Thu Jun  4 03:21:37 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 04 Jun 2009 01:21: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: <1244078497.72.0.774556235817.issue3675@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Superseded by issue #6137.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Make pickle generated by Python 3.x compatible with 2.x and vice-versa.

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

From report at bugs.python.org  Thu Jun  4 04:47:16 2009
From: report at bugs.python.org (Todd Whiteman)
Date: Thu, 04 Jun 2009 02:47:16 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1244083636.15.0.5425050705.issue2057@psf.upfronthosting.co.za>


Changes by Todd Whiteman <twhitema at yahoo.com.au>:


----------
nosy: +twhitema

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

From report at bugs.python.org  Thu Jun  4 08:01:34 2009
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Widera?=)
Date: Thu, 04 Jun 2009 06:01:34 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1244095293.52.0.791908627774.issue670664@psf.upfronthosting.co.za>


Changes by Pawe? Widera <momat at man.poznan.pl>:


----------
nosy: +momat

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

From report at bugs.python.org  Thu Jun  4 08:10:20 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 04 Jun 2009 06:10:20 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244095820.25.0.635899819869.issue6137@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

The latest patch is missing the file "Lib/_compat.pickle.py". (Seems as
if you forgot to svn add it after patching.)

----------
nosy: +hagen

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

From report at bugs.python.org  Thu Jun  4 08:32:16 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 04 Jun 2009 06:32:16 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1244097136.0.0.0913471109018.issue6170@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee: tarek -> 

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

From report at bugs.python.org  Thu Jun  4 08:34:13 2009
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Widera?=)
Date: Thu, 04 Jun 2009 06:34:13 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1244097253.39.0.143495255584.issue670664@psf.upfronthosting.co.za>


Pawe? Widera <momat at man.poznan.pl> added the comment:

A simple workaround for the BeautifulSoup is the following wrapper. It
sanitize the javascript code before passing it to the parser by joining
the disjoint strings, so that "</scr"+"ipt>" becomes "</script>".

def bs(input):
	pattern = re.compile('\"\+\"')
	match = lambda x: ""
	massage = copy.copy(BeautifulSoup.MARKUP_MASSAGE)
	massage.extend([(pattern, match)])
	return BeautifulSoup(input, markupMassage=massage)

----------

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

From report at bugs.python.org  Thu Jun  4 09:03:39 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 04 Jun 2009 07:03:39 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244099018.91.0.476739691164.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Re point a) and opening files - why not use the "delay" parameter on
FileHandlers, which delays opening until a message is actually logged? I
can understand why one wouldn't want empty log files cluttering up the
place, but the same argument doesn't apply to sockets. If you don't want
an always-open connection, you could also use UDP. While the delay
parameter takes care of files, why does it matter so much about sockets?
Is it actually causing a practical problem, or does it just offend your
aesthetic sensibilities?

If you submit a patch for fileConfig that only created handlers that
were used by at least one logger, I would certainly look at it - I have
both accepted and rejected numerous patches over the years. Would your
patch also consider unused formatters? As the new behaviour could
conceivably create a backward-compatibility problem (some users may be
relying on the current behaviour, no matter how broken it seems to you),
the new behaviour should be accessible through another config setting
(e.g. ignore_unused) which defaults to False (the existing behaviour) if
not specified in the config file.

Re point b), it only really covers the case where you have single-level
loggers (qualname = word), and not actually a multi-level hierarchy
(qualname = words-separated-by-dots). So I don't feel it's worth doing
this, especially as there seems to be no widespread demand for this
functionality.

I'll mark the issue as pending for now.

----------
status: open -> pending

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

From report at bugs.python.org  Thu Jun  4 09:40:00 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 04 Jun 2009 07:40:00 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7	with
	macports libintl
In-Reply-To: <1244075057.44.0.532913417066.issue6154@psf.upfronthosting.co.za>
Message-ID: <B3D4AD36-8DE6-4ED9-BE04-41075DFC11D7@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 4 Jun, 2009, at 2:24, Brett Cannon wrote:
>
>
> Ronald, can you look at the changes I proposed on Makefile.pre.in to
> make sure LIBS from configure get used in the framework builds? If you
> do then that change with the configure.in change I suggested should
> solve all of this.

The basic idea looks fine, I will have a more serious look later  
today. I'm not entirely sure of adding LIBS to the link line is 100%  
correct, or if it would be better to have a separate FRAMEWORKLIBS  
definition that only contains the files that must be linked into the  
framework.

----------
title: Python 3.1 rc1 will not build on OS X 10.5.7 with	macports libintl -> Python 3.1 rc1 will not build on OS X 10.5.7	with macports libintl

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

From report at bugs.python.org  Thu Jun  4 09:40:34 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 04 Jun 2009 07:40:34 +0000
Subject: [issue5648] OS X Installer: do not install obsolete documentation
	within Python.app bundle
In-Reply-To: <1238596647.54.0.611757278193.issue5648@psf.upfronthosting.co.za>
Message-ID: <1244101233.85.0.543305163073.issue5648@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


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

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

From report at bugs.python.org  Thu Jun  4 09:47:01 2009
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Widera?=)
Date: Thu, 04 Jun 2009 07:47:01 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>


New submission from Pawe? Widera <momat at man.poznan.pl>:

Of course both are not correct HTML but are easy to guess, so I believe
the parser should not give up too quick here.

1) extra comma between attributes
<form action="/xxx.php?a=1&amp;b=2&amp", method="post">

2) missing closing quotation mark for the first attribute
<a href="http://xxx.org/xxx.php?a=1 target="_blank">click me</a>

----------
components: Library (Lib)
messages: 88867
nosy: momat
severity: normal
status: open
title: HTMLParser attribute parsing - 2 test cases when it fails
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  4 11:01:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 09:01:30 +0000
Subject: [issue5767] xmlrpclib loads invalid documents
In-Reply-To: <1239841199.24.0.504542013197.issue5767@psf.upfronthosting.co.za>
Message-ID: <1244106090.66.0.00113287287219.issue5767@psf.upfronthosting.co.za>


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

Applied in r73201, r73202.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Thu Jun  4 11:13:16 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 09:13:16 +0000
Subject: [issue3613] base64.encodestring does not actually accept strings
In-Reply-To: <1219212034.35.0.601192649417.issue3613@psf.upfronthosting.co.za>
Message-ID: <1244106796.04.0.133043982476.issue3613@psf.upfronthosting.co.za>


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

Applied a patch to rename (and keep old aliases) in r73204.

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

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

From report at bugs.python.org  Thu Jun  4 11:15:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 09:15: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: <1244106926.51.0.715032815186.issue3684@psf.upfronthosting.co.za>


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

Thanks, committed as r73206.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Thu Jun  4 11:30:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 09:30:48 +0000
Subject: [issue3791] bsddb not completely removed
In-Reply-To: <1220661145.94.0.113291838613.issue3791@psf.upfronthosting.co.za>
Message-ID: <1244107848.0.0.625355795987.issue3791@psf.upfronthosting.co.za>


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

Removed the last traces of bsddb in r73208.

----------
nosy: +georg.brandl
resolution: accepted -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Jun  4 11:58:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 09:58:32 +0000
Subject: [issue3798] SystemExit incorrectly displays unicode message
In-Reply-To: <1220737862.32.0.22799945135.issue3798@psf.upfronthosting.co.za>
Message-ID: <1244109512.97.0.473210810982.issue3798@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/issue3798>
_______________________________________

From report at bugs.python.org  Thu Jun  4 12:00:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 10:00:11 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1244109611.3.0.252491658223.issue433028@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Major reworking of Python 2.5.2 re module

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

From report at bugs.python.org  Thu Jun  4 12:07:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 10:07:35 +0000
Subject: [issue4186] type() doesn't accept bases and dict keyword arguments
In-Reply-To: <1224753211.57.0.0760272194538.issue4186@psf.upfronthosting.co.za>
Message-ID: <1244110055.79.0.409482088156.issue4186@psf.upfronthosting.co.za>


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

2.6 has been released and out there some time, and there was no cry
about this, so I guess this can be ignored.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> pending

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

From report at bugs.python.org  Thu Jun  4 12:08:19 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 10:08:19 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
Message-ID: <1244110099.88.0.366835021826.issue4199@psf.upfronthosting.co.za>


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

Postponed to 3.2.

----------
nosy: +georg.brandl
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Thu Jun  4 12:16:10 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 10:16:10 +0000
Subject: [issue5967] PyList_GetSlice does not indicate negative ranges dont
	work as in python.
In-Reply-To: <1241786157.93.0.55086599633.issue5967@psf.upfronthosting.co.za>
Message-ID: <1244110570.34.0.846293359353.issue5967@psf.upfronthosting.co.za>


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

Documented in r73213.

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

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

From report at bugs.python.org  Thu Jun  4 12:22:48 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 10:22:48 +0000
Subject: [issue6176] Reference to a wrong version of flock's documentation
In-Reply-To: <1243936280.77.0.510370484524.issue6176@psf.upfronthosting.co.za>
Message-ID: <1244110968.18.0.128313705965.issue6176@psf.upfronthosting.co.za>


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

Thanks, fixed in r73215.

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

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

From report at bugs.python.org  Thu Jun  4 12:27:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 10:27:43 +0000
Subject: [issue6175] inet_aton documentation kind of lies
In-Reply-To: <1243929967.67.0.34945506806.issue6175@psf.upfronthosting.co.za>
Message-ID: <1244111263.1.0.092962460444.issue6175@psf.upfronthosting.co.za>


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

Thanks, updated the docs in r73217.

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

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

From report at bugs.python.org  Thu Jun  4 12:32:42 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 04 Jun 2009 10:32:42 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

It is useful to be able to disable the Nagle algoritm on socket 
connections from the TCPServer.  These are typically used by HTTP servers.

If combined with write buffering (setting RequestHangler.wbufsize = -1) it  
can make sure that http responses are not subject to Nagle/Delayed-ack 
delays.  Disabling Nagle in addition to providing the buffering is 
necessary to make sure that the final wfile.flush() arrives promptly, in 
case a previous flush occurred and the final flush is small.

A patch is provided.

----------
files: disable_nagle.patch
keywords: easy, patch, patch
messages: 88878
nosy: krisvale
severity: normal
status: open
title: add disable_nagle_algorithm to SocketServer.TCPServer
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14185/disable_nagle.patch

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

From report at bugs.python.org  Thu Jun  4 12:32:55 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 04 Jun 2009 10:32:55 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1244111575.6.0.00380932234691.issue6192@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
components: +Library (Lib)

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

From report at bugs.python.org  Thu Jun  4 12:43:59 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 04 Jun 2009 10:43:59 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1244061829.5505.23.camel@localhost>
Message-ID: <4A27A56A.6030306@egenix.com>


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

Here's a new version of the unicode reference type, extended
to run in both Python 2.6 and 3.1:

http://downloads.egenix.com/python/unicoderef-0.0.2.tar.gz

I've also included a benchmark implemented in C which measures
Unicode/Bytes allocation performance at high resolution
and without any VM overhead.

These are the results on a 64-bit system using a regular UCS2
build of Python 2.6.1 and 3.1 on a single core AMD system:

 * Unicode allocation is always much slower than Bytes

 This depends a lot on how much data you have to handle. If the
 data fits into the pymalloc managed sizes, there's little
 difference.

 * CPU cache lines / memory boundaries obviously have some
   impact on the results

 If things are properly aligned, performance is better than
 in the unaligned case. Unfortunately, there's nothing much the
 CPython implementation can do to benefit from this, since the
 hardware layouts are too diverse.

 This explains why you see some unexpected figures in the
 results, e.g. Python 3.1, 4096 words, 32chars - Unicode
 being faster than Bytes.

 * Something must have improved in pymalloc

 The 4096 word tests perform better on 3.1 than on 2.6.

 Since such improvement have a great impact, more
 emphasis should be placed on these, e.g. by having pymalloc
 provide more space to fixed size objects such PyUnicodeObject,
 reducing the need to create new arenas.

 Dictionaries and other PyObjects such as instances objects
 would also benefit from such improvements.

Note that the benchmark scales the bytes word sizes to match
the internal allocation size of the Unicode objects, ie.
2chars maps to a length 4 bytes string on a UCS2 build.

Testing Unicode/Bytes Allocation Speed with Python 3.1rc1+
------------------------------------------------------------------------

=== 1024 words ============================================================

Variant 2chars, 1024 words, Unicode: 0.005503 seconds = 0.054 us per object
(best of 50 rounds)
Variant 2chars, 1024 words, Bytes  : 0.006838 seconds = 0.067 us per object
(best of 50 rounds)

Variant 9chars, 1024 words, Unicode: 0.008956 seconds = 0.087 us per object
(best of 50 rounds)
Variant 9chars, 1024 words, Bytes  : 0.007380 seconds = 0.072 us per object
(best of 50 rounds)

Variant 16chars, 1024 words, Unicode: 0.009257 seconds = 0.090 us per object
(best of 50 rounds)
Variant 16chars, 1024 words, Bytes  : 0.007291 seconds = 0.071 us per object
(best of 50 rounds)

Variant 32chars, 1024 words, Unicode: 0.009589 seconds = 0.094 us per object
(best of 50 rounds)
Variant 32chars, 1024 words, Bytes  : 0.007803 seconds = 0.076 us per object
(best of 50 rounds)

Variant pep100, 1024 words, Unicode: 0.010569 seconds = 0.103 us per object
(best of 50 rounds)
Variant pep100, 1024 words, Bytes  : 0.008198 seconds = 0.080 us per object
(best of 50 rounds)

=== 2048 words ============================================================

Variant 2chars, 2048 words, Unicode: 0.011624 seconds = 0.057 us per object
(best of 50 rounds)
Variant 2chars, 2048 words, Bytes  : 0.013941 seconds = 0.068 us per object
(best of 50 rounds)

Variant 9chars, 2048 words, Unicode: 0.018608 seconds = 0.091 us per object
(best of 50 rounds)
Variant 9chars, 2048 words, Bytes  : 0.014773 seconds = 0.072 us per object
(best of 50 rounds)

Variant 16chars, 2048 words, Unicode: 0.018556 seconds = 0.091 us per object
(best of 50 rounds)
Variant 16chars, 2048 words, Bytes  : 0.014550 seconds = 0.071 us per object
(best of 50 rounds)

Variant 32chars, 2048 words, Unicode: 0.018972 seconds = 0.093 us per object
(best of 50 rounds)
Variant 32chars, 2048 words, Bytes  : 0.016377 seconds = 0.080 us per object
(best of 50 rounds)

Variant pep100, 2048 words, Unicode: 0.021005 seconds = 0.103 us per object
(best of 50 rounds)
Variant pep100, 2048 words, Bytes  : 0.016636 seconds = 0.081 us per object
(best of 50 rounds)

=== 4096 words ============================================================

Variant 2chars, 4096 words, Unicode: 0.022950 seconds = 0.056 us per object
(best of 50 rounds)
Variant 2chars, 4096 words, Bytes  : 0.027813 seconds = 0.068 us per object
(best of 50 rounds)

Variant 9chars, 4096 words, Unicode: 0.037229 seconds = 0.091 us per object
(best of 50 rounds)
Variant 9chars, 4096 words, Bytes  : 0.031123 seconds = 0.076 us per object
(best of 50 rounds)

Variant 16chars, 4096 words, Unicode: 0.037118 seconds = 0.091 us per object
(best of 50 rounds)
Variant 16chars, 4096 words, Bytes  : 0.036433 seconds = 0.089 us per object
(best of 50 rounds)

Variant 32chars, 4096 words, Unicode: 0.040970 seconds = 0.100 us per object
(best of 50 rounds)
Variant 32chars, 4096 words, Bytes  : 0.051422 seconds = 0.126 us per object
(best of 50 rounds)

Variant pep100, 4096 words, Unicode: 0.049630 seconds = 0.121 us per object
(best of 50 rounds)
Variant pep100, 4096 words, Bytes  : 0.034551 seconds = 0.084 us per object
(best of 50 rounds)

Testing Unicode/Bytes Allocation Speed with Python 2.6.1
------------------------------------------------------------------------

=== 1024 words ============================================================

Variant 2chars, 1024 words, Unicode: 0.005810 seconds = 0.057 us per object
(best of 50 rounds)
Variant 2chars, 1024 words, Bytes  : 0.006918 seconds = 0.068 us per object
(best of 50 rounds)

Variant 9chars, 1024 words, Unicode: 0.008539 seconds = 0.083 us per object
(best of 50 rounds)
Variant 9chars, 1024 words, Bytes  : 0.007618 seconds = 0.074 us per object
(best of 50 rounds)

Variant 16chars, 1024 words, Unicode: 0.008478 seconds = 0.083 us per object
(best of 50 rounds)
Variant 16chars, 1024 words, Bytes  : 0.008097 seconds = 0.079 us per object
(best of 50 rounds)

Variant 32chars, 1024 words, Unicode: 0.008969 seconds = 0.088 us per object
(best of 50 rounds)
Variant 32chars, 1024 words, Bytes  : 0.008649 seconds = 0.084 us per object
(best of 50 rounds)

Variant pep100, 1024 words, Unicode: 0.009779 seconds = 0.096 us per object
(best of 50 rounds)
Variant pep100, 1024 words, Bytes  : 0.008318 seconds = 0.081 us per object
(best of 50 rounds)

=== 2048 words ============================================================

Variant 2chars, 2048 words, Unicode: 0.011745 seconds = 0.057 us per object
(best of 50 rounds)
Variant 2chars, 2048 words, Bytes  : 0.013978 seconds = 0.068 us per object
(best of 50 rounds)

Variant 9chars, 2048 words, Unicode: 0.017418 seconds = 0.085 us per object
(best of 50 rounds)
Variant 9chars, 2048 words, Bytes  : 0.014443 seconds = 0.071 us per object
(best of 50 rounds)

Variant 16chars, 2048 words, Unicode: 0.018138 seconds = 0.089 us per object
(best of 50 rounds)
Variant 16chars, 2048 words, Bytes  : 0.016200 seconds = 0.079 us per object
(best of 50 rounds)

Variant 32chars, 2048 words, Unicode: 0.021348 seconds = 0.104 us per object
(best of 50 rounds)
Variant 32chars, 2048 words, Bytes  : 0.018144 seconds = 0.089 us per object
(best of 50 rounds)

Variant pep100, 2048 words, Unicode: 0.019593 seconds = 0.096 us per object
(best of 50 rounds)
Variant pep100, 2048 words, Bytes  : 0.016692 seconds = 0.082 us per object
(best of 50 rounds)

=== 4096 words ============================================================

Variant 2chars, 4096 words, Unicode: 0.024347 seconds = 0.059 us per object
(best of 50 rounds)
Variant 2chars, 4096 words, Bytes  : 0.028411 seconds = 0.069 us per object
(best of 50 rounds)

Variant 9chars, 4096 words, Unicode: 0.041480 seconds = 0.101 us per object
(best of 50 rounds)
Variant 9chars, 4096 words, Bytes  : 0.031532 seconds = 0.077 us per object
(best of 50 rounds)

Variant 16chars, 4096 words, Unicode: 0.047986 seconds = 0.117 us per object
(best of 50 rounds)
Variant 16chars, 4096 words, Bytes  : 0.038006 seconds = 0.093 us per object
(best of 50 rounds)

Variant 32chars, 4096 words, Unicode: 0.062115 seconds = 0.152 us per object
(best of 50 rounds)
Variant 32chars, 4096 words, Bytes  : 0.049687 seconds = 0.121 us per object
(best of 50 rounds)

Variant pep100, 4096 words, Unicode: 0.044331 seconds = 0.108 us per object
(best of 50 rounds)
Variant pep100, 4096 words, Bytes  : 0.035939 seconds = 0.088 us per object
(best of 50 rounds)

----------

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

From report at bugs.python.org  Thu Jun  4 12:54:44 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 04 Jun 2009 10:54:44 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <ca471dc20906031431h79b8e6ia9ac8db280d2d079@mail.gmail.com>
Message-ID: <4A27A7EE.4010309@egenix.com>


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

Guido van Rossum wrote:
> Guido van Rossum <guido at python.org> added the comment:
> 
> On Wed, Jun 3, 2009 at 1:41 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>> Apart from the example Marc-Andr? just posted (and which is a 0.0.1
>> proof of concept he apparently just wrote), the number of users is,
>> AFAICT, zero.
> 
> IIUC Marc-Andre extracted that from a larger code base (MX) which he
> owns and has been maintaining for a decade or so.

Only part of it.

I wrote the sub-type Unicode Reference sub-type implementation
just a few days ago, in order to demonstrate how easy it is
provided you have a PyObject (rather than a PyVarObject) to
build on.

We should really publicize how easy it is to write such type
extensions. I'm sure that a lot of things which often generated
heated discussions (such as the slicing patches for Unicode)
could easily be solved by just adding a few such sub-types to the
core.

>> Unless there's some closed source extension which happens to extend
>> unicode as a C subtype.
> 
> I believe part of MX is closed source.

True. A large part of the code base is not available to the wider
public.

>> Now, as for easing the subclassing of unicode in C, there are probably
>> several possibilities which range from devising a clever set of macros
>> to abusing the ob_size field for a tagged pointer. People who really
>> care should do a concrete proposal (and I don't know who these people
>> are, apart from Marc-Andr?).
> 
> Not really if the core code uses a macro that depends on the layout of
> the object (i.e. the data immediately following the header, like old
> 8-bit strings), unless you change the core (or the macro) to only use
> this if the type matches exactly, and for subtypes use a more
> expensive API. But that would slow down unnecessarily for subclasses
> written in Python (of which there are plenty).
> 
> But I would like to point out that few people if any have ever
> complained about the contiguous allocation for 8-bit strings in Python
> [0-2].x. And we certainly wouldn't have given in. Now that Unicode is
> no longer some fancy-schmancy advanced concept but the basis for *all*
> Python string processing I think we should apply the same policy.

I've spent enough time with this discussion.

If you think it's better to make sub-typing harder and thereby
closing the door for improvements which could really speed up
e.g. template processing (by not requiring copying the same data
over and over again), go for it.

I still think that it's better to keep things the way they
are and benefit from the fact that PyUnicodeObjects have a
fixed size with the variable part being dealt with separately.

Since pymalloc is being used to manage such objects, there's
a lot of room for improvements, since the allocation scheme
is under out control. E.g. we could have pymalloc allocate
larger pools for PyUnicodeObjects.

Doing the same for variable sized objects is a lot harder,
consumes more memory and likely less efficient.

----------

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

From report at bugs.python.org  Thu Jun  4 13:26:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Jun 2009 11:26:16 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A27A7EE.4010309@egenix.com>
Message-ID: <1244114906.4913.1.camel@localhost>


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

> Since pymalloc is being used to manage such objects, there's
> a lot of room for improvements, since the allocation scheme
> is under out control. E.g. we could have pymalloc allocate
> larger pools for PyUnicodeObjects.

I'm not sure what "larger pools for PyUnicodeObjects" means. pymalloc
doesn't have separate pools per object type, only per object size.
OTOH, we could grow the size limit under which pymalloc is used,
especially on 64-bit systems.

----------

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

From report at bugs.python.org  Thu Jun  4 13:39:31 2009
From: report at bugs.python.org (Johannes Hoff)
Date: Thu, 04 Jun 2009 11:39:31 +0000
Subject: [issue5611] Auto-detect indentation in C source in vimrc
In-Reply-To: <1238436646.8.0.898787236764.issue5611@psf.upfronthosting.co.za>
Message-ID: <1244115571.5.0.162772123376.issue5611@psf.upfronthosting.co.za>


Johannes Hoff <johannes at johanneshoff.com> added the comment:

I came across this bug while searching for autodetecting tabs/spaces. 
Thanks for the help.

To address Georg's question, the patch should be modified to say
    if search('^\t', 'n', 100)
instead of
    if search('^\t')

The former will not move the cursor, and will only search the first 100 
lines.

----------
nosy: +johshoff

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

From report at bugs.python.org  Thu Jun  4 14:13:35 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 04 Jun 2009 12:13:35 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1244114906.4913.1.camel@localhost>
Message-ID: <4A27BA65.8000706@egenix.com>


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

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Since pymalloc is being used to manage such objects, there's
>> a lot of room for improvements, since the allocation scheme
>> is under out control. E.g. we could have pymalloc allocate
>> larger pools for PyUnicodeObjects.
> 
> I'm not sure what "larger pools for PyUnicodeObjects" means. pymalloc
> doesn't have separate pools per object type, only per object size.

I meant larger pools for objects of sizeof(PyUnicodeObject) bytes.
The same could be done for other often used PyObjects (and only for
those).

pymalloc is a lot faster than the OS malloc() and was designed for
Python object memory management, ie. for small blocks...

"""
/* A fast, special-purpose memory allocator for small blocks, to be used
   on top of a general-purpose malloc -- heavily based on previous art. */

/* Vladimir Marangozov -- August 2000 */
"""

> OTOH, we could grow the size limit under which pymalloc is used,
> especially on 64-bit systems.

The limit is 256 bytes. Increasing it doesn't make much sense,
since the pools are 4k each and managed in arenas of
256kb.

Anything larger than 256 bytes goes straight to the OS malloc().

----------

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

From report at bugs.python.org  Thu Jun  4 14:18:11 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Jun 2009 12:18:11 +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: <1244117891.17.0.383771452218.issue3684@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Any plans for a unit test for this change?

----------
nosy: +exarkun

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

From report at bugs.python.org  Thu Jun  4 14:18:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Jun 2009 12:18:14 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A27BA65.8000706@egenix.com>
Message-ID: <1244118025.4913.5.camel@localhost>


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

> Anything larger than 256 bytes goes straight to the OS malloc().

Under a 64-bit system, a plain dict is more than 256 bytes.

----------

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

From report at bugs.python.org  Thu Jun  4 17:46:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Jun 2009 15:46:03 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1244130363.41.0.946258592467.issue6192@psf.upfronthosting.co.za>


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

Looks ok to me.

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

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

From report at bugs.python.org  Thu Jun  4 18:15:01 2009
From: report at bugs.python.org (mARK)
Date: Thu, 04 Jun 2009 16:15:01 +0000
Subject: [issue4108] robotparser.py fail when more than one User-Agent: * is
	present
In-Reply-To: <1223818892.29.0.704490324988.issue4108@psf.upfronthosting.co.za>
Message-ID: <1244132101.49.0.52914076068.issue4108@psf.upfronthosting.co.za>


mARK <python.mbloore at xoxy.net> added the comment:

this looks like a good fix.  i've put it into my own copy.

----------
nosy: +mbloore

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

From report at bugs.python.org  Thu Jun  4 19:08:11 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Thu, 04 Jun 2009 17:08:11 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244135291.96.0.426761818186.issue5798@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Well, with fresh build of Python 3.1rc1 on MacOS X 10.4.11 Tiger (Intel) test_asynchat.py rev 73183 still seems to 
fail, perhaps differently.  Here is 3 different results.  First, rev 73183:

% ./python.exe  Lib/test/test_asynchat73183.py
test_close_when_done (__main__.TestAsynchat) ... ok
test_empty_line (__main__.TestAsynchat) ... ok
test_line_terminator1 (__main__.TestAsynchat) ... ok
test_line_terminator2 (__main__.TestAsynchat) ... ok
test_line_terminator3 (__main__.TestAsynchat) ... ok
test_none_terminator (__main__.TestAsynchat) ... ok
test_numeric_terminator1 (__main__.TestAsynchat) ... ok
test_numeric_terminator2 (__main__.TestAsynchat) ... ok
test_simple_producer (__main__.TestAsynchat) ... ok
test_string_producer (__main__.TestAsynchat) ... ok
test_close_when_done (__main__.TestAsynchat_WithPoll) ... ok
test_empty_line (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x10835b0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator1 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083550> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x1083610> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x10835f0> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator2 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083630> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x1083870> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x10838b0> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator3 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083610> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x1083550> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x10835f0> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_none_terminator (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083550> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_numeric_terminator1 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083630> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_numeric_terminator2 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x10837f0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_simple_producer (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083910> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_string_producer (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x10835b0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_find_prefix_at_end (__main__.TestHelperFunctions) ... ok
test_basic (__main__.TestFifo) ... ok
test_given_list (__main__.TestFifo) ... ok

----------------------------------------------------------------------
Ran 23 tests in 7.717s

OK


Second, this is the result of test_asyncat.py included in Python 3.1rc1:

% ./python.exe Lib/test/test_asynchat.py
test_close_when_done (__main__.TestAsynchat) ... ok
test_empty_line (__main__.TestAsynchat) ... ok
test_line_terminator1 (__main__.TestAsynchat) ... ok
test_line_terminator2 (__main__.TestAsynchat) ... ok
test_line_terminator3 (__main__.TestAsynchat) ... ok
test_none_terminator (__main__.TestAsynchat) ... ok
test_numeric_terminator1 (__main__.TestAsynchat) ... ok
test_numeric_terminator2 (__main__.TestAsynchat) ... ok
test_simple_producer (__main__.TestAsynchat) ... ok
test_string_producer (__main__.TestAsynchat) ... ok
test_close_when_done (__main__.TestAsynchat_WithPoll) ... ok
test_empty_line (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x10835b0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator1 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083550> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x1083610> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x10835f0> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator2 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083630> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x1083870> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x10838b0> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_line_terminator3 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083610> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x1083550> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
error: uncaptured python exception, closing channel <__main__.echo_client at 0x10835f0> (<class 
'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_none_terminator (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083550> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_numeric_terminator1 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083670> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_numeric_terminator2 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x10837f0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_simple_producer (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x1083910> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_string_producer (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel 
<__main__.echo_client at 0x10835b0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [../Python-
3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
ok
test_find_prefix_at_end (__main__.TestHelperFunctions) ... ok
test_basic (__main__.TestFifo) ... ok
test_given_list (__main__.TestFifo) ... ok

----------------------------------------------------------------------
Ran 23 tests in 7.721s

OK


Both are not the exact same, but equivalent.  Lastly, here are 4 snippets from the 'make test' output.

....<deleted>....

test test_asynchat produced unexpected output:
**********************************************************************
*** lines 2-16 of actual output doesn't appear in expected output after line 1:
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x22704f0> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270b10> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x22704b0> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270470> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x22703d0> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270450> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x22704f0> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x22704b0> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270b10> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270530> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270b10> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270470> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x22704d0> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x22709f0> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
+ error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x2270b10> (<class 
'socket.error'
>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Tools/Python-
3.1rc1/Lib/asyncore.py|handle_expt_event|440])
**********************************************************************
....<deleted>....

test_cmd_line
test test_cmd_line failed -- Traceback (most recent call last):
  File "../Tools/Python-3.1rc1/Lib/test/test_cmd_line.py", line 145, in test_run_code
    0)
AssertionError: 1 != 0
....<deleted>....

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:50714 at 
0x3b21ff0> (<cl
ass 'socket.error'>:[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [/Users/
../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440])
**********************************************************************
....<deleted>....

308 tests OK.
3 tests failed:
    test_asynchat test_cmd_line test_smtplib
25 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
    test_epoll test_largefile test_nis test_normalization
    test_ossaudiodev test_pep277 test_smtpnet test_socketserver
    test_startfile test_timeout test_tk test_ttk_guionly
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_xmlrpc_net test_zipfile64
Those skips are all expected on darwin.
make: *** [test] Error 1

----------

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

From report at bugs.python.org  Thu Jun  4 19:16:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Jun 2009 17:16:53 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7	with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244135813.87.0.492290640295.issue6154@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14183/smime.p7s

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

From report at bugs.python.org  Thu Jun  4 19:16:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Jun 2009 17:16:58 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7	with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244135818.83.0.558701991673.issue6154@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14182/smime.p7s

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

From report at bugs.python.org  Thu Jun  4 19:17:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Jun 2009 17:17:02 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7	with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244135822.72.0.751029725094.issue6154@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14181/smime.p7s

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

From report at bugs.python.org  Thu Jun  4 19:17:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Jun 2009 17:17:06 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7	with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244135826.52.0.706431261104.issue6154@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file14180/smime.p7s

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

From report at bugs.python.org  Thu Jun  4 19:19:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jun 2009 17:19:20 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244135960.52.0.648100504283.issue5798@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I presume you mean "a fresh build of 3.1rc1+" (from svn)?  3.1rc1 does
not contain the most recent fix.

----------

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

From report at bugs.python.org  Thu Jun  4 20:01:52 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 04 Jun 2009 18:01:52 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244138512.43.0.837825847704.issue5798@psf.upfronthosting.co.za>


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

I installed 3.1rc1 on my OS X (10.5.?) machine, updated asynchat, and ran 
the test with and without my change.  Without my change, it breaks in the 
way described numerous times.  With my change, it seems to work fine on OS 
X, linux, and Windows for me.

Looking at line 106 in py3k/Lib/asyncore.py 
(http://svn.python.org/view/python/branches/py3k/Lib/asyncore.py?
annotate=73183) gets me "obj.handle_close()".  Your tracebacks show line 
106 calling "obj.handle_expt_event()", which is the old code.

----------

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

From report at bugs.python.org  Thu Jun  4 20:28:51 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Jun 2009 18:28:51 +0000
Subject: [issue1590864] import deadlocks when using PyObjC threads
Message-ID: <1244140131.93.0.40206085915.issue1590864@psf.upfronthosting.co.za>


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

Been thinking about it and as a compromise to people who view this as a
bug I am re-opening it but lowering the priority.

----------
components: +Interpreter Core -Library (Lib)
priority: normal -> low
resolution: wont fix -> 
stage: committed/rejected -> test needed
status: closed -> open

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

From report at bugs.python.org  Thu Jun  4 20:34:50 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Jun 2009 18:34:50 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244140490.8.0.0088819756282.issue6154@psf.upfronthosting.co.za>


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


----------
title: Python 3.1 rc1 will not build on OS X 10.5.7	with macports libintl -> Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl

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

From report at bugs.python.org  Thu Jun  4 20:36:45 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Jun 2009 18:36:45 +0000
Subject: [issue1590864] Function-level import in os triggering an threaded
	import deadlock
Message-ID: <1244140605.35.0.901545503811.issue1590864@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib) -Interpreter Core
title: import deadlocks when using PyObjC threads -> Function-level import in os triggering an threaded import deadlock

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

From report at bugs.python.org  Thu Jun  4 20:40:50 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Jun 2009 18:40:50 +0000
Subject: [issue6182] Remove ipaddr library from py3k before 3.1rc2
In-Reply-To: <1243994583.57.0.193467275614.issue6182@psf.upfronthosting.co.za>
Message-ID: <1244140850.34.0.537925168364.issue6182@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

r73230 and r73223

----------
status: open -> closed

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

From report at bugs.python.org  Thu Jun  4 21:00:15 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 19:00:15 +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: <1244142015.17.0.0797530388849.issue3684@psf.upfronthosting.co.za>


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

Good point. Added a test in r73232.

----------

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

From report at bugs.python.org  Thu Jun  4 21:05:28 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 19:05:28 +0000
Subject: [issue6193] urllib: ... IOError: ... unknown url type: 'c'
In-Reply-To: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>
Message-ID: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

On Windows, urllib fails to open local files:

> python -c "import urllib; urllib.urlopen(r'C:\test.txt').read()"
Traceback (most recent call last):
  File "C:\HOME\as\pypm\bin\python-script.py", line 33, in <module>
    exec _val
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\urllib.py", line 87, in urlopen
    return opener.open(url)
  File "C:\Python26\lib\urllib.py", line 200, in open
    return self.open_unknown(fullurl, data)
  File "C:\Python26\lib\urllib.py", line 212, in open_unknown
    raise IOError, ('url error', 'unknown url type', type)
IOError: [Errno url error] unknown url type: 'c'


However, on Unix this is not an issue:

$ python -c "import urllib; print urllib.urlopen('/tmp/test.txt').read()"
Foo
$

----------
components: Library (Lib)
messages: 88894
nosy: srid
severity: normal
status: open
title: urllib: ... IOError: ... unknown url type: 'c'
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  4 21:07:42 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 19:07:42 +0000
Subject: [issue6193] urllib: ... IOError: ... unknown url type: 'c'
In-Reply-To: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>
Message-ID: <1244142462.73.0.967602520604.issue6193@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

This also happens on 3.1 (urllib.urlrequest) .. and I believe must also
happen on 2.7 and 3.0.

----------
components: +Windows
versions: +Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jun  4 21:08:56 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 19:08:56 +0000
Subject: [issue6193] urllib: ... IOError: ... unknown url type: 'c'
In-Reply-To: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>
Message-ID: <1244142536.57.0.501048411019.issue6193@psf.upfronthosting.co.za>


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

You should use file:// to open local files with urllib.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Jun  4 21:09:47 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 19:09:47 +0000
Subject: [issue6193] urllib: ... IOError: ... unknown url type: 'c'
In-Reply-To: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>
Message-ID: <1244142587.43.0.524049249147.issue6193@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Relevant discussion:

http://osdir.com/ml/python.py2exe/2008-03/msg00013.html

[quote]'The only thing I could think of was editing urllib.py and
changing the splittype method (...)'[endquote]

----------

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

From report at bugs.python.org  Thu Jun  4 21:10:24 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 19:10:24 +0000
Subject: [issue6193] urllib: ... IOError: ... unknown url type: 'c'
In-Reply-To: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>
Message-ID: <1244142624.5.0.158305387673.issue6193@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

[Brandl] You should use file:// to open local files with urllib.

Hmm, that is strange. How come it works on Unix without file://?

----------

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

From report at bugs.python.org  Thu Jun  4 21:13:06 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 19:13:06 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244142786.51.0.152770640839.issue6191@psf.upfronthosting.co.za>


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

I do not think HTMLParser should guess.  Guessing always opens the door
to misinterpretation.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Jun  4 21:33:36 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jun 2009 19:33:36 +0000
Subject: [issue6193] urllib: ... IOError: ... unknown url type: 'c'
In-Reply-To: <1244142328.47.0.29736473077.issue6193@psf.upfronthosting.co.za>
Message-ID: <1244144016.95.0.839114111951.issue6193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because in unix the filename starts with a '/', while in windows your
filename started with a 'C:'.  That looks like the urltype portion of a
url, and it isn't a valid one, so urllib correctly rejects it.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Thu Jun  4 22:32:22 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 04 Jun 2009 20:32:22 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244147542.76.0.113197493816.issue6137@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Oops. Here is a new patch with _compat_pickle.py.

----------
Added file: http://bugs.python.org/file14186/compat_pickle7.diff

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

From report at bugs.python.org  Thu Jun  4 22:33:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Jun 2009 20:33:02 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244147582.48.0.268696428197.issue6137@psf.upfronthosting.co.za>


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

Committed in r73236 in the hope that it gets a bit more testing before
rc2/final.

----------
assignee: alexandre.vassalotti -> 
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Thu Jun  4 23:36:33 2009
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Widera?=)
Date: Thu, 04 Jun 2009 21:36:33 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244151393.63.0.110728527881.issue6191@psf.upfronthosting.co.za>


Pawe? Widera <momat at man.poznan.pl> added the comment:

It depends whether you want a HTMLParser to be an useful tool that can
deal with real world HTML or just a toy without practical meaning.
Crashing on every little deviation from the standard, where more relaxed
approach is possible, doesn't sound to me as a reasonable choice.

Maybe guess is not a proper word... If the standard strict approach
fails, the parser should fall back to a less strict one in an attempt to
actually parse the document. Throwing an exception and giving up is just
not good enough.

Can we have somebody else commenting on this one please?

----------
status: closed -> open

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

From report at bugs.python.org  Thu Jun  4 23:38:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jun 2009 21:38:38 +0000
Subject: [issue6194] fcntl footnote about O_SHLOCK and O_EXLOCK is misleading
In-Reply-To: <1244151518.6.0.751803851074.issue6194@psf.upfronthosting.co.za>
Message-ID: <1244151518.6.0.751803851074.issue6194@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

At the bottom of http://docs.python.org/library/fcntl.html there is a
"see also" section for the os module that says:

    If the locking flags O_SHLOCK and O_EXLOCK are present in the os
module, the os.open() function provides a more platform-independent
alternative to the lockf() and flock() functions.

However, those flags are documented as being "unix only" (ie: no
windows), and in fact Linux does not support them.  Alan Cox rejected
support for them back in 2000 according to this linux kernel posting:

  http://lkml.indiana.edu/hypermail/linux/kernel/0005.1/1309.html

so it doesn't seem likely linux will ever support them.

Thus, to say that they provide a "more platform independent-alternative"
would appear to be false, since they appear to only be supported on BSD
and derivitives.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 88904
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: fcntl footnote about O_SHLOCK and O_EXLOCK is misleading
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jun  4 23:40:19 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 04 Jun 2009 21:40:19 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244151619.6.0.330015235615.issue6154@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

The current check for *gettext/*textdomain* functions is not so correct.
It mix(!?!) checks for headers with check for functions.

GNU libc include them and on linux we will see in pyconfig.h (trunk):
-----------
/* #undef WITH_LIBINTL */
#define HAVE_LIBINTL_H 1
#define HAVE_BIND_TEXTDOMAIN_CODESET 1
-----------

If system "C" library don't include them then configure check(search) in
 additional libraries (-lintl) but in this case
"bind_textdomain_codeset" is not detected.

As the current check is "AC_CHECK_LIB(intl, textdomain, [ACTION], ..."
the library is not added to LIBS (see autoconf texinfo pages as reference).

Another file is setup.py . Trunk version add library "intl" if
WITH_LIBINTL is defined and on darwin adds '-framework',
'CoreFoundation' to link flags.

It seems to me that patch is not so simple.
May i propose following changes:
- remove current check for function "bind_textdomain_codeset";
- remove current check for header "libintl.h"
- replace "AC_CHECK_LIB(intl, textdomain, ..." with 
AC_SEARCH_LIBS(bindtextdomain, intl, 
 #ACTION-IF-FOUND
   check for header "libintl.h"
   check for function "bind_textdomain_codeset"
- adjust use of defines in locale module
- adjust setup.py if necessary (I don't know p3k branch)


In a more advanced check I won't add library "intl" to $LIBS.
The check will be similar to the check for readline + restore of LIBS
after check and I will move line for locale module from Setup.dist into
Setup.config.in as example:
_locale _localemodule.c @LOCALE_LIBS@ #
where LOCALE_LIBS is substituted by configure script.

----------

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

From report at bugs.python.org  Thu Jun  4 23:42:55 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 21:42:55 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244151775.95.0.643024532005.issue6191@psf.upfronthosting.co.za>


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

> Throwing an exception and giving up is just not good enough.

Yes it is, in some cases. There are "forgiving" HTML parsers out there,
HTMLParser does not strive to be one.

There are *so many* cases where HTML is a bit malformed that it takes
more than just two exceptions to get it right.  It's for a reason that
browsers' parsers are so complex.  If you add these corner cases, people
will come asking for this exception, and that one, etc.

----------
status: open -> pending

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

From report at bugs.python.org  Thu Jun  4 23:42:59 2009
From: report at bugs.python.org (Lisandro Dalcin)
Date: Thu, 04 Jun 2009 21:42:59 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>


New submission from Lisandro Dalcin <dalcinl at gmail.com>:

When doctests are written in docstrings from C extension modules,
'doctest' reads the binary extension module file.

The attached one-line patch seems to fix the problem, it is in fact very
similar to patch for issue4050 related to 'inspect'.

----------
components: Library (Lib), Tests
files: doctest.diff
keywords: patch
messages: 88907
nosy: dalcinl, scoder
severity: normal
status: open
title: Serious regression in doctest in Py3.1rc1
versions: Python 3.1
Added file: http://bugs.python.org/file14187/doctest.diff

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

From report at bugs.python.org  Thu Jun  4 23:45:52 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 21:45:52 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

If a tarball has a-x perms set on its root directory, one cannot access
its contents. 

$ tar zxf generator_tools-0.3.5.tar.gz.
$ ls generator_tools-0.3.5/
ls: cannot access generator_tools-0.3.5/README.txt: Permission denied
...
sridharr at double:/tmp/i$ 

This is fine for GNU tar (the user can always do a chmod +x later). But
for the tarfile library, it would be better to have a flag such as
readaccess=True that will force ``extractall`` to enforce *minimum*
permissions required for the basic read access. This means, tarfile
would ignore u-x on directories and u-r on files.

The reason I make this feature request (instead of working around the
issue myself in a verbose way) is that the very reason to write a
program to extract tarball (instead of doing it manually) is to automate
it .. which automation is more effective and simple if ``extractall``
had a flag such as readaccess=True.

----------
components: Library (Lib)
messages: 88908
nosy: srid
severity: normal
status: open
title: tarfile.extractall(readaccess=True)
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/issue6196>
_______________________________________

From report at bugs.python.org  Thu Jun  4 23:46:31 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 21:46:31 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244151991.15.0.072710064158.issue6196@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Here's a test data from PyPI:
http://pypi.python.org/packages/source/g/generator_tools/generator_tools-0.3.5.tar.gz

----------

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

From report at bugs.python.org  Thu Jun  4 23:50:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jun 2009 21:50:27 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244152227.38.0.361488389478.issue6191@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In doing web scraping I started using BeautifulSoup precisely because it
was very lenient in what html it accepted (I haven't written such an ap
for a while, so I'm not sure what BeautifulSoup currently does...I
thought I heard it was now using HTMLParser...).

There are a lot of messed up web pages out there.

I don't have time right now to evaluate your particular cases, but my
rule of thumb would be that if the major web browsers do something
"reasonable" with these cases, then a python tool designed to read web
pages should do so as well, where possible.  ("Be liberal in what you
accept, and strict in what you generate.")

That said, I'm not sure what HTMLParser's design goals are, so this may
not be an appropriate goal for the module.

----------
nosy: +r.david.murray
priority:  -> normal
status: pending -> open

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

From report at bugs.python.org  Thu Jun  4 23:52:03 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 21:52:03 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244152323.12.0.69186905173.issue6196@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Considering this bug where tarfile fails to set g+s,

  https://bugs.launchpad.net/pyopenssl/+bug/236190

a more general approach could be:

  tarfile.extractall(safe_perms=True)

where if safe_perms is set, tarfile can 1) ignore +/-s on all files, 2)
ignore u-x on directories and 3) ignore u-r on files.

----------

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

From report at bugs.python.org  Fri Jun  5 00:12:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Jun 2009 22:12:07 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244153527.36.0.599518653645.issue6196@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see why the tarfile case should be different from the tar case.
 You can "always chmod it later" in python, too (with os.walk and
os.chmod).  Perhaps the real need is for a recursive chmod in shutil?

----------
nosy: +r.david.murray
priority:  -> low

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

From report at bugs.python.org  Fri Jun  5 00:22:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Jun 2009 22:22:25 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244154145.87.0.978837949202.issue6191@psf.upfronthosting.co.za>


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

So BeautifulSoup is using HTMLParser? That is interesting, because they
claim to support "broken" HTML.

In any case, if a "quirky" mode is added, it should have to be turned on
explicitly by a flag.

----------
resolution: wont fix -> 

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

From report at bugs.python.org  Fri Jun  5 00:24:22 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 04 Jun 2009 22:24:22 +0000
Subject: [issue6127] Unexpected universal newline behavior (newline
	duplication) in Windows
In-Reply-To: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>
Message-ID: <1244154262.49.0.806651290695.issue6127@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Can you check if the patch in issue #5645 fix the bug?

----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Fri Jun  5 00:28:17 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 04 Jun 2009 22:28:17 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244154497.9.0.219226865054.issue6196@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

[David] I don't see why the tarfile case should be different from the
tar case. (...)

As I explained, Viz:

[quote]'(...)the very reason to write a program to extract tarball
(instead of doing it manually) is to automate it .. which automation is
*more effective and simple* if ``extractall`` had a flag such as
readaccess=True'[endquote] (emphasis added)

[David] You can "always chmod it later" in python, too (with os.walk and
os.chmod). (...)

Of course, I can. Or:

        EXECUTE = 0100
        READ = 0400
        dir_perm = EXECUTE
        file_perm = EXECUTE | READ
        for tarinfo in f.getmembers():
            tarinfo.mode |= (dir_perm if tarinfo.isdir() else file_perm)

As you can see, for a tarfile with huge list of files.. this can be a
performance issue.

[David] (...) Perhaps the real need is for a recursive chmod in shutil?

The real need is to fix the weird permissions on some tarballs (such as
generator_tools-0.3.5.tar.gz in PyPI and the above mentioned pyopenssl
tarball).

This need usually leads to designing workarounds. 

I just think it is not simple (as in, keeping the code off from such
hacks that are tangential to the problem being solved) and effective (as
in, not having to deal with potential unintended side effects like bugs
in the post-fix chmoding or in the pre-fix tarinfo mode modifications).

Hence the feature request.

----------

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

From report at bugs.python.org  Fri Jun  5 02:41:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Jun 2009 00:41:51 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244162511.05.0.249762231318.issue6195@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
nosy: +r.david.murray
priority:  -> high
stage:  -> test needed

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

From report at bugs.python.org  Fri Jun  5 03:53:32 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Jun 2009 01:53:32 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244166812.4.0.249431790769.issue6195@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's a test case which fails with the existing code and passes with
the patch applied.

However, with the patch applied some of the other doctest tests fail
with an off-by-one error in the source line number output.  I'd like to
understand that difference before committing the patch, but haven't
figured it out yet.

----------
stage: test needed -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file14188/doctest-test.diff

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

From report at bugs.python.org  Fri Jun  5 04:28:05 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Jun 2009 02:28:05 +0000
Subject: [issue6127] Unexpected universal newline behavior (newline
	duplication) in Windows
In-Reply-To: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>
Message-ID: <1244168885.97.0.462110361089.issue6127@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Indeed, that patch works.  I'm attaching the same patch applicable to
branches/release26-maint.

----------
keywords: +patch
Added file: http://bugs.python.org/file14189/issue5645_release26-maint.patch

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

From report at bugs.python.org  Fri Jun  5 04:29:23 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Jun 2009 02:29:23 +0000
Subject: [issue5645] test_memoryio fails for py3k on windows
In-Reply-To: <1238586810.86.0.465926636353.issue5645@psf.upfronthosting.co.za>
Message-ID: <1244168963.36.0.969113920838.issue5645@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Patch is also applicable to #6127.

----------
nosy: +jaraco

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

From report at bugs.python.org  Fri Jun  5 05:43:34 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 03:43:34 +0000
Subject: [issue6197] test__locale fails with RADIXCHAR on Windows
In-Reply-To: <1244173414.49.0.136863993589.issue6197@psf.upfronthosting.co.za>
Message-ID: <1244173414.49.0.136863993589.issue6197@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

regrtest.py test__locale fails with:
test__locale
test test__locale crashed -- <type 'exceptions.ImportError'>: cannot
import name
 RADIXCHAR
1 test failed:
    test__locale

The attached patch backports the fix from issue5643

----------
components: Tests, Windows
files: test__locale_on_windows.patch
keywords: patch
messages: 88919
nosy: abbeyj, benjamin.peterson, ocean-city
severity: normal
status: open
title: test__locale fails with RADIXCHAR on Windows
versions: Python 2.7
Added file: http://bugs.python.org/file14190/test__locale_on_windows.patch

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

From report at bugs.python.org  Fri Jun  5 06:19:02 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 05 Jun 2009 04:19:02 +0000
Subject: [issue5798] test_asynchat fails on Mac OSX
In-Reply-To: <1240225332.5.0.570636191093.issue5798@psf.upfronthosting.co.za>
Message-ID: <1244175542.41.0.113153297996.issue5798@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Correct.  With new Lib/asyncore.py file rev 73183 all 23 tests in the 
original test_asynchat.py pass in Python 3.1rc1 built from source on 
MacOS X 10.4.11 Tiger (Intel).

% ./python.exe Lib/test/test_asynchat.py
test_close_when_done (__main__.TestAsynchat) ... ok
test_empty_line (__main__.TestAsynchat) ... ok
test_line_terminator1 (__main__.TestAsynchat) ... ok
test_line_terminator2 (__main__.TestAsynchat) ... ok
test_line_terminator3 (__main__.TestAsynchat) ... ok
test_none_terminator (__main__.TestAsynchat) ... ok
test_numeric_terminator1 (__main__.TestAsynchat) ... ok
test_numeric_terminator2 (__main__.TestAsynchat) ... ok
test_simple_producer (__main__.TestAsynchat) ... ok
test_string_producer (__main__.TestAsynchat) ... ok
test_close_when_done (__main__.TestAsynchat_WithPoll) ... ok
test_empty_line (__main__.TestAsynchat_WithPoll) ... ok
test_line_terminator1 (__main__.TestAsynchat_WithPoll) ... ok
test_line_terminator2 (__main__.TestAsynchat_WithPoll) ... ok
test_line_terminator3 (__main__.TestAsynchat_WithPoll) ... ok
test_none_terminator (__main__.TestAsynchat_WithPoll) ... ok
test_numeric_terminator1 (__main__.TestAsynchat_WithPoll) ... ok
test_numeric_terminator2 (__main__.TestAsynchat_WithPoll) ... ok
test_simple_producer (__main__.TestAsynchat_WithPoll) ... ok
test_string_producer (__main__.TestAsynchat_WithPoll) ... ok
test_find_prefix_at_end (__main__.TestHelperFunctions) ... ok
test_basic (__main__.TestFifo) ... ok
test_given_list (__main__.TestFifo) ... ok

----------------------------------------------------------------------
Ran 23 tests in 7.726s

OK

----------

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

From report at bugs.python.org  Fri Jun  5 07:30:28 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 05 Jun 2009 05:30:28 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244179827.59.0.0195757180628.issue6137@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I think it is worth noting that now some Python 3.1 protocol 2 pickles
can't be read by Python 3.0. We probably don't have to do anything about
that, but perhaps it should be mentioned somewhere? Docs, release notes?

----------
status: pending -> open

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

From report at bugs.python.org  Fri Jun  5 07:46:34 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 05:46:34 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

test_float fails on Windows with:
======================================================================
FAIL: test_format_testfile (test.test_float.IEEEFormatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Projects\python-trunk\lib\test\test_float.py", line 319, in
test_format_testfile
    self.assertEqual(fmt % float(arg), rhs)
AssertionError: '3' != '2'

----------------------------------------------------------------------


The problematic line from formatfloat_testcases.txt is:
%.0f 2.5 -> 2


On some systems *printf() uses round-to-even.  But the Windows CRT uses
round-half-away-from-zero.  Consider the following C code:
	printf("%+.1f -> %+.0f\n", -2.5, -2.5);
	printf("%+.1f -> %+.0f\n", -1.5, -1.5);
	printf("%+.1f -> %+.0f\n", +1.5, +1.5);
	printf("%+.1f -> %+.0f\n", +2.5, +2.5);

On Linux this will produce:
-2.5 -> -2
-1.5 -> -2
+1.5 -> +2
+2.5 -> +2

And on Windows:
-2.5 -> -3
-1.5 -> -2
+1.5 -> +2
+2.5 -> +3

----------
components: Tests, Windows
messages: 88922
nosy: abbeyj
severity: normal
status: open
title: test_float fails on Windows
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  5 07:58:16 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 05:58:16 +0000
Subject: [issue6199] test_unittest fails on Windows
In-Reply-To: <1244181487.09.0.399837041232.issue6199@psf.upfronthosting.co.za>
Message-ID: <1244181487.09.0.399837041232.issue6199@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

test_unittest fails on Windows with:
======================================================================
FAIL: test_find_tests_with_package (test.test_unittest.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Projects\python-trunk\lib\test\test_unittest.py", line 3540,
in test_find_tests_with_package
    self.assertEqual(suite, ['load_tests', '/foo/test_directory2 module
tests'])

AssertionError: Lists differ: ['load_tests', '/foo\\test_dir... !=
['load_tests', '/foo/test_dire...

First differing element 1:
/foo\test_directory2 module tests
/foo/test_directory2 module tests

- ['load_tests', '/foo\\test_directory2 module tests']
?                     ^^

+ ['load_tests', '/foo/test_directory2 module tests']
?                     ^


----------------------------------------------------------------------


Patch attached.

----------
components: Tests, Windows
files: test_unittest_on_windows.patch
keywords: patch
messages: 88923
nosy: abbeyj
severity: normal
status: open
title: test_unittest fails on Windows
versions: Python 2.7
Added file: http://bugs.python.org/file14191/test_unittest_on_windows.patch

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

From report at bugs.python.org  Fri Jun  5 08:04:10 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 05 Jun 2009 06:04:10 +0000
Subject: [issue6197] test__locale fails with RADIXCHAR on Windows
In-Reply-To: <1244173414.49.0.136863993589.issue6197@psf.upfronthosting.co.za>
Message-ID: <1244181850.65.0.604582354571.issue6197@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Committed in r73238. Thanks!

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

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

From report at bugs.python.org  Fri Jun  5 08:45:43 2009
From: report at bugs.python.org (James Abbatiello)
Date: Fri, 05 Jun 2009 06:45:43 +0000
Subject: [issue6201] test_winreg fails
In-Reply-To: <1244184342.63.0.700408501075.issue6201@psf.upfronthosting.co.za>
Message-ID: <1244184342.63.0.700408501075.issue6201@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

test_winreg fails with:
======================================================================
ERROR: testLocalMachineRegistryWorks (test.test_winreg.WinregTests)
----------------------------------------------------------------------
Traceback (most recent call last):
<snip>
  File "C:\Projects\python-trunk\lib\test\test_winreg.py", line 86, in
ReadTestData
    with OpenKey(key, "sub_key") as sub_key:
AttributeError: __exit__

----------------------------------------------------------------------

_winreg.OpenKey() returns a PyHKEY.  This type can no longer be used in
a "with" statement after r72912 introduced the SETUP_WITH opcode.  The
old way used PyObject_GetAttr() to get __enter__ and __exit__ which
works fine with PyHKEY since it has a tp_getattr function.  The new way
uses _PyObject_LookupSpecial() which uses the MRO and the dict of the
object.

I guess the right fix here is to update PyHKEY so it uses the modern
APIs but I don't know how to do this without breaking the special casing
for the "handle" member.  Using T_INT isn't quite correct since it is a
pointer not an int.

----------
components: Tests, Windows
messages: 88926
nosy: abbeyj
severity: normal
status: open
title: test_winreg fails
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  5 10:26:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 08:26:01 +0000
Subject: [issue6199] test_unittest fails on Windows
In-Reply-To: <1244181487.09.0.399837041232.issue6199@psf.upfronthosting.co.za>
Message-ID: <1244190360.96.0.302986863253.issue6199@psf.upfronthosting.co.za>


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


----------
assignee:  -> michael.foord
nosy: +michael.foord

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

From report at bugs.python.org  Fri Jun  5 10:26:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 08:26:24 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244190384.45.0.100158395587.issue6198@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun  5 10:26:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 08:26:50 +0000
Subject: [issue6201] test_winreg fails
In-Reply-To: <1244184342.63.0.700408501075.issue6201@psf.upfronthosting.co.za>
Message-ID: <1244190410.72.0.797148645231.issue6201@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun  5 10:42:14 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Jun 2009 08:42:14 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244191334.16.0.964585190237.issue6198@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Fri Jun  5 10:54:54 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Jun 2009 08:54:54 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244192094.72.0.348969255357.issue6198@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I can duplicate this with Visual C++ 9.0 Express Edition on XP.

----------

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

From report at bugs.python.org  Fri Jun  5 11:50:24 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 09:50:24 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1244195424.38.0.910889324902.issue1943@psf.upfronthosting.co.za>


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

Raymond suggested the patch be committed in 3.1, so as to minimize
disruption between 3.1 and 3.2. Benjamin, what do you think?

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

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

From report at bugs.python.org  Fri Jun  5 12:37:11 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Jun 2009 10:37:11 +0000
Subject: [issue6202] Obsolete default file encoding "mac-roman" on OS X,
	not influenced by locale env variables
In-Reply-To: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>
Message-ID: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Potential Release Blocker

The default file encoding for 3.x file objects is the value of 
locale.getpreferredencoding(). Currently, the locale module behavior on 
OS X deviates from other python POSIX platforms in a few unexpected and 
bad ways:

1. On OS X, locale.getpreferredencoding() returns "mac-roman", an 
obsolete encoding from the old "Classic" MacOS days.

2. Unlike other POSIX platforms (at least Debian Linux), the values 
returned by locale.getdefaultlocale() and locale.getpreferredencoding() 
on OS X are not influenced by the settings of the POSIX locale 
environment variables, i.e LANG.  So, unlike on the other POSIX 
platforms, one can't override the (obsolete) encoding without explicitly 
setting the encoding argument to open().

Compare the results from Debian Linux:

$ unset LANG
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'ANSI_X3.4-1968'
>>> open('blah','r').encoding
'ANSI_X3.4-1968'
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
(None, None)
>>> 
$ export LANG=en_US.UTF-8
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'UTF-8'
>>> open('blah','r').encoding
'UTF-8'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

... to OS X:

$ unset LANG
$ python3.1
Python 3.1rc1+ (py3k, Jun  3 2009, 14:31:41) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'mac-roman'
>>> open('blah','r').encoding
'mac-roman'
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
(None, 'mac-roman')
>>> 
$ export LANG=en_US.UTF-8
$ python3.1
Python 3.1rc1+ (py3k, Jun  3 2009, 14:31:41) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'mac-roman'
>>> open('blah','r').encoding
'mac-roman'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
(None, 'mac-roman')
>>> 

A quick look at the code shows that part of the problem is in 
Modules/_localemodule.c where there is a #if defined(__APPLE__) version 
of PyLocale_getdefaultlocale which appears to have its origins in MacOS 
and should probably just be removed and locale.py modified to 
eliminate/minimize the special case mac/darwin code.  For the case of no 
locale, "UTF-8" would seem to be a reasonable default.  In any case, 
"mac-roman" is not.

----------
assignee: ronaldoussoren
components: IO, Library (Lib), Macintosh
messages: 88929
nosy: benjamin.peterson, nad, ronaldoussoren
severity: normal
status: open
title: Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  5 12:43:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Jun 2009 10:43:02 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244198582.74.0.560066935909.issue6198@psf.upfronthosting.co.za>


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

Thanks for the report.  It sounds as though I might have backported
some tests from py3k to trunk that shouldn't have been backported.

abbeyj or eric, do you know whether py3k also has this failure on your 
machine?  I'm hoping not:  py3k doesn't use the CRT *printf functions for 
float formatting, so the test should pass there.

----------
assignee:  -> marketdickinson

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

From report at bugs.python.org  Fri Jun  5 12:50:12 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Jun 2009 10:50:12 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244199012.06.0.277498165354.issue6198@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Yes, this test passes on py3k on my Windows box. That would be a
nightmare if it didn't!

I agree that this is a test problem, not a code problem. I suggest we
just remove the offending line from formatfloat_testcases.txt in trunk.
I can do this and verify it works on Windows before checking in, if
you'd like.

----------

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

From report at bugs.python.org  Fri Jun  5 12:56:39 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Jun 2009 10:56:39 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

In the Library Reference section 22.2.1 for locale, it states:

"Initially, when a program is started, the locale is the C locale, no 
matter what the user?s preferred locale is. The program must explicitly 
say that it wants the user?s preferred locale settings by calling 
setlocale(LC_ALL, '')."

This is the case for python2.x:

$ export LANG=en_US.UTF-8
$ python2.5
Python 2.5.4 (r254:67916, Feb 17 2009, 20:16:45) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

but not for 3.1:
$ python3.1
Python 3.1a1+ (py3k, Mar 23 2009, 00:12:12) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; locale.getlocale()
('en_US', 'UTF8')
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> 

Either the code is incorrect in 3.1 or the documentation should be 
updated.

----------
assignee: georg.brandl
components: Documentation
messages: 88932
nosy: georg.brandl, nad
severity: normal
status: open
title: 3.x locale does not default to C, contrary to the documentation and to 2.x behavior
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  5 12:57:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Jun 2009 10:57:56 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244199476.66.0.051733038198.issue6198@psf.upfronthosting.co.za>


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

[Eric]
> I can do this and verify it works on Windows before checking in, if
> you'd like.

That would be great---yes, please!  My main computer died yesterday, 
taking my Windows access and my python svn access with it. :-(

----------
assignee: marketdickinson -> eric.smith

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

From report at bugs.python.org  Fri Jun  5 13:00:18 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 05 Jun 2009 11:00:18 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244199618.74.0.927694653323.issue6196@psf.upfronthosting.co.za>


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

I am still not convinced why tarfile needs this kind of a work-around
built in. We talk about a very small number of cases here and the
generator_tools-0.3.5.tar.gz is really broken beyond repair. It is the
only thing that should be fixed here IMO ;-)
I agree with David here. It is easy to manipulate the tarfile in
advance, as you have shown yourself. The performance argument does not
convince me either.

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

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

From report at bugs.python.org  Fri Jun  5 13:04:36 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Jun 2009 11:04:36 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244199876.77.0.967657736343.issue6195@psf.upfronthosting.co.za>


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

Patches (fix+test) are good.

----------
nosy: +amaury.forgeotdarc
resolution:  -> accepted

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

From report at bugs.python.org  Fri Jun  5 13:06:16 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 05 Jun 2009 11:06:16 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1244195424.38.0.910889324902.issue1943@psf.upfronthosting.co.za>
Message-ID: <4A28FC26.1030806@egenix.com>


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

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Raymond suggested the patch be committed in 3.1, so as to minimize
> disruption between 3.1 and 3.2. Benjamin, what do you think?

Has Guido pronounced on this already ?

----------

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

From report at bugs.python.org  Fri Jun  5 13:34:08 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Jun 2009 11:34:08 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244201648.08.0.883511460204.issue6198@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I had to remove a bunch of tests. Some were of the form
"<even-number>5", rounded to before the 5. Some were comparing a large
number of digits.

Then there's these:
%#.0g 0 -> 0.         Got '0.0'
%#.1g 0 -> 0.         Got '0.0'
%#.2g 0 -> 0.0        Got '0.00'
%#.3g 0 -> 0.00       Got '0.000'
%#.4g 0 -> 0.000      Got '0.0000'

I'm going to remove these, too, since they're all based on underlying
printf differences. But they seem like a bigger problem than the other
cases.

----------
assignee: eric.smith -> marketdickinson

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

From report at bugs.python.org  Fri Jun  5 13:47:07 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 05 Jun 2009 11:47:07 +0000
Subject: [issue6202] Obsolete default file encoding "mac-roman" on OS X,
	not influenced by locale env variables
In-Reply-To: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>
Message-ID: <1244202427.18.0.440435412454.issue6202@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm setting the priority to "release blocker" because the current 
behaviour is completely unwanted, the "mac-roman" encoding is no longer 
used by default on OSX. All system tools write UTF-8 encoded files by 
default, and the LANG variable is set to an UTF8 encoding as well.

I won't be able to look into before sunday, and possibly only after next 
week (that is june 15th or later) because I'll be at a conference and 
don't know if I have spare time to spent on this after sunday.

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

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

From report at bugs.python.org  Fri Jun  5 14:09:49 2009
From: report at bugs.python.org (Michael Markert)
Date: Fri, 05 Jun 2009 12:09:49 +0000
Subject: [issue6204] Missing reference in section 4.6 to chapter on classes
In-Reply-To: <1244203789.01.0.516038095674.issue6204@psf.upfronthosting.co.za>
Message-ID: <1244203789.01.0.516038095674.issue6204@psf.upfronthosting.co.za>


New submission from Michael Markert <markert.michael at gmail.com>:

In section 4.6 there is described that classes will be explained later
on. I think a real reference would be more appropriate.
See attached patch.

----------
assignee: georg.brandl
components: Documentation
files: controlflow.rst.patch
keywords: patch
messages: 88939
nosy: cofi, georg.brandl
severity: normal
status: open
title: Missing reference in section 4.6 to chapter on classes
versions: Python 3.1
Added file: http://bugs.python.org/file14192/controlflow.rst.patch

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

From report at bugs.python.org  Fri Jun  5 14:35:52 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Jun 2009 12:35:52 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244205352.54.0.157114707185.issue6198@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Checked in to trunk in r73240.

----------
assignee: marketdickinson -> eric.smith
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Jun  5 14:56:26 2009
From: report at bugs.python.org (Dennis Benzinger)
Date: Fri, 05 Jun 2009 12:56:26 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1244206586.67.0.947769866246.issue4966@psf.upfronthosting.co.za>


Changes by Dennis Benzinger <Dennis.Benzinger at gmx.net>:


----------
nosy: +dcbbcd

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

From report at bugs.python.org  Fri Jun  5 14:57:14 2009
From: report at bugs.python.org (Dennis Benzinger)
Date: Fri, 05 Jun 2009 12:57:14 +0000
Subject: [issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]
In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
Message-ID: <1244206634.54.0.275692460494.issue3292@psf.upfronthosting.co.za>


Changes by Dennis Benzinger <Dennis.Benzinger at gmx.net>:


----------
nosy: +dcbbcd

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

From report at bugs.python.org  Fri Jun  5 15:03:51 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 05 Jun 2009 13:03:51 +0000
Subject: [issue6123] tarfile: opening an empty tar file fails
In-Reply-To: <1243427347.79.0.845990376951.issue6123@psf.upfronthosting.co.za>
Message-ID: <1244207031.14.0.973793932766.issue6123@psf.upfronthosting.co.za>


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

Thanks for the report. Empty archives are perfectly valid and tarfile
should be able to read them without error. I will take care of this
issue soon.

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

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

From report at bugs.python.org  Fri Jun  5 15:43:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Jun 2009 13:43:25 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244209405.76.0.360861777714.issue6198@psf.upfronthosting.co.za>


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

Thanks, Eric.  All those changes look good to me.

Out of interest, what does '%#.0f' % 1.5 produce on
Python 2.7/Windows?  I'd expect to get '2.' both for
round-half-to-even and round-half-away-from-zero.
Does Windows round this down to '1.' instead?

I'm surprised by the %#.ng results for 0;  this looks
like questionable behaviour (producing n+1 digits when
only n significant digits were requested).  Is the MS
implementation of printf directly responsible for this,
or is the CPython code somehow adding the extra 0?
If this is just the way that Windows behaves for formatting
of zeros, then I suppose we could add code to work around
this, but it's not clear that it's really worth it.

I suspect that we're in for some complaints when
Windows users discover that Python 3.1 string formatting
does round-half-to-even rather than the round-half-up
they're used to in Python 2.x.

----------

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

From report at bugs.python.org  Fri Jun  5 15:58:51 2009
From: report at bugs.python.org (Tim Peters)
Date: Fri, 05 Jun 2009 13:58:51 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244210331.08.0.595550617926.issue6198@psf.upfronthosting.co.za>


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

> Out of interest, what does '%#.0f' % 1.5 produce on
> Python 2.7/Windows?

Microsoft's float->string routines have always done "add a half and
chop" rounding.  So, yes, 1.5 rounds to 2 there.

> ...
> I suspect that we're in for some complaints when
> Windows users discover that Python 3.1 string
> formatting does round-half-to-even rather than
> the round-half-up they're used to in Python 2.x.

Historically, overall we've had more gripes from non-Windows users
complaining that, e.g., 2.5 does /not/ round up to 3 -- you can't win
here, so don't worry about it.  X-platform consistency is incompatible
with platform-specific behavior, and most users will agree consistency
is overwhelmingly more important.  Of course that won't deter them from
complaining ;-)

----------
nosy: +tim_one

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

From report at bugs.python.org  Fri Jun  5 16:03:20 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Jun 2009 14:03:20 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244209405.76.0.360861777714.issue6198@psf.upfronthosting.co.za>
Message-ID: <4A2925C1.9080802@trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

Mark Dickinson wrote:
> Out of interest, what does '%#.0f' % 1.5 produce on
> Python 2.7/Windows?  I'd expect to get '2.' both for
> round-half-to-even and round-half-away-from-zero.
> Does Windows round this down to '1.' instead?

Windows in trunk gives '2.'.

> I'm surprised by the %#.ng results for 0;  this looks
> like questionable behaviour (producing n+1 digits when
> only n significant digits were requested).  Is the MS
> implementation of printf directly responsible for this,
> or is the CPython code somehow adding the extra 0?
> If this is just the way that Windows behaves for formatting
> of zeros, then I suppose we could add code to work around
> this, but it's not clear that it's really worth it.

This is from a C program on Windows, using printf:
%#.0g: 0.0
%#.1g: 0.0
%#.2g: 0.00
%#.3g: 0.000

Same program on Linux:
%#.0g: 0.
%#.1g: 0.
%#.2g: 0.0
%#.3g: 0.00

In 2.6 on Windows:
 >>> '%#.1g' % 0.0
'0.0'
 >>> '%#.2g' % 0.0
'0.00'

In 2.6 on Linux:
 >>> '%#.1g' % 0.0
'0.'
 >>> '%#.2g' % 0.0
'0.0'

So this isn't a problem we caused with the short repr work, it's 
pre-existing. I don't think it's worth working around, but that's me. 
%-formatting should just die.

> I suspect that we're in for some complaints when
> Windows users discover that Python 3.1 string formatting
> does round-half-to-even rather than the round-half-up
> they're used to in Python 2.x.

But at least in 3.1 it will now be consistent cross-platform. Can't have 
it both ways!

----------

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

From report at bugs.python.org  Fri Jun  5 16:03:27 2009
From: report at bugs.python.org (James)
Date: Fri, 05 Jun 2009 14:03:27 +0000
Subject: [issue6205] sdist doesn't include data_files
In-Reply-To: <1244210606.6.0.749223227815.issue6205@psf.upfronthosting.co.za>
Message-ID: <1244210606.6.0.749223227815.issue6205@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

Hi, I have shown the output from my terminal below, since it will be
easier to follow for explaining the bug.

james at computer:~/testsetup$ ls
helloworld2.py  image1.jpg  setup.py
james at computer:~/testsetup$ cat setup.py 
#!/usr/bin/python
import distutils.core	#from distutils.core import setup, Extension
import os

# build a list of modules required for setup function below
py_modules = []

py_modules.append('helloworld2')

distutils.core.setup(
	name='helloworld2',
	description='distutils test',
	version='0.1',
	author='James',
	author_email='purpleidea at gmail.com',
	py_modules=py_modules,
	# data_files: install directory, 
	data_files=[('share/helloworld2', ['image1.jpg'])]
)

james at computer:~/testsetup$ ./setup.py sdist
running sdist
warning: sdist: manifest template 'MANIFEST.in' does not exist (using
default file list)
warning: sdist: standard file not found: should have one of README,
README.txt
writing manifest file 'MANIFEST'
creating helloworld2-0.1
making hard links in helloworld2-0.1...
hard linking helloworld2.py -> helloworld2-0.1
hard linking setup.py -> helloworld2-0.1
creating dist
tar -cf dist/helloworld2-0.1.tar helloworld2-0.1
gzip -f9 dist/helloworld2-0.1.tar
removing 'helloworld2-0.1' (and everything under it)
james at computer:~/testsetup$ 

as you will notice, the image1.jpg file does not get included in the
source distribution, and if i want to backup the entire dir/code of
everything to send to someone else.
perhaps this is a peculiarity of distutils. i realize i could write my
own manifest.in but then i have to specify *everything* and this isn't
automatic anymore.
this is definitely an issue since a user who downloads the sdist file
and runs an install will see:

error: can't copy 'image1.jpg': doesn't exist or not a regular file

this occurs because it obviously didn't get included in the sdist. the
same thing happens when sdist is run with --no-prune

i thought that perhaps i was using the wrong target so i tried a bdist
(tar.gz). in this case the image1.jpg file gets included, however
unpacking the directory doesn't give me a structure similar to the one
my code is originally maintained in.
so how do i use distutils to share *everything*, (eg: everything
specified in the setup.py directory) with my friends on the tubes?

if you want, i'll write a patch.

_J

----------
assignee: tarek
components: Distutils
messages: 88945
nosy: purpleidea, tarek
severity: normal
status: open
title: sdist doesn't include data_files
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun  5 16:08:52 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 05 Jun 2009 14:08:52 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A28FC26.1030806@egenix.com>
Message-ID: <ca471dc20906050708x5110030fk2b8f15d07d63e5d0@mail.gmail.com>


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

On Fri, Jun 5, 2009 at 4:06 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Antoine Pitrou wrote:
>> Antoine Pitrou <pitrou at free.fr> added the comment:
>>
>> Raymond suggested the patch be committed in 3.1, so as to minimize
>> disruption between 3.1 and 3.2. Benjamin, what do you think?
>
> Has Guido pronounced on this already ?

I don't want it added to 3.1 unless we start the beta cycle afresh.
It's too subtle for submitting after rc1. Talk to Benjamin if you
disagree.

I think it's fine to wait for 3.2. Maybe add something to the docs
about not subclassing unicode in C.

----------

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

From report at bugs.python.org  Fri Jun  5 16:15:30 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Jun 2009 14:15:30 +0000
Subject: [issue6199] test_unittest fails on Windows
In-Reply-To: <1244181487.09.0.399837041232.issue6199@psf.upfronthosting.co.za>
Message-ID: <1244211330.73.0.0441945734252.issue6199@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Thanks - I should have tested on Windows first. Tests now pass on
Windows and Mac OS X. Committed revision 73247.

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

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

From report at bugs.python.org  Fri Jun  5 16:59:10 2009
From: report at bugs.python.org (Wolfgang Schnerring)
Date: Fri, 05 Jun 2009 14:59:10 +0000
Subject: [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1244213950.12.0.955214842992.issue5727@psf.upfronthosting.co.za>


Wolfgang Schnerring <wosc+python at wosc.de> added the comment:

I've tracked down the reason by diffing pdb.py and cmd.py between 2.4
and 2.5:
It turns out that pdb.Pdb in 2.5 changes the way it handles input
depending on whether an explicit output was provided, more precisely, it
disables readline in that case. I don't understand what's going on here,
but there is a simple, non-intrusive fix on the doctest side, see the
attached patch.

Unfortunately, I can't imagine how to write a test to check this behaviour.

----------
keywords: +patch
Added file: http://bugs.python.org/file14193/doctest-readline.patch

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

From report at bugs.python.org  Fri Jun  5 17:26:13 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Fri, 05 Jun 2009 15:26:13 +0000
Subject: [issue6206] Correct a trivial typo introduced by r73238.
In-Reply-To: <1244215573.84.0.259638619581.issue6206@psf.upfronthosting.co.za>
Message-ID: <1244215573.84.0.259638619581.issue6206@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached is a patch which should fix the 'too many values to unpack'
error introduced by commit r73238.

----------
components: Tests
files: test__locale_typo_jun_5_2009.patch
keywords: patch
messages: 88949
nosy: vshenoy
severity: normal
status: open
title: Correct a trivial typo introduced by r73238.
versions: Python 2.7
Added file: http://bugs.python.org/file14194/test__locale_typo_jun_5_2009.patch

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

From report at bugs.python.org  Fri Jun  5 17:54:36 2009
From: report at bugs.python.org (Gabriel Koritzky)
Date: Fri, 05 Jun 2009 15:54:36 +0000
Subject: [issue6207] Simple For-Loops
In-Reply-To: <1244217276.14.0.120438841588.issue6207@psf.upfronthosting.co.za>
Message-ID: <1244217276.14.0.120438841588.issue6207@psf.upfronthosting.co.za>


New submission from Gabriel Koritzky <naoehomeuemail at gmail.com>:

I don't know if something like this has been said before, so if it did
just ignore this.

I have noticed that very few programming languages use simple for loops.
Python itself doesn't have a really simple one. So here's my suggestion:

for ( value ):
# Repeats the code that follows 'value' times if value is an integer. If
it's a string or a list, repeats the code once per character or instance
on 'value'.

for ( iniINC , finalEXC ):
# Repeats the code that follows 'finalEXC - iniINC' times if they're
integers.

for ( variable , iniINC , finalEXC ):
# Assigns iniINC to variable and raises it by one until it reaches
finalEXC (not executing when it does).

#example1
for 70:
	doNothing()

#example2
a = 10
for a:
	doNothing()

#example3
a = 5
for ( a , 10 ):
	doNothing()

#example4
i = 0
for ( i , 10 , 20 ):
	doNothing()

----------
messages: 88950
nosy: gabrielkfl
severity: normal
status: open
title: Simple For-Loops

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

From report at bugs.python.org  Fri Jun  5 17:55:19 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 05 Jun 2009 15:55:19 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <ca471dc20906050708x5110030fk2b8f15d07d63e5d0@mail.gmail.com>
Message-ID: <4A293FE4.6080605@egenix.com>


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

Guido van Rossum wrote:
> I think it's fine to wait for 3.2. Maybe add something to the docs
> about not subclassing unicode in C.

We should have a wider discussion about this on python-dev.

I'll publish the unicoderef extension and then we can see
whether users want this or not.

Antoine's patch makes such extensions impossible (provided you
don't want to copy over the complete unicodeobject.c
implementation in order to change the memory allocation
scheme).

Note that in Python 2.x you don't have such issues because
there, most tools for text processing will happily work on
any sort of buffer, so you don't need a string sub-type
in order to implement e.g. references into another string
(the buffer type will allow you to do this easily).

----------

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

From report at bugs.python.org  Fri Jun  5 18:15:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 16:15:54 +0000
Subject: [issue6207] Simple For-Loops
In-Reply-To: <1244217276.14.0.120438841588.issue6207@psf.upfronthosting.co.za>
Message-ID: <1244218554.75.0.628982498465.issue6207@psf.upfronthosting.co.za>


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

This is not a place for such discussion. Please post on comp.lang.python.

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

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

From report at bugs.python.org  Fri Jun  5 18:17:27 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 16:17:27 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4A293FE4.6080605@egenix.com>
Message-ID: <1244218783.5306.12.camel@localhost>


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

> Note that in Python 2.x you don't have such issues because
> there, most tools for text processing will happily work on
> any sort of buffer, so you don't need a string sub-type
> in order to implement e.g. references into another string
> (the buffer type will allow you to do this easily).

The new buffer API has a provision for type flags, although none of them
had a chance to be implemented by the original author before he ran
away...
There could be a type flag for unicode characters and then its support
could be implemented in the memoryview object.

----------

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

From report at bugs.python.org  Fri Jun  5 19:29:35 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Jun 2009 17:29:35 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1244222975.47.0.655582517146.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've now completed all of the aforementioned tasks.

1) Kernel32 does not need to be freed.  It is not freed by other calls
after which this additional code was modeled.  Additionally, the MSDN
indicates that it should only be freed by the module that loaded the
handle (which is not this one).

2) Functions that could be made inline have been made inline.

3) The todo, detection of whether a symlink target is a directory, has
been implemented.

4) A unit test with three tests has been added.  This test has not been
integrated into the larger test suite, but must be run explicitly (for
now).  The unit test passes with no failures on Windows Vista as written.

Some issues still remain.

A) In general, there is a implementation mismatch between Posix and
Windows symlinks.  In particular, Windows maintains that a symlink is
either for a directory or for a file, regardless of the existence of the
target.  Posix instead treats all symlinks like (special) files but
determines the directory status based on the target.  This mismatch
causes more specific problems.

B) Existing unit tests in test_os.py are going to fail (and maybe
others).  In particular, they will fail because they attempt to remove
symlinks to directories using os.remove.  Windows expects the use of
os.rmdir for directory-like symlinks (that is, symlinks who's original
destination was a directory or who's target_is_directory was set to true
at the time it was created).  The unit test included with the patch
illustrates some of these nuances.

C) Because lstat hides the directory status of a symlink (i.e. clears
S_IFLNK), it is not always possible to determine whether a symlink
should be removed using os.remove or os.rmdir.  Specifically, if the
symlink has no target or a directory symlink references a file, the user
will only know to call os.rmdir when os.remove fails with a WindowsError.

I see these issues break down into two categories:

I) How to remove a symlink?
  (a) Should os.remove be rewritten to handle directory symlinks on
Windows?  This method would provide the best compatibility with existing
code.
  (b) Or, do we require python authors to manually determine which
method to call to remove a symlink?  This approach is less intrusive,
but really doesn't provide an effective solution, as it's only partly
compatible with Posix implementations.

II) How to detect a directory symlink?  In either case of (I), there
needs to be an implementation to detect directoryness of a symlink.
  (a) Create a new function in posixmodule that exposes the directory
bit of a symlink, perhaps "is_symlink_directory", which always returns
false except on Windows.
  (b) Change win_lstat to leave the S_IFDIR bit in tact and modify
S_ISLNK to ignore that bit.  Then is_symlink_directory becomes
S_ISDIR(lstat_mode) and S_ISLNK(lstat_mode).

Alternately, maybe trying to fit the Windows APIs into Posix
compatibility is the wrong approach.  Maybe instead there should be a
Python abstraction layer for symlink handling.  I think we're close with
the existing approach, but I'm somewhat worried that we will continue to
find edge cases that break because of the differences in assumptions
about the two implementations.

I think this is getting very close.  I appreciate all the help and support.

----------
Added file: http://bugs.python.org/file14195/windows symlink draft 5.patch

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

From report at bugs.python.org  Fri Jun  5 19:43:48 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 05 Jun 2009 17:43:48 +0000
Subject: [issue798520] os.popen with invalid mode differs on Windows and POSIX
Message-ID: <1244223828.37.0.608459394696.issue798520@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I can confirm this but, but os.popen() is deprecated in 2.6 hence there
is no point in fixing generated exception even though in a language that
claims to be cross-platform exceptions should be unified.

I would add os.popen to keywords list for future reference and close
this bug as "won't fix". There are many other bugs about os.popen on
windows platform and people would be interested to know exactly why
subprocess should be used.

----------
nosy: +techtonik

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

From report at bugs.python.org  Fri Jun  5 19:45:08 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 05 Jun 2009 17:45:08 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244223908.4.0.571807697802.issue6196@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

[Lars] (...) We talk about a very small number of cases here and the
generator_tools-0.3.5.tar.gz is really broken beyond repair. It is the
only thing that should be fixed here IMO ;-)

Sure, that is what the pyopenssl folks did - fix their tarball. However,
it is reasonable expect certain tarballs to be 'broken beyond repair'
when you are running tarfile.extracall over a huge number of tarballs
such as the ones in PyPI.

Indeed, the tarfile module already has several fixes for such 'broken'
cases, Viz:

[quote]'If ignore_zeros is False, treat an empty block as the end of the
archive. If it is True, skip empty (and invalid) blocks and try to get
as many members as possible. This is only useful for reading
concatenated or **damaged** archives.'[endquote] [emphasis added]

[quote]'(...)Directory information like owner, modification time and
permissions are set after all members have been extracted. This is done
to work around two problems: A directory?s modification time is reset
each time a file is created in it. And, if a directory?s **permissions
do not allow writing**, extracting files to it will fail'[endquote]
[emphasis added]

[Lars] I agree with David here. It is easy to manipulate the tarfile in
advance, as you have shown yourself. The performance argument does not
convince me either.

Ok. Can you comment on this argument?

[quote]'(...)the very reason to write a program to extract tarball
(instead of doing it manually) is to automate it .. which automation is
*more effective and simple* if ``extractall`` had a flag such as
readaccess=True'[endquote] (emphasis added)

[quote]'I just think it is not simple (as in, keeping the code off from
such hacks that are tangential to the problem being solved) and
effective (as in, not having to deal with potential unintended side
effects like bugs in the post-fix chmoding or in the pre-fix tarinfo
mode modifications).'[endquote]

----------

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

From report at bugs.python.org  Fri Jun  5 19:53:14 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Jun 2009 17:53:14 +0000
Subject: [issue6202] Obsolete default file encoding "mac-roman" on OS X,
	not influenced by locale env variables
In-Reply-To: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>
Message-ID: <1244224394.36.0.144475776356.issue6202@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here's a patch. (for the trunk as it is also afflicted) It simply
removes the specific mac cases and uses posix detection.

----------
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file14196/fix_mac_encoding.patch

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

From report at bugs.python.org  Fri Jun  5 20:21:50 2009
From: report at bugs.python.org (ThurnerRupert)
Date: Fri, 05 Jun 2009 18:21:50 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>


New submission from ThurnerRupert <rupert.thurner at credit-suisse.com>:

when installing python for windows and running it from a msys or cygwin
shell, python does not notice that the path separator is backslash "/"
instead of forward slash "\".

can this be configured somehow, so the outputs are done like the current
shell accepts it? like checking in
http://docs.python.org/library/os.path.html what the parent process accepts?

----------
messages: 88958
nosy: ThurnerRupert
severity: normal
status: open
title: path separator output ignores shell's path separator: / instead of \
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Jun  5 20:22:19 2009
From: report at bugs.python.org (ThurnerRupert)
Date: Fri, 05 Jun 2009 18:22:19 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244226139.18.0.3379665206.issue6208@psf.upfronthosting.co.za>


Changes by ThurnerRupert <rupert.thurner at credit-suisse.com>:


----------
components: +IO, Windows

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

From report at bugs.python.org  Fri Jun  5 20:25:00 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 05 Jun 2009 18:25:00 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244226300.74.0.939637487364.issue6136@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

OK, I hadn't seen the "delay" parameter until now. I guess this is new
in Python 2.6? Good that there is already a way to avoid lots of empty
files, though it'll be a while before I can assume Python 2.6
unfortunately... that probably renders point (a) moot.

As for (b), do you not think a large number of users will not bother
with the hierarchical aspect of the logging framework? I'd say you need
to be pretty advanced/large scale before that becomes interesting.

I don't really understand why accepting such a patch would be a problem,
as it's a simple change that wouldn't break backwards compatibility.
It's surely got to be better than exiting with a python stack, which is
what happens today.

(To give an idea of the bloat-factor, since migrating to the logging
framework a typical configuration file for my system is now roughly 3
times the size it used to be for the same functionality)

----------
status: pending -> open

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

From report at bugs.python.org  Fri Jun  5 20:29:42 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Fri, 05 Jun 2009 18:29:42 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1244226582.51.0.752358342855.issue4953@psf.upfronthosting.co.za>


Timothy Farrell <tfarrell at swgen.com> added the comment:

I'm working on a web framework for Python 3.  Naturally this is a
blocker for me.  I was kinda expecting this to be addressed in 3.1 but
now that rc1 is out and I don't see anything about it, I'm wondering
about the status of this bug.  Can we get a status update?

----------
versions: +Python 3.2

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

From report at bugs.python.org  Fri Jun  5 20:37:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Jun 2009 18:37:10 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244227030.63.0.374817192401.issue6208@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure I understand the quesiton.  The cygwin path separator is
forward slash, isn't it?  Beyond that, I'm not clear on what behavior
you think is incorrect.  What "outputs"?

----------
components: +Installation -IO
nosy: +r.david.murray
priority:  -> normal
type:  -> behavior

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

From report at bugs.python.org  Fri Jun  5 20:46:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Jun 2009 18:46:20 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1244227580.98.0.986458134062.issue4953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Can you provide a test case that clearly demonstrates the problem
(preferably a unit test, but anything easily reproducible will do)?  I'm
not sure what to do with the code attached to the case.

----------
nosy: +r.david.murray
priority:  -> high
stage:  -> test needed

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

From report at bugs.python.org  Fri Jun  5 21:01:33 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 05 Jun 2009 19:01:33 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244228493.93.0.292322999511.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

"As for (b), do you not think a large number of users will not bother
with the hierarchical aspect of the logging framework? I'd say you need
to be pretty advanced/large scale before that becomes interesting."

I disagree with this. The hierarchical set up is one of the key points
of the approach. Casual users may not use it, but there are a lot of
users who do - and not only on advanced or large-scale systems. Users wh
o don't need hierarchies don't have to use them, but the system has to
support those who find them useful. 

"I don't really understand why accepting such a patch would be a
problem, as it's a simple change that wouldn't break backwards
compatibility. It's surely got to be better than exiting with a python
stack, which is what happens today."

Any software might result in an exception if you don't interface to it
in the expected and documented way. And, in my previous comment, I
merely set some conditions which a patch would have to meet. Also, as it
is definitely the case that many users use the hierarchical feature,
even if you don't, I expect that the qualname setting will stay.

"(To give an idea of the bloat-factor, since migrating to the logging
framework a typical configuration file for my system is now roughly 3
times the size it used to be for the same functionality)"

How big is that in KB? Disk space is pretty cheap these days. If it is a
big problem for you, you can always try using your existing
configuration format, reading it yourself and using the programmatic API
to configure logging yourself. It should be a small bit of up-front work
which can then be used on all your future projects.

----------
status: open -> pending

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

From report at bugs.python.org  Fri Jun  5 21:01:44 2009
From: report at bugs.python.org (dpodbori)
Date: Fri, 05 Jun 2009 19:01:44 +0000
Subject: [issue6209] compilation error in std. lib. module shutil (Python
	3.1rc1, platform Win32)
In-Reply-To: <1244228504.73.0.885392136191.issue6209@psf.upfronthosting.co.za>
Message-ID: <1244228504.73.0.885392136191.issue6209@psf.upfronthosting.co.za>


New submission from dpodbori <dpodbori at gmail.com>:

In Python 3.1rc1 (observed under Win32) standard library function 
shutil.copyfile(src, dst) has an unreferenced local variable "st" that 
causes the following exception in the calling code:

D:\> c:\Python31\python.exe copyDrivers.py
Traceback (most recent call last):
  File "copyDrivers.py", line 20, in <module>
    shutil.copy( file1, file2)
  File "c:\Python31\lib\shutil.py", line 101, in copy
    copyfile(src, dst)
  File "c:\Python31\lib\shutil.py", line 62, in copyfile
    if stat.S_ISFIFO(st.st_mode):
UnboundLocalError: local variable 'st' referenced before assignment

----------
components: Library (Lib)
messages: 88964
nosy: dpodbori
severity: normal
status: open
title: compilation error in std. lib. module shutil (Python 3.1rc1, platform Win32)
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  5 21:04:25 2009
From: report at bugs.python.org (Patrick W.)
Date: Fri, 05 Jun 2009 19:04:25 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>


New submission from Patrick W. <poke at BornToLaugh.de>:

I'm currently writing a library that executes predefined http requests
to a specified server. In case there is for example a HTTP Error, I want
to raise a user-defined exception that contains additional information
about when the error actually occured (so that the user of that library
gets information what happened without having to look at the actual
library code).
The in Python 3 introduced "feature" of chained exceptions (PEP 3134) is
something which is a bit annoying in that particular situation. While it
is probably good in a lot situation to know where an exception comes
from (especially when they are chained), it makes reading the actual
exception for the library user harder.
Let me show you an example:

def doXY ():
  # ...
  try:
    page = urlopen( someRequest )
  except urllib.error.URLError as e:
    raise MyError( 'while doing XY', e )
  # ...

MyError is an exception class, that uses the second parameter to get
additional information (for HTTPErrors the status code for example) and
compiles a detailed error message.
Before Python 3, this was a good way to prevent users from having to dig
into the code when they encounter an exception. Now however, you get
some error message like this:

-----
Traceback (most recent call last):
  File "..", line ., in doXY
    page = urlopen( someRequest )
  File "..\lib\urllib\request.py", line 122,
in urlopen
    return _opener.open(url, data, timeout)
  File "..\lib\urllib\request.py", line 364,
in open
    response = meth(req, response)
  File "..\lib\urllib\request.py", line 476,
in http_response
    'http', request, response, code, msg, hdrs)
  File "..\lib\urllib\request.py", line 402,
in error
    return self._call_chain(*args)
  File "..\lib\urllib\request.py", line 336,
in _call_chain
    result = func(*args)
  File "..\lib\urllib\request.py", line 484,
in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 401: Unauthorized

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "..", line ., in <module>
    doXY()
  File "..", line ., in doXY
    raise MyError( 'while doing XY', e )
MyError: 'HTTP Error 401 while doing XY (Unauthorized)'
-----

While the error message of MyError would be completely sufficient for
the user to know (and to fix by simply giving correct data) he is
flooded with a lot of information about the previously raised exception
instead with far too many unneccessary information.

So what I basically would like to have is some mechanism to prevent
Python from printing out all previous exception. As there is already the
'raise NewException from PreviousException' syntax, something like
'raise NewException from None' would be great, with explicitely stating
None to clear the buffer of previous exceptions.


Thanks you for any comments on this issue.
Patrick W.

----------
components: Interpreter Core
messages: 88965
nosy: poke
severity: normal
status: open
title: Exception Chaining missing method for suppressing context
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Fri Jun  5 21:09:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Jun 2009 19:09:42 +0000
Subject: [issue6209] compilation error in std. lib. module shutil (Python
	3.1rc1, platform Win32)
In-Reply-To: <1244228504.73.0.885392136191.issue6209@psf.upfronthosting.co.za>
Message-ID: <1244228982.56.0.876925591489.issue6209@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73250.

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

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

From report at bugs.python.org  Fri Jun  5 21:14:18 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Jun 2009 19:14:18 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1244229258.03.0.84053922295.issue6210@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Fri Jun  5 21:18:30 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 05 Jun 2009 19:18:30 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244229510.0.0.317407817625.issue6196@psf.upfronthosting.co.za>


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

Sure, tarfile contains numerous work-arounds for quirky and buggy
archives. Otherwise, it would not be usable in real-life.

But we should not mix up different issues here. tarfile reads and
extracts your generator_tools.tar just fine. Formally, the data is okay.
It's the stored information that is useless and that you are not happy
with. But as we both agree it is rather simple to fix this information
in advance:

import tarfile
tar = tarfile.open("generator_tools-0.3.5.tar.gz")
for t in tar:
    if t.isdir():
        t.mode = 0755
    else:
        t.mode = 0644
tar.extractall()
tar.close()

Sure, there is some functionality in extractall() that addresses issues
with inappropriate permissions, but without this functionality the
archive would not even *extract* cleanly. That is very different from
your problem.

In my opinion, the code above illustrates quite well, that tarfile was
designed to be high-level and flexible at the same time. Make use of
that. I honestly think that extractall() can do well without a
readaccess argument.

----------

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

From report at bugs.python.org  Fri Jun  5 21:40:12 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 05 Jun 2009 19:40:12 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244230812.39.0.673093999933.issue6136@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Who said anything about not supporting users who want the hierarchy? I'm
talking about making "qualname" ****optional****, not removing it
entirely! I even supplied the entirety of the code (all 4 lines of it)
to be clear what I meant a few comments ago.

The files have gone from about 5kb to about 15kb. Of course diskspace is
not a problem in itself, but these files need to be read and edited by
non-coders and they're a lot scarier (and harder to tweak) than the old
ones were. Basically they're full of abstract technical concepts
("qualname", "handler") and bits of python code to be eval'ed. 

Yes, I can write my own format. But I can't see anything about my case
which is unusual and I'm sure there must be a demand for something
simpler, which is why I bothered to report this issue at all. 

It's not particularly hard to find people out there raising this if you
google a bit. But I shall raise this on comp.lang.python as you suggest.

----------
status: pending -> open

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

From report at bugs.python.org  Fri Jun  5 21:46:07 2009
From: report at bugs.python.org (Michael Markert)
Date: Fri, 05 Jun 2009 19:46:07 +0000
Subject: [issue6211] [Tutorial] Section 4.7.2 has a wrong description of an
	example
In-Reply-To: <1244231167.47.0.192271891945.issue6211@psf.upfronthosting.co.za>
Message-ID: <1244231167.47.0.192271891945.issue6211@psf.upfronthosting.co.za>


New submission from Michael Markert <markert.michael at gmail.com>:

[Tutorial] Section 4.7.2 has a piece of example code which gives three
possibilities to call that function, but the description states that
there are only two possibilities.

Attached patch changes that and gives the third possibility of calling.

----------
assignee: georg.brandl
components: Documentation
files: controlflow.patch
keywords: patch
messages: 88969
nosy: cofi, georg.brandl
severity: normal
status: open
title: [Tutorial] Section 4.7.2 has a wrong description of an example
versions: Python 3.1
Added file: http://bugs.python.org/file14197/controlflow.patch

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

From report at bugs.python.org  Fri Jun  5 21:59:23 2009
From: report at bugs.python.org (Robert T McQuaid)
Date: Fri, 05 Jun 2009 19:59:23 +0000
Subject: [issue6212] piped input
In-Reply-To: <1244231963.89.0.682497283333.issue6212@psf.upfronthosting.co.za>
Message-ID: <1244231963.89.0.682497283333.issue6212@psf.upfronthosting.co.za>


New submission from Robert T McQuaid <rtmq at fixcas.com>:

#
#  Python 3.0.1 can read piped input when invoked with a
#  program name as the argument of the interpreter, but not
#  when invoked implicitly by the file extension.  On
#  Windows xp the first command below runs successfully, the
#  second ends with a diagnostic:  'NoneType' object has no
#  attribute 'isatty'
#
#
#  dir | e:\python30\python test17.py
#  dir | test17.py
#
#

import sys
if sys.stdin.isatty(): pass

----------
components: IO
messages: 88970
nosy: rtmq
severity: normal
status: open
title: piped input
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Jun  5 22:10:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Jun 2009 20:10:40 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244232640.16.0.947575155608.issue6198@psf.upfronthosting.co.za>


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

[Mark]
> Out of interest, what does '%#.0f' % 1.5 produce on
> Python 2.7/Windows?  I'd expect to get '2.' both for
> round-half-to-even and round-half-away-from-zero.
> Does Windows round this down to '1.' instead?

[Eric]
> Windows in trunk gives '2.'.

Thanks.  I was mainly wondering why you'd commented out the
line "%#.0f 1.5 -> 2." in the formatfloat_testcases.txt
file.

[Eric, about zero formatting on Windows]
> So this isn't a problem we caused with the short repr work, it's 
> pre-existing. I don't think it's worth working around, but that's me.

I agree it doesn't seem worth working around.  Let's wait until
somebody complains. :-)

----------

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

From report at bugs.python.org  Fri Jun  5 22:17:43 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 20:17:43 +0000
Subject: [issue6213] Incremental encoder incompatibility between 2.x and py3k
In-Reply-To: <1244233063.22.0.634170589597.issue6213@psf.upfronthosting.co.za>
Message-ID: <1244233063.22.0.634170589597.issue6213@psf.upfronthosting.co.za>


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

The behaviour of several incremental encoders is inconsistent between
2.x and py3k.

In 2.x:
>>> enc = codecs.getincrementalencoder('utf-16')()
>>> enc.getstate()
0
>>> enc.setstate(0)
>>> enc.encode(u'abc')
'\xff\xfea\x00b\x00c\x00'

In py3k:
>>> enc = codecs.getincrementalencoder('utf-16')()
>>> enc.getstate()
2
>>> enc.setstate(0)
>>> enc.encode('abc')
b'a\x00b\x00c\x00'

----------
messages: 88972
nosy: pitrou
priority: normal
severity: normal
status: open
title: Incremental encoder incompatibility between 2.x and py3k
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun  5 23:21:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 21:21:32 +0000
Subject: [issue6214] test__locale broken on trunk
In-Reply-To: <1244236892.05.0.964070660069.issue6214@psf.upfronthosting.co.za>
Message-ID: <1244236892.05.0.964070660069.issue6214@psf.upfronthosting.co.za>


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

======================================================================
ERROR: test_lc_numeric_localeconv (test.test__locale._LocaleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test__locale.py", line
88, in test_lc_numeric_localeconv
    "thousands_sep"):
ValueError: too many values to unpack

----------
assignee: ocean-city
components: Tests
messages: 88973
nosy: ocean-city, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test__locale broken on trunk
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  5 23:29:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 21:29:20 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>


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

The new IO lib has undergone deep changes in py3k which have never been
backported to trunk. This patch brings trunk up to date, including tests.

----------
components: IO
files: iobackport.patch
keywords: patch
messages: 88974
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Backport the IO lib to trunk
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14198/iobackport.patch

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

From report at bugs.python.org  Fri Jun  5 23:43:24 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 05 Jun 2009 21:43:24 +0000
Subject: [issue6212] piped input
In-Reply-To: <1244231963.89.0.682497283333.issue6212@psf.upfronthosting.co.za>
Message-ID: <1244238204.29.0.961990676383.issue6212@psf.upfronthosting.co.za>


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

This is a bug in Windows Python can do nothing about, see
http://support.microsoft.com/kb/321788.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sat Jun  6 00:08:09 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Jun 2009 22:08:09 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244239689.49.0.145359735814.issue6215@psf.upfronthosting.co.za>


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

Please note that test_io leaks references because of #2521. Otherwise
it's fine.

----------
nosy: +alexandre.vassalotti, amaury.forgeotdarc, benjamin.peterson

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

From report at bugs.python.org  Sat Jun  6 00:11:01 2009
From: report at bugs.python.org (Neil Muller)
Date: Fri, 05 Jun 2009 22:11:01 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1244239861.71.0.763360890504.issue2768@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Updated combined patch for python trunk added (indentation issues
hopefully also fixed).

----------
Added file: http://bugs.python.org/file14199/posixmodule_comb.patch

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

From python at rcn.com  Mon Jun  1 19:24:46 2009
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 1 Jun 2009 10:24:46 -0700
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
References: <4A240B3E.5070408@v.loewis.de>
Message-ID: <EBFE02F9FB62454587A0AA1EDB176744@RaymondLaptop1>


>> My hope is that now that a library has been selected, it can be improved 
>> before Python 2.7 and 3.1 ship.
> 
> That is fairly unlikely. The 3.1 release candidate has been produced,
> so the only options possible at this point are to either go ahead with
> what is in the code, or withdraw the library from 3.1 if it can be
> demonstrated to have severe flaws.

I concur with Martin here.  The only choices are to
keep it as-is or cleanly rip it out of the release.


Raymond


From rdmurray at bitdance.com  Mon Jun  1 23:01:46 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 1 Jun 2009 17:01:46 -0400 (EDT)
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <8657ee3f0906011333p28c10403p803ba5dcda563442@mail.gmail.com>
References: <8657ee3f0906011333p28c10403p803ba5dcda563442@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0906011642160.32513@kimball.webabinitio.net>

> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True

As a network engineer I don't see any inherent problem with that equality.
In fact I make use of that conceptual equality on a regular basis.

Further, if you were to add a specifically 'address-without-netmask'
type, the above equality would still be true, because then the above
would be comparing two addresses-with-netmasks and you would want to
apply the hostmask to a bare address for convenience.  To get inequality,
you'd be comparing two different object types...which comparison would
be False by default.

From mal at egenix.com  Wed Jun  3 00:25:50 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 03 Jun 2009 00:25:50 +0200
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1243963193.5426.42.camel@localhost>
References: <1243963193.5426.42.camel@localhost>
Message-ID: <4A25A6EE.9020505@egenix.com>

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> You cannot simply recompile your code and have it working.
> 
> Who is "you"?
> People doing mundane things with PyUnicodeObjects certainly can,
> assuming they use the macros for any member access.

As soon as they want to do C-level sub-typing, a change from
PyObject to PyVarObject will break their code in non-trivial ways.

>> Please note that all type objects documented in the header files
>> not explicitly declared for private use only, are in fact
>> public APIs.
> 
> If the datatype layout is not publicly documented in the API reference,
> it certainly seems to be a non-public part of the API. That's why we
> have macros for member access, instead of letting people access members
> directly.

Header files *are* the API reference.

There are many instances where they include things that are only
meant to be used internally by the interpreter, but these are
carefully documented in the header files.

>> You need access to those type objects in order to
>> be able to subclass them.
> 
> As is needed for every other core object whose layout is nevertheless
> changed now and then... I think it should be expected that any code
> relying on low-level implementation specifics can break now and then.
> Changing low-level implementation specifics is often a prerequisite for
> improving things and it would be foolish to make a promise that we
> guarantee 100% compatibility at that level.

It would be foolish to break such compatibility for the sake of some
really minor performance win.

Python's main focus is flexibility, not speed. Your proposed change
makes it a lot harder to tap into the available flexibility, since
sub-typing of PyVarObjects is non-trivial.

> (we could of course strengthen the rules for unicode if it was
> demonstrated that there are several popular instances of subclassing
> unicode in a C extension. However, I haven't seen any such examples)

Well, since you don't appear to count the many attempts to get
slicing-by-reference into the base type as proof that such ideas
do have use-cases, I've posted an example implementation which
provides such a sub-type.

It's easy to extend to all the use cases I've mentioned so far.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 03 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2009-06-29: EuroPython 2009, Birmingham, UK                25 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From report at bugs.python.org  Sat Jun  6 00:22:43 2009
From: report at bugs.python.org (venkat manian)
Date: Fri, 05 Jun 2009 22:22:43 +0000
Subject: [issue1633605] logging module / wrong bytecode?
Message-ID: <1244240563.64.0.292004275516.issue1633605@psf.upfronthosting.co.za>


Changes by venkat manian <venkatasubramanian at gmail.com>:


----------
nosy: +annacoder

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

From report at bugs.python.org  Sat Jun  6 00:22:58 2009
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Jun 2009 22:22:58 +0000
Subject: [issue6202] Obsolete default file encoding "mac-roman" on OS X,
	not influenced by locale env variables
In-Reply-To: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>
Message-ID: <1244240578.47.0.642357933892.issue6202@psf.upfronthosting.co.za>


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

A very quick test of the patch on trunk for 10.4 and 10.5 looks good, 
though it should be re-tested once the unrelated current breakage of 
test__locale is fixed.

----------

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

From report at bugs.python.org  Sat Jun  6 00:30:49 2009
From: report at bugs.python.org (Neil Muller)
Date: Fri, 05 Jun 2009 22:30:49 +0000
Subject: [issue2768] os.fstat and other os.f* methods should use
	PyObject_AsFileDescriptor
In-Reply-To: <1209986866.69.0.462896858511.issue2768@psf.upfronthosting.co.za>
Message-ID: <1244241049.69.0.256187184755.issue2768@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Similar patch for the python 3 branch.

----------
Added file: http://bugs.python.org/file14200/posixmodule_comb_py3k.patch

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

From report at bugs.python.org  Sat Jun  6 00:44:51 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Jun 2009 22:44:51 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244241891.27.0.211852677886.issue6198@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

> [Mark]
>> Out of interest, what does '%#.0f' % 1.5 produce on
>> Python 2.7/Windows?  I'd expect to get '2.' both for
>> round-half-to-even and round-half-away-from-zero.
>> Does Windows round this down to '1.' instead?
> 
> [Eric]
>> Windows in trunk gives '2.'.
> 
[Mark]
> Thanks.  I was mainly wondering why you'd commented out the
> line "%#.0f 1.5 -> 2." in the formatfloat_testcases.txt
> file.

Over-zealous commenting out on my part. I'm away from my Windows box,
but I'll correct this next week and check it back in with that line
re-enabled.

Thanks for catching that.

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

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

From report at bugs.python.org  Sat Jun  6 02:04:14 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Jun 2009 00:04:14 +0000
Subject: [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
In-Reply-To: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>
Message-ID: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

>From msg88801
'''
for 3.1: raising the KEEPALIVE_SIZE_LIMIT to 32 as explained and
motivated here:

msg64215

That's a simple non-disruptive change which makes a lot of sense
due to the advances in CPU designs in the last 9 years. I determined
the original value of 9 using benchmarks and similar statistics in
1999/2000.

It's probably also a good time to remove the warning, now that the
implementation has proven itself for so many years...

/* Limit for the Unicode object free list stay alive optimization.

   The implementation will keep allocated Unicode memory intact for
   all objects on the free list having a size less than this
   limit. This reduces malloc() overhead for small Unicode objects.

   At worst this will result in PyUnicode_MAXFREELIST *
   (sizeof(PyUnicodeObject) + KEEPALIVE_SIZE_LIMIT +
   malloc()-overhead) bytes of unused garbage.

   Setting the limit to 0 effectively turns the feature off.

   Note: This is an experimental feature ! If you get core dumps when
   using Unicode objects, turn this feature off.

*/

#define KEEPALIVE_SIZE_LIMIT       9
'''
If this is as non-controversial as it seems, perhaps someone could
change 9 to 32 and remove "Note: This is an experimental feature..." in
time for rc2.

----------
components: Interpreter Core
messages: 88981
nosy: tjreedy
severity: normal
status: open
title: Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun  6 02:11:49 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Jun 2009 00:11:49 +0000
Subject: [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
In-Reply-To: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>
Message-ID: <1244247109.74.0.75743876331.issue6216@psf.upfronthosting.co.za>


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

Marc-Andre Lemburg's message is from #1943

----------

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

From report at bugs.python.org  Sat Jun  6 02:16:19 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Jun 2009 00:16:19 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1244247379.59.0.825114141352.issue1943@psf.upfronthosting.co.za>


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

In the interest of possibly improving the imminent 3.1 release,
I opened #6216
Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?

I wonder if it is possible to make it generically easier to subclass
PyVarObjects (but my C knowledge to getting too faded to have any ideas).

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

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

From report at bugs.python.org  Sat Jun  6 02:17:41 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Jun 2009 00:17:41 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244247461.47.0.177611354106.issue6195@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The fix is not in fact correct.  Without the fix, source code is found
that is skipped with the fix in place.  This may mean that the fix for
issue4050 is also in error.

The object found by inspect.getfile when it isn't an a .so is of the form:

   <doctest test.test_doctest.test_DocTestRunner.basics[3]>

So I think we need some way to determine whether or not what is returned
by getfile is binary data or not.

----------
resolution: accepted -> 
stage: patch review -> needs patch

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

From report at bugs.python.org  Sat Jun  6 02:26:25 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 06 Jun 2009 00:26:25 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244247985.41.0.462439906786.issue6196@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

[Lars] Sure, there is some functionality in extractall() that addresses
issues with inappropriate permissions, but without this functionality the
archive would not even *extract* cleanly. That is very different from
your problem.

Fair enough.

'tis time to creating a pypi package out of my high-level wrapper:

  http://gist.github.com/124597

----------

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

From report at bugs.python.org  Sat Jun  6 03:57:20 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Sat, 06 Jun 2009 01:57:20 +0000
Subject: [issue6217] Add _io._TextIOWrapper.errors
In-Reply-To: <1244253440.08.0.0505415308962.issue6217@psf.upfronthosting.co.za>
Message-ID: <1244253440.08.0.0505415308962.issue6217@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

_pyio.TextIOWrapper provides the encoding and associated errors values, 
but _io._TextIOWrapper only provides encoding. Patch adds errors and has 
it show up in repr in both places, against py3k

----------
components: IO
files: textiowrapper-errors.diff
keywords: patch
messages: 88986
nosy: pitrou, pjenvey
severity: normal
status: open
title: Add _io._TextIOWrapper.errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14201/textiowrapper-errors.diff

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

From report at bugs.python.org  Sat Jun  6 04:21:15 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 06 Jun 2009 02:21:15 +0000
Subject: [issue6218] Make io.BytesIO and io.StringIO picklable.
In-Reply-To: <1244254875.51.0.0941712294298.issue6218@psf.upfronthosting.co.za>
Message-ID: <1244254875.51.0.0941712294298.issue6218@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

Here is a patch to add pickling support to io.BytesIO and io.StringIO.
Although they are non-trivial, the additions were made with a fair
amount of care (and love!) and thus I believe they could be included in
3.1. 

Furthermore, the improved test-suite uncovered a number of bugs in the
implementation of io.StringIO. So the patch also fixes:

  * fixes a memory-leak in stringio_dealloc; 
  * disallows bytes-like object from being used as the newline
    argument of StringIO;
  * and changes the exception raised by StringIO.__init__ to a
    TypeError when initial_value is not a str.

----------
components: IO, Library (Lib)
files: pickle_support_for_memoryio.diff
keywords: patch, patch
messages: 88987
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Make io.BytesIO and io.StringIO picklable.
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14202/pickle_support_for_memoryio.diff

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

From report at bugs.python.org  Sat Jun  6 07:05:35 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 06 Jun 2009 05:05:35 +0000
Subject: [issue6206] Correct a trivial typo introduced by r73238.
In-Reply-To: <1244215573.84.0.259638619581.issue6206@psf.upfronthosting.co.za>
Message-ID: <1244264735.87.0.709309491293.issue6206@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


----------
type:  -> compile error

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

From report at bugs.python.org  Sat Jun  6 07:54:46 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Jun 2009 05:54:46 +0000
Subject: [issue6206] Correct a trivial typo introduced by r73238.
In-Reply-To: <1244215573.84.0.259638619581.issue6206@psf.upfronthosting.co.za>
Message-ID: <1244267686.88.0.874943596944.issue6206@psf.upfronthosting.co.za>


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

Fixed in r73252.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Jun  6 09:04:03 2009
From: report at bugs.python.org (Pushkar Paranjpe)
Date: Sat, 06 Jun 2009 07:04:03 +0000
Subject: [issue6219] nested list value change
In-Reply-To: <1244271843.74.0.384598823496.issue6219@psf.upfronthosting.co.za>
Message-ID: <1244271843.74.0.384598823496.issue6219@psf.upfronthosting.co.za>


New submission from Pushkar Paranjpe <pushkarparanjpe at gmail.com>:

Is this a bug ?

>>> a = [[1,2],[3,4],[5,6]]
>>> a
[[1, 2], [3, 4], [5, 6]]
>>> b = a[0]
>>> b
[1, 2]
>>> b[0] = -8888
>>> b
[-8888, 2]
>>> a
[[-8888, 2], [3, 4], [5, 6]]
>>>

Created a new variable (b) which refers to an element in a list (a).
Changing the value of the new variable also reflects in the original
list. I thought the new variable is actually a new variable with its own
memory allocation and not a symbolic link to pre-existing data. is this
a bug?
Please help.

----------
components: Library (Lib)
messages: 88989
nosy: pushkarparanjpe
severity: normal
status: open
title: nested list value change
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Jun  6 09:09:27 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 06 Jun 2009 07:09:27 +0000
Subject: [issue6196] tarfile.extractall(readaccess=True)
In-Reply-To: <1244151952.15.0.48823803395.issue6196@psf.upfronthosting.co.za>
Message-ID: <1244272167.43.0.112130308286.issue6196@psf.upfronthosting.co.za>


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

I close this issue then.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jun  6 09:21:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Jun 2009 07:21:45 +0000
Subject: [issue6219] nested list value change
In-Reply-To: <1244271843.74.0.384598823496.issue6219@psf.upfronthosting.co.za>
Message-ID: <1244272905.15.0.176169014143.issue6219@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is correct behavior.
Try making a new *copy* of the sublist:

a = [[1,2],[3,4],[5,6]]
b = a[0][:]
b[0] = -8888

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

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

From report at bugs.python.org  Sat Jun  6 11:58:28 2009
From: report at bugs.python.org (cate)
Date: Sat, 06 Jun 2009 09:58:28 +0000
Subject: [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>


New submission from cate <cate at debian.org>:

http://docs.python.org/dev/howto/doanddont.html use twice in example the
"opne" function, which should be written as "open". From google it seems
that also 3.x is affected (but not really checked)

----------
assignee: georg.brandl
components: Documentation
messages: 88992
nosy: cate, georg.brandl
severity: normal
status: open
title: typo: opne in "doanddont"
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun  6 12:11:26 2009
From: report at bugs.python.org (John Szakmeister)
Date: Sat, 06 Jun 2009 10:11:26 +0000
Subject: [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244283086.72.0.860748928104.issue6220@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

Here's a patch for trunk.

----------
keywords: +patch
nosy: +jszakmeister
Added file: http://bugs.python.org/file14203/issue-6220-doanddont.patch

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

From report at bugs.python.org  Sat Jun  6 12:13:26 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 10:13:26 +0000
Subject: [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244283206.41.0.586583693106.issue6220@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That "typo" is intentional, it's also written in the comment:
try:
    foo = opne("file") # misspelled "open"
except:
    sys.exit("could not open file!")

This example shows how a bare except will catch the NameError caused by
'opne' and return the wrong error message, whereas "except IOError" will
only catch IOErrors and show the NameError.

----------
nosy: +ezio.melotti
resolution:  -> invalid

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

From report at bugs.python.org  Sat Jun  6 12:15:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 10:15:52 +0000
Subject: [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244283352.72.0.0370211204995.issue6220@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Sat Jun  6 12:16:54 2009
From: report at bugs.python.org (John Szakmeister)
Date: Sat, 06 Jun 2009 10:16:54 +0000
Subject: [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244283414.34.0.726646181307.issue6220@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

That'll teach me to pay more attention before submitting a patch. 
Thanks Ezio!

----------

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

From report at bugs.python.org  Sat Jun  6 13:02:39 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 06 Jun 2009 11:02:39 +0000
Subject: [issue6214] test__locale broken on trunk
In-Reply-To: <1244236892.05.0.964070660069.issue6214@psf.upfronthosting.co.za>
Message-ID: <1244286159.19.0.200138996565.issue6214@psf.upfronthosting.co.za>


Vikram U Shenoy <vikram.u.shenoy at gmail.com> added the comment:

Georg has fixed it in r73252.

----------
nosy: +vshenoy

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

From report at bugs.python.org  Sat Jun  6 13:06:17 2009
From: report at bugs.python.org (John Szakmeister)
Date: Sat, 06 Jun 2009 11:06:17 +0000
Subject: [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244286377.59.0.947621066103.issue6220@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

Actually, what's the second example trying to show:
try:
   foo = opne("file") # will be changed to "open" as soon as we run it
except IOError:
   sys.exit("could not open file")

I'm not sure what that comment really means?

----------

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

From report at bugs.python.org  Sat Jun  6 13:19:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jun 2009 11:19:19 +0000
Subject: [issue6218] Make io.BytesIO and io.StringIO picklable.
In-Reply-To: <1244254875.51.0.0941712294298.issue6218@psf.upfronthosting.co.za>
Message-ID: <1244287159.0.0.929439983587.issue6218@psf.upfronthosting.co.za>


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

I think it's too late for 3.1, since it's a new feature.

----------
nosy: +benjamin.peterson, pitrou
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Jun  6 13:22:40 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jun 2009 11:22:40 +0000
Subject: [issue1143] Update to latest ElementTree in Python 2.7
In-Reply-To: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za>
Message-ID: <1244287360.77.0.598586409848.issue1143@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Sat Jun  6 13:30:57 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 11:30:57 +0000
Subject: [issue6220] typo: opne in "doanddont"
In-Reply-To: <1244282308.76.0.113174634694.issue6220@psf.upfronthosting.co.za>
Message-ID: <1244287857.8.0.321108367604.issue6220@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If we use the bare "except:" the message "could not open file!" is shown
and we would waste time trying to figure out why it can't be opened.

Instead, if we use "except IOError:", the first time we run the program
the error "NameError: name 'opne' is not defined" is raised, telling us
what's wrong. Once we know it, we can change 'opne' to 'open' and solve
the problem.

Indeed it could be clearer.

----------
keywords:  -patch

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

From report at bugs.python.org  Sat Jun  6 15:10:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Jun 2009 13:10:20 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244293820.34.0.724788583893.issue6195@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It turns out that doctest patches linecache.getlines (which is not, by
the way, a public interface of linecache according to the docs and the
__all__ string) to retrieve the doctest source code.  The special
filename it uses to trigger this is not returned by getsourcefile but is
returned by getfile.

So the issue4050 fix is not impacted, but the fix for this bug is not so
straightforward.

----------

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

From report at bugs.python.org  Sat Jun  6 15:26:31 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jun 2009 13:26:31 +0000
Subject: [issue6221] Windows buildbot failure in test_winreg
In-Reply-To: <1244294791.11.0.0504716192427.issue6221@psf.upfronthosting.co.za>
Message-ID: <1244294791.11.0.0504716192427.issue6221@psf.upfronthosting.co.za>


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

I'm filing this as release blocker since it might indicate serious
breakage (I'm not a Windows expert).


======================================================================
FAIL: testLocalMachineRegistryWorks (test.test_winreg.WinregTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_winreg.py",
line 148, in testLocalMachineRegistryWorks
    self.TestAll(HKEY_CURRENT_USER)
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_winreg.py",
line 143, in TestAll
    self.WriteTestData(root_key, subkeystr)
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_winreg.py",
line 50, in WriteTestData
    "Not the correct number of values")
AssertionError: Not the correct number of values

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 89001
nosy: pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Windows buildbot failure in test_winreg
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun  6 15:30:30 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jun 2009 13:30:30 +0000
Subject: [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
In-Reply-To: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>
Message-ID: <1244295030.31.0.426801685851.issue6216@psf.upfronthosting.co.za>


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

I'm not sure it is "as non-controversial as it seems".
Someone should 1) do the math 2) show impact on a couple of benchmarks
of his choice

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

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

From report at bugs.python.org  Sat Jun  6 15:54:07 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Jun 2009 13:54:07 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244296447.64.0.804399218061.issue6195@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, here is a revised patch that passes all tests, including the new one.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file14204/issue6195.patch

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

From report at bugs.python.org  Sat Jun  6 16:22:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Jun 2009 14:22:14 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244298134.53.0.862489140767.issue6137@psf.upfronthosting.co.za>


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

I've added an entry in the what's new file in r73254.

----------
status: open -> closed

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

From report at bugs.python.org  Sat Jun  6 18:11:53 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Sat, 06 Jun 2009 16:11:53 +0000
Subject: [issue6222] 2to3 except fixer failed in certain case
In-Reply-To: <1244304713.46.0.332603077148.issue6222@psf.upfronthosting.co.za>
Message-ID: <1244304713.46.0.332603077148.issue6222@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

The 2to3 except fixer will be failed with this code:

try: raise TypeError
except TypeError, x:
    pass

with this code, 2to3 will produce an empty diff, i.e. it fixes nothing.

But when change it to the following, 2to3 works again:

try:
    raise TypeError
except TypeError, x:
    pass

with this, 2to3 will provide a correct diff.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 89005
nosy: bhy
severity: normal
status: open
title: 2to3 except fixer failed in certain case
versions: Python 2.6, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jun  6 18:24:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jun 2009 16:24:03 +0000
Subject: [issue6222] 2to3 except fixer failed in certain case
In-Reply-To: <1244304713.46.0.332603077148.issue6222@psf.upfronthosting.co.za>
Message-ID: <1244305443.71.0.619720007944.issue6222@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73255.

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

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

From report at bugs.python.org  Sat Jun  6 19:11:05 2009
From: report at bugs.python.org (Haoyu Bai)
Date: Sat, 06 Jun 2009 17:11:05 +0000
Subject: [issue6223] Make _PyUnicode_AsString as public API
In-Reply-To: <1244308265.08.0.506507735575.issue6223@psf.upfronthosting.co.za>
Message-ID: <1244308265.08.0.506507735575.issue6223@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

Why _PyUnicode_AsString and _PyUnicode_AsStringAndSize are not public
API? They are very useful when porting extension module to Python 3,
because they have the semantic as same as PyString_AsString. For
extension author, these API can be used for replacing PyString_AsString
without any other change in code logic.

So why not make these API public? Any consideration? If we can document
these API, then C extension author can know them and use them, without
spending a lot of time to dig them out from Python source code.

Thanks!

----------
assignee: georg.brandl
components: Documentation, Extension Modules, Interpreter Core, Unicode
messages: 89007
nosy: bhy, georg.brandl
severity: normal
status: open
title: Make _PyUnicode_AsString as public API
type: feature request
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jun  6 19:26:01 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jun 2009 17:26:01 +0000
Subject: [issue6223] Make _PyUnicode_AsString as public API
In-Reply-To: <1244308265.08.0.506507735575.issue6223@psf.upfronthosting.co.za>
Message-ID: <1244309161.1.0.400072537536.issue6223@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

They are not public because implicitly encoding unicode is bad practice
in Python 3. You should use PyUnicode_AsEncodedString() or such.

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

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

From report at bugs.python.org  Sat Jun  6 19:50:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Jun 2009 17:50:32 +0000
Subject: [issue6211] [Tutorial] Section 4.7.2 has a wrong description of an
	example
In-Reply-To: <1244231167.47.0.192271891945.issue6211@psf.upfronthosting.co.za>
Message-ID: <1244310632.0.0.705993543435.issue6211@psf.upfronthosting.co.za>


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

Fixed in r73257.

Please respect the limit of 80 chars per line in future patches :)

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

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

From report at bugs.python.org  Sat Jun  6 19:51:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Jun 2009 17:51:39 +0000
Subject: [issue6204] Missing reference in section 4.6 to chapter on classes
In-Reply-To: <1244203789.01.0.516038095674.issue6204@psf.upfronthosting.co.za>
Message-ID: <1244310699.38.0.798008312709.issue6204@psf.upfronthosting.co.za>


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

Thanks, applied in r73258!

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

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

From report at bugs.python.org  Sat Jun  6 20:02:33 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Jun 2009 18:02:33 +0000
Subject: [issue6217] Add _io._TextIOWrapper.errors
In-Reply-To: <1244253440.08.0.0505415308962.issue6217@psf.upfronthosting.co.za>
Message-ID: <1244311353.22.0.911208050181.issue6217@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the report! Fixed in r73259.

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

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

From report at bugs.python.org  Sat Jun  6 20:11:36 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Sat, 06 Jun 2009 18:11:36 +0000
Subject: [issue6224] References to JPython
In-Reply-To: <1244311896.45.0.961216428321.issue6224@psf.upfronthosting.co.za>
Message-ID: <1244311896.45.0.961216428321.issue6224@psf.upfronthosting.co.za>


New submission from Thijs Triemstra <lists at collab.nl>:

The documentation refers to JPython in several places, which is the old 
name, it's called Jython nowadays.

 - platform.java_ver
 - tkinter

----------
assignee: georg.brandl
components: Documentation
messages: 89012
nosy: georg.brandl, thijs
severity: normal
status: open
title: References to JPython
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Jun  6 20:11:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 18:11:52 +0000
Subject: [issue6214] test__locale broken on trunk
In-Reply-To: <1244236892.05.0.964070660069.issue6214@psf.upfronthosting.co.za>
Message-ID: <1244311912.59.0.274574024084.issue6214@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jun  6 20:22:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Jun 2009 18:22:08 +0000
Subject: [issue6224] References to JPython
In-Reply-To: <1244311896.45.0.961216428321.issue6224@psf.upfronthosting.co.za>
Message-ID: <1244312528.72.0.757089181029.issue6224@psf.upfronthosting.co.za>


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

Thanks, fixed in r73260.

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

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

From report at bugs.python.org  Sat Jun  6 21:46:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Jun 2009 19:46:04 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1244317564.7.0.159588388026.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've uploaded a new version of the patch and test suite.  I wanted a few
more test cases but didn't want to litter the test directory with little
test files, so I borrowed some techniques from test_import and created
the modules to import on the fly.

I haven't come up with a fix for your last test case (yet?).  I've
commented the test to indicate this.  I think to fix it we may need to
look into the traceback itself.

----------
Added file: http://bugs.python.org/file14205/issue5230.patch

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

From report at bugs.python.org  Sat Jun  6 21:54:06 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 19:54:06 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1244318046.87.0.735344603205.issue4966@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
type:  -> feature request

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

From report at bugs.python.org  Sat Jun  6 22:50:04 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 20:50:04 +0000
Subject: [issue3798] SystemExit incorrectly displays unicode message
In-Reply-To: <1220737862.32.0.22799945135.issue3798@psf.upfronthosting.co.za>
Message-ID: <1244321404.34.0.716631966819.issue3798@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I did some more experiments, here are the results:

Windows XP, from cmd.exe (cp850):
Py 2.x:
>>> raise SystemExit(u'aeiou') # unicode string, ascii chars, works fine
aeiou

>>> raise SystemExit(u'?????') # unicode string, non-ascii chars, no output


>>> raise SystemExit('?????') # byte strings, non-ascii chars, works fine
?????

Py 3.0:
>>> raise SystemExit('?????') # unicode string, non-ascii chars, wrong
output
??????????

The output here is utf-8 and cmd shows it as cp850.


Linux, UTF-8 terminal:
Py 2.x:
>>> raise SystemExit(u'?????') # unicode string, non-ascii chars, no output

There's no output even if the terminal uses utf-8.

Py 3.x:
>>> raise SystemExit('?????') # unicode string, non-ascii chars, works fine
?????


When a unicode string with non-ascii characters is passed:
* Py2 always fails (no output);
* Py3 works only when the terminal uses utf-8, otherwise it fails (the
chars are displayed using another encoding).

----------
components: +Unicode
nosy: +ezio.melotti
priority:  -> normal
type:  -> behavior
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Jun  6 23:00:41 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 21:00:41 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244322041.07.0.715166390269.issue6203@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Confirmed for 3.1, 3.0 still returns (None, None).

----------
components: +Library (Lib)
nosy: +ezio.melotti
priority:  -> normal

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

From report at bugs.python.org  Sat Jun  6 23:10:54 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Jun 2009 21:10:54 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1244322654.21.0.543959131215.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In the interest of expediency, I've implemented I.(a): specifically,
I've put a wrapper around DeleteFileW to check if the target is a
directory-symlink, and if it is, call RemoveDirectory instead.  I've
updated the test case to reflect this behavior.  Patch draft 6 includes
these changes.

Is there anything else that needs to be addressed before this can be merged?

----------
Added file: http://bugs.python.org/file14206/windows symlink draft 6.patch

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

From report at bugs.python.org  Sat Jun  6 23:20:01 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 21:20:01 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1244323201.24.0.2526622055.issue6191@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

BeautifulSoup use SGMLParser for all the versions <3.1. BeautifulSoup 
3.1 is supposed to be compatible with Python 3 and since SGMLParser is
gone it's now using HTMLParser, but it's not able to handle some things
anymore.

For more information:
http://www.crummy.com/software/BeautifulSoup/3.1-problems.html

(FWIW I tried BeautifulSoup 3.1 but it failed where BeautifulSoup 3.0.7
was working so I came back to 3.0.7)

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Jun  6 23:35:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Jun 2009 21:35:52 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1244324152.48.0.404848489107.issue670664@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 2.7, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Sat Jun  6 23:56:36 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 06 Jun 2009 21:56:36 +0000
Subject: [issue6225] Fixing several minor bugs in Tkinter.Canvas and one in
	Misc._configure
In-Reply-To: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za>
Message-ID: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Hi,

While testing Tkinter.Canvas I've found several minor bugs that I would
prefer to see fixed. Many of them change the current Canvas api a bit,
but for better. For example, the methods "focus", "gettags", "icursor",
"index", "insert", "move" (and some others) accept arbitrary amount of
arguments, but all these tcl subcommands have a fixed amount of
arguments they accept, so I consider it is better to make this clear on
Tkinter too.

I've also found a problem in Misc._configure which is also fixed by the
attached patch. The problem is that when cnf is a string, the call
"self.tk.split(self.tk.call(_flatten((self._w, cmd, '-'+cnf))))" may
still result in an empty string causing the following statement to fail
"return (x[0][1:],) + x[1:]".

One thing that left me curious was the comment "# XXX Should use
_flatten on args" in Canvas.coords. I've tried understanding why it
should use _flatten there, but couldn't figure it out. This is a very
old comment, so maybe it is no longer true ?

----------
components: Tkinter
files: Canvas_fixes.diff
keywords: patch
messages: 89019
nosy: gpolo
severity: normal
status: open
title: Fixing several minor bugs in Tkinter.Canvas and one in Misc._configure
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14207/Canvas_fixes.diff

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

From report at bugs.python.org  Sun Jun  7 00:02:08 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Sat, 06 Jun 2009 22:02:08 +0000
Subject: [issue6226] Inconsistent 'file' vs 'stream' kwarg in pprint,
	other stdlibs
In-Reply-To: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>
Message-ID: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

It'd be nice to eventually standardize on the kwarg name used for basic 
file-like args in the stdlib. print, warnings.showwarning and some 
others take a file= argument whereas pprint, getpass.getpass take 
stream=

print and pprint in particular should match -- though they do have a 
different option set, when you're using the same options this 
consistency would ease replacing:

print(obj, file=sys.stderr)
with
pprint(obj, stream=sys.stderr)

----------
components: Library (Lib)
messages: 89020
nosy: pjenvey
severity: normal
status: open
title: Inconsistent 'file' vs 'stream' kwarg in pprint, other stdlibs
type: feature request

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

From report at bugs.python.org  Sun Jun  7 00:35:20 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 06 Jun 2009 22:35:20 +0000
Subject: [issue798058] IDLE / PyOS_InputHook
Message-ID: <1244327720.97.0.932904967485.issue798058@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing as promised.

----------

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

From report at bugs.python.org  Sun Jun  7 01:10:31 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 06 Jun 2009 23:10:31 +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: <1244329831.07.0.616564756984.issue3573@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Idle has changed a bit since the initial message, so it no longer hangs
when it is configured to open an edit window by default, but now it
hangs when running it as: idle -e <somedirnamehere> (which the patch fixes).

----------

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

From report at bugs.python.org  Sun Jun  7 02:09:49 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Jun 2009 00:09:49 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244333389.57.0.0767847400098.issue6215@psf.upfronthosting.co.za>


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

New patch incorporating the latest py3k changes.

----------
Added file: http://bugs.python.org/file14208/iobackport2.patch

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

From report at bugs.python.org  Sun Jun  7 02:13:59 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 07 Jun 2009 00:13:59 +0000
Subject: [issue6221] Windows buildbot failure in test_winreg
In-Reply-To: <1244294791.11.0.0504716192427.issue6221@psf.upfronthosting.co.za>
Message-ID: <1244333639.54.0.917192424253.issue6221@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This doesn't happen on Win2k. Maybe does it depend on OS?

----------
nosy: +ocean-city

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

From report at bugs.python.org  Sun Jun  7 04:24:05 2009
From: report at bugs.python.org (Michael Newman)
Date: Sun, 07 Jun 2009 02:24:05 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1244341445.23.0.0191996024187.issue4309@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

Regarding Section "15.15.1.5. Calling functions, continued" on:
http://docs.python.org/3.0/library/ctypes.html

I would recommend changing the first example code block to the following:

>>> printf = libc.printf
>>> printf(b"Hello, %s\n", b"World!")
Hello, World!
14
>>> printf(c_char_p("Hello, %s\n"), c_char_p("World!"))
Hello, World!
14
>>> printf(b"Hello, %S\n", "World!")
Hello, World!
14
>>> printf(c_char_p("Hello, %S\n"), "World!")
Hello, World!
14
>>> printf(c_char_p("%d bottles of beer\n"), 42)
42 bottles of beer
19
>>> printf(c_char_p("%f bottles of beer\n"), 42.5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ctypes.ArgumentError: argument 2: <class 'TypeError'>: Don't know how to
convert parameter 2

And change the second example block to:

>>> printf(c_char_p("An int %d, a double %f\n"), 1234, c_double(3.14))
An int 1234, a double 3.140000
31

Aside: For reference, here is how I started up the interactive session:
mike at www:~$ python3.0
Python 3.0.1 (r301:69556, Jun  6 2009, 21:34:43)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> libc = CDLL("libc.so.6")

Note the "printf.argtypes" method is discussed later in Section
"15.15.1.7. Specifying the required argument types (function
prototypes)", so it might be premature to use it here.

----------
nosy: +mnewman

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

From report at bugs.python.org  Sun Jun  7 06:37:44 2009
From: report at bugs.python.org (James Abbatiello)
Date: Sun, 07 Jun 2009 04:37:44 +0000
Subject: [issue6227] doctest_aliases doesn't test duplicate removal
In-Reply-To: <1244349464.7.0.139481605677.issue6227@psf.upfronthosting.co.za>
Message-ID: <1244349464.7.0.139481605677.issue6227@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

The file Lib/test/doctest_aliases.py is used by test_doctest to check
the handling of duplicate removal.  The "g = f" line in this file is one
indent too far to the right so instead of creating an alias for f called
g it is just unreachable code inside of f.  Since there is no alias
there is no need to remove duplicates and the test passes trivially.

I think this affects all versions but I've only checked on 2.7.

----------
components: Tests
files: doctest_aliases.patch
keywords: patch
messages: 89027
nosy: abbeyj
severity: normal
status: open
title: doctest_aliases doesn't test duplicate removal
versions: Python 2.7
Added file: http://bugs.python.org/file14210/doctest_aliases.patch

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

From report at bugs.python.org  Sun Jun  7 09:25:00 2009
From: report at bugs.python.org (Frans)
Date: Sun, 07 Jun 2009 07:25:00 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244359500.15.0.0854348896655.issue4749@psf.upfronthosting.co.za>


Frans <Frans.van.Nieuwenhoven at gmail.com> added the comment:

I ran into the same problem with RotatingFileHandler from a
multithreaded daemon under Ubuntu. I Googled around and found the
ConcurrentLogHandler on pypi
(http://pypi.python.org/pypi/ConcurrentLogHandler). It solved the problem.

----------
nosy: +Frans

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

From report at bugs.python.org  Sun Jun  7 09:44:04 2009
From: report at bugs.python.org (steve21)
Date: Sun, 07 Jun 2009 07:44:04 +0000
Subject: [issue6228] round() error
In-Reply-To: <1244360644.6.0.321389592966.issue6228@psf.upfronthosting.co.za>
Message-ID: <1244360644.6.0.321389592966.issue6228@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

I wish to round the float 697.04157958254996 to 10 decimal digits after
the decimal point.

$ python3.0
Python 3.0.1 (r301:69556, Jun  7 2009, 14:51:41)
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> 697.04157958254996
697.04157958254996      # python float can represent this number exactly

>>> 697.04157958250000  # this is the expected result
697.04157958250005      # this is the closest python float representation

>>> round(697.04157958254996, 10)
697.04157958259998      # error

round() gives a result that is closer to
697.0415795826
than the expected result of
697.0415795825
- it has not rounded to the closest 10th decimal digit after the decimal
point.

(python 2.6.2 has the same problem)

----------
messages: 89029
nosy: steve21
severity: normal
status: open
title: round() error
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sun Jun  7 12:05:02 2009
From: report at bugs.python.org (eric)
Date: Sun, 07 Jun 2009 10:05:02 +0000
Subject: [issue6229] Installation python on mac
In-Reply-To: <1244369102.02.0.674682912004.issue6229@psf.upfronthosting.co.za>
Message-ID: <1244369102.02.0.674682912004.issue6229@psf.upfronthosting.co.za>


New submission from eric <mullen at gmx.ch>:

Hello
i wan't to install the python 3.0 on my mac. the python image, .dmg
file, i download from this site, run the installation. After this, the
framework doesn't installation in the folder
/System/Library/Frameworks/Python.framework.
How can i change the installation folder?

thx kostonstyle

----------
messages: 89030
nosy: kostonstyle
severity: normal
status: open
title: Installation python on mac
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun  7 13:35:18 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Jun 2009 11:35:18 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244374518.42.0.410109776405.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

ConcurrentLogHandler is for multiple *processes* writing to the same
file, not multiple threads in a single process. Python logging does not
support multiple processes writing to the same file because there is no
portable IPC locking across all platforms supported by Python.
ConcurrentLogHandler uses portalocker to achieve interprocess
synchronization, and there is no equivalent mechanism which is part of
the Python stdlib. AFAIK portalocker works on Windows and Linux - I'm
not sure about other platforms.

Python logging *does* support multiple threads in a single process
writing to the same file, which is why I asked Robert if it was
definitely a single-process environment he was working in.

----------

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

From report at bugs.python.org  Sun Jun  7 14:28:33 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Jun 2009 12:28:33 +0000
Subject: [issue6229] Installation python on mac
In-Reply-To: <1244369102.02.0.674682912004.issue6229@psf.upfronthosting.co.za>
Message-ID: <1244377713.51.0.0608793705347.issue6229@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please ask this question on a mailing list like comp.lang.python.

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

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

From report at bugs.python.org  Sun Jun  7 15:59:36 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 13:59:36 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244383176.92.0.591714507126.issue2746@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Patch which includes the given fix and adds a test case to cover this
(test case from Russell Cloran)

----------
keywords: +patch
nosy: +Neil Muller
Added file: http://bugs.python.org/file14211/issue-2746.diff

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

From report at bugs.python.org  Sun Jun  7 16:00:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Jun 2009 14:00:33 +0000
Subject: [issue6228] round() error
In-Reply-To: <1244360644.6.0.321389592966.issue6228@psf.upfronthosting.co.za>
Message-ID: <1244383233.62.0.577564422685.issue6228@psf.upfronthosting.co.za>


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

Thanks for the report.

This is fixed in Python 3.1 (except on a few unusual hardware/OS 
combinations):

Python 3.1rc1+ (py3k:73252, Jun  6 2009, 10:35:36) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> round(697.04157958254996, 10)
697.0415795825

It's a "won't fix" for Python 2.x.  Rounding to 10 decimal places 
involves multiplying by 10**10., rounding to the nearest integer, then 
dividing by 10**10. again;  the problem in this case is that 
multiplication by 10.**10 is inexact, and the error involved in the 
multiplication by 10**10. pushes the value from the 'round down' region 
into the 'round up region':

Python 2.7a0 (trunk:73252, Jun  6 2009, 10:16:08) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 697.04157958254996 * 10**10
6970415795825.5
[38623 refs]

There's no easy way to fix this, short of using multiple-precision 
arithmetic to do the rounding (which is what Python 3.1 does).


By the way, Python's float can't represent the number

697.04157958254996

exactly (assuming IEEE 754 arithmetic):  the closest it gets is the 
value:

697.041579582549957194714806973934173583984375

but the repr of a float (in Python 3.0 and 2.x) only produces 17 
significant digits, since that's enough to guarantee that the
repr() value evaluates back to the correct float (assuming correct
rounding).

----------
nosy: +marketdickinson
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Jun  7 16:00:38 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:00:38 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244383238.09.0.608076037575.issue2746@psf.upfronthosting.co.za>


Changes by Neil Muller <drnlmuller+bugs at gmail.com>:


----------
nosy: +effbot

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

From report at bugs.python.org  Sun Jun  7 16:08:16 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:08:16 +0000
Subject: [issue6230] ElementTree.Element and cElementTree.Element have
	slightly different repr
In-Reply-To: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>
Message-ID: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

ElementTree and cElementTree give slightly different results for
repr(Element):

>>> import xml.etree.ElementTree as ET
>>> import xml.etree.cElementTree as cET
>>> repr(ET.ElementTree('tag'))
'<Element tag at b7cf506c>'
>>> repr(cET.ElementTree('tag')
"<Element 'tag' at 0xb7c266f8>"

The quoting around the tag name is missing from ElementTree.

This inconsistency seems pointless.

Attached patch changes ElementTree to match cElementTree behaviour, and
adds a test.

----------
components: Library (Lib)
files: repr-fix.diff
keywords: patch
messages: 89035
nosy: Neil Muller, effbot
severity: normal
status: open
title: ElementTree.Element and cElementTree.Element have slightly different repr
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14212/repr-fix.diff

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

From report at bugs.python.org  Sun Jun  7 16:10:51 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:10:51 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244383851.78.0.233731851296.issue2746@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Previous patch was missing two lines in the test case. Correct fix uploaded

----------
Added file: http://bugs.python.org/file14213/issue-2746.diff

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

From report at bugs.python.org  Sun Jun  7 16:21:44 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:21:44 +0000
Subject: [issue6231] ElementInclude may drop text
In-Reply-To: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>
Message-ID: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

In some cases, ElementInclude will not include the tail from the current
node.

Test case and patch against trunk attached (from Simon Cross).

----------
components: Library (Lib)
files: ElementInclude.diff
keywords: patch
messages: 89037
nosy: Neil Muller, effbot, hodgestar
severity: normal
status: open
title: ElementInclude may drop text
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14214/ElementInclude.diff

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

From report at bugs.python.org  Sun Jun  7 16:31:24 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:31:24 +0000
Subject: [issue6232] Improve test coverage of ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

The test coverage for ElementTree and cElementTree could be improved.

The attached file adds several more tests for ElementTree (including a
number from the ElementTree 1.2.7 pre-release).

This excludes the tests suggested in:
http://bugs.python.org/issue6230
http://bugs.python.org/issue6231
http://bugs.python.org/issue2746

----------
components: Tests
files: test_xml_etree.py
messages: 89038
nosy: Neil Muller, effbot
severity: normal
status: open
title: Improve test coverage of ElementTree and cElementTree
versions: Python 2.7
Added file: http://bugs.python.org/file14215/test_xml_etree.py

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

From report at bugs.python.org  Sun Jun  7 16:34:33 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 14:34:33 +0000
Subject: [issue6232] Improve test coverage of ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1244385273.74.0.458280573684.issue6232@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

This adds the same tests for cElementTree, disabling them in a few cases
were the behaviour differs.

(Tests include work from Russell Cloran, Jeremy Thurgood, Simon Cross,
Adrianna Pinksa and Graham Poulter)

----------
Added file: http://bugs.python.org/file14216/test_xml_etree_c.py

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

From report at bugs.python.org  Sun Jun  7 16:37:24 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Jun 2009 14:37:24 +0000
Subject: [issue6228] round() error
In-Reply-To: <1244360644.6.0.321389592966.issue6228@psf.upfronthosting.co.za>
Message-ID: <1244385444.92.0.847773809127.issue6228@psf.upfronthosting.co.za>


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

See also issue 1869 and the issues it links to for additional discussions 
about round.

----------

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

From report at bugs.python.org  Sun Jun  7 16:37:33 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Jun 2009 14:37:33 +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: <1244385453.43.0.957419082513.issue1869@psf.upfronthosting.co.za>


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

See also issue 6228.

----------

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

From report at bugs.python.org  Sun Jun  7 16:54:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Jun 2009 14:54:00 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1244386440.21.0.787892043249.issue5308@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: marketdickinson -> 

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

From report at bugs.python.org  Sun Jun  7 17:17:00 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jun 2009 15:17:00 +0000
Subject: [issue2922] "No windows home dir" doc error
In-Reply-To: <1211232599.63.0.873438869576.issue2922@psf.upfronthosting.co.za>
Message-ID: <1244387820.68.0.823291594663.issue2922@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Closing as 'works for me' since the OP hasn't responded with any counter
argument to Martin's assertion and it's been open for more than a year.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jun  7 17:30:00 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Jun 2009 15:30:00 +0000
Subject: [issue6202] Obsolete default file encoding "mac-roman" on OS X,
	not influenced by locale env variables
In-Reply-To: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>
Message-ID: <1244388600.17.0.331513340538.issue6202@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The patch looks good, and tests pass on 10.5.7.

I've committed this as r73268

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

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

From report at bugs.python.org  Sun Jun  7 17:32:18 2009
From: report at bugs.python.org (Russell Cloran)
Date: Sun, 07 Jun 2009 15:32:18 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244388738.2.0.72893541005.issue2746@psf.upfronthosting.co.za>


Changes by Russell Cloran <rcloran+py at gmail.com>:


----------
nosy: +russell

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

From report at bugs.python.org  Sun Jun  7 17:32:43 2009
From: report at bugs.python.org (Russell Cloran)
Date: Sun, 07 Jun 2009 15:32:43 +0000
Subject: [issue6230] ElementTree.Element and cElementTree.Element have
	slightly different repr
In-Reply-To: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>
Message-ID: <1244388763.94.0.786474543693.issue6230@psf.upfronthosting.co.za>


Changes by Russell Cloran <rcloran+py at gmail.com>:


----------
nosy: +russell

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

From report at bugs.python.org  Sun Jun  7 17:33:07 2009
From: report at bugs.python.org (Russell Cloran)
Date: Sun, 07 Jun 2009 15:33:07 +0000
Subject: [issue6231] ElementInclude may drop text
In-Reply-To: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>
Message-ID: <1244388787.21.0.488262543961.issue6231@psf.upfronthosting.co.za>


Changes by Russell Cloran <rcloran+py at gmail.com>:


----------
nosy: +russell

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

From report at bugs.python.org  Sun Jun  7 17:33:11 2009
From: report at bugs.python.org (Russell Cloran)
Date: Sun, 07 Jun 2009 15:33:11 +0000
Subject: [issue6232] Improve test coverage of ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1244388791.53.0.28942528547.issue6232@psf.upfronthosting.co.za>


Changes by Russell Cloran <rcloran+py at gmail.com>:


----------
nosy: +russell

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

From report at bugs.python.org  Sun Jun  7 17:39:11 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Jun 2009 15:39:11 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244389151.86.0.352728271323.issue6154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached file libintl-framework-ronald.patch should do the trick.

Could someone who is affected by this issue test this patch (and feel free 
to commit it if it works). I don't have libintl on my system and hence 
cannot test right now.

----------
Added file: http://bugs.python.org/file14217/libintl-framework-ronald.patch

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

From report at bugs.python.org  Sun Jun  7 17:39:46 2009
From: report at bugs.python.org (Simon Cross)
Date: Sun, 07 Jun 2009 15:39:46 +0000
Subject: [issue6230] ElementTree.Element and cElementTree.Element have
	slightly different repr
In-Reply-To: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>
Message-ID: <1244389186.96.0.8522986597.issue6230@psf.upfronthosting.co.za>


Changes by Simon Cross <hodgestar at gmail.com>:


----------
nosy: +hodgestar

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

From report at bugs.python.org  Sun Jun  7 17:40:17 2009
From: report at bugs.python.org (Simon Cross)
Date: Sun, 07 Jun 2009 15:40:17 +0000
Subject: [issue6232] Improve test coverage of ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1244389217.35.0.615036345398.issue6232@psf.upfronthosting.co.za>


Changes by Simon Cross <hodgestar at gmail.com>:


----------
nosy: +hodgestar

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

From report at bugs.python.org  Sun Jun  7 18:11:35 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Jun 2009 16:11:35 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244391095.81.0.288418492633.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

"Who said anything about not supporting users who want the hierarchy?
I'm talking about making "qualname" ****optional****, not removing it
entirely!"

Ok, I see - sorry for the misunderstanding on my part.

"... these files need to be read and edited by non-coders and they're a
lot scarier (and harder to tweak) than the old ones were. Basically
they're full of abstract technical concepts ("qualname", "handler") and
bits of python code to be eval'ed."

The configuration format is not (and was never) intended for
non-technical end users. Because of the way it works, typos in the
elements which are eval'd can throw exceptions, which is obviously
undesirable. If you want such users to be able to change the logging
configuration, I would advise you implement your own layer which does
not use any technical terminology such as "handler" or "qualname", and
from that layer either update the logging configuration via the logging
API, or write a standard logging config file.

"It's not particularly hard to find people out there raising this if you
google a bit."

Well, I did do a search for "+python +logging +config +problems" which
didn't throw up much (other than this issue). I'd be grateful for some
specific links to recent items which you have found.

----------
status: open -> pending

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

From report at bugs.python.org  Sun Jun  7 18:44:30 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 07 Jun 2009 16:44:30 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1244393070.34.0.0799044556231.issue6192@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed in revision 73272

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

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

From report at bugs.python.org  Sun Jun  7 18:47:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jun 2009 16:47:19 +0000
Subject: [issue2947] subprocess (Replacing popen) - add a warning / hint
In-Reply-To: <1211469479.53.0.83820029984.issue2947@psf.upfronthosting.co.za>
Message-ID: <1244393239.87.0.151178146553.issue2947@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patch attached that adds an example that shows how to translate return
code handling, loosely based on Helmut's example.  I also turned the
function references in the section titles into links because I think
that would be very useful to someone wanting to do a translation
(provides easy access to the docs for the old functions).  The font size
looks a bit weird in the generated docs, though, so perhaps that is why
this wasn't done originally.  If putting references in section titles is
a no-no let me know and I'll remove them from the patch.

Also included in the patch is a fix for the cross reference link from
the os.spawn section to the 'replacing functions' section of the
subprocess docs.

----------
keywords: +easy, patch
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review
type:  -> feature request
versions: +Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14218/issue2947-doc.patch

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

From report at bugs.python.org  Sun Jun  7 19:43:57 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 07 Jun 2009 17:43:57 +0000
Subject: [issue6202] Obsolete default file encoding "mac-roman" on OS X,
	not influenced by locale env variables
In-Reply-To: <1244198231.29.0.333691708249.issue6202@psf.upfronthosting.co.za>
Message-ID: <1244396637.83.0.755114978261.issue6202@psf.upfronthosting.co.za>


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

(and committed to trunk in r73270 by Benjamin)

----------

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

From report at bugs.python.org  Sun Jun  7 21:12:01 2009
From: report at bugs.python.org (Frans)
Date: Sun, 07 Jun 2009 19:12:01 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1244374518.42.0.410109776405.issue4749@psf.upfronthosting.co.za>
Message-ID: <33db10b30906071211v72eddfe1iad96ba2ccece97cc@mail.gmail.com>


Frans <Frans.van.Nieuwenhoven at gmail.com> added the comment:

Hi Vinay,

Thanks for your info. I have just shared my experience. I ran into a problem
(apperently, there is one)  and found a work-around that fits my needs.
If I find the real fix, I will surely follow up on it.

Regards,

Frans

2009/6/7 Vinay Sajip <report at bugs.python.org>

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> ConcurrentLogHandler is for multiple *processes* writing to the same
> file, not multiple threads in a single process. Python logging does not
> support multiple processes writing to the same file because there is no
> portable IPC locking across all platforms supported by Python.
> ConcurrentLogHandler uses portalocker to achieve interprocess
> synchronization, and there is no equivalent mechanism which is part of
> the Python stdlib. AFAIK portalocker works on Windows and Linux - I'm
> not sure about other platforms.
>
> Python logging *does* support multiple threads in a single process
> writing to the same file, which is why I asked Robert if it was
> definitely a single-process environment he was working in.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4749>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14219/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________
-------------- next part --------------
Hi Vinay, <br><br>Thanks for your info. I have just shared my experience. I ran into a problem (apperently, there is one)?? and found a work-around that fits my needs.<br>If I find the real fix, I will surely follow up on it.<br>
<br>Regards,<br><br>Frans<br><br><br><div class="gmail_quote">2009/6/7 Vinay Sajip <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Vinay Sajip &lt;<a href="mailto:vinay_sajip at yahoo.co.uk">vinay_sajip at yahoo.co.uk</a>&gt; added the comment:<br>
<br>
ConcurrentLogHandler is for multiple *processes* writing to the same<br>
file, not multiple threads in a single process. Python logging does not<br>
support multiple processes writing to the same file because there is no<br>
portable IPC locking across all platforms supported by Python.<br>
ConcurrentLogHandler uses portalocker to achieve interprocess<br>
synchronization, and there is no equivalent mechanism which is part of<br>
the Python stdlib. AFAIK portalocker works on Windows and Linux - I&#39;m<br>
not sure about other platforms.<br>
<br>
Python logging *does* support multiple threads in a single process<br>
writing to the same file, which is why I asked Robert if it was<br>
definitely a single-process environment he was working in.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue4749" target="_blank">http://bugs.python.org/issue4749</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sun Jun  7 21:23:16 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Sun, 07 Jun 2009 19:23:16 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244402596.08.0.206967136762.issue6136@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

If it was never intended for end users, then perhaps you could rename
this request as "provide an end-user-friendly log configuration format"
(that would live alongside the current one). It's hardly unusual that
users should be able to troubleshoot systems themselves by requesting
more (or different) logging, is it?

For example, log4py's format looked like this:
[my_logger]
LogLevel: Normal
Target: my_filename.log

Pretty much anyone can edit a bunch of sections that look like that
(with optional extras such as formatting where appropriate).

------------------------

As for mentions of this issue online, I linked to one such on my
comp.lang.python posting. It isn't recent, but the points about the
config file still apply as it hasn't substantially changed since then as
far as I can see. 3 different users raise essentially the same point
(and you also contributed to this thread)

http://www.mechanicalcat.net/richard/log/Python/Simple_usage_of_Python_s_logging_module

Here's another (only some of the discussion is relevant, but this exact
point is raised by the original poster and agreed with by the responder):

http://markmail.org/message/amxocg2nskd72qaf

----------
status: pending -> open

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

From report at bugs.python.org  Sun Jun  7 21:31:02 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Sun, 07 Jun 2009 19:31:02 +0000
Subject: [issue1184112] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <1244403062.76.0.421243975695.issue1184112@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

Confirmed on versions 2.6.2, 3.0.1 and 3.1rc1.  On the three of them, I
tried this:

>>> import parser 
>>> test = 'def foo():\n\tpass\n\n# comment'
>>> parser.suite(test)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 4
    # comment
           ^
SyntaxError: invalid syntax
>>>

----------
nosy: +ptn

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

From report at bugs.python.org  Sun Jun  7 21:31:47 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Sun, 07 Jun 2009 19:31:47 +0000
Subject: [issue1184112] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <1244403107.39.0.165992975029.issue1184112@psf.upfronthosting.co.za>


Changes by Pablo Torres Navarrete <tn.pablo at gmail.com>:


----------
versions: +Python 3.1

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

From report at bugs.python.org  Sun Jun  7 22:11:20 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Jun 2009 20:11:20 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244405480.39.0.995332046415.issue6154@psf.upfronthosting.co.za>


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

OK, committed by configure.in patch along with Ronald's Makefile.pre.in
patch in r73274. Thanks to everyone who helped out with this. Building
sucks and autoconf doesn't always help.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Sun Jun  7 22:11:32 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Jun 2009 20:11:32 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1244405492.56.0.980673293137.issue6154@psf.upfronthosting.co.za>


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


----------
status: open -> closed

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

From report at bugs.python.org  Sun Jun  7 22:13:57 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 20:13:57 +0000
Subject: [issue6230] ElementTree.Element and cElementTree.Element have
	slightly different repr
In-Reply-To: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>
Message-ID: <1244405637.82.0.913776533861.issue6230@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Same issue affects python 3k - the patch applies there cleanly as well.

----------

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

From report at bugs.python.org  Sun Jun  7 22:17:16 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 20:17:16 +0000
Subject: [issue6231] ElementInclude may drop text
In-Reply-To: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>
Message-ID: <1244405836.74.0.620491062314.issue6231@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Same issue affects python 3k. Modified patch (print statement needed
changing) added

----------
Added file: http://bugs.python.org/file14220/ElementInclude_py3k.diff

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

From report at bugs.python.org  Sun Jun  7 22:58:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jun 2009 20:58:09 +0000
Subject: [issue2977] truncation of text in tables in Library Reference PDF
In-Reply-To: <1211834269.04.0.0744383580947.issue2977@psf.upfronthosting.co.za>
Message-ID: <1244408289.62.0.900107878545.issue2977@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The (2.6) docs have changed enough that I can't find the tables at issue
from your page numbers.  Is this still a problem and if so can you
please identify the tables rather than the page numbers?  Thanks.

----------
nosy: +r.david.murray
type: performance -> behavior

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

From report at bugs.python.org  Sun Jun  7 22:59:57 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 20:59:57 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244408397.0.0.446006208756.issue2746@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Issue also effects p3k. Adapted patch attached.

----------
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14221/issue-2746_py3k.diff

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

From report at bugs.python.org  Sun Jun  7 23:00:34 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 21:00:34 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244408434.37.0.843107345971.issue2746@psf.upfronthosting.co.za>


Changes by Neil Muller <drnlmuller+bugs at gmail.com>:


Removed file: http://bugs.python.org/file14211/issue-2746.diff

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

From report at bugs.python.org  Sun Jun  7 23:00:57 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 21:00:57 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244408457.22.0.744829165906.issue2746@psf.upfronthosting.co.za>


Changes by Neil Muller <drnlmuller+bugs at gmail.com>:


Removed file: http://bugs.python.org/file14213/issue-2746.diff

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

From report at bugs.python.org  Sun Jun  7 23:01:52 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 21:01:52 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244408512.28.0.417950807849.issue2746@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Previous upload of issue_2746 was corrupt. Fixed version uploaded.

----------
Added file: http://bugs.python.org/file14222/issue-2746.diff

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

From report at bugs.python.org  Sun Jun  7 23:31:00 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 21:31:00 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

In py3k, ElementTree no longer correctly converts characters to entities
when they can't be represented in the requested output encoding.

Python 2:

>>> import xml.etree.ElementTree as ET
>>> e = ET.XML("<?xml version='1.0'
encoding='iso-8859-1'?><body>t\xe3t</body>")
>>> ET.tostring(e, 'ascii')
"<?xml version='1.0' encoding='ascii'?>\n<body>t&#227;t</body>"

Python 3:

>>> import xml.etree.ElementTree as ET
>>> e = ET.XML("<?xml version='1.0'
encoding='iso-8859-1'?><body>t\xe3t</body>")
>>> ET.tostring(e, 'ascii')
.....
UnicodeEncodeError: 'ascii' codec can't encode characters in position
1-2: ordinal not in range(128)


It looks like _encode_entity isn't ever called inside ElementTree
anymore - it probably should be called as part of _encode for characters
that can't be represented.

----------
components: Library (Lib)
messages: 89058
nosy: Neil Muller, effbot, hodgestar
severity: normal
status: open
title: ElementTree (py3k) doesn't properly encode characters that can't be represented in the specified encoding
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jun  7 23:47:43 2009
From: report at bugs.python.org (Neil Muller)
Date: Sun, 07 Jun 2009 21:47:43 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1244411263.9.0.14008614008.issue6233@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Simple possible patch uploaded

This doesn't give the expected answer for the test above, but does work
when starting from an XML file in utf-8 encoding. I still need to
determine why this happens.

----------
keywords: +patch
Added file: http://bugs.python.org/file14223/issue6233_py3k.diff

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

From report at bugs.python.org  Mon Jun  8 00:07:37 2009
From: report at bugs.python.org (Evan Fosmark)
Date: Sun, 07 Jun 2009 22:07:37 +0000
Subject: [issue6234] cgi.FieldStorage is broken when given POST data
In-Reply-To: <1244412456.94.0.493968112391.issue6234@psf.upfronthosting.co.za>
Message-ID: <1244412456.94.0.493968112391.issue6234@psf.upfronthosting.co.za>


New submission from Evan Fosmark <me at evanfosmark.com>:

Right now, it seems impossible to use cgi.FieldStorage in 3.0 if you're
giving it environ['wsgi.input'] like so:

    post_data = cgi.FieldStorage(
        fp=environ["wsgi.input"],
        environ=environ,
        keep_blank_values=True
        )


It gives the following error:

      File "/usr/local/lib/python3.0/cgi.py", line 489, in __init__
        self.read_urlencoded()
      File "/usr/local/lib/python3.0/cgi.py", line 589, in read_urlencoded
        self.strict_parsing):
      File "/usr/local/lib/python3.0/urllib/parse.py", line 377, in
parse_qsl
        pairs = [s2 for s1 in qs.split('&') for s2 in s1.split(';')]
TypeError: Type str doesn't support the buffer API

----------
components: Library (Lib)
messages: 89060
nosy: efosmark
severity: normal
status: open
title: cgi.FieldStorage is broken when given POST data
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun  8 01:09:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Jun 2009 23:09:06 +0000
Subject: [issue6221] Windows buildbot failure in test_winreg
In-Reply-To: <1244294791.11.0.0504716192427.issue6221@psf.upfronthosting.co.za>
Message-ID: <1244416146.13.0.195469141352.issue6221@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r73273 seems to have done the trick. (Thanks Martin!)

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

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

From report at bugs.python.org  Mon Jun  8 02:19:11 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Jun 2009 00:19:11 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1244420351.05.0.470743698471.issue6192@psf.upfronthosting.co.za>


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

This patch should be committed to py3k after 3.1 is released.

----------
assignee:  -> krisvale
status: closed -> open
versions: +Python 3.2 -Python 2.7

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

From report at bugs.python.org  Mon Jun  8 02:56:41 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 08 Jun 2009 00:56:41 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244422601.91.0.588678269694.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

"If it was never intended for end users, then perhaps you could rename
this request as "provide an end-user-friendly log configuration format"
(that would live alongside the current one). It's hardly unusual that
users should be able to troubleshoot systems themselves by requesting
more (or different) logging, is it?"

It's unlikely that this would be provided as part of the Python stdlib:
requirements which are truly end-user-friendly are also likely to be
application-specific. When the configuration format was devised I did
seek feedback - but people with strong opinions on the issue told me
they'd prefer to roll their own. I'm fine with that; you can't please
all of the people all of the time and I sadly can't devote much time to
this at the moment.

"For example, log4py's format looked like this:
[my_logger]
LogLevel: Normal
Target: my_filename.log"

Looks fine for logging to files only. Does log4py support the wide range
of output sinks that Python logging does? If not, then the more
complicated logging configuration would seem reasonable as there are
more options in Python logging.

"As for mentions of this issue online, I linked to one such on my
comp.lang.python posting."

I'm not sure which posting you mean - I didn't see any recent postings
by you on c.l.py (I look at it via the corresponding Google group).

Re. the links you posted - Richard Jones' thread came out shortly after
logging was released and was largely about documentation and the need
for casual-use functionality which was subsequently provided by
basicConfig(). The MarkMail thread which you linked to doesn't appear to
raise the same points you did - Steve Hindle's original post of 17 May
2006 mentions only in point 4 about "crufty config file syntax", with no
specifics, and I can only find 3 messages in that thread - 2 by Steve
Hindle and one by Aahz which simply suggests moving the discussion to
c.l.py. I checked the Baypiggies archive on mail.python.org - same thing.

My suggestion would be - if you want to promote a simpler config file
syntax for logging, implement one and upload it on PyPI, and post
announcements on c.l.py and c.l.py.announce. If there is demand for this
functionality, people can easily download your package from PyPI and use
it. After all, logging.config is a separate sub-module and need not be
loaded at all.

----------
status: open -> pending

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

From report at bugs.python.org  Mon Jun  8 03:51:23 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 08 Jun 2009 01:51:23 +0000
Subject: [issue6235] \d missing from effects of re.ASCII flag
In-Reply-To: <1244425883.3.0.62231385408.issue6235@psf.upfronthosting.co.za>
Message-ID: <1244425883.3.0.62231385408.issue6235@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the documentation of the re module the ASCII flag is described as
"Make \w, \W, \b, \B, \s and \S perform ASCII-only matching instead of
full Unicode matching." This should also include \d and \D.

----------
assignee: georg.brandl
components: Documentation
messages: 89064
nosy: MLModel, georg.brandl
severity: normal
status: open
title: \d missing from effects of re.ASCII flag
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jun  8 04:20:18 2009
From: report at bugs.python.org (nestor)
Date: Mon, 08 Jun 2009 02:20:18 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>


New submission from nestor <nestornissen at gmail.com>:

Python 2.6.2 (r262:71600, Jun  4 2009, 16:07:26) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.popen('cat','w')

<open file 'cat', mode 'w' at 0x1101ab4f8>


Python 3.0.1 (r301:69556, Jun  4 2009, 16:07:22) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.popen('cat','w')

<os._wrap_close object at 0x1103e5748> 

Python 3.1rc1 (r31rc1:73054, Jun  1 2009, 10:49:24) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.popen('cat','w')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Python-3.1rc1/Lib/os.py", line 641, in popen
    return _wrap_close(io.TextIOWrapper(proc.stdin), proc)
IOError: [Errno 29] Illegal seek 

This in turn causes help not to work:

Python 3.1rc1 (r31rc1:73054, Jun  1 2009, 10:49:24) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> help(open)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Python-3.1rc1/Lib/site.py", line 429, in __call__
    return pydoc.help(*args, **kwds)
  File "/Python-3.1rc1/Lib/pydoc.py", line 1709, in __call__
    self.help(request)
  File "/Python-3.1rc1/Lib/pydoc.py", line 1756, in help
    else: doc(request, 'Help on %s:')
  File "/Python-3.1rc1/Lib/pydoc.py", line 1505, in doc
    pager(render_doc(thing, title, forceload))
  File "/Python-3.1rc1/Lib/pydoc.py", line 1320, in pager
    pager(text)
  File "/Python-3.1rc1/Lib/pydoc.py", line 1340, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/Python-3.1rc1/Lib/pydoc.py", line 1359, in pipepager
    pipe = os.popen(cmd, 'w')
  File "/Python-3.1rc1/Lib/os.py", line 641, in popen
    return _wrap_close(io.TextIOWrapper(proc.stdin), proc)
IOError: [Errno 29] Illegal seek

----------
components: Library (Lib)
messages: 89065
nosy: nestor
severity: normal
status: open
title: os.popen causes illegal seek on AIX in Python 3.1rc
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun  8 04:26:53 2009
From: report at bugs.python.org (Funda Wang)
Date: Mon, 08 Jun 2009 02:26:53 +0000
Subject: [issue6237] Build errors when using LDFLAGS="-Wl,--no-undefined"
In-Reply-To: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za>
Message-ID: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za>


New submission from Funda Wang <fundawang at gmail.com>:

============================
gcc -pthread -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -lstdc++ -
Xlinker -export-dynamic -o python \
                        Modules/python.o \
                        -L. -lpython2.6 -lpthread -ldl  -lutil   -lm
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/_ctypes_test.o: In function `my_sqrt':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes_test.c:83: 
undefined reference to `sqrt'
collect2: ld returned 1 exit status
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
audioop.o: In function `audioop_rms':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/audioop.c:419: undefined 
reference to `sqrt'
collect2: ld returned 1 exit status
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_open':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:187: undefined 
reference to `dlopen'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:189: undefined 
reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_close':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:49: undefined 
reference to `dlclose'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_sym':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:68: undefined 
reference to `dlsym'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_call':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:96: undefined 
reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:100: undefined 
reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
dlmodule.o: In function `dl_dealloc':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/dlmodule.c:41: undefined 
reference to `dlclose'
collect2: ld returned 1 exit status

============================

build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/_ctypes.o: In function `CDataType_in_dll':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:600: 
undefined reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:608: 
undefined reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/_ctypes.o: In function `CFuncPtr_FromDll':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:3285: 
undefined reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/_ctypes.c:3293: 
undefined reference to `dlerror'
/usr/bin/ld: Dwarf Error: Offset (2614) greater than or equal 
to .debug_str size (815).
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/callproc.o: In function `py_dl_sym':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1448: 
undefined reference to `dlsym'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1451: 
undefined reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/callproc.o: In function `py_dl_close':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1430: 
undefined reference to `dlclose'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1432: 
undefined reference to `dlerror'
build/temp.linux-i686-2.6/home/fwang/rpm/BUILD/Python-2.6.2/Modules/
_ctypes/callproc.o: In function `py_dl_open':
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1412: 
undefined reference to `dlopen'
/home/fwang/rpm/BUILD/Python-2.6.2/Modules/_ctypes/callproc.c:1414: 
undefined reference to `dlerror'
collect2: ld returned 1 exit status

============================


Failed to find the necessary bits to build these modules:
bsddb185           sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for 
the module's name.


Failed to build these modules:
_ctypes            _ctypes_test       audioop
dl

============================

I've attached the detail build log.

----------
components: Build
files: build.0.20090608003719.log.bz2
messages: 89066
nosy: fundawang
severity: normal
status: open
title: Build errors when using LDFLAGS="-Wl,--no-undefined"
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14224/build.0.20090608003719.log.bz2

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

From report at bugs.python.org  Mon Jun  8 07:06:54 2009
From: report at bugs.python.org (Jeremy Thurgood)
Date: Mon, 08 Jun 2009 05:06:54 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1244437614.68.0.147744693699.issue2746@psf.upfronthosting.co.za>


Changes by Jeremy Thurgood <firxen at gmail.com>:


----------
nosy: +jerith

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

From report at bugs.python.org  Mon Jun  8 07:07:35 2009
From: report at bugs.python.org (Jeremy Thurgood)
Date: Mon, 08 Jun 2009 05:07:35 +0000
Subject: [issue6230] ElementTree.Element and cElementTree.Element have
	slightly different repr
In-Reply-To: <1244383696.52.0.0575632707865.issue6230@psf.upfronthosting.co.za>
Message-ID: <1244437655.15.0.69679087801.issue6230@psf.upfronthosting.co.za>


Changes by Jeremy Thurgood <firxen at gmail.com>:


----------
nosy: +jerith

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

From report at bugs.python.org  Mon Jun  8 07:08:42 2009
From: report at bugs.python.org (Jeremy Thurgood)
Date: Mon, 08 Jun 2009 05:08:42 +0000
Subject: [issue6231] ElementInclude may drop text
In-Reply-To: <1244384504.27.0.561199535147.issue6231@psf.upfronthosting.co.za>
Message-ID: <1244437722.61.0.217781316711.issue6231@psf.upfronthosting.co.za>


Changes by Jeremy Thurgood <firxen at gmail.com>:


----------
nosy: +jerith

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

From report at bugs.python.org  Mon Jun  8 09:50:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 07:50:02 +0000
Subject: [issue6235] \d missing from effects of re.ASCII flag
In-Reply-To: <1244425883.3.0.62231385408.issue6235@psf.upfronthosting.co.za>
Message-ID: <1244447402.6.0.878992037904.issue6235@psf.upfronthosting.co.za>


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

Thanks, fixed in r73285.

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

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

From report at bugs.python.org  Mon Jun  8 09:53:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 07:53:04 +0000
Subject: [issue2947] subprocess (Replacing popen) - add a warning / hint
In-Reply-To: <1211469479.53.0.83820029984.issue2947@psf.upfronthosting.co.za>
Message-ID: <1244447584.67.0.0598912068467.issue2947@psf.upfronthosting.co.za>


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

Patch looks good, except for strange code indentation in the replaced
example.

----------
assignee: georg.brandl -> r.david.murray

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

From report at bugs.python.org  Mon Jun  8 09:58:45 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 08 Jun 2009 07:58:45 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1244247379.59.0.825114141352.issue1943@psf.upfronthosting.co.za>
Message-ID: <4A2CC4B2.40109@egenix.com>


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

Terry J. Reedy wrote:
> In the interest of possibly improving the imminent 3.1 release,
> I opened #6216
> Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?

Thanks for opening that ticket.

> I wonder if it is possible to make it generically easier to subclass
> PyVarObjects (but my C knowledge to getting too faded to have any ideas).

Even if we were to add some pointer arithmetic tricks to at least
hide away the complexities, you'd no longer be able to change the
way the data memory allocation works.

The reason is simple: subclassing is about reusing existing method
implementations and only adding/changing a few of them.

If you want to change the way the allocation works, you'd have
to replace all of them.

Furthermore, using your subclasses objects with the existing APIs
would no longer be safe, since these would still assume the
original base class memory allocation scheme.

In summary:

Implementations like the unicoderef type I posted
and most of the other use cases I mentioned are no longer
possible, ie. you will *always* have to copy the data in order
to work with the existing Unicode APIs on it.

The current implementation has no problem with working on referenced
data, since support for this was built in right from the start.

That's what I meant with closing the door on future enhancements
that would make a huge difference if used right, for a mere
10% performance increase.

----------

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

From report at bugs.python.org  Mon Jun  8 10:05:18 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 08 Jun 2009 08:05:18 +0000
Subject: [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
In-Reply-To: <1244247109.74.0.75743876331.issue6216@psf.upfronthosting.co.za>
Message-ID: <4A2CC63A.2060206@egenix.com>


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

I think we should also consider raising the free list limit
of currently 1024 objects.

The keep-alive optimization currently uses at most 1024 * 9 * 2
= 18432 bytes (+ pymalloc overhead) on a UCS2 build of Python in
the worst case.

With a limit of 32 you get 65536 bytes.

Given that Unicode objects are one of the most used object in
Python 3k and looking at todays CPU cache sizes, it would
probably be fair to allocate up to 256kB for such an
optimization, e.g. by allowing up to 4096 objects to reside
in the free list.

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

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

From report at bugs.python.org  Mon Jun  8 10:52:28 2009
From: report at bugs.python.org (ThurnerRupert)
Date: Mon, 08 Jun 2009 08:52:28 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244451148.89.0.752340154464.issue6208@psf.upfronthosting.co.za>


ThurnerRupert <rupert.thurner at credit-suisse.com> added the comment:

if one installes python for windows with the provided installer, and 
then run this python from mingw/msys or cygwin, python prints 
backslash as path separator instead of forward slash.

it would be nice if python would notice that it was started out of 
bash and this determines the path separator vs "output", e.g. print to 
the console.

----------

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

From report at bugs.python.org  Mon Jun  8 12:05:13 2009
From: report at bugs.python.org (John Szakmeister)
Date: Mon, 08 Jun 2009 10:05:13 +0000
Subject: [issue4829] confusing error for file("foo", "w++")
In-Reply-To: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>
Message-ID: <1244455513.62.0.538771816046.issue4829@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

The offending lines in io.py are:
    modes = set(mode)
    if modes - set("arwb+tU") or len(mode) > len(modes):
        raise ValueError("invalid mode: %r" % mode)

In particular, the "or len(mode) > len(modes)" is picking off the fact 
that there is repeated mode characters.  Leaving that off allows 
io.open() to behave exactly like the built-in open() call.

OTOH, someone obviously wanted to make sure that repeat mode characters 
were not allowed.  So I guess someone needs to rule on whether we want 
io.open() and io.FileIO() to behave like the built-in, or to keep things 
more strict.

----------

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

From report at bugs.python.org  Mon Jun  8 13:13:57 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 08 Jun 2009 11:13:57 +0000
Subject: [issue6213] Incremental encoder incompatibility between 2.x and py3k
In-Reply-To: <1244233063.22.0.634170589597.issue6213@psf.upfronthosting.co.za>
Message-ID: <1244459637.15.0.611275123888.issue6213@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

This was done because the codec state is part of the return value of
tell(). To have a reasonable return value (i.e. one with just the
position itself) in as many cases as possible it makes sense to design
the codec state in such a way, that the most common state is 0. This is
what was done for py3k: The default state (no BOM read/written yet) is 2
not 0.

----------
nosy: +doerwalter

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

From report at bugs.python.org  Mon Jun  8 13:19:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Jun 2009 11:19:08 +0000
Subject: [issue6213] Incremental encoder incompatibility between 2.x and py3k
In-Reply-To: <1244233063.22.0.634170589597.issue6213@psf.upfronthosting.co.za>
Message-ID: <1244459948.67.0.956715798766.issue6213@psf.upfronthosting.co.za>


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

Yes, I agree with py3k's behaviour. But it should be backported to 2.x
as well. I don't know where the changes must be done so if someone else
could do it it would be nice :-)
(I'm backporting the py3k IO lib and I had to disable two tests because
of this)

----------

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

From report at bugs.python.org  Mon Jun  8 13:59:31 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 08 Jun 2009 11:59:31 +0000
Subject: [issue6213] Incremental encoder incompatibility between 2.x and py3k
In-Reply-To: <1244233063.22.0.634170589597.issue6213@psf.upfronthosting.co.za>
Message-ID: <1244462371.44.0.603694635973.issue6213@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

AFAICR the difference is: 2.x may return any object in getstate(), but
py3k must return a (buffered input, integer) tuple. Simply moving py3ks
getstate/setstate implementation over to 2.x might do the trick.

----------

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

From report at bugs.python.org  Mon Jun  8 15:28:52 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 13:28:52 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1244467732.0.0.612856742428.issue4309@psf.upfronthosting.co.za>


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

I fixed this, and a few other bytes/string issues, in r73293.

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

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

From report at bugs.python.org  Mon Jun  8 15:29:56 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 13:29:56 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244467796.13.0.791996940105.issue6203@psf.upfronthosting.co.za>


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

Deferring to Martin which one is correct :)

----------
assignee: georg.brandl -> loewis
nosy: +loewis

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

From report at bugs.python.org  Mon Jun  8 15:31:49 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 08 Jun 2009 13:31:49 +0000
Subject: [issue6099] HTTP/1.1 with keep-alive support for xmlrpclib.ServerProxy
In-Reply-To: <1243198332.08.0.299017339998.issue6099@psf.upfronthosting.co.za>
Message-ID: <1244467909.16.0.785734753191.issue6099@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

It turns out we need to deal with exceptions and clear the cached 
HTTPConnection if they happen.
Also, we just deal with a ECONNRESET which can happen if there is a long 
delay between requests, and retry the request once in that case.  New 
patch uploaded.

----------
Added file: http://bugs.python.org/file14225/xmlprclib.patch

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

From report at bugs.python.org  Mon Jun  8 15:35:03 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 13:35:03 +0000
Subject: [issue6194] fcntl footnote about O_SHLOCK and O_EXLOCK is misleading
In-Reply-To: <1244151518.6.0.751803851074.issue6194@psf.upfronthosting.co.za>
Message-ID: <1244468103.35.0.674135438711.issue6194@psf.upfronthosting.co.za>


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

Thanks, fixed in r73294.

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

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

From report at bugs.python.org  Mon Jun  8 17:17:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Jun 2009 15:17:25 +0000
Subject: [issue798058] IDLE / PyOS_InputHook
Message-ID: <1244474245.15.0.441456522784.issue798058@psf.upfronthosting.co.za>


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

Guilherme, you did not actually close the issue

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

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

From report at bugs.python.org  Mon Jun  8 17:18:32 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 08 Jun 2009 15:18:32 +0000
Subject: [issue798058] IDLE / PyOS_InputHook
Message-ID: <1244474312.5.0.416150103069.issue798058@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uh oh, awesome. Thanks ;)

----------
status: open -> closed

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

From report at bugs.python.org  Mon Jun  8 17:19:08 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 08 Jun 2009 15:19:08 +0000
Subject: [issue798058] IDLE / PyOS_InputHook
Message-ID: <1244474348.55.0.759839636404.issue798058@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


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

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

From report at bugs.python.org  Mon Jun  8 17:34:28 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jun 2009 15:34:28 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244475268.99.0.715377676254.issue6208@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That would mean that python's notion of which OS it was running on
(windows or cygwin) would have to change depending on which shell it was
lanched from. This affects far more than the path seperator, and as far
as I know is not practical with the current python design (you are
welcome to try to work up a patch, though).

If you want cygwin behavior from python, run the cygwin python.

----------
resolution:  -> invalid
stage:  -> committed/rejected

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

From report at bugs.python.org  Mon Jun  8 17:58:30 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Jun 2009 15:58:30 +0000
Subject: [issue6238] string.ljust documentation is missing optional fillchar
	description
In-Reply-To: <1244476710.84.0.84375943998.issue6238@psf.upfronthosting.co.za>
Message-ID: <1244476710.84.0.84375943998.issue6238@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The documentation for string.ljust, string.rjust, and string.center is
missing the optional parameter fillchar.  The str.ljust documentation
appears to be correct.

This was observed in Python 2.6.2 documentation as found on the
docs.python.org site at the time of this report.

----------
assignee: georg.brandl
components: Documentation
messages: 89083
nosy: georg.brandl, jaraco
severity: normal
status: open
title: string.ljust documentation is missing optional fillchar description
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun  8 18:01:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jun 2009 16:01:06 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244476866.42.0.0352807952776.issue6203@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is definately a bug in 3.1, for the same reason that a C program
uses the C locale until an explicit setlocale is done: otherwise, a
non-locale-aware program can run into bugs resulting from locale issues
when run under a different locale than that of the program author.

I have a memory of this being reported before somewhere and someone
tracking it down to a change in python initialization, but I can't find
a bug report and my google-foo is failing me.

----------
nosy: +r.david.murray
priority: normal -> release blocker
stage:  -> needs patch

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

From report at bugs.python.org  Mon Jun  8 18:04:18 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 16:04:18 +0000
Subject: [issue6238] string.ljust documentation is missing optional fillchar
	description
In-Reply-To: <1244476710.84.0.84375943998.issue6238@psf.upfronthosting.co.za>
Message-ID: <1244477058.45.0.512930088095.issue6238@psf.upfronthosting.co.za>


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

Fixed in r73296.  You shouldn't have been looking at those anyway :)

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

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

From report at bugs.python.org  Mon Jun  8 18:07:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Jun 2009 16:07:29 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

If you assign a function a restype of c_char_p, you get back a Unicode
string, but you should get a bytes object.

>>> from ctypes import *
>>> strchr = cdll['libc.so.6'].strchr
>>> strchr.restype = c_char_p
>>> strchr.argtypes = [c_char_p, c_char]
>>> strchr(b'abcde', b'd')
'de'

----------
assignee: theller
components: ctypes
messages: 89086
nosy: georg.brandl, theller
priority: critical
severity: normal
stage: needs patch
status: open
title: c_char_p return value returns string, not bytes
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun  8 18:09:54 2009
From: report at bugs.python.org (ThurnerRupert)
Date: Mon, 08 Jun 2009 16:09:54 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244477394.66.0.461854828643.issue6208@psf.upfronthosting.co.za>


ThurnerRupert <rupert.thurner at credit-suisse.com> added the comment:

to give an example case, running mercurial, which we do for a couple 
of years now with success. one install, starting it either from cmd, 
or mingw/msys bash:
$ hg status
M src\com\file.txt
$ hg co -m "different path now" src/com/file.txt

apart from the backslash in the printed paths, we are very happy on 
how neatly python handles this case. 

it is running on windows, using the standard libraries, .. therefor 
everything else is really "windows". it would be quite an exceptional 
case if anything else would be affected. could you come up with an 
example which you were thinking on?

if you point us to some location in the code which would be best to 
start reading i'd be thankful.

----------

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

From report at bugs.python.org  Mon Jun  8 18:17:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Jun 2009 16:17:55 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244477875.03.0.0811140664183.issue6203@psf.upfronthosting.co.za>


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

For some reason only LC_CTYPE is affected:

>>> locale.getlocale(locale.LC_CTYPE)
('fr_FR', 'UTF8')
>>> locale.getlocale(locale.LC_MESSAGES)
(None, None)
>>> locale.getlocale(locale.LC_TIME)
(None, None)
>>> locale.getlocale(locale.LC_NUMERIC)
(None, None)
>>> locale.getlocale(locale.LC_COLLATE)
(None, None)

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

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

From report at bugs.python.org  Mon Jun  8 18:22:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jun 2009 16:22:11 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244478131.29.0.103373396689.issue6203@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I can tell you exactly why that is, then.  I noticed this in
pythonrun.c while grepping the source:

#ifdef HAVE_SETLOCALE
        /* Set up the LC_CTYPE locale, so we can obtain
           the locale's charset without having to switch
           locales. */
        setlocale(LC_CTYPE, "");
#endif

SVN blames Martin in r56922, so this case is assigned appropriately. 
Perhaps changing only LC_CTYPE is safe?  I must admit to ignorance as to
what all the LC variables mean/control.

----------

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

From report at bugs.python.org  Mon Jun  8 18:26:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Jun 2009 16:26:26 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244478386.43.0.087759028298.issue6203@psf.upfronthosting.co.za>


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

It would still be better it is was unset afterwards. Third-party
extensions could have LC_CTYPE-dependent behaviour.

----------

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

From report at bugs.python.org  Mon Jun  8 18:34:16 2009
From: report at bugs.python.org (Robert Cronk)
Date: Mon, 08 Jun 2009 16:34:16 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244478856.59.0.345131207011.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I have a small script that reproduces the problem.  I couldn't 
reproduce it until I added some os.system() calls in the threads that 
were logging.  Here's the output using python 2.6.1:


Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 74, in emit
    if self.shouldRollover(record):
  File "C:\Python26\lib\logging\handlers.py", line 146, in 
shouldRollover
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file


Here is the script - let me know if I'm doing things incorrectly:

import os, threading, logging, logging.handlers

class LoggerThread(threading.Thread):
    def __init__(self, numLoops):
	threading.Thread.__init__(self)
	self.numLoops = numLoops


    def run(self):
	for x in range(0, self.numLoops):
	    os.system('cd.>blah.txt')
	    os.system('del blah.txt')
	    logging.debug('This is log message ' + str(x) + ' from ' + 
self.name + ' and I think this should be a little longer, so I\'ll add 
some more data here because perhaps the size of the individual log 
message is a factor.  Who knows for sure until this simple test fails.')


if __name__=="__main__":
    logSize = 2048
    numberOfLogs = 10

    files = logging.handlers.RotatingFileHandler('logthred.log', 'a', 
logSize, numberOfLogs)
    console = logging.StreamHandler()

    # set a format
    fileFormatter = logging.Formatter('%(asctime)s %(levelname)-8s %
(thread)-4s %(message)s')
    consoleFormatter = logging.Formatter('%(asctime)s %(levelname)-8s %
(thread)-4s %(message)s')

    # tell the handler to use this format
    files.setFormatter(fileFormatter)
    console.setFormatter(consoleFormatter)

    # add the handlers to the root logger
    logging.getLogger('').addHandler(files)
    logging.getLogger('').addHandler(console)
    logging.getLogger('').setLevel(logging.DEBUG)

    numThreads = 10
    numLoops = 100

    # Create and execute threads
    for x in range(0, numThreads):
	LoggerThread(numLoops).start()

----------
Added file: http://bugs.python.org/file14226/logthred.py

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

From report at bugs.python.org  Mon Jun  8 19:48:24 2009
From: report at bugs.python.org (Robert Cronk)
Date: Mon, 08 Jun 2009 17:48:24 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244483304.16.0.428638239318.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

P.S. The above script and failure is running on winxp sp3.  Also, if 
you comment out the two os.system() calls, it works just fine.  They 
seem like they should be unrelated to the logging though.  You'll also 
see some errors about access to the blah.txt file which makes sense 
since multiple threads are hitting that file at the same time.  I don't 
know if this is about using os.system() itself from multiple threads 
while logging or if it's about having an error condition during the 
os.system() call on top of that.  Anyway, let me know what you think or 
if I've done something wrong, let me know how to fix it and that might 
be good documentation for others running into this problem.  Thanks.

----------

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

From report at bugs.python.org  Mon Jun  8 20:03:06 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 08 Jun 2009 18:03:06 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244484186.22.0.136021289532.issue6135@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Mon Jun  8 20:03:13 2009
From: report at bugs.python.org (Lowell Alleman)
Date: Mon, 08 Jun 2009 18:03:13 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1244483304.16.0.428638239318.issue4749@psf.upfronthosting.co.za>
Message-ID: <839ec5810906081103v53505f5fg3bb1370bd8440ddc@mail.gmail.com>


Lowell Alleman <lowell87 at gmail.com> added the comment:

Robert, please provide the Python version and distribution that your are
using.  This should do the trick:

import sys
print sys.version

----------
Added file: http://bugs.python.org/file14227/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________
-------------- next part --------------
Robert, please provide the Python version and distribution that your are using.?? This should do the trick:<br><br>import sys<br>print sys.version<br>

From report at bugs.python.org  Mon Jun  8 20:03:20 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 08 Jun 2009 18:03:20 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244484200.62.0.0451630009104.issue6135@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
versions: +Python 2.6

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

From report at bugs.python.org  Mon Jun  8 20:08:02 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 08 Jun 2009 18:08:02 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244484482.47.0.0459396768197.issue6135@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Related discussion thread: https://answers.launchpad.net/bzr/+question/63601

----------

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

From report at bugs.python.org  Mon Jun  8 20:40:42 2009
From: report at bugs.python.org (Frans)
Date: Mon, 08 Jun 2009 18:40:42 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1244483304.16.0.428638239318.issue4749@psf.upfronthosting.co.za>
Message-ID: <33db10b30906081140k4200be06n2054c93180048632@mail.gmail.com>


Frans <Frans.van.Nieuwenhoven at gmail.com> added the comment:

Hi Robert,

Thanks, I have run the script, both on

=> Windows: '2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)]'
=> And on Ubuntu: '2.5.2 (r252:60911, Oct  5 2008, 19:24:49) \n[GCC 4.3.2]'

In both cases the problem appeared almost immediately. I've zipped the
produced log file, the script used, and the console output (files attached),
so you can see for your self.
Also, on linux the logfile is cluttered with a lot of bianry 0 values. This
is consistent with what I saw with my own script.

Regards,

Frans

2009/6/8 Robert Cronk <report at bugs.python.org>

>
> Robert Cronk <cronk.r at gmail.com> added the comment:
>
> P.S. The above script and failure is running on winxp sp3.  Also, if
> you comment out the two os.system() calls, it works just fine.  They
> seem like they should be unrelated to the logging though.  You'll also
> see some errors about access to the blah.txt file which makes sense
> since multiple threads are hitting that file at the same time.  I don't
> know if this is about using os.system() itself from multiple threads
> while logging or if it's about having an error condition during the
> os.system() call on top of that.  Anyway, let me know what you think or
> if I've done something wrong, let me know how to fix it and that might
> be good documentation for others running into this problem.  Thanks.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4749>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14228/unnamed
Added file: http://bugs.python.org/file14229/logthred-windows.zip
Added file: http://bugs.python.org/file14230/logthread-ubuntu.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________
-------------- next part --------------
Hi Robert,<br><br>Thanks, I have run the script, both on <br><br>=&gt; Windows: &#39;2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]&#39;<br>=&gt; And on Ubuntu: &#39;2.5.2 (r252:60911, Oct?? 5 2008, 19:24:49) \n[GCC 4.3.2]&#39;<br>
<br>In both cases the problem appeared almost immediately. I&#39;ve zipped the produced log file, the script used, and the console output (files attached), so you can see for your self.<br>Also, on linux the logfile is cluttered with a lot of bianry 0 values. This is consistent with what I saw with my own script. <br>
<br>Regards,<br><br>Frans<br><br><br><div class="gmail_quote">2009/6/8 Robert Cronk <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
Robert Cronk &lt;<a href="mailto:cronk.r at gmail.com">cronk.r at gmail.com</a>&gt; added the comment:<br>
<br>
</div>P.S. The above script and failure is running on winxp sp3. ??Also, if<br>
you comment out the two os.system() calls, it works just fine. ??They<br>
seem like they should be unrelated to the logging though. ??You&#39;ll also<br>
see some errors about access to the blah.txt file which makes sense<br>
since multiple threads are hitting that file at the same time. ??I don&#39;t<br>
know if this is about using os.system() itself from multiple threads<br>
while logging or if it&#39;s about having an error condition during the<br>
os.system() call on top of that. ??Anyway, let me know what you think or<br>
if I&#39;ve done something wrong, let me know how to fix it and that might<br>
be good documentation for others running into this problem. ??Thanks.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue4749" target="_blank">http://bugs.python.org/issue4749</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logthred-windows.zip
Type: application/zip
Size: 14096 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090608/8f86bcfc/attachment-0002.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logthread-ubuntu.zip
Type: application/zip
Size: 11691 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20090608/8f86bcfc/attachment-0003.zip>

From report at bugs.python.org  Mon Jun  8 20:53:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jun 2009 18:53:16 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244487196.94.0.174877268599.issue6208@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So is this a cosmetic issue or a functional issue?  Either way, it is a
feature request and I've updated the issue to reflect that.

If you want to look at the code, ntpath.py is probably the relevant module.

----------
priority: normal -> low
resolution: invalid -> 
stage: committed/rejected -> 
type: behavior -> feature request
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun  8 21:01:45 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 08 Jun 2009 19:01:45 +0000
Subject: [issue6240] API to get source encoding as defined by PEP 263
In-Reply-To: <1244487704.55.0.771864398626.issue6240@psf.upfronthosting.co.za>
Message-ID: <1244487704.55.0.771864398626.issue6240@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

It'd be nice to get the encoding used by a specific Python file.
Considering that 'print' uses sys.stdout.encoding which is always set to
None when the Python process is run by subprocess, knowing the source
encoding is absolutely necessary in decoding the output generated by
that script.

eg: Run 'python setup.py --author' in the python-wifi-0.3.1 source
package as a subprocess.Popen(...) call.. and print the stdout.read()
string; you'll get encoding error.. unless you do
stdout.read().decode('latin1') .. where latin1 is specified as a coding:
line in setup.py.

The following function tries to detect the coding, but this guess work
not necessary when this is integrated with the standard library whose
implementation maps directly to that of PEP 263.

+def get_python_source_encoding(python_file):
+    """Detect the encoding used in the file ``python_file``
 
+    Detection is done as per http://www.python.org/dev/peps/pep-0263/
+    """
+    first_two_lines = open(python_file).readlines()[:2]
+    coding_line_regexp = ".*coding[:=]\s*([-\w.]+).*"
+
+    for line in first_two_lines:
+        m = re.match(coding_line_regexp, line)
+        if m:
+            return m.group(1)
+
+    # if no encoding is defined, use the default encoding
+    return 'ascii'

ref:
subprocess encoding mess: http://bugs.python.org/issue6135

----------
components: Interpreter Core, Library (Lib)
messages: 89097
nosy: lemburg, loewis, srid
severity: normal
status: open
title: API to get source encoding as defined by PEP 263
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jun  8 21:02:38 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Jun 2009 19:02:38 +0000
Subject: [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
In-Reply-To: <4A2CC63A.2060206@egenix.com>
Message-ID: <4A2D569E.5080406@udel.edu>


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

If you write a patch, you are free to include the additional change.

----------

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

From report at bugs.python.org  Mon Jun  8 21:05:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Jun 2009 19:05:03 +0000
Subject: [issue6240] API to get source encoding as defined by PEP 263
In-Reply-To: <1244487704.55.0.771864398626.issue6240@psf.upfronthosting.co.za>
Message-ID: <1244487903.78.0.235504891261.issue6240@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Already done. tokenize.detect_encoding()

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

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

From report at bugs.python.org  Mon Jun  8 21:06:44 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 08 Jun 2009 19:06:44 +0000
Subject: [issue1944] Documentation for PyUnicode_AsString (et al.) missing.
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1244488004.81.0.579807928415.issue1944@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The patch looks alright. I don't like the documentation for
PyUnicode_FromFormatV, however. Here's my attempt to document it:

.. cfunction:: PyObject* PyUnicode_FromFormatV(const char *format,
va_list vargs)

   Equivalent to the function :cfunc:`PyUnicode_FromFormat`, except that
it takes a va_list instead of variable number of arguments.

----------

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

From report at bugs.python.org  Mon Jun  8 21:39:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Jun 2009 19:39:30 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244478386.43.0.087759028298.issue6203@psf.upfronthosting.co.za>
Message-ID: <4A2D68EE.9020603@v.loewis.de>


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

> It would still be better it is was unset afterwards. Third-party
> extensions could have LC_CTYPE-dependent behaviour.

In principle, they could, yes - but what specific behavior might that
be? What will change is character classification, which I consider
fairly harmless. Also, multi-byte conversion routines will change, which
is the primary reason for leaving it modified.

----------
title: 3.x locale does not default to C, contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C,	contrary to the documentation and to 2.x behavior

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

From report at bugs.python.org  Mon Jun  8 21:43:10 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Jun 2009 19:43:10 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <4A2D68EE.9020603@v.loewis.de>
Message-ID: <1244490329.5399.7.camel@localhost>


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

> In principle, they could, yes - but what specific behavior might that
> be? What will change is character classification, which I consider
> fairly harmless. Also, multi-byte conversion routines will change, which
> is the primary reason for leaving it modified.

Ok, so I suppose we could leave the code as-is.

----------
title: 3.x locale does not default to C,	contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C, contrary to the documentation and to 2.x behavior

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

From report at bugs.python.org  Mon Jun  8 21:45:52 2009
From: report at bugs.python.org (Robert Cronk)
Date: Mon, 08 Jun 2009 19:45:52 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244490352.82.0.676341337077.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

>>> import sys
>>> print sys.version
2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit (Intel)]

I have seen this behavior in older versions as well.  Interesting to 
see it fail in linux as well.

----------

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

From report at bugs.python.org  Mon Jun  8 21:47:02 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 08 Jun 2009 19:47:02 +0000
Subject: [issue6241] Better type checking for the arguments of io.StringIO
In-Reply-To: <1244490422.03.0.396715163252.issue6241@psf.upfronthosting.co.za>
Message-ID: <1244490422.03.0.396715163252.issue6241@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

The included patch makes type checking of the arguments of StringIO
consistent between pyio and io.

>>> import io
>>> io.StringIO(b"hello")
Traceback (most recent call last):
  ...
ValueError: initial_value must be str or None, not bytes
>>> io.StringIO(newline=b"\n")
<_io.StringIO object at 0x7f93d52953d0>
>>> import _pyio as pyio
>>> pyio.StringIO(newline=b"\n")
Traceback (most recent call last):
  ...
TypeError: illegal newline type: <class 'bytes'>

>>> io.StringIO([])
Traceback (most recent call last):
  ...
ValueError: initial_value must be str or None, not list
>>> pyio.StringIO([])
<_pyio.StringIO object at 0x7f93d4942610>

----------
components: IO, Library (Lib)
files: typecheck_init_stringio.diff
keywords: patch
messages: 89104
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Better type checking for the arguments of io.StringIO
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14231/typecheck_init_stringio.diff

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

From report at bugs.python.org  Mon Jun  8 21:51:37 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 08 Jun 2009 19:51:37 +0000
Subject: [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

io.StringIO does not clear its reference to its attributes dictionary
when deleted. This causes a leak when io.StringIO has attributes. 

>>> def leak():
...    for _ in range(100):
...      f = io.StringIO()
...      f.foo = 1
... 
[39348 refs]
>>> leak()
[39650 refs]
>>> leak()
[39950 refs]
>>> leak()
[40250 refs]

----------
components: IO, Library (Lib)
files: fix_refleak_stringio.diff
keywords: patch
messages: 89105
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Fix reference leak in io.StringIO
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14232/fix_refleak_stringio.diff

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

From report at bugs.python.org  Mon Jun  8 22:09:34 2009
From: report at bugs.python.org (nestor)
Date: Mon, 08 Jun 2009 20:09:34 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1244491774.67.0.30778987442.issue6236@psf.upfronthosting.co.za>


nestor <nestornissen at gmail.com> added the comment:

This quick and dirty fix in pydoc.py makes so it no longer aborts help.

(less behaves somewhat strange for some commands but that is better than
no help at all)

def pipepager(text, cmd):
    """Page through text by feeding it to another program."""
    import subprocess
    pipe=subprocess.Popen(cmd,stdin=subprocess.PIPE).stdin
    #pipe = os.popen(cmd, 'w')
    try:
        pipe.write(bytes(text,sys.getdefaultencoding()))
        #pipe.write(text)
        pipe.close()
    except IOError:
        pass # Ignore broken pipes caused by quitting the pager program.

----------

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

From report at bugs.python.org  Mon Jun  8 22:10:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Jun 2009 20:10:45 +0000
Subject: [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1244491845.3.0.414277276885.issue6242@psf.upfronthosting.co.za>


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

It seems wrong to call PyObject_ClearWeakRefs() in stringio_clear().
Weakrefs should only be notified when the object is deallocated, not
cleared.
Besides, you should add a test for this, so that the leak can be spotted
with regrtest -R.

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

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

From report at bugs.python.org  Mon Jun  8 22:18:11 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 08 Jun 2009 20:18:11 +0000
Subject: [issue6218] Make io.BytesIO and io.StringIO picklable.
In-Reply-To: <1244254875.51.0.0941712294298.issue6218@psf.upfronthosting.co.za>
Message-ID: <1244492291.93.0.0719499520703.issue6218@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I split the bug fixes in the patch into two separate issues. It looks
like pickling support for io.StringIO and io.BytesIO will have to wait
for 3.2.

----------
dependencies: +Better type checking for the arguments of io.StringIO
Added file: http://bugs.python.org/file14233/pickle_support_for_memoryio-2.diff

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

From report at bugs.python.org  Mon Jun  8 22:27:45 2009
From: report at bugs.python.org (Lowell Alleman)
Date: Mon, 08 Jun 2009 20:27:45 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1244490352.82.0.676341337077.issue4749@psf.upfronthosting.co.za>
Message-ID: <839ec5810906081327u2b2a535bl84e516adfd615d95@mail.gmail.com>


Lowell Alleman <lowell87 at gmail.com> added the comment:

I tested this against a number of different python installs that I
have laying around.  Here are the results that I found:

Releases that reproduce this bug:

Python 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
Python 2.4.5 (#2, Jul 31 2008, 18:51:48) [GCC 4.2.3 (Ubuntu
4.2.3-2ubuntu7)] on linux2  (Ubuntu 8.04)
Python 2.4.6 (#2, Mar 19 2009, 10:00:53) [GCC 4.3.3] on linux2 (Ubuntu 9.04)
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on win32

The following release worked fine:
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu
4.2.3-2ubuntu7)] on linux2 (Ubuntu 8.04)
Python 2.5.4 (r254:67916, Apr  4 2009, 17:55:16) [GCC 4.3.3] on linux2
(Ubuntu 9.04)
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on
linux2 (Ubuntu 9.04)

----------

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

From report at bugs.python.org  Mon Jun  8 22:35:08 2009
From: report at bugs.python.org (Robert Cronk)
Date: Mon, 08 Jun 2009 20:35:08 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244493308.79.0.105346373736.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

P.S.  Frans - It's good to get these other data points from you.  So 
this is reproducible from another person and on different versions of 
python AND on different platforms!  I wasn't expecting that at all.  
Thanks Frans.

Is there a way we can reopen this bug?  I couldn't find a way to change 
its status now that we seem to have a reproducible case.  Perhaps Vinay 
is authorized to do so.

----------

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

From report at bugs.python.org  Mon Jun  8 22:36:14 2009
From: report at bugs.python.org (Trundle)
Date: Mon, 08 Jun 2009 20:36:14 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>


New submission from Trundle <andy-python at hammerhartes.de>:

Snippet to reproduce:

import curses

scr = curses.initscr()
curses.ungetch(1025)
scr.getkey()

This is because `keyname()` in `PyCursesWindow_GetKey()` returns NULL
which is passed to `PyString_FromString()` then.

The attached patch fixes the segfault.

----------
components: Library (Lib)
files: python_curses_ungetch_getkey.patch
keywords: patch
messages: 89111
nosy: Trundle
severity: normal
status: open
title: getkey() can segfault in combination with curses.ungetch()
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file14234/python_curses_ungetch_getkey.patch

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

From report at bugs.python.org  Mon Jun  8 22:39:31 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Mon, 08 Jun 2009 20:39:31 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1244493571.15.0.291425540831.issue4953@psf.upfronthosting.co.za>


Timothy Farrell <tfarrell at swgen.com> added the comment:

I've attached unittest.zip.  Simply unzip it to a directory and run it.
 I've included a Python2.x version of the unittest for the sake of
clarity.  The 2.x version was developed on 2.4.  The 3.x version was
developed on 3.0.1 and 3.1rc1 (with identical results).

It seems that there are several issues with cgi.FieldStorage and
multi-part form data.

- Does Formstation read in a Bytes or String?
-- It seems to expect a String but this yields invalid results for
uploading files.
-- A stream of Bytes would make more sense but loses it Pythonic
"Batteries included" nature if the user has to decode the encoding
manually for each form field.

----------
Added file: http://bugs.python.org/file14235/unittest.zip

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

From report at bugs.python.org  Mon Jun  8 22:48:49 2009
From: report at bugs.python.org (Robert Cronk)
Date: Mon, 08 Jun 2009 20:48:49 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244494129.16.0.805183331899.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

Thanks Lowell - good information.  You have many more versions of 
Python "laying around" than I do.  ;)

----------

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

From report at bugs.python.org  Mon Jun  8 22:54:53 2009
From: report at bugs.python.org (Sebastian Ramacher)
Date: Mon, 08 Jun 2009 20:54:53 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1244494493.58.0.0761399691927.issue6243@psf.upfronthosting.co.za>


Changes by Sebastian Ramacher <sebastinas at users.sourceforge.net>:


----------
nosy: +sebastinas

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

From report at bugs.python.org  Mon Jun  8 23:17:28 2009
From: report at bugs.python.org (Robert Cronk)
Date: Mon, 08 Jun 2009 21:17:28 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244495848.14.0.822304346116.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I just upgraded to 2.6.2 windows from python.org and it fails as well:

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit 
(Intel)] on win32

I hope Vinay can track this down in case it's a race condition that's 
just moving around between versions or track it down to something 
concrete that has actually been purposefully fixed somewhere else that 
fixes this too.  I guess we'll see.

Lowell - what's the difference between my 2.6.2 shown above and yours 
(release26-maint, Apr 19 2009)?  Yours is on ubuntu and mine is on 
windows, but I'm not familiar with the two version types (r262:71605 
vs. release26-maint).  Yours is 5 days newer - is it a patch?  What was 
changed in it that might affect this problem?  Just wondering aloud 
until Vinay can help make sense of all of this.  Thanks everyone.

----------

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

From report at bugs.python.org  Mon Jun  8 23:20:51 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 08 Jun 2009 21:20:51 +0000
Subject: [issue3816] __newobj__ pickle feature is not documented
In-Reply-To: <1220962394.03.0.479554047795.issue3816@psf.upfronthosting.co.za>
Message-ID: <1244496051.28.0.786689731931.issue3816@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Closing as the feature is documented in the section "The __newobj__
unpickling function" of PEP 307.

----------
assignee: georg.brandl -> 
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3816>
_______________________________________

From report at bugs.python.org  Mon Jun  8 23:23:26 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Jun 2009 21:23:26 +0000
Subject: [issue5809] "No such file or directory" with framework build under
	MacOS 10.4.11
In-Reply-To: <1240329712.27.0.0341104214309.issue5809@psf.upfronthosting.co.za>
Message-ID: <1244496206.12.0.891535418444.issue5809@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r73305 (trunk), r73306 (2.6) and r73307 (3.1) 

That is, with the above mentioned checkins configure will give a clear 
error message when you specify both --enable-framework and --enable-
shared.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5809>
_______________________________________

From report at bugs.python.org  Mon Jun  8 23:35:03 2009
From: report at bugs.python.org (Michael Scherer)
Date: Mon, 08 Jun 2009 21:35:03 +0000
Subject: [issue6244] Support for tcl 8.6
In-Reply-To: <1244496903.79.0.308106230348.issue6244@psf.upfronthosting.co.za>
Message-ID: <1244496903.79.0.308106230348.issue6244@psf.upfronthosting.co.za>


New submission from Michael Scherer <misc at mandriva.org>:

It seems that python do not compile with tcl 8.6. Here is a patch, done
by Adam Williamson, to add this version in the supported list. We are
using on mandriva since 6 months without trouble, so I think this is
safe to include. The patch is against version 2.6.3, but I can rediff if
needed.

----------
components: Installation
files: python-2.5-tcl86.patch
keywords: patch
messages: 89117
nosy: misc
severity: normal
status: open
title: Support for tcl 8.6
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14236/python-2.5-tcl86.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6244>
_______________________________________

From report at bugs.python.org  Mon Jun  8 23:35:39 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Jun 2009 21:35:39 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Apple just announced that MacOSX 10.6 ("Snow Leopard") will be released 
in September, and will only support intel systems.

This means that the --with-universal-archs option is not 100% usable if 
you want to build a version of Python that specifically targets this 
release of the OS.

The attached patch adds the option '--with-universal-archs=intel', which 
will build a 32-bit/64-bit framework for intel systemsn (that is i386 
and x86_64). 

Note: the patch is for the trunk, I'll port it to 3.x after review.

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: arch-intel.patch
keywords: needs review, patch
messages: 89118
nosy: ronaldoussoren
severity: normal
status: open
title: Add "intel" universal architecture on OSX
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14237/arch-intel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Mon Jun  8 23:42:00 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jun 2009 21:42:00 +0000
Subject: [issue6244] Support for tcl 8.6
In-Reply-To: <1244496903.79.0.308106230348.issue6244@psf.upfronthosting.co.za>
Message-ID: <1244497320.81.0.292409530067.issue6244@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/issue6244>
_______________________________________

From report at bugs.python.org  Mon Jun  8 23:51:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Jun 2009 21:51:34 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1244497894.32.0.179895578637.issue6245@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What do you mean by "not 100% usable"? I would hope that a four-way
binary still works just fine, no? So what are the restrictions?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Mon Jun  8 23:51:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jun 2009 21:51:51 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244497911.49.0.59535679261.issue6203@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since it controls what is considered to be whitespace, it is possible
this will lead to subtle bugs, but I agree that it seems relatively
benign, especially considering 3.x's unicode orientation.  So, this
becomes a doc bug...

----------
components:  -Library (Lib)
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Mon Jun  8 23:55:02 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 08 Jun 2009 21:55:02 +0000
Subject: [issue6244] Support for tcl 8.6
In-Reply-To: <1244496903.79.0.308106230348.issue6244@psf.upfronthosting.co.za>
Message-ID: <1244498102.65.0.442813670529.issue6244@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This is a bit misleading. Python supports compiling with Tcl 8.6 and
Tkinter (and _tkinter) will work (or at least should work) with it, what
is not supported are tcl/tk versions below 8.3.1.

I'm ok with with patching setup.py to add this "support" for everyone
else, I have compiled python with tcl 8.6 before but didn't bother
suggesting this change in setup.py. Anyway, just came here to try to
clear this up and say there is nothing in python saying it doesn't
support tcl 8.6 (hope this helps anyone that got confused and thought
tcl 8.6 wasn't really supported by python).

----------
nosy: +gpolo
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6244>
_______________________________________

From report at bugs.python.org  Tue Jun  9 00:12:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Jun 2009 22:12:13 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244499133.71.0.959266348529.issue4749@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
status: closed -> open
type: crash -> behavior
versions:  -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 00:48:41 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 08 Jun 2009 22:48:41 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244501321.03.0.91437144788.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I did some tests on the zip files which Frans attached to this post. The
reason you are getting errors is at least partly that you are not
following best practices in the test scripts. Specifically, the threads
are making system calls to update and delete blah.txt without handling
contention between them. Also, you are not joining on the created
threads before exiting the main thread, which means that the atexit code
will be invoked while the threads are still running. This is nothing
specifically to do with logging, except that logging registers an atexit
handler to close open files etc. So, you need to join the created threads.

I also found some mixture of tabs and spaces in the scripts Frans attached.

So, you need to test with the modified script which I am attaching here.
This script runs without problems on Ubuntu (Hardy/Python 2.5.2 built
Jul 31 2008 17:28:52 and Jaunty 2.6.2 built on Apr 19 2009 01:56:41).
There is still a problem on Windows, which appears to be related to an
error in os.rename. I am investigating this further to see if it is a
logging bug.

----------
resolution: works for me -> 
status: open -> pending
Added file: http://bugs.python.org/file14238/revised-logthred.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 00:50:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jun 2009 22:50:25 +0000
Subject: [issue4254] _cursesmodule.c callable update_lines_cols()
In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
Message-ID: <1244501425.76.0.754476420988.issue4254@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/issue4254>
_______________________________________

From report at bugs.python.org  Tue Jun  9 01:06:41 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 08 Jun 2009 23:06:41 +0000
Subject: [issue6246] Python bebugger ignores exception if instructed to return
	from generator
In-Reply-To: <1244502401.73.0.647401575179.issue6246@psf.upfronthosting.co.za>
Message-ID: <1244502401.73.0.647401575179.issue6246@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

I get this debugger session with the attached file. Note that even
though a NameError occurs, no indication of that error is visible on the
debugger conosle.
8< -----------------------------------------------------------------
$ python -m pdb pdb_bug.py
> /home/andreas/tmp/pdb_bug.py(1)<module>()
-> def f():
(Pdb) n
> /home/andreas/tmp/pdb_bug.py(6)<module>()
-> list(f())
(Pdb) s
--Call--
> /home/andreas/tmp/pdb_bug.py(1)f()
-> def f():
(Pdb) n
> /home/andreas/tmp/pdb_bug.py(2)f()
-> print "BLAH"
(Pdb) r
BLAH
--Return--
> /home/andreas/tmp/pdb_bug.py(3)f()->None
-> bogus
(Pdb)

----------
components: Library (Lib)
files: pdb_bug.py
messages: 89123
nosy: inducer
severity: normal
status: open
title: Python bebugger ignores exception if instructed to return from generator
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file14239/pdb_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6246>
_______________________________________

From report at bugs.python.org  Tue Jun  9 01:33:04 2009
From: report at bugs.python.org (Robert Cronk)
Date: Mon, 08 Jun 2009 23:33:04 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244503984.79.0.952782425174.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I didn't care about the os.system() call contention because that's what 
caused the logging problem and that blah.txt file contention should not 
cause logging to fail.

I also had the join calls originally but took them out to simplify the 
code since it seemed to run correctly either way - if this were 
production code, I'd have left them in.

The revised script works for me on windows 2.6.2 (the version I 
upgraded to) but I think it just puts locks around the problem and 
masks the true problem out.  It appears something in os.system() is 
crashing logging and that shouldn't happen.  If locks need to be 
placed, they should be placed around the problem within os.system() or 
within logging, if needed.

Please take the locks off the os.system() calls and see why logging is 
failing when those calls are made.  Remember, this is a test script I 
wrote from scratch with the express purpose of making logging fail from 
multiple threads so you could catch it in a debugger or something.  
Changing the script to make it work misses the point.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 01:39:31 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 08 Jun 2009 23:39:31 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244504371.98.0.00628099753493.issue4749@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Removed file: http://bugs.python.org/file14238/revised-logthred.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 01:42:18 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jun 2009 23:42:18 +0000
Subject: [issue5377] Strange behavior when performing int on a Decimal made
	from -sys.maxint-1
In-Reply-To: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
Message-ID: <1244504538.22.0.973018544293.issue5377@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Thanks, Victor

You're welcome :-)

> - I'm getting a test failure in test_class

fixed

> - you should probably be using sys.maxint rather than sys.maxsize

done

> This still doesn't fix the case of int(Fraction(2L))

fixed: Fraction uses __trunc__ rather than __int__.

See updated patch: force_int-4.patch

----------
Added file: http://bugs.python.org/file14240/force_int-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5377>
_______________________________________

From report at bugs.python.org  Tue Jun  9 01:42:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Jun 2009 23:42:23 +0000
Subject: [issue5377] Strange behavior when performing int on a Decimal made
	from -sys.maxint-1
In-Reply-To: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
Message-ID: <1244504543.53.0.341055542709.issue5377@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file13456/force_int-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5377>
_______________________________________

From report at bugs.python.org  Tue Jun  9 01:43:42 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 08 Jun 2009 23:43:42 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244504622.59.0.247206713222.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Whoops, my revised test script still had some tabs. Replacing. Further
information on Windows - you sometimes get error 32 (cannot rename file
because owned by another process) because of anti-virus or Windows
indexing software having the file open. Can you please retry on Windows
but with anti-virus software and Windows indexing temporarily turned off
during the test? (On Windows you'll have to rename "rm" to "del" in the
os.system() call.

----------
status: open -> pending
Added file: http://bugs.python.org/file14241/revised-logthred.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 01:51:33 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 08 Jun 2009 23:51:33 +0000
Subject: [issue6246] Python debugger ignores exception if instructed to return
	from generator
In-Reply-To: <1244502401.73.0.647401575179.issue6246@psf.upfronthosting.co.za>
Message-ID: <1244505093.06.0.860854058266.issue6246@psf.upfronthosting.co.za>


Changes by Andreas Kloeckner <inform at tiker.net>:


----------
title: Python bebugger ignores exception if instructed to return from generator -> Python debugger ignores exception if instructed to return from generator

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6246>
_______________________________________

From report at bugs.python.org  Tue Jun  9 02:02:26 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Jun 2009 00:02:26 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244505746.59.0.886251694085.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

On Ubuntu, without the locks around the os.system calls, I was not
getting any errors other than file-not-found errors on blah.txt - which
you would expect if another thread had just deleted the file. You didn't
post the errors which your test script was generating - and I assumed
you may have been referring to the file-not-founds on blah.txt.

You definitely need the join calls, as without them atexit processing in
the main thread will close the handlers when the threads are still
running. This will lead to errors like the ones you saw (I/O operation
on closed file), but this is not a bug - you definitely need to join on
all created threads before exiting the main thread - whether test or
production.

Please post the exact errors you are getting, after removing the locks
around the os.system calls. Delete all logthred.log files before the
test run, and please post the console output as Frans did. As I said in
my earlier comment - ensure that anti-virus, Windows indexing and any
other software which may open files at non-deterministic times is
disabled. If you are seeing a WindowsError with an error code of 32
(this might get lost in all the other output, but it's the first error I
found - the other messages look like they are a consequence of that
initial error).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 02:11:55 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Jun 2009 00:11:55 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244506315.49.0.908214649579.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The last sentence in my last comment got truncated  - it's getting late
here ;-)

I meant to say: If you are seeing a WindowsError with an error code of 32
(this might get lost in all the other output, but it's the first error I
found - the other messages look like they are a consequence of that
initial error), then it looks as if *something* is definitely holding
the file open and that's why logging is failing. We just need to find
out what it is, maybe you can use the Sysinternals tools from Microsoft
(e.g. procexp, handle) to see what's holding the file open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 02:17:29 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Jun 2009 00:17:29 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1244506649.55.0.999838825206.issue6245@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The details of snow leopard are under NDA, but based on public 
information :

* Snow Leopard will only support Intel-based systems

* Apple's "rosetta" dynamaic translation subsystem for running PPC code 
on an intel system only supports 32-bit PPC code.

There is therefore no reason to include 64-bit PPC code in builds for 
Snow Leopard, and I wouldn't be surprised if SL would ship without 64-
bit PPC code in system frameworks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Tue Jun  9 02:18:17 2009
From: report at bugs.python.org (Michael Newman)
Date: Tue, 09 Jun 2009 00:18:17 +0000
Subject: [issue4309] ctypes documentation
In-Reply-To: <1226523194.83.0.190505447778.issue4309@psf.upfronthosting.co.za>
Message-ID: <1244506697.59.0.346538865983.issue4309@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

Watch out on Line 247 of r73293:
"bytes objcet"
should be:
"bytes object"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4309>
_______________________________________

From report at bugs.python.org  Tue Jun  9 02:47:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Jun 2009 00:47:40 +0000
Subject: [issue2947] subprocess (Replacing popen) - add a warning / hint
In-Reply-To: <1211469479.53.0.83820029984.issue2947@psf.upfronthosting.co.za>
Message-ID: <1244508460.01.0.54925761556.issue2947@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied (with spacing fix) in r73313.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2947>
_______________________________________

From report at bugs.python.org  Tue Jun  9 06:32:23 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Jun 2009 04:32:23 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244506649.55.0.999838825206.issue6245@psf.upfronthosting.co.za>
Message-ID: <4A2DE5C8.40100@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The details of snow leopard are under NDA, but based on public 
> information :

This is all fine, and really not surprising. My question is:
Why is that causing limited usability? I would expect that
Snow Leopard just ignores the PPC bits in the universal binaries,
and just accesses the x86 bits. The binaries might be larger
than necessary; people bothered by that could easily strip them
using ditto (IIUC).

I'm fine with an option of not building the PPC bits - I'm
just puzzled by the claim that, without the patch, it will
not be "100% usable".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Tue Jun  9 07:17:40 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 09 Jun 2009 05:17:40 +0000
Subject: [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1244524660.61.0.613574686166.issue6242@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here's an updated patch. The new patch also cleans up tp_clear,
tp_traverse and tp_dealloc of io.BytesIO which used weakreflist incorrectly.

I also added support for test_memoryio for adding reference leak
regression tests. As you'll see, the support is a bit heavyweight for
the only test case there. So perhaps I could change this to something
simpler.

----------
Added file: http://bugs.python.org/file14242/fix_refleak_stringio-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6242>
_______________________________________

From report at bugs.python.org  Tue Jun  9 08:40:28 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Tue, 09 Jun 2009 06:40:28 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>


New submission from Ritesh Raj Sarraf <rrs at researchut.com>:

Shoudl argparse be included in the Python Standard Library.

I know we already have getopt and optparse but optparse doesn't
support many features easily. (like options without hyphen, nargs=*)

Here a little about argparse:


argparse: Python command line parser
The argparse module makes writing command line tools in Python easy.
Just briefly describe your command line interface and argparse will take
care of the rest, including: 
parsing the arguments and flags from sys.argv 
converting arg strings into objects for your program 
formatting and printing any help messages 
and much more ... 
For those familiar with the optparse module from the Python standard
library, argparse improves on this module in a number of ways, including: 
handling positional arguments 
supporting sub-commands 
allowing alternative option prefixes like + and / 
handling zero-or-more and one-or-more style arguments 
producing more informative usage messages 
providing a much simpler interface for custom types and actions

----------
components: Extension Modules
messages: 89134
nosy: rickysarraf
severity: normal
status: open
title: should we include argparse
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Jun  9 08:54:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Jun 2009 06:54:53 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244530493.14.0.677615126987.issue6247@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

One important prerequisite for including it is that the author of the
code contributes it for inclusion (irrespective of any license that may
allow us to fork the code), and that he, or somebody else, volunteers to
maintain it.

IIUC, you are not the author, so I have to reject this request.

If you find that some features are lacking in optparse, please provide
patches to enhance it.

----------
nosy: +loewis
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Jun  9 09:10:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Jun 2009 07:10:26 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244531426.66.0.277670424368.issue6203@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

To add a little bit more analysis: posix.device_encoding requires that
the LC_CTYPE is set. Setting it just in this function would not be
possible, as setlocale is not thread-safe.

So for 3.1, it seems that Python must set LC_CTYPE. If somebody can
propose a patch that avoids that for 3.2, I'd be certainly in favor.

----------
assignee: loewis -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Tue Jun  9 09:20:38 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Jun 2009 07:20:38 +0000
Subject: [issue5623] test_fdopen fails with vs2005,
	release build on Windows 2000
In-Reply-To: <1238513083.42.0.065691454167.issue5623@psf.upfronthosting.co.za>
Message-ID: <1244532038.19.0.160120754193.issue5623@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why is this still open?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5623>
_______________________________________

From report at bugs.python.org  Tue Jun  9 09:59:43 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Tue, 09 Jun 2009 07:59:43 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244534383.96.0.277866670603.issue6247@psf.upfronthosting.co.za>


Ritesh Raj Sarraf <rrs at researchut.com> added the comment:

>From the author, Steven Berthard:
====================
Sorry about the delay - conferences and moving means that I haven't
had as much time for argparse as I'd like. Basically, the way things
get into the Python standard library is if a large enough community
requests it. I'm happy to contribute (and support) it if there's
enough demand, though since Python 3.1b1 is already out, the earliest
releases that might include it would be Python 2.7 and 3.2.
====================


>From the conversation I have had with the author, he does seem to be
interested in it. I'll ask the author to respond to this bug report.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Jun  9 10:09:23 2009
From: report at bugs.python.org (rubisher)
Date: Tue, 09 Jun 2009 08:09:23 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1244534963.29.0.174796001599.issue6006@psf.upfronthosting.co.za>


rubisher <rubisher at scarlet.be> added the comment:

Just to mention the same issue for Python-2.6.2 and gcc-4.2.0 on aix 
5.3 too.

----------
nosy: +rubisher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6006>
_______________________________________

From report at bugs.python.org  Tue Jun  9 10:36:52 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 09 Jun 2009 08:36:52 +0000
Subject: [issue5623] test_fdopen fails with vs2005,
	release build on Windows 2000
In-Reply-To: <1238513083.42.0.065691454167.issue5623@psf.upfronthosting.co.za>
Message-ID: <1244536612.83.0.46595792373.issue5623@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Closing this defect, as the issues seems worked around on our end.

Btw, here is the issue on Microsoft's end.  They've marked it as "won't 
fix".
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
FeedbackID=409955&wa=wsignin1.0

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5623>
_______________________________________

From report at bugs.python.org  Tue Jun  9 11:32:40 2009
From: report at bugs.python.org (John Szakmeister)
Date: Tue, 09 Jun 2009 09:32:40 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1244539960.63.0.714075009226.issue6245@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

I think Ronald is trying to say that a 10.6 SDK is likely not to support
building 64-bit binaries at all for the PPC (since there won't be 64-bit
versions of the supporting libraries).  So you need this patch, if
you're going to build against it.  I don't think he's trying to claim
that fat binaries won't run if there is 64-bit PPC code in them.  FWIW,
it's the --with-universal-archs option that he said wasn't 100% usable,
not the binaries.

----------
nosy: +jszakmeister

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Tue Jun  9 11:34:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Jun 2009 09:34:24 +0000
Subject: [issue5924] When setting complete PYTHONPATH on Python 3.x,
	paths in the PYTHONPATH are ignored
In-Reply-To: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>
Message-ID: <1244540064.79.0.525565791442.issue5924@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a patch: fix+test.

I left the initial code, #ifdef'd for PC platforms different than
MS_WINDOWS. Just in case someone wants to port py3k to OS/2...

----------
keywords: +patch
Added file: http://bugs.python.org/file14243/large_pythonpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Tue Jun  9 12:43:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jun 2009 10:43:42 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1244544222.56.0.586586836376.issue6203@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6203>
_______________________________________

From report at bugs.python.org  Tue Jun  9 13:09:46 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jun 2009 11:09:46 +0000
Subject: [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1244545786.09.0.818687904076.issue6242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why do you need all this? Isn't it enough to take a weakref and check
the callback is triggered?
(besides, we should avoid tests which only work in debug mode)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6242>
_______________________________________

From report at bugs.python.org  Tue Jun  9 13:18:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jun 2009 11:18:55 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1244546335.01.0.587251074243.issue6006@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

AIX doesn't seem listed in the platforms supported by libffi.
http://sourceware.org/libffi/ suggests you send platform test results to
libffi-discuss at sourceware.org

On the other hand, perhaps the libffi version which comes with Python is
outdated.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6006>
_______________________________________

From report at bugs.python.org  Tue Jun  9 14:41:33 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 09 Jun 2009 12:41:33 +0000
Subject: [issue6198] test_float fails on Windows
In-Reply-To: <1244180782.5.0.462809934135.issue6198@psf.upfronthosting.co.za>
Message-ID: <1244551293.21.0.312091856428.issue6198@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

In r73314, I restored the one test erroneously removed ("%#.0f 1.5 -> 2.").

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6198>
_______________________________________

From report at bugs.python.org  Tue Jun  9 14:58:09 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 09 Jun 2009 12:58:09 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <20090609125757.GB15612@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

I hope you read this thread which discusses the same issue.

* http://mail.python.org/pipermail/python-list/2007-January/592646.html

MvL,effbot and jjlee had shared their views to the original author of
argparse module. It did not go anywhere from there.

I see that this issue might be rejected unless followed the steps as
mentioned in that mail thread.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Jun  9 15:02:17 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Jun 2009 13:02:17 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244552537.73.0.847156030373.issue6247@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Jun  9 15:43:11 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 09 Jun 2009 13:43:11 +0000
Subject: [issue6096] SimpleXMLRPCServer not suitable for HTTP/1.1 keep-alive
In-Reply-To: <1243184810.28.0.183866106023.issue6096@psf.upfronthosting.co.za>
Message-ID: <1244554991.58.0.183984328509.issue6096@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is a better patch.
Remove the individual flush() operations from the implementation classes, 
rather do it in the BaseHTTPRequestHandler().  This allows any request 
handler to be write buffered.

----------
Added file: http://bugs.python.org/file14244/xmlsrv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6096>
_______________________________________

From report at bugs.python.org  Tue Jun  9 16:23:13 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Tue, 09 Jun 2009 14:23:13 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244557393.18.0.385803323002.issue6247@psf.upfronthosting.co.za>


Ritesh Raj Sarraf <rrs at researchut.com> added the comment:

Thanks for the link. As a user, I see many of the features that argparse
brings, to be helpful.

Since they are missing in optparse, and since it doesn't look like
argparse will be included, should I open new bugs for those features
against optparse ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Jun  9 17:17:10 2009
From: report at bugs.python.org (Lisandro Dalcin)
Date: Tue, 09 Jun 2009 15:17:10 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244560630.86.0.653728692812.issue6195@psf.upfronthosting.co.za>


Lisandro Dalcin <dalcinl at gmail.com> added the comment:

I've tested latest David's patch against Cython test suite (doctests
living in extension modules), and all is working as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6195>
_______________________________________

From report at bugs.python.org  Tue Jun  9 18:08:07 2009
From: report at bugs.python.org (Robert Cronk)
Date: Tue, 09 Jun 2009 16:08:07 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244563687.46.0.103189442675.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

Thanks Vinay.  I ran the newest revised script with virus protection 
turned off and got the same failures as before (see console output 
below).

If you comment out the os.system() calls, everything works just fine.  
Uncomment them and logging breaks.

The os.system() calls shouldn't break logging, especially since they 
are accessing a completely unrelated file - not the log file.

If you could go back to my original script that fails for you, you 
should be able to chase down why these unrelated os.system() calls are 
breaking logging.  Feel free to add the joins and replace the tabs if 
you want to, but don't put locks around the os.system() calls because 
that just makes the problem go away and leaves us with nothing to do.  
Does that make sense?  Regardless of what the os.system() calls are 
doing, they shouldn't break logging in any way whatsoever.  So if my 
original script breaks for you, please use that broken state to debug 
the problem and find out why an os.system() call is breaking logging.

-----------------------------------

C:\logthred>revised.py
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 72, in emit
    self.doRollover()
  File "C:\Python26\lib\logging\handlers.py", line 129, in doRollover
    os.rename(self.baseFilename, dfn)
WindowsError: [Error 32] The process cannot access the file because it 
is being
used by another process
2009-06-09 09:54:47,828 DEBUG    3704 This is log message 0 from thread-
00 and I
 think this should be a little longer, so I'll add some more data here 
because p
erhaps the size of the individual log message is a factor.  Who knows 
for sure u
ntil this simple test fails.
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 71, in emit
    if self.shouldRollover(record):
  File "C:\Python26\lib\logging\handlers.py", line 145, in 
shouldRollover
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
2009-06-09 09:54:47,967 DEBUG    9052 This is log message 0 from thread-
01 and I
 think this should be a little longer, so I'll add some more data here 
because p
erhaps the size of the individual log message is a factor.  Who knows 
for sure u
ntil this simple test fails.
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 71, in emit
    if self.shouldRollover(record):
  File "C:\Python26\lib\logging\handlers.py", line 145, in 
shouldRollover
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
2009-06-09 09:54:48,062 DEBUG    7480 This is log message 0 from thread-
02 and I
 think this should be a little longer, so I'll add some more data here 
because p
erhaps the size of the individual log message is a factor.  Who knows 
for sure u
ntil this simple test fails.
Traceback (most recent call last):
  File "C:\Python26\lib\logging\handlers.py", line 71, in emit
    if self.shouldRollover(record):
  File "C:\Python26\lib\logging\handlers.py", line 145, in 
shouldRollover
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file
.
.
.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 18:48:17 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Jun 2009 16:48:17 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244566097.8.0.723426907602.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Debugging threading problems is never as simple as it seems. I don't
believe logging is breaking because of some interaction with the system
calls - rather, the presence of the system calls is changing the
real-time characteristics of the system and exposing the failure.

This problem is not directly related to logging - for example, see

http://groups.google.com/group/comp.lang.python/browse_thread/thread/98fa9592e7c47130/d5642964c573dfc0#d5642964c573dfc0

I will look to see if I can find what the exact problem is. Did you turn
off Windows search indexing for the volume before running the test, in
addition to turning off the anti-virus? It looks as if something else is
opening the file (which, in our test, will have been very recently
written to when the error occurs) and the suspicion must fall on
anti-virus or search indexing or some other file watching software (e.g.
backup software which is configured to monitor all file changes and
refresh the backup copy in pseudo-real-time).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 18:55:38 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 09 Jun 2009 16:55:38 +0000
Subject: [issue6248] TCP Sockets not closed by TCPServer and
	StreamRequestHandler
In-Reply-To: <1244566538.72.0.477638958657.issue6248@psf.upfronthosting.co.za>
Message-ID: <1244566538.72.0.477638958657.issue6248@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

When an error occurs in a StreamRequestHandler, its wfile and rfile 
members are not closed.  This causes the underlaying socket to stay 
alive and and it is therefore not closed, even when the SocketServer 
closes it in server.close_request().  This means that a client will not 
know that there is no one listening on the other end.

This is due to incorrect error handling semantics in BaseRequestHandler.

This patch fixes the error handling in BaseRequestHandler, ensuring that 
request.finish() is called when request.setup() has completed.

I also add an explicit socket.shutdown() in TCPServer.close_request() to 
make sure that at least a half-close occurs even in the face of socket 
reference leaks.

----------
components: Library (Lib)
files: socketserver.patch
keywords: needs review, patch, patch
messages: 89152
nosy: krisvale
severity: normal
status: open
title: TCP Sockets not closed by TCPServer and StreamRequestHandler
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14245/socketserver.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6248>
_______________________________________

From report at bugs.python.org  Tue Jun  9 19:56:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jun 2009 17:56:55 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244570215.52.0.0279372549621.issue6137@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Guido, Raymond suggested we ask your input on this one, although it's
obviously a bit late (the patch has been committed).

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Jun  9 20:03:20 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 09 Jun 2009 18:03:20 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244570600.75.0.281326718792.issue6137@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm not on IRC. What exactly is your question for me? What is Raymond's 
view?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Jun  9 20:14:47 2009
From: report at bugs.python.org (Robert Cronk)
Date: Tue, 09 Jun 2009 18:14:47 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244571287.38.0.329263124116.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I'll thoroughly look through every piece of software that's running to 
see if I can turn eveything off that might be causing the problem.

Were you able to reproduce the problem with my original script?  I'm 
sure you have all of your virus/searching/etc. stuff turned off, so if 
it reproduced for you, then those things aren't the problem.

Question: If you take my original script and add joins at the end so 
it's proper and modify nothing else about it, does it show the rollover 
error?

If so, then I think that is where we need to start since you then have 
a simple test that manifests the problem without virus scanners (etc.) 
that might taint the issue.  Then you can chase this without having to 
assume what my system has running on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Tue Jun  9 20:16:41 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Jun 2009 18:16:41 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244571401.94.0.686453046012.issue6137@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I vaguely remember you rejecting a proposal along these lines when Brett
was doing the library renaming.  

The patch (as applied) turns on the renaming automatically when used
with protocol 2 (i.e. all object names are stored with their 2.x names,
not their new names).   Hagen points out that 3.1 proto 2 pickles can't
be read by 3.0.  I would think that the back-translation should be
disabled by default or else we're going to live with the 2.x names for a
very long time.

I don't care much one way or the other.  Just thought you should see it
before it got released and set in stone.  It's not too late for a one
line change, setting the fix_imports default from True to False.

FWIW, the argument for leaving the default as True is the theory that
anyone using protocol 2 is likely doing so to exchange data with 2.x.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Jun  9 21:03:00 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 09 Jun 2009 19:03:00 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1244571401.94.0.686453046012.issue6137@psf.upfronthosting.co.za>
Message-ID: <ca471dc20906091202x4049c8e3l471028aafc2d934a@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Ah. How about only doing back-translation when protocol=2 (or lower)
is explicitly selected?

I don't much like that 3.0 will be to read pickles written by 3.1 with
the default protocol (i.e. 3), but I don't mind breaking protocol 2,
since that's most likely (as you say) intended for Python 2. So the
default for fix_imports would be None, and the __init__ would check if
it's None, and then set it to (protocol <= 2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Jun  9 21:16:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jun 2009 19:16:28 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <ca471dc20906091202x4049c8e3l471028aafc2d934a@mail.gmail.com>
Message-ID: <1244575125.4424.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ah. How about only doing back-translation when protocol=2 (or lower)
> is explicitly selected?

Well, this is exactly what is implemented!

> I don't much like that 3.0 will be to read pickles written by 3.1 with
> the default protocol (i.e. 3),

I suppose you meant to say "will be unable", but it isn't, since
protocol 3 pickles are not affected at all by this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Jun  9 21:26:41 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 09 Jun 2009 19:26:41 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1244575125.4424.1.camel@localhost>
Message-ID: <ca471dc20906091226p2888bdb9t585cdbf96c54c224@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Tue, Jun 9, 2009 at 12:16 PM, Antoine Pitrou<report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Ah. How about only doing back-translation when protocol=2 (or lower)
>> is explicitly selected?
>
> Well, this is exactly what is implemented!

Ah, I missed that. Fine then!

>> I don't much like that 3.0 will be to read pickles written by 3.1 with
>> the default protocol (i.e. 3),
>
> I suppose you meant to say "will be unable",

Indeed.

> but it isn't, since
> protocol 3 pickles are not affected at all by this patch.

Good.

So I'm okay with the status quo -- too bad 3.0 can't read those
pickles, but that's the deal with abandoning 3.0...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Jun  9 21:32:48 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Jun 2009 19:32:48 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1244575968.39.0.455855773445.issue6137@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for taking a look and opining.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Jun  9 21:47:35 2009
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 09 Jun 2009 19:47:35 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244576855.12.0.426355995221.issue6136@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

My comp.lang.python thread is here:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/a0c35c3c9ad210a4

It was met by deafening silence though.

I don't see why a simple format would need to be customer-specific.
log4py's isn't/wasn't and that worked just fine. It did support logging
to more than files but its configuration file scaled down much more
gracefully for simple usage, mostly because it didn't expose its
internal design like the logging one does. It had only loggers instead
of loggers/handlers/formatters.

But log4py is discontinued now as a project and I can't face maintaining
my own copy of it any more.

I'm getting the feeling you're just trying to fob me off here. You
dismiss the threads I found as being "mostly about other things" or "not
mentioning specifics". That may be so, but the fact is, in those threads
you have five other people expressing in one way or another that the
configuration file is too complex - and I'm sure I could find more if
you really want. If you prefer to ignore them and me there's not much
point in discussing further.

I'm not demanding that you do this work. I'm simply trying to raise the
issue and asking you to consider accepting such a patch if I or somebody
else produce it.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6136>
_______________________________________

From report at bugs.python.org  Tue Jun  9 22:08:35 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 09 Jun 2009 20:08:35 +0000
Subject: [issue6242] Fix reference leak in io.StringIO
In-Reply-To: <1244490696.88.0.117703122021.issue6242@psf.upfronthosting.co.za>
Message-ID: <1244578115.28.0.529360186545.issue6242@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> Why do you need all this? Isn't it enough to take a weakref and check
> the callback is triggered?

No, because you would need a weak reference to the instance's __dict__,
which is unavailable for io.StringIO.

Anyway, here's a simplified patch without the fun experimental code. :-)

----------
Added file: http://bugs.python.org/file14246/fix_refleak_stringio-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6242>
_______________________________________

From report at bugs.python.org  Tue Jun  9 22:17:35 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 09 Jun 2009 20:17:35 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244578655.05.0.366923775073.issue6215@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I think the build configuration for _io on Windows is missing.
Modules/Setup.dist probably needs to be updated too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Tue Jun  9 22:36:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Jun 2009 20:36:26 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244539960.63.0.714075009226.issue6245@psf.upfronthosting.co.za>
Message-ID: <4A2EC7C6.5050900@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> FWIW,
> it's the --with-universal-archs option that he said wasn't 100% usable,
> not the binaries.

Ah, ok. That clarifies it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Tue Jun  9 22:38:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Jun 2009 20:38:25 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244578655.05.0.366923775073.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244580045.4424.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think the build configuration for _io on Windows is missing.

Yes.

> Modules/Setup.dist probably needs to be updated too.

Not sure, I don't think any of these modules are built-in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Tue Jun  9 22:46:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Jun 2009 20:46:12 +0000
Subject: [issue5924] When setting complete PYTHONPATH on Python 3.x,
	paths in the PYTHONPATH are ignored
In-Reply-To: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>
Message-ID: <1244580372.97.0.0259468920386.issue5924@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks right to me, please apply.

----------
assignee:  -> amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Tue Jun  9 22:53:16 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 09 Jun 2009 20:53:16 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244580796.92.0.595967580351.issue6215@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

> Not sure, I don't think any of these modules are built-in.

Ah true. Although there are built-in in py3k, you are right that it
doesn't make sense to make the trunk versions built-in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Tue Jun  9 23:04:26 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Jun 2009 21:04:26 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244557393.18.0.385803323002.issue6247@psf.upfronthosting.co.za>
Message-ID: <4A2ECE57.4030200@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Since they are missing in optparse, and since it doesn't look like
> argparse will be included, should I open new bugs for those features
> against optparse ?

I think chances are very low that any such bug report would be reacted
on within the next decade.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Tue Jun  9 23:32:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Jun 2009 21:32:25 +0000
Subject: [issue5924] When setting complete PYTHONPATH on Python 3.x,
	paths in the PYTHONPATH are ignored
In-Reply-To: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>
Message-ID: <1244583145.86.0.951063306208.issue5924@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r73322 (py3k) and r73323 (3.0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Tue Jun  9 23:32:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Jun 2009 21:32:37 +0000
Subject: [issue5924] When setting complete PYTHONPATH on Python 3.x,
	paths in the PYTHONPATH are ignored
In-Reply-To: <1241463970.43.0.829234478071.issue5924@psf.upfronthosting.co.za>
Message-ID: <1244583157.44.0.402200685245.issue5924@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5924>
_______________________________________

From report at bugs.python.org  Wed Jun 10 00:03:39 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Jun 2009 22:03:39 +0000
Subject: [issue6136] Make logging configuration files easier to use
In-Reply-To: <1243494599.99.0.653406283097.issue6136@psf.upfronthosting.co.za>
Message-ID: <1244585019.23.0.00355868372753.issue6136@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

"It was met by deafening silence though."

Give it time - it's only been a few days. For some reason, Google Groups
doesn't show your post in the first page of results when I search for
logging configuration by date (i.e. most recent on top):

http://groups.google.com/group/comp.lang.python/search?q=logging+configuration&start=0&scoring=d

The same problem if I search for "logging configuration" the phrase -
again, it doesn't show up.

However, if after a while there's still not much response, it would
indicate that this is not perhaps such an important issue for the
community as you feel it is. This doesn't stop you from rolling your own
format, but gives less justification for adding a patch to the core stdlib.

"[log4py's] configuration file scaled down much more
gracefully for simple usage, mostly because it didn't expose its
internal design like the logging one does. It had only loggers instead
of loggers/handlers/formatters."

Yes - Python logging is more complex because that's what's useful for
developers. It's not really intended for end-users to change - in fact
once something is in production, typically only levels need to change.
This is surely editable by end users even with the existing config file
format, as long as they're not too fazed by the other stuff which they
don't need to touch. If they are - then a much simpler,
application-specific, end-user friendly format seems more in order.

"But log4py is discontinued now as a project and I can't face
maintaining my own copy of it any more."

What's to maintain? Python logging has been pretty stable now for a long
time, and log4py being simpler shouldn't need any particular maintenance
(since it has worked for you in the past).

"I'm getting the feeling you're just trying to fob me off here. You
dismiss the threads I found as being 'mostly about other things' or 'not
mentioning specifics'. That may be so, but the fact is, in those threads
you have five other people expressing in one way or another that the
configuration file is too complex - and I'm sure I could find more if
you really want. If you prefer to ignore them and me there's not much
point in discussing further."

I'm not trying to fob you off - I just stated what I found about those
posts. The complaints you refer to were not specific enough to suggest
improvements, and anyone can write comments about how crufty they think
something is - it doesn't exactly tell the maintainer which direction
they would like to go in. I'm not saying that applies to anything you
personally have said - I'm referring to the comments in those posts you
referred to. All of us in open source development have to balance a
number of different issues and we all have different agendas and
priorities. My position is that the logging configuration system, while
not perfect, works and is used by quite a lot of people without
problems. It's just not high on my list of priorities to tinker with the
format, because the feedback I've had in the past is that those people
who care a lot about configuration will roll their own anyway. I'm never
going to be able to please them all, so why not focus my energies elsewhere?

"I'm not demanding that you do this work. I'm simply trying to raise the
issue and asking you to consider accepting such a patch if I or somebody
else produce it."

As I've said before, I've accepted numerous patches from numerous people
in the past. You can confirm this from SVN where commit messages
generally refer to issue numbers on this tracker. Clearly I can't make
promises in advance to accept any future patch, but I've indicated where
I'd set the bar (backward compatibility, doc changes, test changes) for
a patch to be considered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6136>
_______________________________________

From report at bugs.python.org  Wed Jun 10 00:08:11 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 09 Jun 2009 22:08:11 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1244585291.88.0.48124635515.issue2919@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Jean Brouwers wrote:
> All tests passed after regenerating the expected results

The tests for profile are output test. If you regenerate them, they pass
for sure.

Merging cProfile/profile will require a lot more work than just renaming
the module. The designs of cProfile and profile are significantly
different. So a successful merge will require settling one profiler
design (cProfile is the better designed one, IMHO) and rewrite the other
one to match the chosen design.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Wed Jun 10 00:52:56 2009
From: report at bugs.python.org (Robert Cronk)
Date: Tue, 09 Jun 2009 22:52:56 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244587976.2.0.0407929238583.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I turned off anti-virus again as well as file indexing and google 
desktop too and still got the errors when I disabled the locks around 
the os.system() calls.

Vinay - when the locks aren't around the os.system() calls, do you get 
the rotating log errors?

I'm still confused at how the os.system calls could be affecting the 
logging at all.  The os.system calls aren't touching the log files.  
Why would it cause them to fail when the os.system calls fail?  It 
seems that when the os.system calls succeed (because of the locks) then 
the logging succeeds but when the os.system calls fail (because the 
locks are disabled), then logging fails.  If, as you suggest, this is a 
race condition that is being exposed by the os.system calls failing 
because they don't have locks around them, then that would be the 
perfect situation (if you can reproduce it) to debug it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 01:10:30 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Jun 2009 23:10:30 +0000
Subject: [issue6201] test_winreg fails
In-Reply-To: <1244184342.63.0.700408501075.issue6201@psf.upfronthosting.co.za>
Message-ID: <1244589030.64.0.201338803433.issue6201@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r73325.
2.7 really introduces an incompatibility here; I added an entry in the 
whatsnew file.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6201>
_______________________________________

From report at bugs.python.org  Wed Jun 10 01:35:25 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Jun 2009 23:35:25 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244590525.03.0.333730453822.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've just run a test several times - it's your original script with
joins added at the end. I kept the acquire_lock and release_lock calls
but made them only do anything if a constant USE_LOCK was True. I set
this to False, so that no locking is actually occurring.

My earlier tests had run with Windows indexing not turned off properly
(there's an option to turn off for all subfolders which I mistakenly
didn't select, so that I had only turned it off on the root folder).
Now, I've turned off search indexing for the entire volume, as well as
the anti-virus, and re-run the tests. I also found that the TortoiseSVN
Windows shell extension sometimes scans files if you are working inside
a directory which is part of an SVN checkout, so I was careful to work
outside any SVN tree.

I also ran SysInternals filemon. I attach the log: it appears to show
that a SHARING VIOLATION (the WindowsError 32) is occurring specifically
because of interaction with a spawned os.system child process. However,
this does not appear to be logging-specific: my conjecture is that when
the cmd.exe is spawned, it inherits file handles from the parent process
(the Python process which is doing the logging). When cmd.exe exits, it
closes all its open file handles, thereby pulling the rug out from under
the Python process.

To confirm this, I created another script, thredio.py, which does not
use logging but does the equivalent I/O operations (including using a
threading lock around them to serialise access from the threads - but
there is no locking around the os.system() calls).

Guess what - the same error occurs. Here's the extract from the console
output:

Exception in thread Thread-10:
Traceback (most recent call last):
  File "C:\Python\lib\threading.py", line 488, in __bootstrap_inner
    self.run()
  File "C:\temp\thredio.py", line 28, in run
    os.rename('logthred.log', dfn)
WindowsError: [Error 32] The process cannot access the file because it
is being used by another process

So, I submit that this is not a logging issue, and am closing this issue.

----------
Added file: http://bugs.python.org/file14247/python-logging-capture.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 01:36:16 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Jun 2009 23:36:16 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244590576.16.0.972648519812.issue4749@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file14248/thredio.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 01:37:10 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Jun 2009 23:37:10 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244590630.6.0.23117474431.issue4749@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> invalid
status: open -> closed
Added file: http://bugs.python.org/file14249/python-io-capture.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 02:07:18 2009
From: report at bugs.python.org (Jason Kankiewicz)
Date: Wed, 10 Jun 2009 00:07:18 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244592438.94.0.364183873004.issue1254718@psf.upfronthosting.co.za>


Jason Kankiewicz <jkankiewicz at acm.org> added the comment:

I've attached a patch, based on the original, that will fix distutils
for both GCC and ICC.

----------
nosy: +jkankiewicz
Added file: http://bugs.python.org/file14250/distutils-rpath-gcc_and_icc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 02:25:15 2009
From: report at bugs.python.org (Jason Kankiewicz)
Date: Wed, 10 Jun 2009 00:25:15 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244593515.68.0.64368503605.issue1254718@psf.upfronthosting.co.za>


Changes by Jason Kankiewicz <jkankiewicz at acm.org>:


Removed file: http://bugs.python.org/file14250/distutils-rpath-gcc_and_icc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 02:28:43 2009
From: report at bugs.python.org (Jason Kankiewicz)
Date: Wed, 10 Jun 2009 00:28:43 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244593723.59.0.0405751327234.issue1254718@psf.upfronthosting.co.za>


Jason Kankiewicz <jkankiewicz at acm.org> added the comment:

I've updated my patch to resemble the patch from issue1032 and also
because profiling showed that using str.__contains__ is more efficient
than using str.find.

----------
Added file: http://bugs.python.org/file14251/distutils-rpath-gcc_and_icc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 02:31:59 2009
From: report at bugs.python.org (SonMarvin)
Date: Wed, 10 Jun 2009 00:31:59 +0000
Subject: [issue6249] Error Prompt
In-Reply-To: <1244593919.18.0.459180854095.issue6249@psf.upfronthosting.co.za>
Message-ID: <1244593919.18.0.459180854095.issue6249@psf.upfronthosting.co.za>


New submission from SonMarvin <marvinsd at gmail.com>:

When I open a Python File Prompt closes it quickly.My friends do not
have this problem. Now reinstall, download older versions and the
problem continued.

----------
components: Windows
messages: 89177
nosy: SonMarvin
severity: normal
status: open
title: Error Prompt
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6249>
_______________________________________

From report at bugs.python.org  Wed Jun 10 02:46:04 2009
From: report at bugs.python.org (Seo Sanghyeon)
Date: Wed, 10 Jun 2009 00:46:04 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244594764.39.0.277547053079.issue1254718@psf.upfronthosting.co.za>


Seo Sanghyeon <sanxiyn at gmail.com> added the comment:

any() built-in is new in 2.5. PEP 291 specifies 2.3 compatibility for
distutils. (tarek: Why?) The original patch used str.find because
backward-compatibility requirement used to be stricter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 03:43:14 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 01:43:14 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244598194.65.0.302588766638.issue1254718@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, min() can usually be substituted for any().

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 04:07:47 2009
From: report at bugs.python.org (Robert Cronk)
Date: Wed, 10 Jun 2009 02:07:47 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244599667.6.0.110930594486.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

Vinay - that's great news!  Are you going to create a new bug for this issue with a proper title?  It would seem to me that the fix for this would be to put locks internal to the os.system() call around where it spawns cmd so multiple spawns don't occur simultaneously.

Is the proper procedure at this point to open a new bug with a more correct title that points back to this bug for reference?  Can you do that Vinay?  I don't know if I have the authority (nor experience with the bug tracking system) to do that.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 04:11:36 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 10 Jun 2009 02:11:36 +0000
Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc
In-Reply-To: <1188169656.44.0.377858080562.issue1032@psf.upfronthosting.co.za>
Message-ID: <1244599896.02.0.144971621756.issue1032@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> GCC detection for runtime_library_dirs when ccache is used

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1032>
_______________________________________

From report at bugs.python.org  Wed Jun 10 04:40:47 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 10 Jun 2009 02:40:47 +0000
Subject: [issue5437] Singleton MemoryError can hold traceback data and locals
	indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1244601647.43.0.206517825042.issue5437@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Honestly, I don't think it is a big issue. MemoryErrors are rare and
typically cause the interpreter to shutdown.

By the way, do you think the static PyExc_RecursionErrorInst object is
affected by this bug?

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5437>
_______________________________________

From report at bugs.python.org  Wed Jun 10 04:56:29 2009
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 10 Jun 2009 02:56:29 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244602589.63.0.262646013963.issue6247@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm happy to contribute argparse to the standard library and volunteer
to maintain it.

For what it's worth, I don't agree that there are already too many
argument parsing libraries in the standard library. I do agree that
there are already too many *option* parsing libraries. But both getopt
and optparse don't know how to parse positional arguments at all. For
example, if your program usage looks like:

    prog eggs [spam] [baz [baz [...]]]

then getopt and optparse are worthless to you - they'll just return
sys.argv[1:] since there are no options. The argparse module, on the
other hand, can correctly parse out "eggs", "spam" and the "baz" list
into appropriate attributes (in addition to doing all the other stuff
that optparse does).

I also don't think there's much of a chance of optparse ever growing
most of the argparse features. When I started argpasre, my goal was
exactly that - to keep the module fully backwards compatible with
optparse and just to add the missing features. The optparse code just
wasn't written in a way that allowed me to do that. In particular, the
optparse extension API is horribly designed, and exposes so many
internals of optparse that it's nearly impossible to add any new
features to optparse without breaking this.

----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Wed Jun 10 05:59:45 2009
From: report at bugs.python.org (James Abbatiello)
Date: Wed, 10 Jun 2009 03:59:45 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

Python currently emits bytecode for code that is unreachable (e.g.
following a return statement).  This doesn't hurt anything but it takes
up space doing nothing.

This patch attempts to avoid generating any bytecode in this situation.
 There's an optional warning, enabled with the -r command line switch,
which notifies you if any unreachable code is found.  Running
regrtest.py with this switch produces a bit of noise but also revealed
issue6227 which looks like a real bug.

----------
components: Interpreter Core
files: deadcode.patch
keywords: patch
messages: 89183
nosy: abbeyj, collinwinter, jyasskin, pitrou
severity: normal
status: open
title: Python compiles dead code
versions: Python 2.7
Added file: http://bugs.python.org/file14252/deadcode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Wed Jun 10 08:10:25 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Jun 2009 06:10:25 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244614225.26.0.798627911538.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The problem may occur just because of the way file handles work with
child processes. I'm not sure if it's a bug, or even if it's specific to
Python, so I'm not going to raise another issue. It's worth searching to
see if there's an existing issue about it, though.

Anyone can raise a new bug; you just log in and click on "Create New"
under "Issues" in the menu on the left of the page. I would suggest that
you research the issue first to see if it's previously been raised on
this tracker, or in c.l.py, or on the wider Internet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 08:18:00 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Jun 2009 06:18:00 +0000
Subject: [issue6249] Error Prompt
In-Reply-To: <1244593919.18.0.459180854095.issue6249@psf.upfronthosting.co.za>
Message-ID: <1244614680.63.0.606292090529.issue6249@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please consult a Python mailing list or newsgroup to learn how to use
the command box.  This is not a Python bug.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6249>
_______________________________________

From report at bugs.python.org  Wed Jun 10 08:38:48 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 06:38:48 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1244615928.92.0.370808412179.issue6250@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

We've rejected dead-code elimination in the past (too much effort for
nearly zero benefit).  Will take a look at your patch though.

----------
assignee:  -> rhettinger
nosy: +rhettinger
priority:  -> low
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Wed Jun 10 08:45:44 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 10 Jun 2009 06:45:44 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244602589.63.0.262646013963.issue6247@psf.upfronthosting.co.za>
Message-ID: <4A2F5696.3050206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Steven Bethard wrote:
> In particular, the
> optparse extension API is horribly designed, and exposes so many
> internals of optparse that it's nearly impossible to add any new
> features to optparse without breaking this.

It would be useful if several people could confirm that argparse
is *not* horribly designed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Wed Jun 10 09:16:21 2009
From: report at bugs.python.org (rubisher)
Date: Wed, 10 Jun 2009 07:16:21 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1244618181.68.0.862632524513.issue6006@psf.upfronthosting.co.za>


rubisher <rubisher at scarlet.be> added the comment:

Having a look at
<http://www-
03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html>

gcc libffi is wel available for Aix, though?

That said, I just need python for bzr and associated tools to maintain 
localy a small number of script, so imho I would be able survive 
without ffi support in python (even _ctype?).

Any idea how to remove this support at build from src time: I have a 
look at ./configure --help and even try to change some other 
compilation option like -O2 (in place of default -O3) but nothing 
seems to be helpfull.

Tx for additional advise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6006>
_______________________________________

From report at bugs.python.org  Wed Jun 10 09:57:19 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Wed, 10 Jun 2009 07:57:19 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244620639.58.0.791920970413.issue6247@psf.upfronthosting.co.za>


Ritesh Raj Sarraf <rrs at researchut.com> added the comment:

I'm not sure about the design part, but as a user, I find both to have very
similar interfaces.

argparse is better because it handles nargs=*. This has long been
asked in optparse. Positional arguments is something I wanted recently,
and argparse makes it very easy to use that too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Wed Jun 10 10:19:14 2009
From: report at bugs.python.org (John O'Driscoll)
Date: Wed, 10 Jun 2009 08:19:14 +0000
Subject: [issue6251] c++ extension module implementation guide/example in
	extending/embedding documentation
In-Reply-To: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>
Message-ID: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>


New submission from John O'Driscoll <biggerbumme at yahoo.co.in>:

feature: extension module C++ howto/example in extending-embedding/c-api
documentation


why:	The embedding/extension documentation states that module
implementation in c++ is possible, without providing any guidance beyond
this. Coders more familiar/comfortable with c++ than c, writing c++ code
to expose in python, might want to create the actual python class/module
implementations in c++ classes or structs. A basic guide can help
prevent wastage of energy reinventing the wheel, and also serve as a
guide to safe/preferred style. The method outlined here can be a
starting point in finding out what that style is. 
Also it seems, to my eyes at least, a little easier to 'visualise' and
apply than the equivalent in plain C (the Noddy module etc), a bit more
'systematic', and easier to understand the relation between c and python
objects. So after some trial and error, discovering the pitfalls, I am
finding it easy to create useful python classes with this recipe. Others
might also find it useful, even if only as a stimulus to find a Better Way.

Python is an object-oriented language noted for its clarity, so an
allegedly simple and clear OO implementation strategy for module classes
should be examined.


what:	I've written a module currently called 'cpeepee', containing a
basic python class ,(struct TestRealDestructor in C++,
'cpeepee.destructo' in python). It has been tested with python-2.5 and
g++-4.2 on ubuntu-'hardy heron' and python-2.5/g++-3.4 on FreeBSD-6.4. 

The c++ struct inherits from PyObject.(You could also inherit from
PyVarObject or other more specialised types). The most important
non-feature of this class is that it is not virtual, has no virtual
destructor or functions(in member objects virtual destructors and the
rest are OK however). Therefore the packing of ob_refcnt and friends is
correct, and casting to/from PyObject is safe(-and otherwise is not -
the PyObject* cast from such a type with virtual destructor is offset by
the size of a pointer -the vptr?-, but when python casts back to the
type - from void* or so?- the offset is not removed, leading to mayhem).

[You could also not inherit, simply put the PyObject_HEAD macro as the
first entry in the struct - could be a class also, as long as the
PyObject members(ob_refcnt, ob_type ... )were public - You would have to
write a new macro to fill in those members in the constructor's
initialiser list, but that doesn't look too hard. As it is the inherited
classes use a function and some macros (almost identical to
PyObject_HEAD_INIT(typo) ) to fill in the PyObject parent. Again, vfuncs
are out]

	The destructo method and member tables are static members of
TestRealDestructor, as is its type object.(Other optional tables etc
should also be static members if provided - makes for a simple
consistent setup)
	The objects constructor is called from
TestRealDestructor::type.tp_new() and passed the args and kwds arguments
it is passed, using placement new with memory obtained from
tp_alloc()(see TestRealDestructor::create() ). Being able to properly
call an object's constructor was the real motivation for writing the
code this derives from. Using C style one is stuck casting a char* to
your type and then filling its fields by hook or crook.
 
On error, either you could throw a c++ exception in constructor to catch
in tp_new, and convert to a python exception, or simply throw the python
exception in the constructor, and then check if PyErr_Occurred() in
tp_new() - the approach with destructo.

Since tp_new and the constructor take care of object creation, this
leaves tp_init not doing much at all. It could be used for extra checks,
or printing funky messages about preserved ham

Functions to be exposed in python API as class member functions should
static members of the class, and to do the work they call ordinary
member functions of the class object passed into the static function .
You could use global static functions(with the first arg
TestRealDestructor* say, rather than PyObject*), but that's less clear,
less systematic, less OO.

Everything can be placed in a namespace to avoid any pollution of global
namespace.

I've worked out the bugs that were obvious to me, so it should compile
and run as is, without error messages. The one compile warning I don't
know how to banish comes from the offsetof macro when setting member
offsets in the member table(as copied from the c example) - however the
object whose offset is so established works fine from python, so I think
it's a spurious warning. 

If you find any issues with my approach, I'm happy to work through them,
or if you know what to do then make whatever changes you think required.

I'm happy to put any code or words I contribute on this topic to go
under python's copyright as long as I'm credited somehow(however you
normally do that). Whatever, I'm happy to contribute to such a great
project as python

sincerely

John O'Driscoll

----------
assignee: georg.brandl
components: Documentation
files: CXXdemo-0.1.tar.gz
messages: 89190
nosy: georg.brandl, subgeometer
severity: normal
status: open
title: c++ extension module implementation guide/example in extending/embedding documentation
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file14253/CXXdemo-0.1.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6251>
_______________________________________

From report at bugs.python.org  Wed Jun 10 10:24:26 2009
From: report at bugs.python.org (Jeremy Thurgood)
Date: Wed, 10 Jun 2009 08:24:26 +0000
Subject: [issue6232] Improve test coverage of ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1244622266.32.0.041957861.issue6232@psf.upfronthosting.co.za>


Changes by Jeremy Thurgood <firxen at gmail.com>:


----------
nosy: +jerith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6232>
_______________________________________

From report at bugs.python.org  Wed Jun 10 10:30:55 2009
From: report at bugs.python.org (Turnaev Evgeny)
Date: Wed, 10 Jun 2009 08:30:55 +0000
Subject: [issue6252] logging midnigh rotation
In-Reply-To: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>
Message-ID: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>


New submission from Turnaev Evgeny <xiled at yandex.ru>:

i have a very basic setup of logging in a long running daemon app..
I use TimedRotatingFileHandler with rotating at midnight.
The bug:
The last open logging file was for 2009-05-25..
app was running without logging anything for about a week or more.
After a week past something happened and daemon started to log messages,
but.. for each new message logging system creates new file.
In other words.. suppose we was idle since 2009-05-25, now it is 
2009-06-10 and we want to log 10 messages.. 
current opened file is for 2009-05-25.. so when a first messages
arrives into logging system current must be closed. and a new file must 
be opened where all 10 messages should be..
but instead logging system will log each subsequent message in files 
2009-05-26, 2009-05-27, 2009-05-28..(in fact it will log in file 
without a date and then when nect message arives rename current to 
2009-05-26, 2009-05-27, 2009-05-28.. but is still the same) and so on, 
one message per file.. i think until it reaches current date.
It is a logic error.


my logging setup looks like this:
---------
import logging
from logging import debug,warning,info,error,critical
from logging.handlers import TimedRotatingFileHandler

log_path = '/var/log/cherry/smsd_reg'
log_level = logging.DEBUG

basic_log_handler = TimedRotatingFileHandler(log_path + "/
app_log_smsd_reg_server",'midnight',1)
basic_log_handler.setLevel(log_level)
basic_log_formatter = logging.Formatter('%(asctime)s pid: %(process)d, 
%(levelname)s %(message)s')
basic_log_handler.setFormatter(basic_log_formatter)
logging.getLogger('').addHandler(basic_log_handler)
logging.getLogger('').setLevel(log_level)

----------------

system info:
Python 2.5.1
FreeBSD 6.2-RELEASE-p7 FreeBSD 6.2-RELEASE-p7

----------
components: Extension Modules
messages: 89191
nosy: SanityIO
severity: normal
status: open
title: logging midnigh rotation
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6252>
_______________________________________

From report at bugs.python.org  Wed Jun 10 10:58:10 2009
From: report at bugs.python.org (Gabriel de Perthuis)
Date: Wed, 10 Jun 2009 08:58:10 +0000
Subject: [issue5331] multiprocessing hangs when Pool used within Process
In-Reply-To: <1235146028.47.0.682929217877.issue5331@psf.upfronthosting.co.za>
Message-ID: <1244624290.28.0.38069051667.issue5331@psf.upfronthosting.co.za>


Gabriel de Perthuis <onyxg7 at users.sourceforge.net> added the comment:

Apparently the pool workers die all at once, just after the pool creates
them and before the pool is used.
I added a few lines to multiprocessing/pool.py to get the stack and the
exception backtrace.

        except (EOFError, IOError):
            import traceback
            debug(traceback.format_exc())
            debug(''.join(traceback.format_stack()))
            debug('worker got EOFError or IOError -- exiting')
            break


INFO::Rule dispatcher::multiprocessing::child process calling self.run()
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3082559488
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3082104832
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3081826304
DEBUG::Rule dispatcher::multiprocessing::created semlock with handle
3081822208
INFO::PoolWorker-3:1::multiprocessing::child process calling self.run()
DEBUG::PoolWorker-3:1::multiprocessing::Traceback (most recent call last):
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/pool.py",
line 57, in worker
    task = get()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/queues.py",
line 339, in get
    return recv()
IOError: [Errno 9] Bad file descriptor

DEBUG::PoolWorker-3:1::multiprocessing::  File
"/home/who/var/co/git-svn/what-base/correlator/bin/correlator", line 30,
in <module>
    what.corr.actors.main.main()
  File
"/home/who/var/co/git-svn/what-base/correlator/lib/what/corr/actors/main.py",
line 47, in main
    rrp.start()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 109, in start
    self._popen = Popen(self)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/forking.py",
line 99, in __init__
    code = process_obj._bootstrap()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 236, in _bootstrap
    self.run()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 93, in run
    self._target(*self._args, **self._kwargs)
  File
"/home/who/var/co/git-svn/what-base/correlator/lib/what/corr/actors/rule_dispatcher.py",
line 26, in main
    initargs=(manager.agg_msgs_queue, ))
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/__init__.py",
line 232, in Pool
    return Pool(processes, initializer, initargs)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/pool.py",
line 107, in __init__
    w.start()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 109, in start
    self._popen = Popen(self)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/forking.py",
line 99, in __init__
    code = process_obj._bootstrap()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 236, in _bootstrap
    self.run()
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/process.py",
line 93, in run
    self._target(*self._args, **self._kwargs)
  File
"/home/who/.buildout/eggs/multiprocessing-2.6.1.1-py2.6-linux-i686.egg/multiprocessing/pool.py",
line 61, in worker
    debug(''.join(traceback.format_stack()))

DEBUG::PoolWorker-3:1::multiprocessing::worker got EOFError or IOError
-- exiting
INFO::PoolWorker-3:1::multiprocessing::process shutting down
DEBUG::PoolWorker-3:1::multiprocessing::running all "atexit" finalizers
with priority >= 0

----------
nosy: +onyxg7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5331>
_______________________________________

From report at bugs.python.org  Wed Jun 10 11:59:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Jun 2009 09:59:37 +0000
Subject: [issue6251] c++ extension module implementation guide/example in
	extending/embedding documentation
In-Reply-To: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>
Message-ID: <1244627977.69.0.42710655731.issue6251@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did you take a look at Boost.Python?
This is a much more natural (from C++ point of view) way to create
Python types. All boilerplate code comes from template techniques
(creation/destruction, static methods...)

The tutorial is interesting:
http://www.boost.org/doc/libs/release/libs/python/doc/tutorial/doc/html/python/exposing.html

IOW, I suggest to just add a reference to the boost::python library

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6251>
_______________________________________

From report at bugs.python.org  Wed Jun 10 12:30:12 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Jun 2009 10:30:12 +0000
Subject: [issue6252] logging midnight rotation
In-Reply-To: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>
Message-ID: <1244629812.67.0.525275840457.issue6252@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vsajip
nosy: +vsajip
title: logging midnigh rotation -> logging midnight rotation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6252>
_______________________________________

From report at bugs.python.org  Wed Jun 10 12:37:44 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 10 Jun 2009 10:37:44 +0000
Subject: [issue6251] c++ extension module implementation guide/example in
	extending/embedding documentation
In-Reply-To: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>
Message-ID: <1244630264.18.0.919607356561.issue6251@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6251>
_______________________________________

From report at bugs.python.org  Wed Jun 10 12:42:33 2009
From: report at bugs.python.org (OG7)
Date: Wed, 10 Jun 2009 10:42:33 +0000
Subject: [issue5331] multiprocessing hangs when Pool used within Process
In-Reply-To: <1235146028.47.0.682929217877.issue5331@psf.upfronthosting.co.za>
Message-ID: <1244630553.31.0.490096497628.issue5331@psf.upfronthosting.co.za>


OG7 <onyxg7 at users.sourceforge.net> added the comment:

It seems the root cause is at http://bugs.python.org/issue5155 .
A workaround is to use a duplex Pipe in SimpleQueue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5331>
_______________________________________

From report at bugs.python.org  Wed Jun 10 13:19:40 2009
From: report at bugs.python.org (OG7)
Date: Wed, 10 Jun 2009 11:19:40 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1244632780.15.0.991128838044.issue5313@psf.upfronthosting.co.za>


OG7 <onyxg7 at users.sourceforge.net> added the comment:

Using sys.stdin.close() fixes issues 5155 and 5331.

----------
nosy: +OG7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Wed Jun 10 13:20:26 2009
From: report at bugs.python.org (OG7)
Date: Wed, 10 Jun 2009 11:20:26 +0000
Subject: [issue5155] Multiprocessing.Queue created by sub-process fails when
	used in sub-sub-process ("bad file descriptor" in q.get())
In-Reply-To: <1233798773.64.0.357189782395.issue5155@psf.upfronthosting.co.za>
Message-ID: <1244632826.52.0.758193640748.issue5155@psf.upfronthosting.co.za>


OG7 <onyxg7 at users.sourceforge.net> added the comment:

Issue 5313 seems to be the culprit.

----------
nosy: +OG7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5155>
_______________________________________

From report at bugs.python.org  Wed Jun 10 13:23:33 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 10 Jun 2009 11:23:33 +0000
Subject: [issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path'
	./configure breaks the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1244633013.87.0.454299568194.issue5201@psf.upfronthosting.co.za>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

Hi

What's the status of this?  I haven't seen a commit message regarding this.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5201>
_______________________________________

From report at bugs.python.org  Wed Jun 10 13:39:22 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 10 Jun 2009 11:39:22 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1244633962.33.0.273396204789.issue5313@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Worth noting is that Python documentation in:

http://docs.python.org/library/stdtypes.html

says:

"""
file.fileno()
Return the integer ?file descriptor? that is used by the underlying 
implementation to request I/O operations from the operating system. This 
can be useful for other, lower level interfaces that use file 
descriptors, such as the fcntl module or os.read() and friends.

Note File-like objects which do not have a real file descriptor should 
not provide this method!
"""

So, if sys.stdin is replaced with a file like object, then the code 
should not be assuming that fileno() even exists.

At the moment the code doesn't check for AttributeError which is what is 
going to be raised for trying to access non existent fileno() method.

"""
>>> import StringIO
>>> s=StringIO.StringIO("xxx")
>>> s.fileno()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: StringIO instance has no attribute 'fileno'
"""

Thus error propagates. The better check though would be to use:

    def _bootstrap(self):
       ....
            if sys.stdin is not None and hasattr(sys.stdin, "fileno"):
                try:
                    os.close(sys.stdin.fileno())
                except (OSError, ValueError):
                    pass

That is, only actually call fileno() if it is present.

This would solve the problem for the original reported issue by making 
it actually adhere to what Python documentation says about existence of 
fileno().

This change wouldn't necessarily solve other peoples related issues 
though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Wed Jun 10 15:58:02 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 10 Jun 2009 13:58:02 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1244642282.9.0.123774704077.issue5313@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

Wouldn't it be more pythonic to just try sys.stdin.fileno() and catch 
the AtributeError too?

def _bootstrap(self):
       ....
            try:
                os.close(sys.stdin.fileno())
            except AtributeError:
                sys.stdin.close()
            except (OSError, ValueError):
                pass

----------
nosy: +ptn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Wed Jun 10 16:09:24 2009
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 10 Jun 2009 14:09:24 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <4A2F5696.3050206@v.loewis.de>
Message-ID: <d11dcfba0906100709p265bec8bu5963758183760470@mail.gmail.com>


Steven Bethard <steven.bethard at gmail.com> added the comment:

On Tue, Jun 9, 2009 at 11:45 PM, Martin v. L?wis<report at bugs.python.org> wrote:
> It would be useful if several people could confirm that argparse
> is *not* horribly designed.

A totally reasonable request. Anyone willing to evaluate this can take
a look at:

http://argparse.googlecode.com/svn/trunk/argparse.py

It also may help to look at the extensive test suite:

http://argparse.googlecode.com/svn/trunk/test/test_argparse.py

If anyone has specific questions about how something works or how to
extend argparse with new functionality, I'm happy to answer those
questions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Wed Jun 10 16:18:55 2009
From: report at bugs.python.org (Lowell Alleman)
Date: Wed, 10 Jun 2009 14:18:55 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1244614225.26.0.798627911538.issue4749@psf.upfronthosting.co.za>
Message-ID: <839ec5810906100718w77c8b609na6ebdb089f39b1@mail.gmail.com>


Lowell Alleman <lowell87 at gmail.com> added the comment:

I must say that Vinay's findings are most interesting.  Thanks Vinay
for tracking this down!

Just a thought, but has anybody tried this using the subprocess
module?  I've glanced through subprocess.py and it certainly does not
use os.system().  Instead it uses CreateProcess() on windows and
os.execvp*() on all other platforms.  It also appears to go to great
effort to properly deal with file handles, so I'm wondering if that
would resolve this issue.  (The current 2.6 docs, state that the
subprocess "module is preferable" over the os.system() call, and that
"All of the popen*() functions are obsolete. Use the subprocess
module.")

I'm quite curious to see if my ConcurrentLogHandler will fare any
better with this scenario.  I would really like for it to be able to
handle this scenario, since it's design goals are to be resilient to
this type of thing.  But I'm relying on the threading system and locks
too, so it's hard to say what will happen.

Robert, I agree that submitting a new bug on this would be a good idea
if none currently exists.  I also think it would be good to to put a
warning in the docs about this scenario if there is nothing that can
be done to correct the situation.  Even it if is not Python-specific
thing, I think it is good to let people know about gotchas whenever
possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 16:28:17 2009
From: report at bugs.python.org (Jan Pobrislo)
Date: Wed, 10 Jun 2009 14:28:17 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>


New submission from Jan Pobrislo <ccx at volny.cz>:

When using OptionParser.format_help(formatter), the formatter parameter
should be used to format all of the help message. This is not the case
for usage message, as the method get_usage() is not passed the formatter
and always uses self.formatter. I'm using python-2.6.2-r1.

----------
components: Extension Modules
files: fix_optparse_usage_formatter.diff
keywords: patch
messages: 89202
nosy: ccx
severity: normal
status: open
title: optparse.OptionParser.get_usage uses wrong formatter
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14254/fix_optparse_usage_formatter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Wed Jun 10 16:31:03 2009
From: report at bugs.python.org (Jan Pobrislo)
Date: Wed, 10 Jun 2009 14:31:03 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1244644263.96.0.343226653305.issue6253@psf.upfronthosting.co.za>


Changes by Jan Pobrislo <ccx at volny.cz>:


Added file: http://bugs.python.org/file14255/fix_optparse_usage_formatter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Wed Jun 10 16:31:28 2009
From: report at bugs.python.org (Jan Pobrislo)
Date: Wed, 10 Jun 2009 14:31:28 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1244644288.69.0.328982533767.issue6253@psf.upfronthosting.co.za>


Changes by Jan Pobrislo <ccx at volny.cz>:


Removed file: http://bugs.python.org/file14254/fix_optparse_usage_formatter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Wed Jun 10 17:06:06 2009
From: report at bugs.python.org (Eric Smith)
Date: Wed, 10 Jun 2009 15:06:06 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244646366.29.0.0549350421634.issue6247@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'll take a look at it. I've been meaning to use argparse, anyway.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Wed Jun 10 17:07:36 2009
From: report at bugs.python.org (Jan Pobrislo)
Date: Wed, 10 Jun 2009 15:07:36 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1244646456.65.0.653984842581.issue6253@psf.upfronthosting.co.za>


Jan Pobrislo <ccx at volny.cz> added the comment:

On second thought method name starting with get_ doesn't signify any
formatting, so it might be better to either:

1) Move call to formatter.format_usage from get_usage directly to
format_help.

2) Create method format_usage in OptionParser and call it from there.

----------
Added file: http://bugs.python.org/file14256/fix_optparse_usage_formatter2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Wed Jun 10 17:12:46 2009
From: report at bugs.python.org (OG7)
Date: Wed, 10 Jun 2009 15:12:46 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1244646766.54.0.00453191291083.issue5313@psf.upfronthosting.co.za>


OG7 <onyxg7 at users.sourceforge.net> added the comment:

Closing the stdin fd without closing the stdin file is very dangerous.
It means that stdin will now access some random resource, for example, a
pipe created with os.pipe().

Closing stdin is useful to let the parent be alone in reading from it.
It can be achieved by replacing stdin by open('/dev/null'). The original
stdin can be closed or left to be garbage collected.

The "double flush" case is impossible to handle in general. It's the
libc's responsibility for standard file objects and sockets. But it
can't be helped (except by putting a warning in the documentation) if
someone combines multiprocessing with non-fork-safe code that keeps its
own buffers and doesn't check for a pid change.

So that code in _bootstrap should be:
sys.stdin.close()
sys.stdin = open(os.devnull)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Wed Jun 10 17:30:30 2009
From: report at bugs.python.org (Jan Pobrislo)
Date: Wed, 10 Jun 2009 15:30:30 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1244647830.1.0.222450888408.issue6253@psf.upfronthosting.co.za>


Changes by Jan Pobrislo <ccx at volny.cz>:


Removed file: http://bugs.python.org/file14256/fix_optparse_usage_formatter2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Wed Jun 10 17:30:39 2009
From: report at bugs.python.org (Jan Pobrislo)
Date: Wed, 10 Jun 2009 15:30:39 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1244647839.7.0.342782483838.issue6253@psf.upfronthosting.co.za>


Changes by Jan Pobrislo <ccx at volny.cz>:


Added file: http://bugs.python.org/file14257/fix_optparse_usage_formatter2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Wed Jun 10 17:46:52 2009
From: report at bugs.python.org (Michael K Johnson)
Date: Wed, 10 Jun 2009 15:46:52 +0000
Subject: [issue6254] tarfile unnecessarily requires seekable files
In-Reply-To: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>
Message-ID: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>


New submission from Michael K Johnson <a1237+pybugs at danlj.org>:

In python 2.6 (not 2.4, haven't checked 2.5), the __init__() method of
the TarFile class calls the tell() method on the tar file, which doesn't
work if you are reading from standard input or writing to standard
output, two very reasonable things to do with a tar file.

While there are cases where it is logical to seek within a tar file,
supporting those cases should not preclude the normal design case for
tar archives of streaming reads/writes, including tar files being
streamed between processes via pipes.  If the tell() method is not
implemented for the file object, then the seek() method of TarFile (and
any other methods that can be implemented only for seekable files) can
raise a reasonable exception.  Note that this also means that the next()
method should not need to seek() for non-seekable files; it should
assume that it is at the correct block and read from there.

----------
components: Library (Lib)
messages: 89206
nosy: johnsonm
severity: normal
status: open
title: tarfile unnecessarily requires seekable files
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6254>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:03:30 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Jun 2009 16:03:30 +0000
Subject: [issue6252] logging midnight rotation
In-Reply-To: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>
Message-ID: <1244649810.92.0.655584482803.issue6252@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm unable to reproduce this problem with Python 2.5.2 on either Windows
XP or Ubuntu Hardy.

I used a test script (httpd.py, attached). This sets up an HTTP server
which you can use to trigger logging events.

I created a time simulator to allow testing in a timely way. This
monkey-patches the binding for the time module in logging and
logging.handlers to return either the real time or the simulated time.
Once you have started the server (just run the script), you can trigger
a logging event by running

wget -o /dev/null http://localhost:9022/

and you can initiate simulated timing by running

wget -o /dev/null http://localhost:9022/s

The simulated time is set to the next midnight, to facilitate rollover.
I then ran

wget -o /dev/null http://localhost:9022/

three times, then

wget -o /dev/null http://localhost:9022/s

once, then

wget -o /dev/null http://localhost:9022/

again three times. The only files created were:

vinay at zeta-hardy:~$ ls -l  httpd.log*
-rw-r--r-- 1 vinay vinay 192 2009-06-10 16:46 httpd.log
-rw-r--r-- 1 vinay vinay 256 2009-06-10 16:46 httpd.log.2009-06-10

which is as expected, and the contents are:

vinay at zeta-hardy:~$ cat httpd.log.2009-06-10 
2009-06-10 16:46:22,999 pid: 512 DEBUG - OK 2009-06-10 16:46:22
2009-06-10 16:46:23,765 pid: 512 DEBUG - OK 2009-06-10 16:46:23
2009-06-10 16:46:24,406 pid: 512 DEBUG - OK 2009-06-10 16:46:24
2009-06-10 16:46:25,974 pid: 512 DEBUG - OK 2009-06-10 16:46:25

and

vinay at zeta-hardy:~$ cat httpd.log
2009-06-11 00:00:01,260 pid: 512 DEBUG - OK 2009-06-11 00:00:01
2009-06-11 00:00:01,923 pid: 512 DEBUG - OK 2009-06-11 00:00:01
2009-06-11 00:00:02,547 pid: 512 DEBUG - OK 2009-06-11 00:00:02

which is again as expected.

Please try out the test script in your environment and feed back the
results you get.

----------
resolution:  -> works for me
status: open -> pending
Added file: http://bugs.python.org/file14258/httpd.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6252>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:07:01 2009
From: report at bugs.python.org (Naoki INADA)
Date: Wed, 10 Jun 2009 16:07:01 +0000
Subject: [issue6255] PyInt_FromSize_t is undocumented.
In-Reply-To: <1244650021.11.0.405068030111.issue6255@psf.upfronthosting.co.za>
Message-ID: <1244650021.11.0.405068030111.issue6255@psf.upfronthosting.co.za>


New submission from Naoki INADA <songofacandy at gmail.com>:

PyInt_FromSize_t() is not in Python/C API document.
People seeing document may be not able to find how to make int from 
unsigned long.

----------
assignee: georg.brandl
components: Documentation
messages: 89208
nosy: georg.brandl, naoki
severity: normal
status: open
title: PyInt_FromSize_t is undocumented.
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6255>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:08:12 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 10 Jun 2009 16:08:12 +0000
Subject: [issue6256] Wrong stacklevel in warning for contextlib.nested
In-Reply-To: <1244650092.01.0.50718314097.issue6256@psf.upfronthosting.co.za>
Message-ID: <1244650092.01.0.50718314097.issue6256@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

This leads to unhelpful warnings:

>>> with contextlib.nested(open("x", "w")) as f: pass
... 
/usr/local/lib/python3.1/contextlib.py:17: DeprecationWarning:
With-statements now directly support multiple context managers
  return next(self.gen)

Patch is attached.

----------
components: Library (Lib)
files: warning_stacklevel.patch
keywords: patch
messages: 89209
nosy: hagen
severity: normal
status: open
title: Wrong stacklevel in warning for contextlib.nested
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14259/warning_stacklevel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6256>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:15:22 2009
From: report at bugs.python.org (Robert Cronk)
Date: Wed, 10 Jun 2009 16:15:22 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244650522.25.0.898554429593.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I changed the script to use subprocess (attached file) and got the same 
rollover errors as before.  I had to change cd and del to be cd.bat and 
del.bat which contained cd %1 and del %1 respectively since it appears 
subprocess can't run internal commands like cd and del (unless you 
specify shell = True, which I thought might defeat the purpose of the 
test).

I will search around for this bug to see if it's already been entered.  
If the python developers decide not to fix this by wrapping os.system 
(and I guess subprocess.Popen too) with locks to prevent this error, 
then I agree that it should at least be well documented.

----------
Added file: http://bugs.python.org/file14260/subprclg.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:15:47 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 16:15:47 +0000
Subject: [issue6256] Wrong stacklevel in warning for contextlib.nested
In-Reply-To: <1244650092.01.0.50718314097.issue6256@psf.upfronthosting.co.za>
Message-ID: <1244650547.28.0.451910227475.issue6256@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  r73333 and r73334

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6256>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:24:11 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Jun 2009 16:24:11 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244651051.66.0.938676733711.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

You may want to re-test with Popen(..., close_fds=True) with the latest
Python 2.6. From the latest docs:

http://docs.python.org/library/subprocess.html

"If close_fds is true, all file descriptors except 0, 1 and 2 will be
closed before the child process is executed. (Unix only). Or, on
Windows, if close_fds is true then no handles will be inherited by the
child process. Note that on Windows, you cannot set close_fds to true
and also redirect the standard handles by setting stdin, stdout or stderr."

In Python 2.5, you can't use close_fds on Windows. In the 2.5
documentation (ActivePython 2.5.2.2) the above paragraph ends with
"(Unix only)."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:26:30 2009
From: report at bugs.python.org (Collin Winter)
Date: Wed, 10 Jun 2009 16:26:30 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1244651190.56.0.678527692587.issue6250@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

As another data point, Unladen Swallow had to take explicit steps to
deal with this dead code when compiling bytecode to machine code. Since
Python's compiler isn't smart enough to ignore code following a "return"
or "raise" in the same suite, support for that had to percolate into our
compiler.

For me, it's cleanliness issue, not a performance issue. That certainly
lowers the priority, though.

The warning James is adding for dead code detection may also be useful;
it looks to have already found one bug in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:27:09 2009
From: report at bugs.python.org (Robert Cronk)
Date: Wed, 10 Jun 2009 16:27:09 +0000
Subject: [issue1425127] os.remove OSError: [Errno 13] Permission denied
Message-ID: <1244651229.82.0.85760092765.issue1425127@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

Could this problem be associated with issue4749?  It was found that 
something goes wrong when two cmd children processes are spawned from 
different threads, when the first exits, it is closing file handles 
shared with the first (or something like that) and it's causing a 
problem with logging in issue4749.  That bug has been closed since it's 
not a problem with logging so I'm searching for other similar bugs to 
see if we can create a new bug that documents the cause and link to 
these other bugs that are all showing different symptoms of the bug.  
Thoughts?

----------
nosy: +rcronk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1425127>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:32:30 2009
From: report at bugs.python.org (Robert Cronk)
Date: Wed, 10 Jun 2009 16:32:30 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244651550.0.0.876078949225.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

I found Issue1425127 which may be a different symptom of this core 
problem.  I suggested that we create a bug that documents the core 
problem here as described by Vinay in msg89174 and links to these two 
bugs (along with any others we find) as examples of the types of 
symptoms that can come from this bug.  At that point, the merits of 
working around this bug in python versus documenting the problem for 
python users to work around it can be discussed and a decision can be 
made.  Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:37:20 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 16:37:20 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1244651840.22.0.432312214932.issue6250@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It looks like the patch is extensive and well thought out.  I look
forward to going through it in detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:47:22 2009
From: report at bugs.python.org (Andy Harrington)
Date: Wed, 10 Jun 2009 16:47:22 +0000
Subject: [issue6257] Idle terminates on source save while debugging
In-Reply-To: <1244652442.36.0.452724625348.issue6257@psf.upfronthosting.co.za>
Message-ID: <1244652442.36.0.452724625348.issue6257@psf.upfronthosting.co.za>


New submission from Andy Harrington <aharrin at luc.edu>:

When I am running the idle debugger, and change something in a source
file and save it, the save works but idle immediately closes. 

I can see the debugger not liking it, but it would be much better if
just the debugger stopped, not the whole idle environment.

I'm running XP professional, Python 3.0.1

----------
messages: 89217
nosy: andyharrington
severity: normal
status: open
title: Idle terminates on source save while debugging
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6257>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:56:41 2009
From: report at bugs.python.org (Robert Cronk)
Date: Wed, 10 Jun 2009 16:56:41 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244653001.69.0.946709618521.issue4749@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

One more possibly related bug is issue2320 where subprocesses are 
spawned from multiple threads.  They found an interesting workaround 
that I found seems to help our problem too: "on Windows, if close_fds 
is true then no handles will be inherited by the child process."  So if 
I change the subprocess.Popen lines in my most recently uploaded script 
to:

rc = subprocess.Popen('cd.bat . > blah.txt', close_fds=True).wait()
rc = subprocess.Popen('del.bat blah.txt', close_fds=True).wait()

The rollover logging failure goes away.  Does os.system have a similar 
option?  If not, then that would mean I'd have to convert all os.system 
calls to subprocess.Popen and add the close_fds=True parameter to it.  
The problem with this is that "Note that on Windows, you cannot set 
close_fds to true and also redirect the standard handles by setting 
stdin, stdout or stderr" and I am using both stdin and stdout on my 
main subprocess.Popen call and I have a couple of os.system calls as 
well.  Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Jun 10 18:58:43 2009
From: report at bugs.python.org (Robert Cronk)
Date: Wed, 10 Jun 2009 16:58:43 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1244653123.93.0.290385068636.issue2320@psf.upfronthosting.co.za>


Robert Cronk <cronk.r at gmail.com> added the comment:

Could this problem be associated with issue4749?  It was found that 
something goes wrong when two cmd children processes are spawned from 
different threads, when the first exits, it is closing file handles 
shared with the first (or something like that) and it's causing a 
problem with logging in issue4749.  That bug has been closed since it's 
not a problem with logging itself so I'm searching for other similar 
bugs to see if we can create a new bug that documents the cause and 
link to these other bugs that are all showing different symptoms of the 
bug.  Thoughts?

----------
nosy: +rcronk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Wed Jun 10 19:57:31 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 10 Jun 2009 17:57:31 +0000
Subject: [issue1069410] import on Windows: please call SetErrorMode first
Message-ID: <1244656651.81.0.380522341491.issue1069410@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

i.e., fixed in r60221

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1069410>
_______________________________________

From report at bugs.python.org  Wed Jun 10 20:10:45 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Jun 2009 18:10:45 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows fail
	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

It appears as if bdist_msi isn't properly tagging 64-bit binary builds.

When launching an .msi built by Python 2.6.2 using bdist_msi, such as
numpy found here
(https://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103),
it improperly detects the location of Python (which it gets from the
registry).  If the 32-bit Python 2.6 is also installed, it finds that
version.  If 32-bit Python 2.6 is not installed, it fails to find the
Python installation.  Even if the proper 64-bit Python 2.6 location is
selected, the files are not installed to the Python 2.6 site-packages. 
Furthermore, the registry Uninstall information is stored in the
Wow6432Node.

bdist_wininst executables appear to detect 64-bit Python and install
correctly.

I will attempt to recreate this problem with a minimal project and clean
64-bit Vista or Windows 7 machine at a later date.

----------
assignee: tarek
components: Distutils
messages: 89221
nosy: jaraco, tarek
severity: normal
status: open
title: distributions built with bdist_msi on 64-bit Windows fail to install correctly
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Wed Jun 10 20:24:44 2009
From: report at bugs.python.org (Jason Kankiewicz)
Date: Wed, 10 Jun 2009 18:24:44 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244658284.82.0.981922096203.issue1254718@psf.upfronthosting.co.za>


Jason Kankiewicz <jkankiewicz at acm.org> added the comment:

Seo, This ticket specifies Python-2.6 as the only version so using "any"
didn't seem to be a problem. 
I was not aware of PEP 291 until you mentioned it and, in order to
maintain compatibility with Python-2.3, the generator expression would
have to be dispensed with as well.

Raymond, I would prefer to substitute "max" for "any" in this case as it
seems to be more straightforward. There's no performance benefit to
using "min" as both "min" and "max" are O(n), no?

----------
Added file: http://bugs.python.org/file14261/distutils-rpath-gcc_and_icc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 20:33:43 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 18:33:43 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244658823.71.0.861670771591.issue1254718@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

min() is a substitute for all() and
max() is a substitute for any().

They are O(n) but do not have the early
out behavior of any() and all().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 20:34:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 18:34:00 +0000
Subject: [issue1254718] GCC detection for runtime_library_dirs when ccache is
	used
Message-ID: <1244658840.87.0.0849576934627.issue1254718@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254718>
_______________________________________

From report at bugs.python.org  Wed Jun 10 21:26:50 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 10 Jun 2009 19:26:50 +0000
Subject: [issue6254] tarfile unnecessarily requires seekable files
In-Reply-To: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>
Message-ID: <1244662010.02.0.178204452451.issue6254@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

If I am not mistaken the functionality you look for is the streaming
mode of tarfile.open():

tar = tarfile.open(fileobj=sys.stdin, mode="r|*")

Does this solve your problem?

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6254>
_______________________________________

From report at bugs.python.org  Wed Jun 10 21:38:00 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 10 Jun 2009 19:38:00 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements some pointer arithmetic operations for ctypes.

----------
files: ctypes-pointerarith.patch
keywords: patch
messages: 89225
nosy: theller
severity: normal
status: open
title: ctypes pointer arithmetic
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14262/ctypes-pointerarith.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Wed Jun 10 21:39:59 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 10 Jun 2009 19:39:59 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1244662799.48.0.940992681568.issue6259@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
assignee:  -> theller
components: +ctypes
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Wed Jun 10 21:50:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Jun 2009 19:50:10 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1244663410.34.0.12367482327.issue6259@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Wed Jun 10 22:05:14 2009
From: report at bugs.python.org (Michael K Johnson)
Date: Wed, 10 Jun 2009 20:05:14 +0000
Subject: [issue6254] tarfile unnecessarily requires seekable files
In-Reply-To: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>
Message-ID: <1244664314.1.0.503978369805.issue6254@psf.upfronthosting.co.za>


Michael K Johnson <a1237+pybugs at danlj.org> added the comment:

We are doing output, and mode='w|' works.  We were using
tarfile.TarFile, not realizing that the default constructor was an
unsupported and deprecated interface (!?!)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6254>
_______________________________________

From report at bugs.python.org  Wed Jun 10 22:06:33 2009
From: report at bugs.python.org (James)
Date: Wed, 10 Jun 2009 20:06:33 +0000
Subject: [issue6260] os.utime should allow None values for ATIME or MTIME
In-Reply-To: <1244664392.83.0.0874142819498.issue6260@psf.upfronthosting.co.za>
Message-ID: <1244664392.83.0.0874142819498.issue6260@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

Hi, in using os.utime, it's nice that you can specify `None' for the
second argument. However it would be even `nicer' to be able to specify
None for either (or potentially both) values for the argument in the
tuple. to emulate this, i've been using os.stat to read the value
beforehand, and just use os.utime with the new value, and the old one
pulled from stat()

HTH, _J

example:
os.utime('/dev/pts/1', None) WORKS
os.utime('/dev/pts/1') SHOULD WORK (allow second argument to default to
None)
os.utime('/dev/pts/1', (time.time(), None)) SHOULD WORK
os.utime('/dev/pts/1', (None, None)) SHOULD WORK
os.utime('/dev/pts/1', (None, time.time())) I GUESS SHOULD WORK

ps: if this is a feature you'd agree with, let me know any maybe i can
*try* to write a patch?

----------
components: IO
messages: 89227
nosy: purpleidea
severity: normal
status: open
title: os.utime should allow None values for ATIME or MTIME
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6260>
_______________________________________

From report at bugs.python.org  Wed Jun 10 22:16:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Jun 2009 20:16:40 +0000
Subject: [issue6255] PyInt_FromSize_t is undocumented.
In-Reply-To: <1244650021.11.0.405068030111.issue6255@psf.upfronthosting.co.za>
Message-ID: <1244665000.57.0.0620677279524.issue6255@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It seems to me that PyInt_FromSize_t() wouldn't be the right way to create a Python 
int from a C unsigned long anyway, since there's no guarantee that C's unsigned 
long and size_t have the same precision.

(I'm not disputing that PyInt_FromSize_t should be documented, by the way.)

Maybe a PyInt_FromUnsignedLong method would be useful?  It would be trivial to 
implement.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6255>
_______________________________________

From report at bugs.python.org  Wed Jun 10 22:30:23 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Jun 2009 20:30:23 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B67E2DDA50E9@hornigold.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Indeed, I confirmed that using the simple example from the distutils manual (http://docs.python.org/distutils/introduction.html#a-simple-example) on a clean install of Python 2.6.2, bdist_msi exhibits the behavior previously described.

I suspect that the TargetPlatform property needs to be set (based on what I read here: http://msdn.microsoft.com/en-us/library/cd7a85k9(VS.80).aspx ).

----------
title: distributions built with bdist_msi on 64-bit Windows fail to install correctly -> distributions built with bdist_msi on 64-bit Windows fail	to install correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Wed Jun 10 23:21:35 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Jun 2009 21:21:35 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244668895.59.0.397617770462.issue6258@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Based on the MSDN article and what I read in a blog entry
(http://blogs.msdn.com/heaths/archive/2005/10/24/windows-installer-on-64-bit-platforms.aspx),
I thought that the enclosed patch might work around the issue... and
while it does set the template property to x64, the undesirable behavior
persists.

Index: Lib/msilib/__init__.py
===================================================================
--- Lib/msilib/__init__.py      (revision 73295)
+++ Lib/msilib/__init__.py      (working copy)
@@ -3,8 +3,11 @@
 # Licensed to PSF under a Contributor Agreement.
 from _msi import *
 import os, string, re
+import sys

-Win64=0
+Intel64=0
+AMD64 = 'AMD64' in sys.version
+Win64 = Intel64 or AMD64

 # Partially taken from Wine
 datasizemask=      0x00ff
@@ -145,8 +148,10 @@
     si.SetProperty(PID_TITLE, "Installation Database")
     si.SetProperty(PID_SUBJECT, ProductName)
     si.SetProperty(PID_AUTHOR, Manufacturer)
-    if Win64:
+    if Intel64:
         si.SetProperty(PID_TEMPLATE, "Intel64;1033")
+    elif AMD64:
+        si.SetProperty(PID_TEMPLATE, "x64;1033")
     else:
         si.SetProperty(PID_TEMPLATE, "Intel;1033")
     si.SetProperty(PID_REVNUMBER, gen_uuid())

----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Wed Jun 10 23:23:54 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Jun 2009 21:23:54 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244669034.86.0.0884070598626.issue6258@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm adding Martin to this as he appears to be the author of msilib.  If
it's inappropriate for me to do this, I apologize.  Just let me know and
I won't do it again.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Wed Jun 10 23:30:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Jun 2009 21:30:28 +0000
Subject: [issue6261] Clarify behaviour of random.uniform
In-Reply-To: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>
Message-ID: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The documentation for random.uniform() was recently updated to reflect 
the fact that it's possible for random.uniform(a, b) to produce the 
value b;  see issue 4979.

In a recent c.l.p. thread, Robert Kern suggested that 'it 
might be confusing to a user why random.random() returns values in a 
half-open interval while random.uniform() claims a closed interval';  
the thread itself confirms this potential for confusion.  See

http://mail.python.org/pipermail/python-list/2009-June/715851.html

Suggested extra wording for random.uniform, from Robert Kern:

"Due to floating point arithmetic, for some values of a and b, b may or 
may not be one of the possible generated results."

----------
assignee: georg.brandl
components: Documentation
messages: 89232
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Clarify behaviour of random.uniform
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6261>
_______________________________________

From report at bugs.python.org  Wed Jun 10 23:40:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 21:40:16 +0000
Subject: [issue6261] Clarify behaviour of random.uniform
In-Reply-To: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>
Message-ID: <1244670016.44.0.557889522988.issue6261@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6261>
_______________________________________

From report at bugs.python.org  Thu Jun 11 00:00:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Jun 2009 22:00:41 +0000
Subject: [issue6261] Clarify behaviour of random.uniform
In-Reply-To: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>
Message-ID: <1244671241.51.0.730966676248.issue6261@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Regardless of whether the extra wording is added or not, the docstring for 
random.uniform should probably be changed to match the online 
documentation.  It currently says:

"""Get a random number in the range [a, b)."""

That should probably be:

"""Get a random number in the range [a, b]."""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6261>
_______________________________________

From report at bugs.python.org  Thu Jun 11 00:03:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Jun 2009 22:03:29 +0000
Subject: [issue6261] Clarify behaviour of random.uniform
In-Reply-To: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>
Message-ID: <1244671409.64.0.401442043171.issue6261@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6261>
_______________________________________

From report at bugs.python.org  Thu Jun 11 02:57:40 2009
From: report at bugs.python.org (Naoki INADA)
Date: Thu, 11 Jun 2009 00:57:40 +0000
Subject: [issue6255] PyInt_FromSize_t is undocumented.
In-Reply-To: <1244650021.11.0.405068030111.issue6255@psf.upfronthosting.co.za>
Message-ID: <1244681860.49.0.638804291297.issue6255@psf.upfronthosting.co.za>


Naoki INADA <songofacandy at gmail.com> added the comment:

You're right. PyInt_FromSize_t() isn't safe for unsigned long.

> Maybe a PyInt_FromUnsignedLong method would be useful?  It would be 
trivial to 
> implement.

I hope that all of py3k's PyInt_From** are in Python 2.x.
It makes maintaining extension module for both of Py2.x and Py3k a bit 
easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6255>
_______________________________________

From report at bugs.python.org  Thu Jun 11 05:52:59 2009
From: report at bugs.python.org (Turnaev Evgeny)
Date: Thu, 11 Jun 2009 03:52:59 +0000
Subject: [issue6252] logging midnight rotation
In-Reply-To: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>
Message-ID: <1244692379.46.0.936628627638.issue6252@psf.upfronthosting.co.za>


Turnaev Evgeny <xiled at yandex.ru> added the comment:

I am sorry for my poor english. You must be misunderstood me.
I attached a file try it like this:

wget -o /dev/null http://localhost:9022/

then 5-7 times
wget -o /dev/null http://localhost:9022/s

then 4-5 times 
wget -o /dev/null http://localhost:9022/

i bet this error persists in 3.1

----------
status: pending -> open
Added file: http://bugs.python.org/file14263/httpd.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6252>
_______________________________________

From report at bugs.python.org  Thu Jun 11 08:39:10 2009
From: report at bugs.python.org (John O'Driscoll)
Date: Thu, 11 Jun 2009 06:39:10 +0000
Subject: [issue6251] c++ extension module implementation guide/example in
	extending/embedding documentation
In-Reply-To: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>
Message-ID: <1244702350.43.0.755220032265.issue6251@psf.upfronthosting.co.za>


John O'Driscoll <biggerbumme at yahoo.co.in> added the comment:

I'm aware of Boost without being familiar. I should find out more. I 
don't have any reason to think it might not be the better approach.

I guess when I wrote this I was thinking in terms of minimising 
dependencies: writing a program that depended only on the standard 
libraries of c/c++ and python. In that context, if Boost-python were to 
become a part of a stdlib, there'd be no need at all for this. Are there 
any plans afoot?

Also, if dependencies are not a problem for your project, Boost might be 
the way to go. I won't indulge in any polemic one way or the other. I 
just thought a DIY primer might be useful in some contexts. Whether the 
official docs is the place for it I don't know.

John O'Driscoll

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6251>
_______________________________________

From report at bugs.python.org  Thu Jun 11 09:06:16 2009
From: report at bugs.python.org (Bellenot)
Date: Thu, 11 Jun 2009 07:06:16 +0000
Subject: [issue6262] VS 2008 binaries
In-Reply-To: <1244703976.71.0.511260473865.issue6262@psf.upfronthosting.co.za>
Message-ID: <1244703976.71.0.511260473865.issue6262@psf.upfronthosting.co.za>


New submission from Bellenot <bertrand.bellenot at cern.ch>:

Hi,

Would it be possible to obtain MSVC++2008(9.0) binaries of Python 2.5.4?
We are actually stuck to this version and have problem with MSVC 
runtime libraries incompatibility. I can build Python.exe from source, 
but there are a lot of missing modules (external dependencies). Then, 
as you already build full binaries with MSVC++7.1, I was wondering if 
it would be possible for you to build MSVC++9.0(2008) binaries...
Thanks in advance.

Cheers, Bertrand.

----------
components: Windows
messages: 89238
nosy: bellenot
severity: normal
status: open
title: VS 2008 binaries
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6262>
_______________________________________

From report at bugs.python.org  Thu Jun 11 10:35:56 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Jun 2009 08:35:56 +0000
Subject: [issue5201] Using LDFLAGS='-rpath=\$$LIB:/some/other/path'
	./configure breaks the build
In-Reply-To: <1234266292.13.0.602157766238.issue5201@psf.upfronthosting.co.za>
Message-ID: <1244709356.18.0.396175171202.issue5201@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73341 in trunk. I've backported it as well in 2.6/3.0/3.1
branches. (r73342, r73343, r73344)

Thanks !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5201>
_______________________________________

From report at bugs.python.org  Thu Jun 11 10:38:15 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Jun 2009 08:38:15 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244709495.32.0.897628603378.issue6258@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

No that's fine Jason, I was about to do it ;)

I can work on the patch and commit it since it's distutils-related, but
Martin is the one that will validate it and give the green light on msi
matters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Thu Jun 11 10:54:05 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 11 Jun 2009 08:54:05 +0000
Subject: [issue6254] tarfile unnecessarily requires seekable files
In-Reply-To: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>
Message-ID: <1244710445.54.0.249974203815.issue6254@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

tarfile.TarFile is neither unsupported nor deprecated. It is just too
low-level for everyday use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6254>
_______________________________________

From report at bugs.python.org  Thu Jun 11 11:11:11 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Jun 2009 09:11:11 +0000
Subject: [issue6263] syntax error in get_msvcr
In-Reply-To: <1244711471.55.0.267324152593.issue6263@psf.upfronthosting.co.za>
Message-ID: <1244711471.55.0.267324152593.issue6263@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

get_msvcr uses an unknown msc_Ver variable (should be msc_ver),
and wrong string formatting.

----------
assignee: tarek
components: Distutils
messages: 89242
nosy: tarek
severity: normal
status: open
title: syntax error in get_msvcr
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6263>
_______________________________________

From report at bugs.python.org  Thu Jun 11 11:30:14 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Jun 2009 09:30:14 +0000
Subject: [issue6263] syntax error in get_msvcr
In-Reply-To: <1244711471.55.0.267324152593.issue6263@psf.upfronthosting.co.za>
Message-ID: <1244712614.42.0.62900626821.issue6263@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73348, r73349, r73351, r73352

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6263>
_______________________________________

From report at bugs.python.org  Thu Jun 11 11:58:23 2009
From: report at bugs.python.org (Black Dew)
Date: Thu, 11 Jun 2009 09:58:23 +0000
Subject: [issue6264] Misleading instructions for installing extensions with
	mingw
In-Reply-To: <1244714303.63.0.906015224552.issue6264@psf.upfronthosting.co.za>
Message-ID: <1244714303.63.0.906015224552.issue6264@psf.upfronthosting.co.za>


New submission from Black Dew <blackdew at gmail.com>:

This page http://docs.python.org/install/index.html#gnu-c-cygwin-mingw 
says: 

"These instructions only apply if you?re using a version of Python 
prior to 2.4.1 with a MinGW prior to 3.0.0 (with binutils-2.13.90-
20030111-1)" 

But it seems that it is still needed for Python 2.6 with MinGW 3.15.2.

Without manually generating libpython26.a I can't compile any python 
extension, geting a bunch of undefined references, for example:

c:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6
\Release\zfec\fec.o build\temp.win32-2.6\Release\zfec\_fecmodule.o 
build\temp.win32-2.6\Release\zfec\_fec.def -LC:\Python26\libs -
LC:\Python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6
\zfec\_fec.pyd
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xefa): undefined reference to `_imp___Py_TrueStruct'
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xf01): undefined reference to `_imp___Py_TrueStruct'
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xf08): undefined reference to `_imp___Py_ZeroStruct'
build\temp.win32-2.6\Release\zfec\_fecmodule.o:_fecmodule.c:
(.text+0xf0f): undefined reference to `_imp___Py_ZeroStruct'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

If I do generate libpython26.a - everythong works fine.

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 89244
nosy: bdew, georg.brandl
severity: normal
status: open
title: Misleading instructions for installing extensions with mingw
versions: 3rd party, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6264>
_______________________________________

From report at bugs.python.org  Thu Jun 11 12:06:00 2009
From: report at bugs.python.org (Black Dew)
Date: Thu, 11 Jun 2009 10:06:00 +0000
Subject: [issue6264] Misleading instructions for building extensions with mingw
In-Reply-To: <1244714303.63.0.906015224552.issue6264@psf.upfronthosting.co.za>
Message-ID: <1244714760.31.0.0843476706445.issue6264@psf.upfronthosting.co.za>


Black Dew <blackdew at gmail.com> added the comment:

It seems this was writen to the docs after a discussion here: 
http://mail.python.org/pipermail/python-dev/2005-October/057717.html

>> As it turns out, MinGW also implemented, in version 3.0.0 (with
>> binutils-2.13.90-20030111-1), features which make the creation of
>> libpython24.a unnecessary

It looks like the current version of mingw sees python26.lib and 
incorrectly uses it.

If i remove python26.lib and place python26.dll instead - mingw uses 
the exports directly from the dll and everything works too (without 
needing libpython26.a).

This should be reflected in the documentation.

----------
title: Misleading instructions for installing extensions with mingw -> Misleading instructions for building extensions with mingw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6264>
_______________________________________

From report at bugs.python.org  Thu Jun 11 12:20:17 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Jun 2009 10:20:17 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1244715618.0.0.0926087886322.issue6245@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Thu Jun 11 12:32:11 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 11 Jun 2009 10:32:11 +0000
Subject: [issue6252] logging midnight rotation
In-Reply-To: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>
Message-ID: <1244716331.19.0.602634325115.issue6252@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk, release26-maint and py3k.

----------
resolution: works for me -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6252>
_______________________________________

From report at bugs.python.org  Thu Jun 11 12:46:47 2009
From: report at bugs.python.org (Neil Muller)
Date: Thu, 11 Jun 2009 10:46:47 +0000
Subject: [issue6265] cElementTree & ElementTree use different exceptions for
	XML Errors
In-Reply-To: <1244717207.44.0.0661498908043.issue6265@psf.upfronthosting.co.za>
Message-ID: <1244717207.44.0.0661498908043.issue6265@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

cElementTree will raise a SyntaxError on XML parsing errors, while
ElementTree will raise ExpatError.  This makes changing between the two
a bit more problematic than it could be. See for example
https://lists.canonical.com/archives/bazaar/2006q3/017491.html

ElementTree 1.3 raises a ParseError, which is subclassed from
SyntaxError, which will improve the situation when it's merged, but
cElementTree should be adjusted to raise the same error.

----------
messages: 89247
nosy: Neil Muller, effbot, jerith
severity: normal
status: open
title: cElementTree & ElementTree use different exceptions for XML Errors
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6265>
_______________________________________

From report at bugs.python.org  Thu Jun 11 12:53:52 2009
From: report at bugs.python.org (Neil Muller)
Date: Thu, 11 Jun 2009 10:53:52 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

Consider:

>>> from StringIO import StringIO
>>> source = StringIO('<body xmlns="http://&#233;ffbot.org/ns">text</body>')
>>> import xml.etree.ElementTree as ET
>>> events = ("start-ns",)
>>> context = ET.iterparse(source, events)
>>> for action, elem in context:
...    print action, elem
... 
start-ns ('', u'http://\xe9ffbot.org/ns')
>>> source.seek(0)
>>> import xml.etree.cElementTree as cET
>>> context = cET.iterparse(source, events)
>>> for action, elem in context:
...    print action, elem
... 
start-ns ('', 'http://\xc3\xa9ffbot.org/ns')

I'm not sure which is more correct here, but unsing different encodings
in the result is somewhat unexpected.

----------
messages: 89248
nosy: Neil Muller, effbot, jerith
severity: normal
status: open
title: cElementTree.iterparse & ElementTree.iterparse return differently encoded strings
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Thu Jun 11 12:54:28 2009
From: report at bugs.python.org (Neil Muller)
Date: Thu, 11 Jun 2009 10:54:28 +0000
Subject: [issue6232] Improve test coverage of ElementTree and cElementTree
In-Reply-To: <1244385084.63.0.587386346669.issue6232@psf.upfronthosting.co.za>
Message-ID: <1244717668.26.0.964911996314.issue6232@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

some additional notes on the tests disabled for cElementTree:

a) cElementTree still reports the last error (bug noted at
http://effbot.python-hosting.com/ticket/30 , although not filed in the
python bug tracker AFAICS).

b) cElementTree uses Syntax error in places were ElementTree uses
ExpatError - filed as issue6265

c) cEelementTree.iterparse will return normal strings when
ElementTree.iterparse will return unicode strings - filed as issue6266

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6232>
_______________________________________

From report at bugs.python.org  Thu Jun 11 13:15:54 2009
From: report at bugs.python.org (Tim Golden)
Date: Thu, 11 Jun 2009 11:15:54 +0000
Subject: [issue6262] VS 2008 binaries
In-Reply-To: <1244703976.71.0.511260473865.issue6262@psf.upfronthosting.co.za>
Message-ID: <4A30E75F.3000201@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I doubt there's any real likelihood of the official Python 2.5.4 being generated with a different compiler: it would mean, in principle, that all binary extensions would have be recompiled to ensure there were no issues. I suggest you ask on the Python mailing list / newsgroup where people can help you to compile things yourself as you obviously have the means.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6262>
_______________________________________

From report at bugs.python.org  Thu Jun 11 14:51:55 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Jun 2009 12:51:55 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1244724715.81.0.567198637593.issue6259@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I like this feature. Some comments:

- tests...

- unsupported operand types should return Py_NotImplemented.

- gcc supports pointer arithmetic with void*:
  http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
  Could ctypes do the same?

- Some operations are not allowed. If p1 and p2 are ctypes pointers,
  "p1 -= p2" will not work - but it's not a common usage.
  However, "p1 + 1" and "p1 - 1" seem very useful, and should be supported.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Thu Jun 11 17:05:05 2009
From: report at bugs.python.org (Bellenot)
Date: Thu, 11 Jun 2009 15:05:05 +0000
Subject: [issue6262] VS 2008 binaries
In-Reply-To: <1244703976.71.0.511260473865.issue6262@psf.upfronthosting.co.za>
Message-ID: <1244732705.54.0.546944497081.issue6262@psf.upfronthosting.co.za>


Bellenot <bertrand.bellenot at cern.ch> added the comment:

OK, thanks for the reply, I just wanted to be sure.
BTW, why, after having build python with Visual Studio 2008, is it 
still claiming that:
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible 
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin 
installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.
??
Cheers, Bertrand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6262>
_______________________________________

From report at bugs.python.org  Thu Jun 11 17:10:13 2009
From: report at bugs.python.org (Michael K Johnson)
Date: Thu, 11 Jun 2009 15:10:13 +0000
Subject: [issue6254] tarfile unnecessarily requires seekable files
In-Reply-To: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>
Message-ID: <1244733013.01.0.31323578599.issue6254@psf.upfronthosting.co.za>


Michael K Johnson <a1237+pybugs at danlj.org> added the comment:

OK, not intended for "everyday use"; I understand this as meaning that
it is considered primarily an internal interface, and thus one that has
an explicitly unstable API.  It is hard for me to guess that this would
be the case, since this intent is not documented in the docstrings or
comments of either TarFile.__init__() or TarFile.open()

If I'm understanding you correctly, this could be considered a
documentation bug; perhaps the docstring for TarFile.__init__() could
suggest using the open() method, except possibly within TarFile subclasses?

Sorry to be so confused here.  I hope I'm finally converging on
understanding...

Anyway, thanks for the help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6254>
_______________________________________

From report at bugs.python.org  Thu Jun 11 17:30:35 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 11 Jun 2009 15:30:35 +0000
Subject: [issue6267] Cumulative patch to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Please see 
http://codereview.appspot.com/73041/show

----------
messages: 89254
nosy: krisvale
severity: normal
status: open
title: Cumulative patch to http and xmlrpc
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Thu Jun 11 17:33:08 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 11 Jun 2009 15:33:08 +0000
Subject: [issue6267] Cumulative patch to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1244734388.05.0.145071803254.issue6267@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Consider this a superset of
http://bugs.python.org/issue6099
http://bugs.python.org/issue6096

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Thu Jun 11 19:53:39 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Jun 2009 17:53:39 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244742819.24.0.675319724346.issue6195@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unfortunately we're not out of the woods yet.  test_zipimport_support
has a failure with the patch applied.  I will investigate when I get a
chance, but I'm beginning to wonder if the doctest getsouce code needs
some refactoring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6195>
_______________________________________

From report at bugs.python.org  Thu Jun 11 20:26:43 2009
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 11 Jun 2009 18:26:43 +0000
Subject: [issue6268] Seeking to the beginning of a text file a second time
	will return the BOM as first character
In-Reply-To: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>
Message-ID: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

>>> f = open('foo', 'wt+', encoding='UTF-16')
>>> f.write('spam ham eggs')
13
>>> f.seek(0)
0
>>> f.read()
'spam ham eggs'
>>> f.seek(0)
0
>>> f.read()
'\ufeffspam ham eggs'

Although the BOM character is a ZERO WIDTH NO-BREAK SPACE, and should
therefore not impose many problems, the behavior is inconsistent and
unexpected.
codecs.open in 2.x suffers from this same behavior.

----------
components: Unicode
messages: 89257
nosy: eggy
severity: normal
status: open
title: Seeking to the beginning of a text file a second time will return the BOM as first character
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6268>
_______________________________________

From report at bugs.python.org  Thu Jun 11 20:33:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Jun 2009 18:33:54 +0000
Subject: [issue6268] Seeking to the beginning of a text file a second time
	will return the BOM as first character
In-Reply-To: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>
Message-ID: <1244745234.61.0.84457081038.issue6268@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is fixed in 3.1.

----------
nosy: +pitrou
priority:  -> low
versions:  -Python 2.4, Python 2.5, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6268>
_______________________________________

From report at bugs.python.org  Thu Jun 11 22:37:16 2009
From: report at bugs.python.org (Florian Mayer)
Date: Thu, 11 Jun 2009 20:37:16 +0000
Subject: [issue6269] threading documentation makes no mention of the GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

I think the GIL should be mentioned in the threading documentation, so
that people do not try to use them for scalability reasons.

----------
assignee: georg.brandl
components: Documentation
files: threading.rst.patch
keywords: patch
messages: 89259
nosy: georg.brandl, segfaulthunter
severity: normal
status: open
title: threading documentation makes no mention of the GIL
versions: Python 2.7
Added file: http://bugs.python.org/file14264/threading.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Thu Jun 11 22:58:24 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 11 Jun 2009 20:58:24 +0000
Subject: [issue6262] VS 2008 binaries
In-Reply-To: <1244703976.71.0.511260473865.issue6262@psf.upfronthosting.co.za>
Message-ID: <1244753904.81.0.515478696274.issue6262@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Would it be possible to obtain MSVC++2008(9.0) binaries of Python 2.5.4?

It's certainly possible to obtain them, if you create them yourself.
There won't be any further 2.5 binaries at all (regardless of compiler
version) from python.org

As for the distutils question: distutils has hard-coded knowledge what
compiler should have been used to compile Python, and prints that
message irrespective of what compiler was actually used. You'll have to
port distutils to VS 2008 yourself.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6262>
_______________________________________

From report at bugs.python.org  Thu Jun 11 23:09:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 11 Jun 2009 21:09:34 +0000
Subject: [issue6264] Misleading instructions for building extensions with mingw
In-Reply-To: <1244714303.63.0.906015224552.issue6264@psf.upfronthosting.co.za>
Message-ID: <1244754574.99.0.665861851685.issue6264@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's wrong with using the libpython26.a that is included in the
Windows distribution?

I don't think anecdotal observations should be included in the
documentation; an expert would have to confirm first what the right
procedure is.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6264>
_______________________________________

From report at bugs.python.org  Thu Jun 11 23:09:40 2009
From: report at bugs.python.org (Greg Couch)
Date: Thu, 11 Jun 2009 21:09:40 +0000
Subject: [issue6270] Menu deletecommand fails if command is already deleted
In-Reply-To: <1244754580.13.0.801057820447.issue6270@psf.upfronthosting.co.za>
Message-ID: <1244754580.13.0.801057820447.issue6270@psf.upfronthosting.co.za>


New submission from Greg Couch <gregc at cgl.ucsf.edu>:

Sometime around Python 2.5.4, Menu.delete was changed to delete
associated entry commands (and thus plug a memory leak).  This broke
Pmw.OptionMenu because it already had similar code, so when Menu.delete
was called, the commands were already gone, and a TclError was raised
saying "can't delete Tcl command".

While Pmw could be patched to workaround this bug, it seems strange that
Tkinter.Misc.deletecommand unconditionally deletes commands it knows
nothing about.  All uses of deletecommand in Tkinter refer to commands
that were Tkinter.Misc._register'ed, so they should appear in the
widget._tclCommands list.  So the proper solution is to only delete
commands that are still registered with the widget.

Repeat by:

import Pmw
om = Pmw.OptionMenu()
om.pack()
om.setitems(['a', 'b'])
om.setitems(['b'])

----------
components: Tkinter
files: delcmd.patch
keywords: patch
messages: 89262
nosy: gregcouch
severity: normal
status: open
title: Menu deletecommand fails if command is already deleted
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14265/delcmd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6270>
_______________________________________

From report at bugs.python.org  Thu Jun 11 23:17:26 2009
From: report at bugs.python.org (Greg Couch)
Date: Thu, 11 Jun 2009 21:17:26 +0000
Subject: [issue6270] Menu deletecommand fails if command is already deleted
In-Reply-To: <1244754580.13.0.801057820447.issue6270@psf.upfronthosting.co.za>
Message-ID: <1244755046.39.0.729774043334.issue6270@psf.upfronthosting.co.za>


Changes by Greg Couch <gregc at cgl.ucsf.edu>:


Added file: http://bugs.python.org/file14266/delcmd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6270>
_______________________________________

From report at bugs.python.org  Thu Jun 11 23:17:33 2009
From: report at bugs.python.org (Greg Couch)
Date: Thu, 11 Jun 2009 21:17:33 +0000
Subject: [issue6270] Menu deletecommand fails if command is already deleted
In-Reply-To: <1244754580.13.0.801057820447.issue6270@psf.upfronthosting.co.za>
Message-ID: <1244755053.3.0.717958413565.issue6270@psf.upfronthosting.co.za>


Changes by Greg Couch <gregc at cgl.ucsf.edu>:


Removed file: http://bugs.python.org/file14265/delcmd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6270>
_______________________________________

From report at bugs.python.org  Fri Jun 12 00:04:54 2009
From: report at bugs.python.org (Black Dew)
Date: Thu, 11 Jun 2009 22:04:54 +0000
Subject: [issue6264] Misleading instructions for building extensions with mingw
In-Reply-To: <1244714303.63.0.906015224552.issue6264@psf.upfronthosting.co.za>
Message-ID: <1244757894.46.0.130425277036.issue6264@psf.upfronthosting.co.za>


Black Dew <blackdew at gmail.com> added the comment:

It seems that the system I was testing on had the ActiveState python
distribution installed which does not include libpython26.a

I tried installing the official one from python.org and it has
libpython26.a and works fine.

Sorry about opening the bug at the wrong place :(

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6264>
_______________________________________

From report at bugs.python.org  Fri Jun 12 00:24:10 2009
From: report at bugs.python.org (Lowell Alleman)
Date: Thu, 11 Jun 2009 22:24:10 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1244653001.69.0.946709618521.issue4749@psf.upfronthosting.co.za>
Message-ID: <839ec5810906111524x6afb5b11je63dad03e70070c1@mail.gmail.com>


Lowell Alleman <lowell87 at gmail.com> added the comment:

For anyone who is interested, I did some testing with the
ConcurrentRotatingFileHandler from my ConcurrentLogHandler package (v
0.8.3). I've found that it does not fail when dropped into the
revised-logthred.py script.  However, it does spend most of the time
in what I call "degraded" mode because the file rotation fails--this
means that the log file is constantly opened and closed around each
write() call so that eventually the log file can be successfully
rotated.  This is very inefficient, but the design goal of the
ConcurrentRotatingFileHandler is to never loose log events at all
cost, whereas the RotatingFileHandler is a more general purpose
solution and can therefore adhere to more size-based file rotation,
and yields a better and more consistent performance.

What I found interesting is that the ConcurrentRotatingFileHandler
seems to be behaves the same with or without the thread locking around
the os.system() calls.  This is something that I need to look into
when I have some more time.  (I haven't actually timed or traced
anything yet, so it's hard to say for sure what's really going on; or
if something else was going on during my tests)

Robert, one alternate approach to consider given all the complexities
you have going on (by that I mean, multi-threaded process spawning
programs that you need to have the ability to redirect the
stdin/stdout streams...)  You might want to look into adding one more
process in the equation.  You could have your script start off by
launching a "central logging" socket listener (or use a system wide
listener), and then have that single process handle writing to and
rotating your log files.  Then it's just a mater of redirecting the
logging system to push the events to your logging process.  I know
this might not seem like the most appealing approach, but it may end
up being the one that requires the least amount of modifications to
your existing code... just a thought.  (Vinay, I know you've
recommended this approach before, are there any samples laying around
to help people get started with a simple central logging solution
based on (e.g. built on top of) Python's logging package?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Fri Jun 12 00:47:09 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 11 Jun 2009 22:47:09 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1244760429.28.0.714578919173.issue4749@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Lowell, there's a working sample right there in the docs:

I mentioned it in msg78619 in this issue. The link is

http://docs.python.org/library/logging.html#sending-and-receiving-logging-events-across-a-network

This should get anyone started for a multiprocess logging requirement.
For a single-process multi-threaded scenario, Python logging should work
out of the box except in scenarios already discussed, where child
processes contend for the files - as per thredio.py - and if one can't
avoid spawning child processes which cause contention, then the socket
logging approach with a separate process can be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Fri Jun 12 01:12:43 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Jun 2009 23:12:43 +0000
Subject: [issue6261] Clarify behaviour of random.uniform
In-Reply-To: <1244669428.58.0.991347750307.issue6261@psf.upfronthosting.co.za>
Message-ID: <1244761963.48.0.855951007869.issue6261@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r73380

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6261>
_______________________________________

From report at bugs.python.org  Fri Jun 12 01:13:22 2009
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 11 Jun 2009 23:13:22 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1244762002.44.0.288258195001.issue5219@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I've uploaded a patch to solve the problem.

In CallTipWindow.py, the showtip function binds key releases and button
releases to the checkhide_event function. The checkhide_event function
creates a .after callback to itself whenever it's called. Each key
release adds to a cascade of calls to checkhide_event which results in
Tk slowing down.

When checkhide_event is called from .after, the "event" argument takes
its default of None. Only then should a new .after call be made.

----------
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file14267/CallTipWindow.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Fri Jun 12 01:17:04 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 11 Jun 2009 23:17:04 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1244762224.37.0.388303708026.issue6095@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

After a deeper look; this change looks rather complex for a posixpath.c
newbie like me.

I probably won't be able to provide it for 3.1. If you want to do it for
3.1, please go ahead Raymond !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Fri Jun 12 12:50:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Jun 2009 10:50:30 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Hi, Valgrind just told me that Python calls close(-1) on
my_mmap_object.close() for memory mappings. That's because a memory
mapping has no (related) file descriptor.

Using attached warn.py, you can see the warning using strace:

$ strace -e close python warn.py 2>&1|grep -A1 12345
close(12345)                            = -1 EBADF (Bad file descriptor)
close(4294967295)                       = -1 EBADF (Bad file descriptor)
close(12345)                            = -1 EBADF (Bad file descriptor)

where close(4294967295) means close(-1).

Attached patch fixes this warning.

----------
components: Extension Modules
files: warn.py
messages: 89269
nosy: haypo
severity: normal
status: open
title: mmap: don't close file description if fd=-1
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14268/warn.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Fri Jun 12 12:50:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Jun 2009 10:50:38 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244803838.97.0.638194912232.issue6271@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14269/mmap_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Fri Jun 12 12:51:16 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Jun 2009 10:51:16 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244803876.43.0.390881170266.issue6271@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file14270/warn.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Fri Jun 12 12:51:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Jun 2009 10:51:21 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244803881.49.0.352546186009.issue6271@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file14270/warn.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Fri Jun 12 12:51:27 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Jun 2009 10:51:27 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244803887.05.0.266647038815.issue6271@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file14269/mmap_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Fri Jun 12 12:51:36 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Jun 2009 10:51:36 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244803896.26.0.212093667077.issue6271@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file14271/mmap_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Fri Jun 12 13:13:06 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 12 Jun 2009 11:13:06 +0000
Subject: [issue6272] Upgrading xml.etree to ElementTree 1.3
In-Reply-To: <1244805186.91.0.178368726896.issue6272@psf.upfronthosting.co.za>
Message-ID: <1244805186.91.0.178368726896.issue6272@psf.upfronthosting.co.za>


New submission from Senthil <orsenthil at gmail.com>:

The current ElementTree package shipped with Python is ElementTree 1.2.6.
ElementTree 1.3 has certain good features in handing XPaths which would
be a nice addition to the default xml.etree.

I don't know why ElementTree 1.2.6 was chosen initially.
I don't find any request for the upgrade.

So opening this one.

----------
assignee: effbot
components: Library (Lib), XML
messages: 89270
nosy: effbot, orsenthil
priority: normal
severity: normal
status: open
title: Upgrading xml.etree to ElementTree 1.3
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6272>
_______________________________________

From report at bugs.python.org  Fri Jun 12 13:20:43 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 12 Jun 2009 11:20:43 +0000
Subject: [issue6272] Upgrading xml.etree to ElementTree 1.3
In-Reply-To: <1244805186.91.0.178368726896.issue6272@psf.upfronthosting.co.za>
Message-ID: <1244805643.33.0.637642234823.issue6272@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Oh wait. I read at effbot.org that ElementTree 1.3 is Alpha Release.
Is this the reason for not including it? If it's still unstable, then
please ignore this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6272>
_______________________________________

From report at bugs.python.org  Fri Jun 12 14:01:53 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Jun 2009 12:01:53 +0000
Subject: [issue6260] os.utime should allow None values for ATIME or MTIME
In-Reply-To: <1244664392.83.0.0874142819498.issue6260@psf.upfronthosting.co.za>
Message-ID: <1244808113.88.0.2399425677.issue6260@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Functions of the os module that expose POSIX functions should have the
same interface as the system function; and they should not call other
system function.
Here, 'None' is accepted for the second argument only because the POSIX
utime() function accepts a NULL pointer.

Your need is certainly valid; but such a behavior does not belong to the
os module, which has to remain low-level.

----------
nosy: +amaury.forgeotdarc
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6260>
_______________________________________

From report at bugs.python.org  Fri Jun 12 14:20:18 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Jun 2009 12:20:18 +0000
Subject: [issue6272] Upgrading xml.etree to ElementTree 1.3
In-Reply-To: <1244805186.91.0.178368726896.issue6272@psf.upfronthosting.co.za>
Message-ID: <1244809218.41.0.501276674264.issue6272@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Too late for 3.1

----------
nosy: +rhettinger
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6272>
_______________________________________

From report at bugs.python.org  Fri Jun 12 14:35:39 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Jun 2009 12:35:39 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244810139.13.0.402062948288.issue6195@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The problem turned out to be a cut and paste error in my patch.  I'm
uploading the corrected patch, which passes all tests.

----------
Added file: http://bugs.python.org/file14272/issue6195.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6195>
_______________________________________

From report at bugs.python.org  Fri Jun 12 14:35:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Jun 2009 12:35:48 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244810148.03.0.199076739153.issue6195@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file14188/doctest-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6195>
_______________________________________

From report at bugs.python.org  Fri Jun 12 14:35:52 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 12 Jun 2009 12:35:52 +0000
Subject: [issue6254] tarfile unnecessarily requires seekable files
In-Reply-To: <1244648812.36.0.982521816376.issue6254@psf.upfronthosting.co.za>
Message-ID: <1244810152.96.0.388595898109.issue6254@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

It is no documentation bug either: tarfile.open() is prominently
featured right on the top of the first page of the tarfile module online
documentation. tarfile.Tarfile() follows right after it with a short
notice that tarfile.open() should better be used instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6254>
_______________________________________

From report at bugs.python.org  Fri Jun 12 14:35:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Jun 2009 12:35:54 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244810154.05.0.862848362236.issue6195@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file14204/issue6195.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6195>
_______________________________________

From report at bugs.python.org  Fri Jun 12 14:50:26 2009
From: report at bugs.python.org (Neil Muller)
Date: Fri, 12 Jun 2009 12:50:26 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1244811026.34.0.000667233667069.issue6233@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

> This doesn't give the expected answer for the test above

Which is obviously due to not comparing apples with apples, as I should
be using a byte-string in the py3k example.

>>> import xml.etree.ElementTree as ET
>>> e = ET.XML(b"<?xml version='1.0'
encoding='iso-8859-1'?><body>t\xe3t</body>")
>>> ET.tostring(e, 'ascii')


Fails without the patch, behaves as expected with the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Fri Jun 12 15:25:03 2009
From: report at bugs.python.org (James)
Date: Fri, 12 Jun 2009 13:25:03 +0000
Subject: [issue6260] os.utime should allow None values for ATIME or MTIME
In-Reply-To: <1244664392.83.0.0874142819498.issue6260@psf.upfronthosting.co.za>
Message-ID: <1244813103.75.0.746572580828.issue6260@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

very well, this is a good point.
i'm guessing nobody would every accept a patch for upstream utime? (in c)
thanks for your comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6260>
_______________________________________

From report at bugs.python.org  Fri Jun 12 15:42:06 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Jun 2009 13:42:06 +0000
Subject: [issue6237] Build errors when using LDFLAGS="-Wl,--no-undefined"
In-Reply-To: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za>
Message-ID: <1244814126.55.0.282338095835.issue6237@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I can't reproduce it, even after adding "-Wl,--as-needed". Did you
activate --enable-shared?

I suppose it would do no harm to add the libraries
"-lm" to _ctypes_test and audioop,
and "-ldl" to _ctypes and dl modules,
even if they are not needed in the standard case.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6237>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:08:51 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Jun 2009 15:08:51 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244819331.99.0.694588740577.issue6247@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It's unfortunate (at least to me, but I know I have a skewed view of
this) that the help string in add_argument uses %-formatting when
formatting the result. I'd much rather it use str.format().

I see a couple of options:
- leave it as-is and live with %-formatting forever
- add a different, mutually exclusive parameter,
  like help_ex or help_str
- try to guess whether to use %-formatting or str.format,
  based on inspecting the help string

I'm not really wild about any of these.

I'm still looking through the code, slowly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:35:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Jun 2009 15:35:45 +0000
Subject: [issue6195] Serious regression in doctest in Py3.1rc1
In-Reply-To: <1244151779.64.0.307098872881.issue6195@psf.upfronthosting.co.za>
Message-ID: <1244820945.91.0.6237618031.issue6195@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r73389.

I am wondering if the monkeypatching of linecache that doctest does
could be done away with, but I'm not sure whether it might get used
somehow in debug mode (since the comment refers to that).  On the other
hand, if it does get used, the same binary-read issue may exist in that
hypothetical code path.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6195>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:40:38 2009
From: report at bugs.python.org (Funda Wang)
Date: Fri, 12 Jun 2009 15:40:38 +0000
Subject: [issue6237] Build errors when using LDFLAGS="-Wl,--no-undefined"
In-Reply-To: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za>
Message-ID: <1244821238.35.0.0186955773043.issue6237@psf.upfronthosting.co.za>


Funda Wang <fundawang at gmail.com> added the comment:

Regarding python binary target, the actual command when linking is:
gcc -pthread -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -lstdc++ -
Xlinker -export-dynamic -o python \
Modules/python.o \
-LL. -lpython2.6 -lpthread -ldl  -lutil   -lm

The linking order is wrong. "-lstdc++" is LIBADD, it should appear 
after OBJECTS such as Modules/python.o. The same applies to -pthread.

The command should looks like:
gcc -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Xlinker -export-
dynamic -o python \
Modules/python.o \
-LL. -lpython2.6 -lpthread -ldl  -lutil   -lm  -lstdc++

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6237>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:40:51 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 12 Jun 2009 15:40:51 +0000
Subject: [issue2376] Set up "supported"-only buildbot waterfall view
In-Reply-To: <1205802028.97.0.321014582059.issue2376@psf.upfronthosting.co.za>
Message-ID: <1244821251.47.0.187111289557.issue2376@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This was done long ago, it seems.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2376>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:41:48 2009
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 12 Jun 2009 15:41:48 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1244821308.89.0.90394926246.issue6247@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yeah, the % formatting is an artifact of argparse being around before
str.format was available. If argparse became part of the standard
library, it might be reasonable to change to str.format formatting
instead as part of the move.

It would mean that folks would have to modify their code to switch from
the current argparse module to the stdlib one, but maybe that's an
acceptable tradeoff. I'm certainly happy to change things to str.format
if that's agreed on.

Thanks again for looking at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:47:18 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 12 Jun 2009 15:47:18 +0000
Subject: [issue4182] warnings.warn shows the wrong filename and line number
	for stacklevel of 0
In-Reply-To: <1224712526.35.0.138565894307.issue4182@psf.upfronthosting.co.za>
Message-ID: <1244821638.54.0.356637064352.issue4182@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Perhaps the C implementation should interpret the stacklevel parameter
differently so that it is compatible with the Python implementation. 
The stacklevel value is, after all, a very important part of the
interface of warnings.warn, as it is the only way to direct the warning
at a piece of code.

If the C implementation doesn't add a frame to the stack, then maybe it
should special case stacklevel=0 (eg, pointing somewhere arbitrary, not
real, and obviously so).  It seems that it already accounts for this
fact for other stacklevel values, as it doesn't exhibit the obvious
off-by-one error one might expect.

Or, close this ticket as won't-fix, if there is no intention of ever
fixing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4182>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:53:45 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 12 Jun 2009 15:53:45 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1244822025.81.0.693382011707.issue4180@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

So how about it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Fri Jun 12 17:57:47 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 12 Jun 2009 15:57:47 +0000
Subject: [issue4490] xml/sax/expatreader.py raises AttributeError when run
In-Reply-To: <1228233176.69.0.228694076169.issue4490@psf.upfronthosting.co.za>
Message-ID: <1244822267.27.0.438491001409.issue4490@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I found XMLGenerator in xml.sax.saxutils.  Attached patch changes
expatreader to use that instead.  Though I have no idea what the point
of this stanza is.  I suppose it's to exercise the code, in lieu of some
unit tests.  It might be better to just delete this part of the file
entirely.

----------
keywords: +patch
Added file: http://bugs.python.org/file14273/xmlgenerator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4490>
_______________________________________

From report at bugs.python.org  Fri Jun 12 18:23:27 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Jun 2009 16:23:27 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1244823807.11.0.393316693855.issue4180@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I am still on sabbatical so no code review from me.

But from the standpoint of making warn_explicit be overloadable, I'm on 
the fence. I don't mind it happening, but it will be just one more thing 
we have to support. Since it's Benjamin's code he can make the call to add 
the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Fri Jun 12 18:43:48 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 12 Jun 2009 16:43:48 +0000
Subject: [issue6273] Add client side certificate support to httplib
In-Reply-To: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>
Message-ID: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

The attached patch adds client-side cert support to httplib, as well as 
validation. Rather than just commit this, I would like to have additional 
review.

Also, ideally this could be added to 2.6 maint (it seems like a pretty big 
hole) as well as 2.7/3.0. The patch is against 2.6 maint.

----------
files: py26httplib.patch
keywords: patch
messages: 89288
nosy: jnoller
priority: normal
severity: normal
status: open
title: Add client side certificate support to httplib
type: feature request
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14274/py26httplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6273>
_______________________________________

From report at bugs.python.org  Fri Jun 12 18:44:29 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 12 Jun 2009 16:44:29 +0000
Subject: [issue6273] Add client side certificate support to httplib
In-Reply-To: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>
Message-ID: <1244825069.58.0.476746685395.issue6273@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

And yes, I need to finish the doc patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6273>
_______________________________________

From report at bugs.python.org  Fri Jun 12 18:46:40 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Jun 2009 16:46:40 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244825200.97.0.715285991366.issue6208@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Rupert, your original posts mislabels slash '/' and backslach '\' as the
opposite.  I have no idea what change you are requesting.  Please post a
minimal (line or two) code example with actual output and desired output.

I do not know if changing os.sep changes output.  I suspect that what is
printed may be controlled somewhat by the OS.

----------
nosy: +tjreedy
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6208>
_______________________________________

From report at bugs.python.org  Fri Jun 12 19:14:14 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Jun 2009 17:14:14 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244826854.54.0.451073586766.issue6215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch for recent py3k changes. I will commit soon if nobody objects.

----------
Added file: http://bugs.python.org/file14275/iobackport3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Fri Jun 12 19:32:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Jun 2009 17:32:07 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244827927.01.0.745615724476.issue6258@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For 2.7 and 3.1, this is now fixed with r73390 and r73391. The trick is
to set the Win64 bit in RegLocator also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Fri Jun 12 20:10:23 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Jun 2009 18:10:23 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244830223.05.0.869650934885.issue6135@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I propose to add two parameters (encoding, error) to the
subprocess.Popen function.
- python 2.x could build and return codecs.StreamReader objects
- python 3.x would just pass these parameters to io.TextIOWrapper

I'll try to come with a patch.

----------
nosy: +amaury.forgeotdarc
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Fri Jun 12 20:46:36 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 12 Jun 2009 18:46:36 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244832396.8.0.816324657594.issue6258@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

That's great.  Thanks Martin!

What about Python 2.6?  If the fix is hard to port back to 2.6, perhaps
bdist_msi should raise an Unsupported error in 64-bit Python.

Let me know if I can help any further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Fri Jun 12 21:04:26 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 12 Jun 2009 19:04:26 +0000
Subject: [issue5596] memory leaks in 3.1
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1244833466.22.0.871176537184.issue5596@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

These tests are leaking on my build of r73393:

test_docxmlrpc leaked [0, 0, 85, 0, 0, -85, 0, 0, 0, 0] references, sum=0
test_popen leaked [0, 23, -23, 0, 23, 0, -23, 23, -23, 23] references,
sum=23
test_urllib leaked [4, 4, 4, 4, 6, 0, 0, 0, 2, 0] references, sum=24
test_urllib2_localnet leaked [0, 0, 0, 0, 0, 0, 251, -250, 0, 0]
references, sum=1
test_os leaked [0, -26, 26, 0, -26, 26, 0, 23, 0, 0] references, sum=23

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5596>
_______________________________________

From report at bugs.python.org  Fri Jun 12 21:15:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Jun 2009 19:15:27 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1244834127.9.0.772886044129.issue6095@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Fri Jun 12 21:24:22 2009
From: report at bugs.python.org (Jeff McNeil)
Date: Fri, 12 Jun 2009 19:24:22 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1244834662.94.0.141749151158.issue5102@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

I ran into this problem this afternoon as well. The same issue appears
to exist within the Basic & Digest Auth retry code (though it's much
less likely to surface).

I wound up making the suggested fixes to my local install so I'm
attaching the tiny patch in hopes that someone finds it useful.

----------
keywords: +patch
nosy: +j_mcneil
Added file: http://bugs.python.org/file14276/urllib2_timeouts.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Fri Jun 12 21:40:00 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 12 Jun 2009 19:40:00 +0000
Subject: [issue5102] urllib2.py timeouts do not propagate across redirects for
	2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1244835600.17.0.546472145727.issue5102@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Looks reasonable to me. I shall test it and commit the patch. Shall try
for tests too.

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5102>
_______________________________________

From report at bugs.python.org  Fri Jun 12 21:40:51 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 12 Jun 2009 19:40:51 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1244835651.01.0.675140418222.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file14277/python-trunk-20090612-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Fri Jun 12 22:17:20 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Jun 2009 20:17:20 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244837840.48.0.0561191041925.issue6215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done in r73394.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Fri Jun 12 22:18:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Jun 2009 20:18:23 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244837903.38.0.299632436242.issue6215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Someone will probably have to fix the Windows build files, by the way (I
can't do it myself).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Fri Jun 12 22:24:56 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 12 Jun 2009 20:24:56 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244838296.07.0.452745215594.issue6215@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Could simply merge the changes in r71185 to the PC/ and PCbuild/
directories?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Fri Jun 12 22:57:48 2009
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 12 Jun 2009 20:57:48 +0000
Subject: [issue6274] subprocess.Popen() may leak file descriptors
In-Reply-To: <1244840268.32.0.756034248286.issue6274@psf.upfronthosting.co.za>
Message-ID: <1244840268.32.0.756034248286.issue6274@psf.upfronthosting.co.za>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

If something bad happens between a os.pipe() call is called, and the
returned file descriptors are closed, those file descriptors are never
closed.

In a long lived process this is a problem.

Patch (against trunk) to solve this is attached.

----------
assignee: facundobatista
files: subprocess.py.diff
keywords: patch
messages: 89301
nosy: facundobatista
severity: normal
status: open
title: subprocess.Popen() may leak file descriptors
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14278/subprocess.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6274>
_______________________________________

From report at bugs.python.org  Fri Jun 12 23:00:31 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Jun 2009 21:00:31 +0000
Subject: [issue6273] Add client side certificate support to httplib
In-Reply-To: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>
Message-ID: <4A32C1EA.2040504@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The attached patch adds client-side cert support to httplib, as well as 
> validation. Rather than just commit this, I would like to have additional 
> review.

I wouldn't call the feature "client-side cert support" - client
certificates are already supported, and had been for a long time.

What you are adding to httplib is server certificate validation.

I find the patch incomplete, for formal and semantical reasons:
a) it doesn't come with documentation or test suite changes, and
b) it doesn't implement the typical certificate checks that browsers
   do, beyond validating that the certificate is valid - e.g. also
   validating that the certificate is issued to the host you are trying
   to connect to.

API-wise, I'm not sure what the point of passing cert_reqs as a
parameter is - ISTM that, in httplib, if ca_certs is not None, then
cert_reqs should automatically be CERT_REQUIRED (just like it is
in get_server_certificate).

> Also, ideally this could be added to 2.6 maint (it seems like a pretty big 
> hole) 

It's a new feature, so it shouldn't be added to 2.6. Not sure what you
mean by "big hole".

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6273>
_______________________________________

From report at bugs.python.org  Fri Jun 12 23:21:33 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 12 Jun 2009 21:21:33 +0000
Subject: [issue6127] Unexpected universal newline behavior (newline
	duplication) in Windows
In-Reply-To: <1243454503.32.0.886233661759.issue6127@psf.upfronthosting.co.za>
Message-ID: <1244841693.01.0.302010545503.issue6127@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Patch backported in r73399. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6127>
_______________________________________

From report at bugs.python.org  Fri Jun 12 23:27:31 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 12 Jun 2009 21:27:31 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1244842051.93.0.0136041204886.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file14279/python-trunk-20090612-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri Jun 12 23:43:14 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 12 Jun 2009 21:43:14 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

It can be useful, after a unittest.assertRaises() or assertRaisesRegexp() 
to be able to take a closer look at the exception that was raised.
To this end, I propose returning the caught exception from these methods.

Additionally, the context manager involved with keep the caught exception 
in its exc_value member after it has been successfully thrown (and 
matched)

----------
components: Library (Lib)
files: unittest.patch
keywords: easy, needs review, patch, patch
messages: 89304
nosy: krisvale
severity: normal
status: open
title: let unittest.assertRaises() return the exception object caught
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14280/unittest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Fri Jun 12 23:45:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Jun 2009 21:45:50 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244843150.65.0.27843889645.issue6275@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Sat Jun 13 00:37:57 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 12 Jun 2009 22:37:57 +0000
Subject: [issue6273] Add client side certificate support to httplib
In-Reply-To: <4A32C1EA.2040504@v.loewis.de>
Message-ID: <48D73D90-9EED-4E07-A6BB-5C443B86093B@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Jun 12, 2009, at 5:00 PM, Martin v. L?wis <report at bugs.python.org>  
wrote:

>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> The attached patch adds client-side cert support to httplib, as  
>> well as
>> validation. Rather than just commit this, I would like to have  
>> additional
>> review.
>
> I wouldn't call the feature "client-side cert support" - client
> certificates are already supported, and had been for a long time.
>
> What you are adding to httplib is server certificate validation.
>
> I find the patch incomplete, for formal and semantical reasons:
> a) it doesn't come with documentation or test suite changes, and
> b) it doesn't implement the typical certificate checks that browsers
>   do, beyond validating that the certificate is valid - e.g. also
>   validating that the certificate is issued to the host you are trying
>   to connect to.
>
> API-wise, I'm not sure what the point of passing cert_reqs as a
> parameter is - ISTM that, in httplib, if ca_certs is not None, then
> cert_reqs should automatically be CERT_REQUIRED (just like it is
> in get_server_certificate).
>
>> Also, ideally this could be added to 2.6 maint (it seems like a  
>> pretty big
>> hole)
>
> It's a new feature, so it shouldn't be added to 2.6. Not sure what you
> mean by "big hole".
>

Thanks, that's why I filed the ticket, it's my first foray into  
patching httplib - I'll go back to the patch drawing board!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6273>
_______________________________________

From report at bugs.python.org  Sat Jun 13 00:43:16 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 12 Jun 2009 22:43:16 +0000
Subject: [issue5641] Local variables not freed when Exception raises in
	function called from cycle
In-Reply-To: <1238575778.52.0.687578256719.issue5641@psf.upfronthosting.co.za>
Message-ID: <1244846596.05.0.623014439232.issue5641@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

I just spend several days figuring out a problem that was caused by this
behaviour and in the process I really tried to read everything that
relates to destruction of objects and exception handling in Python.

Georg, could you give me a pointer where exactly these semantics are
documented?

Thanks!

----------
nosy: +Nikratio

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5641>
_______________________________________

From report at bugs.python.org  Sat Jun 13 02:21:06 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 13 Jun 2009 00:21:06 +0000
Subject: [issue6273] Add client side certificate support to httplib
In-Reply-To: <1244825028.47.0.339555934683.issue6273@psf.upfronthosting.co.za>
Message-ID: <1244852466.71.0.747896892157.issue6273@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'm going to close this until I come up with a more complete patch, and 
target it for 2.7. No reason to keep this in the tracker as-is

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6273>
_______________________________________

From report at bugs.python.org  Sat Jun 13 03:35:39 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 13 Jun 2009 01:35:39 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1244856939.9.0.913245566542.issue6208@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm not sure Python *can* change its behaviour in this case. How would
it know which shell (cmd or msys/cygwin) it was launched from?

Also, even if it could figure that out, how would it know whether a
particular filename "stringification" with os.path.join() was intended
for display to the user or to be passed to a Windows API?

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6208>
_______________________________________

From report at bugs.python.org  Sat Jun 13 03:50:17 2009
From: report at bugs.python.org (James Eric Pruitt)
Date: Sat, 13 Jun 2009 01:50:17 +0000
Subject: [issue1191964] asynchronous Subprocess
Message-ID: <1244857817.26.0.0195388821973.issue1191964@psf.upfronthosting.co.za>


James Eric Pruitt <eric.pruitt at gmail.com> added the comment:

Hello, I am working on this patch and some additional features for my
Google Summer of Code project (subdev.blogspot.com) and will eventually
attempt to get the code committed to Python 3.1 or 3.2 and Python 2.7. I
will have the unit tests completed shortly and will post a patch for
Python 2.7 and / or Python 3.1rc1.

----------
nosy: +ericpruitt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Sat Jun 13 03:59:23 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 13 Jun 2009 01:59:23 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1244858363.21.0.532421826052.issue6210@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The current behaviour also doesn't match the spec in PEP 3134, which
states the __context__ attribute will only be set by the VM if it hasn't
already been set.

This is not currently the case, as setting __context__ does not keep the
VM from setting it (I also tried this setting __context__ to 1 - it was
still overridden):

>>> try:
...   1/0
... finally:
...   exc = RuntimeError()
...   exc.__context__ = None
...   raise exc
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: int division or modulo by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
RuntimeError

The "raise ... from ..." syntax is not the correct syntax to use
however, since that relates the __cause__ atribute rather than __context__.

A better approach may be to provide a "sys.clear_exc_info()" method in
the sys module to allow exceptions to be raised from exception handlers
without any __context__ information.

A somewhat clumsy workaround that will work with current Python 3 is to
defer raising the exception until after the exception handler has
finished execution:

>>> exc = None
>>> try:
...   1/0
... except:
...   exc = RuntimeError()
...
>>> if exc is not None: raise exc
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Sat Jun 13 04:27:16 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 13 Jun 2009 02:27:16 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244860036.5.0.572390856198.issue5811@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Assigned to Benjamin for assessment - this should be considered for rc2
since it's still broken in 3.1:

>>> f = open('setup.py', 'rb')
>>> len(f.peek(10))
4096
>>> len(f.peek(1))
4096
>>> len(f.peek(4095))
4096
>>> len(f.peek(10095))
4096


Brought up on python-dev in this thread:
http://mail.python.org/pipermail/python-dev/2009-June/089986.html

And previously here:
http://mail.python.org/pipermail/python-dev/2009-April/088229.html

The thread from April suggests the current behaviour may be intentional,
in which case it is the documentation that needs to be fixed, as it is
currently not just misleading but flat out wrong. Then again, Benjamin's
initial response to that thread was to support the idea of changing
peek() so that the argument actually was a cap.

The previous documentation that Alexandre quotes in the April was
changed to the current description in late April without any
corresponding change to the implementation:
http://svn.python.org/view/python/branches/py3k/Doc/library/io.rst?r1=62422&r2=62430

However, the old description was also wrong for the io-c implementation
since it just returns the current buffered data from peek, no matter
what argument you pass in.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, ncoghlan
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 05:38:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Jun 2009 03:38:37 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244864317.04.0.990024762308.issue5811@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think the argument should be used as a upper bound; I will look at
this tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 06:20:58 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sat, 13 Jun 2009 04:20:58 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244866858.89.0.887591273939.issue5811@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Hey guys, I did a patch about this one.
I didn't do many tests but I guess it is ok (it works like I think it
should).
What do you think?

----------
keywords: +patch
nosy: +conf
Added file: http://bugs.python.org/file14281/peek.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 06:23:12 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sat, 13 Jun 2009 04:23:12 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244866992.62.0.671136292767.issue5811@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Oops I overlooked I minor flaw.
A second version.

----------
Added file: http://bugs.python.org/file14282/peek2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 06:48:47 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sat, 13 Jun 2009 04:48:47 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244868527.3.0.532442123499.issue5811@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

There's a problem with my patch... When the size of the data we want to
peek is too big ( > buffer_len - start ) the cursor will move, thus
there isn't a case where the peek function would work properly (except
when we want to peek() just 1 byte).
Couldn't we use a read() followed by a seek() instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 10:10:55 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Jun 2009 08:10:55 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244880655.81.0.31535476993.issue6258@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee: tarek -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Sat Jun 13 11:21:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 13 Jun 2009 09:21:58 +0000
Subject: [issue6258] distributions built with bdist_msi on 64-bit Windows
	fail	to install correctly
In-Reply-To: <1244657445.76.0.468429726834.issue6258@psf.upfronthosting.co.za>
Message-ID: <1244884918.43.0.431440761976.issue6258@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For 2.6 and 3.0, this is now fixed in r73406 and r73407.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6258>
_______________________________________

From report at bugs.python.org  Sat Jun 13 11:34:47 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 09:34:47 +0000
Subject: [issue6276] Fix contextlib.nested DeprecationWarning for test_signal.
In-Reply-To: <1244885687.02.0.348626094115.issue6276@psf.upfronthosting.co.za>
Message-ID: <1244885687.02.0.348626094115.issue6276@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached is the patch to fix DeprecationWarning resulting from using
contextlib.nested() function in test_signal.py

----------
components: Tests
files: test_signal_with_fix_june_13_2009.patch
keywords: patch
messages: 89317
nosy: vshenoy
severity: normal
status: open
title: Fix contextlib.nested DeprecationWarning for test_signal.
versions: Python 2.7
Added file: http://bugs.python.org/file14283/test_signal_with_fix_june_13_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6276>
_______________________________________

From report at bugs.python.org  Sat Jun 13 11:38:49 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 09:38:49 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached are patches adding multiple context manager usage feature to
whats new document to both 2.7.rst in trunk and py3k.

Are 2.x.rsts in py3k supposed to be in sync with trunks 2.x.rsts ?

----------
assignee: georg.brandl
components: Documentation
messages: 89318
nosy: georg.brandl, vshenoy
severity: normal
status: open
title: Add description of new syntax of with to 2.7 whatsnew document.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 11:39:30 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 09:39:30 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244885970.84.0.487560759941.issue6277@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file14284/doc_typo_trunk_may_22_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 11:40:35 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 09:40:35 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244886035.44.0.0780373933304.issue6277@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


----------
versions: +Python 3.1
Added file: http://bugs.python.org/file14285/doc_typo_py3k_may_22_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 12:26:20 2009
From: report at bugs.python.org (Tal Einat)
Date: Sat, 13 Jun 2009 10:26:20 +0000
Subject: [issue6143] IDLE - an extension to clear the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1244888780.16.0.129415711962.issue6143@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

First of all I think that the Squeezer (issue #1529353) extension is
more useful and solves most of the problems that this proposed feature
is set to solve, e.g. issue #1442493.


IMO the second method you offer - temporarily moving "iomark" - is
preferable.

One reason is that it will allow using the undo feature to undo deleting
the entire shell history. I think this is important since deleting the
history by accident without a way to retrieve it would be very annoying.

I propose going with the clear_window2 method, wrapping it with
undo_block_start() and undo_block_stop().

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6143>
_______________________________________

From report at bugs.python.org  Sat Jun 13 12:49:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 13 Jun 2009 10:49:33 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244890173.93.0.351083676973.issue6277@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Are you sure you have attached the right patches? They don't seem to
change the howto document, but instead fix some typos.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 13:12:06 2009
From: report at bugs.python.org (System32)
Date: Sat, 13 Jun 2009 11:12:06 +0000
Subject: [issue6278] http.server, BaseHTTPRequestHandler write string error
In-Reply-To: <1244891526.85.0.0899506861309.issue6278@psf.upfronthosting.co.za>
Message-ID: <1244891526.85.0.0899506861309.issue6278@psf.upfronthosting.co.za>


New submission from System32 <mullwar at gmail.com>:

CODE:
===========================================================
from http.server import HTTPServer, BaseHTTPRequestHandler

class RequestHandler(BaseHTTPRequestHandler):
	def _header(self):
		self.send_response(200)
		self.send_header("Content-type", "text/html")
		self.end_headers()
		
	def do_HEAD(self):
		self._header()
		
	def do_GET(self):
		self._header()	
		
		self.wfile.write('test')
		
server = HTTPServer(('localhost', 80), RequestHandler)
server.serve_forever()
===========================================================

ERROR:
===========================================================
localhost - - [13/Jun/2009 14:00:13] "GET / HTTP/1.1" 200 -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 1907)
Traceback (most recent call last):
  File "C:\Python30\lib\socketserver.py", line 281, in 
_handle_request_noblock
    self.process_request(request, client_address)
  File "C:\Python30\lib\socketserver.py", line 307, in process_request
    self.finish_request(request, client_address)
  File "C:\Python30\lib\socketserver.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Python30\lib\socketserver.py", line 614, in __init__
    self.handle()
  File "C:\Python30\lib\http\server.py", line 363, in handle
    self.handle_one_request()
  File "C:\Python30\lib\http\server.py", line 357, in handle_one_request
    method()
  File "C:\Documents and Settings\User\Desktop\mHome\webserver.py", 
line 18, in
do_GET
    self.wfile.write('human')
  File "C:\Python30\lib\socket.py", line 219, in write
    return self._sock.send(b)
TypeError: send() argument 1 must be bytes or buffer, not str
===========================================================

----------
components: Library (Lib)
messages: 89321
nosy: System32
severity: normal
status: open
title: http.server, BaseHTTPRequestHandler write string error
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6278>
_______________________________________

From report at bugs.python.org  Sat Jun 13 13:47:44 2009
From: report at bugs.python.org (System32)
Date: Sat, 13 Jun 2009 11:47:44 +0000
Subject: [issue6278] http.server, BaseHTTPRequestHandler write string error
In-Reply-To: <1244891526.85.0.0899506861309.issue6278@psf.upfronthosting.co.za>
Message-ID: <1244893664.81.0.328833188496.issue6278@psf.upfronthosting.co.za>


Changes by System32 <mullwar at gmail.com>:


----------
type: compile error -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6278>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:07:13 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 12:07:13 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244894833.97.0.227429696634.issue6135@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

I wrote a patch to add encoding and error to subprocess.Popen in Python
2.7 (trunk).

----------
keywords: +patch
nosy: +segfaulthunter
Added file: http://bugs.python.org/file14286/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:18:50 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 12:18:50 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244895530.11.0.14206900909.issue6277@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


Removed file: http://bugs.python.org/file14284/doc_typo_trunk_may_22_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:18:53 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 12:18:53 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244895533.99.0.511573469878.issue6277@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


Removed file: http://bugs.python.org/file14285/doc_typo_py3k_may_22_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:20:57 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 12:20:57 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244895657.74.0.394459480654.issue6277@psf.upfronthosting.co.za>


Vikram U Shenoy <vikram.u.shenoy at gmail.com> added the comment:

Oops, my mistake. Reattached the proper patches.

----------
Added file: http://bugs.python.org/file14287/doc_mult_context_trunk_jun_13_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:21:41 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Sat, 13 Jun 2009 12:21:41 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1244895701.35.0.667507681651.issue6277@psf.upfronthosting.co.za>


Changes by Vikram U Shenoy <vikram.u.shenoy at gmail.com>:


Added file: http://bugs.python.org/file14288/doc_mult_context_py3k_jun_13_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:21:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jun 2009 12:21:51 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244895711.39.0.726471986274.issue5811@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Lucas, it is indeed impossible for peek() to return more than the buffer
size and remain compatible with non-seekable raw streams. That's why it
/never/ returns more than the buffer size.

As for the fact that peek() doesn't behave as documented, I disagree.
Here is what the docstring says:

        """Returns buffered bytes without advancing the position.

        The argument indicates a desired minimal number of bytes; we
        do at most one raw read to satisfy it.  We never return more
        than self.buffer_size.
        """

Please note : "a desired /minimal/ number of bytes" (minimal, not
maximal). Furthermore, "We never return more than self.buffer_size." The
behaviour looks ok to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:32:33 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 12:32:33 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244896353.38.0.252513938912.issue6135@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

Cosmetic update.

----------
Added file: http://bugs.python.org/file14289/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:32:37 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 12:32:37 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244896357.67.0.639802764749.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Removed file: http://bugs.python.org/file14286/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:37:38 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sat, 13 Jun 2009 12:37:38 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244896658.79.0.924648590458.issue5811@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

We could fill the buffer while moving its start point to 0. I guess this
behavior would require a new function (or a new parameter to
Modules/_io/bufferedio.c:_bufferedreader_fill_buffer() ).
If you are ok with that I could write a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:40:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jun 2009 12:40:19 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1244895711.39.0.726471986274.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244896961.4913.13.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

We could, however, enforce the passed argument and only return the whole
remaining buffer when no argument is given. This is a bit like Frederick
Reeve's proposal on python-dev, but less sophisticated and therefore
less tedious to implement.

In any case, I'm not sure it should be committed before the 3.1 release.
The second and last release candidate is supposed to be today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:47:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jun 2009 12:47:35 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1244896658.79.0.924648590458.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244897398.4913.18.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> We could fill the buffer while moving its start point to 0. I guess this
> behavior would require a new function (or a new parameter to
> Modules/_io/bufferedio.c:_bufferedreader_fill_buffer() ).
> If you are ok with that I could write a patch.

The buffer is used for both reading and writing and you have to be
careful when shifting it. Besides, the same change (or similar) should
also be done in the Python implementation (in _pyio.py).

If you come up with a patch, please add some tests and check the whole
regression suite passes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:57:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Jun 2009 12:57:06 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244897826.87.0.973861845041.issue5811@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm downgrading this because it can't be changed until after 3.1 is
released.

----------
assignee: benjamin.peterson -> 
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sat Jun 13 14:59:57 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 12:59:57 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244897997.24.0.666654769515.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Added file: http://bugs.python.org/file14290/subprocess3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 15:03:29 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 13:03:29 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244898209.74.0.969738328623.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Added file: http://bugs.python.org/file14291/subprocess3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 15:03:33 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 13:03:33 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244898213.51.0.713726385362.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Removed file: http://bugs.python.org/file14290/subprocess3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 15:17:19 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 13 Jun 2009 13:17:19 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244899039.86.0.647971260664.issue6275@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This was suggested before on Python-dev and Guido rejected it as it is
an 'odd' API for a unittest assert method - none of the others return
anything.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Sat Jun 13 16:13:49 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 14:13:49 +0000
Subject: [issue6279] datamodel documentation confuses staticmethod with
	classmethod
In-Reply-To: <1244902429.63.0.613787666637.issue6279@psf.upfronthosting.co.za>
Message-ID: <1244902429.63.0.613787666637.issue6279@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

I think it is confusing that the datamodel documentation says __new__ is
a staticmethod while it actually is a classmethod (as it takes the class
as its first argument). Patch supplied.

----------
files: datamodel.rst.patch
keywords: patch
messages: 89331
nosy: segfaulthunter
severity: normal
status: open
title: datamodel documentation confuses staticmethod with classmethod
Added file: http://bugs.python.org/file14292/datamodel.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6279>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:07:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Jun 2009 16:07:06 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244909226.92.0.339602945973.issue6135@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Two things:
1. The argument should be called `errors` for consistency with open()
and TextIOWrapper(), not `error`
2. You should add some unit tests.

----------
nosy: +pitrou
stage: needs patch -> patch review
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:11:53 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 16:11:53 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244909513.51.0.338392096148.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Removed file: http://bugs.python.org/file14289/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:11:58 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 16:11:58 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244909518.44.0.703178204763.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Removed file: http://bugs.python.org/file14291/subprocess3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:12:25 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 16:12:25 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244909545.02.0.471551923023.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Added file: http://bugs.python.org/file14293/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:12:58 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 16:12:58 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244909578.97.0.54934274215.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Added file: http://bugs.python.org/file14294/subprocess3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:18:49 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 16:18:49 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244909929.25.0.871984741379.issue6135@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

Should we also cover the unusual case where stdout, stderr and stdin
have different encodings, because now we are assuming the are all the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:46:43 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 13 Jun 2009 16:46:43 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1244911603.77.0.240402033162.issue6135@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Added file: http://bugs.python.org/file14295/test_subprocess3.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:48:03 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sat, 13 Jun 2009 16:48:03 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

I've been struggling to write a function that takes UTC timestamps in
ISO-8601 strings and returns UTC timestamps in unix-seconds-since-epoch.
 The first implementation used time.mktime() minus time.timezone
(http://allmydata.org/trac/tahoe/browser/src/allmydata/util/time_format.py?rev=2424
), but that doesn't work in London if the argument date is in a certain
period during the 1970's.  Then there was force-the-tz-to-UTC
(http://allmydata.org/trac/tahoe/changeset/3911/src/allmydata/util/time_format.py
), but that doesn't work on Windows.  Then there was
force-the-tz-to-UTC-except-on-Windows
(http://allmydata.org/trac/tahoe/changeset/3913/src/allmydata/util/time_format.py
), but that still doesn't work on Windows.  Then there was this horrible
hack of converting from string-iso-8601 to localseconds with
time.mktime(), then converting from the resulting localseconds to an
iso-8601 string, then converting the resulting string back to seconds
with time.mktime(), then subtracting the two seconds values to find out
the real offset between UTC-seconds and local-seconds for the current tz
and for the time indicated by the argument
(http://allmydata.org/trac/tahoe/changeset/3914/src/allmydata/util/time_format.py
).  This actually works everywhere, but it is horrible.  Finally,
yesterday, someone pointed out to me that the inverse of time.gmtime()
is located in the "calendar" module and is named calendar.timegm().  Now
the implementation of our function is simple
(http://allmydata.org/trac/tahoe/changeset/3915/src/allmydata/util/time_format.py
)  I suggest that timegm() be moved to the time module next to its
sibling gmtime().

----------
components: Library (Lib)
messages: 89334
nosy: zooko
severity: normal
status: open
title: calendar.timegm() belongs in time module, next to time.gmtime()
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Sat Jun 13 18:52:53 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sat, 13 Jun 2009 16:52:53 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1244911973.16.0.543167862008.issue6280@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Here is the ticket that tracked this issue within the Tahoe-LAFS
project: http://allmydata.org/trac/tahoe/ticket/733

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Sat Jun 13 19:44:28 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sat, 13 Jun 2009 17:44:28 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
	means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1244915068.37.0.742750501737.issue5720@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Okay, I posted to python-dev:

http://mail.python.org/pipermail/python-dev/2009-June/090021.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Jun 13 21:42:52 2009
From: report at bugs.python.org (Virgil Dupras)
Date: Sat, 13 Jun 2009 19:42:52 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1244922172.52.0.730375702769.issue6095@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

I saw this ticket as a good way to get my feet wet (I almost never touched 
C) with Python's C API, so I went ahead and did the part for OS X. I also 
did the Windows part, but I'm not setup to compile Python on Windows, so I 
don't even know if it remotely works.

It would be nice if someone could review this patch and tell me about 
mistakes (such as memory management ones, probably). Thanks!

----------
keywords: +patch
nosy: +vdupras
Added file: http://bugs.python.org/file14296/t6095.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Sun Jun 14 00:45:31 2009
From: report at bugs.python.org (Daniel Eloff)
Date: Sat, 13 Jun 2009 22:45:31 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>


New submission from Daniel Eloff <dan.eloff at gmail.com>:

The try statement at the end of hashlib.py is some of the worst python
code I've had the mispleasure of reading for a long time.

Secondly, it seems flawed in function as well as form.
__get_builtin_constructor can throw an ImportError, which seems
erroneously caught in the except (why on earth does the except span more
than the "import _hashlib"? That's bad style for precisely this reason.)
This will cause an error in the import of hashlib when there are
possibly many working hash functions already imported. Changing the:

try:
    exec funcName + ' = __get_builtin_constructor(funcName)'
except ValueError:
    pass

to catch ImportError as well solves the problem for me.

----------
messages: 89338
nosy: Eloff
severity: normal
status: open
title: Bug in hashlib
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Sun Jun 14 00:48:42 2009
From: report at bugs.python.org (Matt Kern)
Date: Sat, 13 Jun 2009 22:48:42 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1244933322.33.0.448084395904.issue1615158@psf.upfronthosting.co.za>


Matt Kern <matt.kern at undue.org> added the comment:

Ping.  Anything I can do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Sun Jun 14 03:12:29 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Jun 2009 01:12:29 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244941949.2.0.22046055893.issue5811@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's not the docstring that is wrong for the current behaviour, it's the
IO.BufferedReader documentation:

"""
peek([n])
    Return 1 (or n if specified) bytes from a buffer without advancing
the position. Only a single read on the raw stream is done to satisfy
the call. The number of bytes returned may be less than requested since
at most all the buffer?s bytes from the current position to the end are
returned.
"""

That gives absolutely no indication that the call might return more
bytes than expected, and the indication that leaving out the argument
will return only the next byte is flat out wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sun Jun 14 07:17:21 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 14 Jun 2009 05:17:21 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244956641.91.0.541501680672.issue6271@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r73425(trunk), r73426(release26-maint), r73427(py3k),
r73428(release30-maint).

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Sun Jun 14 07:18:19 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 14 Jun 2009 05:18:19 +0000
Subject: [issue6271] mmap: don't close file description if fd=-1
In-Reply-To: <1244803830.2.0.352029440957.issue6271@psf.upfronthosting.co.za>
Message-ID: <1244956699.3.0.881709064854.issue6271@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6271>
_______________________________________

From report at bugs.python.org  Sun Jun 14 09:36:43 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 14 Jun 2009 07:36:43 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244965003.88.0.291879331046.issue6215@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think I could fix windows build issue. (r73423)

It seems some tests are failing. See
http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%20trunk/builds/2244/step-test/0

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Sun Jun 14 10:13:22 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 14 Jun 2009 08:13:22 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1244967202.64.0.803173384956.issue6215@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I found following patch can fix test_invalid_operations error on
windows. Is this correct fix? There are many other places using bare open().

Index: Lib/test/test_io.py
===================================================================
--- Lib/test/test_io.py	(revision 73422)
+++ Lib/test/test_io.py	(working copy)
@@ -298,13 +298,13 @@
     def test_invalid_operations(self):
         # Try writing on a file opened in read mode and vice-versa.
         for mode in ("w", "wb"):
-            with open(support.TESTFN, mode) as fp:
+            with self.open(support.TESTFN, mode) as fp:
                 self.assertRaises(IOError, fp.read)
                 self.assertRaises(IOError, fp.readline)
-        with open(support.TESTFN, "rb") as fp:
+        with self.open(support.TESTFN, "rb") as fp:
             self.assertRaises(IOError, fp.write, b"blah")
             self.assertRaises(IOError, fp.writelines, [b"blah\n"])
-        with open(support.TESTFN, "r") as fp:
+        with self.open(support.TESTFN, "r") as fp:
             self.assertRaises(IOError, fp.write, "blah")
             self.assertRaises(IOError, fp.writelines, ["blah\n"])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Sun Jun 14 11:27:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Jun 2009 09:27:13 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1244971633.94.0.49081576627.issue6281@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you propose an actual test case and a patch?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Sun Jun 14 13:49:59 2009
From: report at bugs.python.org (Omri Shaked)
Date: Sun, 14 Jun 2009 11:49:59 +0000
Subject: [issue6282] In tarfile, compression level cannot be specified
In-Reply-To: <1244980199.28.0.54788876069.issue6282@psf.upfronthosting.co.za>
Message-ID: <1244980199.28.0.54788876069.issue6282@psf.upfronthosting.co.za>


New submission from Omri Shaked <omri.shaked at gmail.com>:

When creating a TarFile object that uses compression, the compressor is
always created using its default compression level.

import bz2
self.cmp = bz2.BZ2Compressor()

You can't specify the compression level (i.e. self.cmp =
bz2.BZ2Compressor(1)).

----------
components: Library (Lib)
messages: 89345
nosy: Tzigi
severity: normal
status: open
title: In tarfile, compression level cannot be specified
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6282>
_______________________________________

From report at bugs.python.org  Sun Jun 14 13:50:37 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sun, 14 Jun 2009 11:50:37 +0000
Subject: [issue6279] datamodel documentation confuses staticmethod with
	classmethod
In-Reply-To: <1244902429.63.0.613787666637.issue6279@psf.upfronthosting.co.za>
Message-ID: <1244980237.15.0.305432863615.issue6279@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

Sorry, my fault.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6279>
_______________________________________

From report at bugs.python.org  Sun Jun 14 13:50:42 2009
From: report at bugs.python.org (Florian Mayer)
Date: Sun, 14 Jun 2009 11:50:42 +0000
Subject: [issue6279] datamodel documentation confuses staticmethod with
	classmethod
In-Reply-To: <1244902429.63.0.613787666637.issue6279@psf.upfronthosting.co.za>
Message-ID: <1244980242.73.0.974160028268.issue6279@psf.upfronthosting.co.za>


Changes by Florian Mayer <flormayer at aim.com>:


Removed file: http://bugs.python.org/file14292/datamodel.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6279>
_______________________________________

From report at bugs.python.org  Sun Jun 14 14:11:42 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 14 Jun 2009 12:11:42 +0000
Subject: [issue6205] sdist doesn't include data_files
In-Reply-To: <1244210606.6.0.749223227815.issue6205@psf.upfronthosting.co.za>
Message-ID: <1244981502.25.0.124614422104.issue6205@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Hi James, this has been changed already for trunk and 3.x, see #2279.

Although it hasn't been backported in Python 2.6.x because it's a major
behavior change that breaks setuptools.

Although, when 2.7 and 3.2 are out, we will provide a backport of
distutils. for 2.6 and 2.5.

until then you do have to declare your files in the MANIFEST.in template

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6205>
_______________________________________

From report at bugs.python.org  Sun Jun 14 15:51:08 2009
From: report at bugs.python.org (Alex Shih-Han Lin)
Date: Sun, 14 Jun 2009 13:51:08 +0000
Subject: [issue6283] Cannot build extension in amd64 using msvc9compiler
In-Reply-To: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>
Message-ID: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>


New submission from Alex Shih-Han Lin <alexsh at mail2000.com.tw>:

OS is Windows 7 x64, python using 2.6.2 amd64, SDK installed, but when I
build some module by setup.py, it always traceback ValueError.

running build
running build_py
running build_ext
building 'genshi._speedups' extension
Traceback (most recent call last):
  File "C:\Genshi-0.5.1\setup.py", line 116, in <module>
    'build_ext': optional_build_ext}
  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\distutils\command\build.py", line 134, in run
    self.run_command(cmd_name)
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Genshi-0.5.1\setup.py", line 39, in run
    build_ext.run(self)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 345, in run
    self.build_extensions()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 471, in
build_extensions
    self.build_extension(ext)
  File "C:\Genshi-0.5.1\setup.py", line 45, in build_extension
    build_ext.build_extension(self, ext)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 536, in
build_extension
    depends=ext.depends)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 448, in compile
    self.initialize()
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 358, in initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 274, in
query_vcvarsall
    raise ValueError(str(list(result.keys())))
ValueError: [u'path']

I printed out the variables "result", it only had key 'path'.

----------
components: Library (Lib)
messages: 89348
nosy: alexsh
severity: normal
status: open
title: Cannot build extension in amd64 using msvc9compiler
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6283>
_______________________________________

From report at bugs.python.org  Sun Jun 14 16:38:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Jun 2009 14:38:09 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1244990289.28.0.569444835261.issue5811@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I updated the documentation in r73429. Is that better?

----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sun Jun 14 18:03:21 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 14 Jun 2009 16:03:21 +0000
Subject: [issue6283] Cannot build extension in amd64 using msvc9compiler
In-Reply-To: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>
Message-ID: <1244995401.59.0.470374002469.issue6283@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Do you have VS2008 installed also?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6283>
_______________________________________

From report at bugs.python.org  Sun Jun 14 18:39:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 14 Jun 2009 16:39:48 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244997588.09.0.629297464793.issue6275@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Guido's comment is out of date.  The assertRaises(exception) already 
returns something:  A context manager.

If we don't want to return the object, how about retainig it in the 
context manager, then?
It is very awkward otherwise to make any kinds of assertions on the thrown 
exceptions.  Using the Regexp variant is rather half-assed.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Sun Jun 14 18:44:14 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 14 Jun 2009 16:44:14 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244997854.0.0.188128880566.issue6275@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, his comment was made after assertRaises had already been made a
context manager. 

Keeping the exception attached to the context manager is an interesting
suggestion and a less 'surprising' change to the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Sun Jun 14 18:45:29 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 14 Jun 2009 16:45:29 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244997929.58.0.583277259116.issue6275@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I disagree that the regex version is half-assed though. If all you want
to do is to make assertions about the exception message (the most common
use case in *my* experience) it is enormously convenient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Sun Jun 14 18:49:43 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 14 Jun 2009 16:49:43 +0000
Subject: [issue1399935] enhance unittest to define tests that *should* fail
Message-ID: <1244998183.34.0.918651868462.issue1399935@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Patch needs updating but still seems like a useful feature. I'll update
and commit. I agree that decorator should be lowercase - should_fail or
shouldfail ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1399935>
_______________________________________

From report at bugs.python.org  Sun Jun 14 18:51:45 2009
From: report at bugs.python.org (Daniel Eloff)
Date: Sun, 14 Jun 2009 16:51:45 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1244998305.43.0.650826409337.issue6281@psf.upfronthosting.co.za>


Daniel Eloff <dan.eloff at gmail.com> added the comment:

If you're missing any hash algorithm from openssl (say sha224) and the
corresponding _sha224 module, hashlib will fail to import and no hash
algorithms will be available.

Additionally, if no (or only some) openssl algorithms are available, the
error branch expects every hash algorithm to be present in it's own
module, if even one is missing, hashlib will fail to import.

Producing a test case for these without mock objects is difficult at
best. I leave that to the python team, if they desire to do so.

Here is a rewritten hashlib.py, without that ugly mess of code and
without the above two bugs. It passes all tests.

----------
Added file: http://bugs.python.org/file14297/hashlib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Sun Jun 14 18:52:34 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 14 Jun 2009 16:52:34 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1244998354.75.0.364846055216.issue6275@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Uploading a slimmed down patch, with only the exc_value memeber added to 
the assertRaises context manager.

----------
Added file: http://bugs.python.org/file14298/unitest2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:03:39 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 14 Jun 2009 17:03:39 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

This function returns the output of PyErr_Print as a unicode string.

We needed this in Blender3D because it has its own error logging system
which does not use the console.

The patch is made against python3k r73429.

----------
components: None
files: PyErr_AsUnicode_r73429.diff
keywords: patch
messages: 89357
nosy: ideasman42
severity: normal
status: open
title: C/API PyErr_AsUnicode()
versions: Python 3.1
Added file: http://bugs.python.org/file14299/PyErr_AsUnicode_r73429.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:05:05 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Jun 2009 17:05:05 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1244999105.08.0.516572825235.issue6281@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:08:53 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 14 Jun 2009 17:08:53 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1244999333.59.0.564125380618.issue6284@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

last patch was bad heres a new one.

----------
Added file: http://bugs.python.org/file14300/PyErr_AsUnicode_r73429.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:09:04 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 14 Jun 2009 17:09:04 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1244999344.71.0.404203729746.issue6284@psf.upfronthosting.co.za>


Changes by Campbell Barton <ideasman42 at gmail.com>:


Removed file: http://bugs.python.org/file14299/PyErr_AsUnicode_r73429.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:10:12 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Jun 2009 17:10:12 +0000
Subject: [issue1399935] enhance unittest to define tests that *should* fail
Message-ID: <1244999412.97.0.832942131554.issue1399935@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually, unittest already has @expectedFailure.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1399935>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:12:12 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 14 Jun 2009 17:12:12 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1244999532.82.0.322846985162.issue6284@psf.upfronthosting.co.za>


Changes by Campbell Barton <ideasman42 at gmail.com>:


Removed file: http://bugs.python.org/file14300/PyErr_AsUnicode_r73429.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:12:27 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 14 Jun 2009 17:12:27 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1244999547.27.0.363328863108.issue6284@psf.upfronthosting.co.za>


Changes by Campbell Barton <ideasman42 at gmail.com>:


Added file: http://bugs.python.org/file14301/PyErr_AsUnicode_r73429.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:37:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Jun 2009 17:37:47 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1245001067.56.0.609847458439.issue6281@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Sun Jun 14 19:51:43 2009
From: report at bugs.python.org (ThurnerRupert)
Date: Sun, 14 Jun 2009 17:51:43 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1245001903.07.0.190037465266.issue6208@psf.upfronthosting.co.za>


ThurnerRupert <rupert.thurner at credit-suisse.com> added the comment:

the parent process would be "sh.exe" in the msys case, contrary to the 
windows standard cmd.exe, explorer.exe, system, system idle 
process, ...

an example is the mercurial "status" command, see 
http://selenic.com/repo/index.cgi/hg/file/8bf6eb68ddaf/mercurial/comman
ds.py#l2752

which uses 
http://selenic.com/repo/index.cgi/hg/file/8bf6eb68ddaf/mercurial/util.p
y#l210 (pathto, ), and normpath = os.path.normcase(path).

which does at the end:
 sys.stdout.write(str(a))

when string the string goes out on stdout or stderr it is not known 
any more it was a file path. hmm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6208>
_______________________________________

From report at bugs.python.org  Sun Jun 14 20:18:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Jun 2009 18:18:29 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244967202.64.0.803173384956.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245003653.13303.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I found following patch can fix test_invalid_operations error on
> windows. Is this correct fix? There are many other places using bare open().

The fix looks ok. 
test_io should use self.open() instead of open() everywhere, except in
places where it's not used as a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Sun Jun 14 20:37:17 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 14 Jun 2009 18:37:17 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1245004637.01.0.0453637730728.issue4388@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

This test still fails and is the only failure with Python 3.1rc2 on MacOS 
X 10.4.11 Tiger (Intel).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sun Jun 14 20:40:24 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 14 Jun 2009 18:40:24 +0000
Subject: [issue1252236] Simplying Tkinter's event loop
Message-ID: <1245004824.28.0.994399956943.issue1252236@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Michiel, the patch on #1049855 has been rejected so there is no longer a
fix for the first problem to be solved.
Also, the fourth problem you described is not entirely true, it is
possible to run tkinter apps on IDLE without calling the mainloop
function (see #989712). It is possible that this wasn't the case 4 years
ago, I don't know, just pointing out the current situation.

I also don't understand how just moving event handling to Python will
solve the problems. But maybe it could be good to add an option that
would prevent calling EnableEventHook in _tkinter after loading tk, so
the user could handle tk events and what not the way he whises.

Is there anyone still interested on this ? Please ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1252236>
_______________________________________

From report at bugs.python.org  Sun Jun 14 20:44:46 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 14 Jun 2009 18:44:46 +0000
Subject: [issue3407] test_urllib2_localnet fails on MacOS X 10.4.11 (Intel)
In-Reply-To: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za>
Message-ID: <1245005086.99.0.702118168431.issue3407@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

This test passes with Python 3.1rc2 on MacOS X 10.4.11 Tiger (Intel).

% ./python.exe
Python 3.1rc2 (r31rc2:73411, Jun 14 2009, 09:27:12) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

% ./python.exe Lib/test/test_urllib2_localnet.py
test_proxy_qop_auth_int_works_or_throws_urlerror 
(__main__.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (__main__.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (__main__.ProxyAuthTests) 
... ok
test_proxy_with_no_password_raises_httperror (__main__.ProxyAuthTests) 
... ok
test_200 (__main__.TestUrlopen) ... ok
test_200_with_parameters (__main__.TestUrlopen) ... ok
test_404 (__main__.TestUrlopen) ... ok
test_bad_address (__main__.TestUrlopen) ... ok
test_basic (__main__.TestUrlopen) ... ok
test_chunked (__main__.TestUrlopen) ... ok
test_geturl (__main__.TestUrlopen) ... ok
test_info (__main__.TestUrlopen) ... ok
test_redirection (__main__.TestUrlopen) ... ok
test_sending_headers (__main__.TestUrlopen) ... ok

----------------------------------------------------------------------
Ran 14 tests in 10.202s

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3407>
_______________________________________

From report at bugs.python.org  Sun Jun 14 20:47:40 2009
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 14 Jun 2009 18:47:40 +0000
Subject: [issue3407] test_urllib2_localnet fails on MacOS X 10.4.11 (Intel)
In-Reply-To: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za>
Message-ID: <1245005260.83.0.898682866251.issue3407@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

The test also passes on Python 2.6.2 on MacOS X 10.4.11 Tiger (Intel):

% ./python.exe
Python 2.6.2 (r262:71600, Apr 15 2009, 21:47:16) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

% ./python.exe Lib/test/test_urllib2_localnet.py
test_proxy_qop_auth_int_works_or_throws_urlerror (__main__.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (__main__.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (__main__.ProxyAuthTests) ... ok
test_proxy_with_no_password_raises_httperror (__main__.ProxyAuthTests) ... ok

----------------------------------------------------------------------
Ran 4 tests in 4.233s

OK
test_200 (__main__.TestUrlopen) ... ok
test_200_with_parameters (__main__.TestUrlopen) ... ok
test_404 (__main__.TestUrlopen) ... ok
test_bad_address (__main__.TestUrlopen) ... ok
test_basic (__main__.TestUrlopen) ... ok
test_geturl (__main__.TestUrlopen) ... ok
test_info (__main__.TestUrlopen) ... ok
test_redirection (__main__.TestUrlopen) ... ok
test_sending_headers (__main__.TestUrlopen) ... ok

----------------------------------------------------------------------
Ran 9 tests in 8.954s

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3407>
_______________________________________

From report at bugs.python.org  Sun Jun 14 21:32:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Jun 2009 19:32:55 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1245007975.38.0.360639869607.issue5811@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Rather than "only a single read on the raw stream", it should be "at
most a single read on the raw stream", IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Sun Jun 14 21:59:36 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 14 Jun 2009 19:59:36 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1245009576.06.0.0812992953453.issue6275@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, maybe a bad choice of words :)
I don't write unittests that much, of course, but I have found that when I 
am writing tests for stuff such as http, I want to verify the actual error 
code, i.e. HTTPError.code, which is not possible using the message alone.
Same goes for e.g. socket.error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Sun Jun 14 22:22:12 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 14 Jun 2009 20:22:12 +0000
Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux
In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za>
Message-ID: <1245010932.47.0.308465325502.issue5492@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I can get a similar error from time to time, just try it a couple of
times and I believe you should hit it too.

When that error isn't thrown IDLE prints the traceback of a SystemExit
exception inside IDLE right before closing, so it may be hard to notice.

The error I am able to get (using 3.1rc2+ r73431):


*** Internal Error: rpc.py:SocketIO.localcall()

 Object: stderr 
 Method: <bound method PseudoFile.write of <idlelib.PyShell.PseudoFile
object at 0x8b6084c>> 
 Args: ('SystemExit: None\n',)

Traceback (most recent call last):
  File "/home/gpolo/python-dev/py3k/Lib/idlelib/rpc.py", line 188, in
localcall
    ret = method(*args, **kwargs)
  File "/home/gpolo/python-dev/py3k/Lib/idlelib/PyShell.py", line 1231,
in write
    self.shell.write(s, self.tags)
  File "/home/gpolo/python-dev/py3k/Lib/idlelib/PyShell.py", line 1214,
in write
    self.text.mark_gravity("iomark", "left")
AttributeError: 'NoneType' object has no attribute 'mark_gravity'


I'm not sure if it can't happen in python-trunk too, I see it throws an
exception when leaving IDLE but till now I never got an error message
after IDLE (almost) exited.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5492>
_______________________________________

From report at bugs.python.org  Sun Jun 14 22:27:24 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 14 Jun 2009 20:27:24 +0000
Subject: [issue1230] Tix HList class missing method implementation for
	info_bbox
In-Reply-To: <1205772959.19.0.842538363686.issue1230@psf.upfronthosting.co.za>
Message-ID: <1245011244.29.0.669622393715.issue1230@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Please include a diff of this modified Tix.py instead.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1230>
_______________________________________

From report at bugs.python.org  Sun Jun 14 23:21:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Jun 2009 21:21:47 +0000
Subject: [issue6227] doctest_aliases doesn't test duplicate removal
In-Reply-To: <1244349464.7.0.139481605677.issue6227@psf.upfronthosting.co.za>
Message-ID: <1245014507.62.0.106112980543.issue6227@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in r73432 (trunk), will be merged to py3k after 3.1 is final.
Thanks for the report!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6227>
_______________________________________

From report at bugs.python.org  Mon Jun 15 00:10:32 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Jun 2009 22:10:32 +0000
Subject: [issue5221] help  related topic doesn't exist
In-Reply-To: <1234385289.6.0.0960868675321.issue5221@psf.upfronthosting.co.za>
Message-ID: <1245017432.19.0.90934131923.issue5221@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.1rc2, SPECIALMETHODS help ends with
"Related help topics: BASICMETHODS, ATTRIBUTEMETHODS, CALLABLEMETHODS,
SEQUENCEMETHODS1, MAPPINGMETHODS, SEQUENCEMETHODS2, NUMBERMETHODS,
CLASSES".
The topic list only has SEQUENCEMETHODS and not S...1 and S...2.
So I suspect the two topics were consolidated into one without changing
the cross-reference lists.  The latter need editing.

----------
keywords: +easy
nosy: +tjreedy
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5221>
_______________________________________

From report at bugs.python.org  Mon Jun 15 00:21:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Jun 2009 22:21:56 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1245018116.05.0.897931165803.issue6284@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PyErr_Print seems a too high-level function for this usage:
- it uses sys.excepthook
- it exits the process if the exception is SystemExit (!)

I'd prefer a function similar to PyErr_Display. And sys.stderr should 
not be redirected to a temporary stream: this change is not thread safe.
For example, A new function PyErr_DisplayEx could take an additional 
(PyObject *fp) argument.

As for the Blender use case: isn't it appropriate for Blender to change 
sys.stderr globally, since the console is not used?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Mon Jun 15 00:23:29 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Jun 2009 22:23:29 +0000
Subject: [issue1489051] keyword and topic help broken in Pythonwin IDE
Message-ID: <1245018209.26.0.299363677706.issue1489051@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Something changed in the past year so that keyword and topic help work
in 3.2rc2 at both the main prompt and help prompt.  Thanks to whoever.
If this is also fixed in 2.6.2 or even 2.6 in SVN, this can be closed.

>>> help('while')
The ``while`` statement...
...
>>> help('ASSERTION')
The ``assert`` statement...
...
help> while
The ``while`` statement
...
help> ASSERTION
The ``assert`` statement

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1489051>
_______________________________________

From report at bugs.python.org  Mon Jun 15 00:38:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Jun 2009 22:38:12 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1245019092.51.0.586343656762.issue6281@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In addition, I would replace
    exec funcName + ' = __get_hash(funcName)'
with
    globals()[funcName] = __get_hash(funcName)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Mon Jun 15 01:00:01 2009
From: report at bugs.python.org (Daniel Eloff)
Date: Sun, 14 Jun 2009 23:00:01 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1245020401.54.0.563452772241.issue6281@psf.upfronthosting.co.za>


Daniel Eloff <dan.eloff at gmail.com> added the comment:

Yes, I prefer:

globals()[funcName] = __get_hash(funcName)

The exec was used in the original code, I'm not aware of the style of
the python stdlib programmers, so I tried to be as true to what I found
as possible.

I just wanted to blunt my words in the original post, I don't want
Gregory Smith to view it as a personal attack, I was just frustrated in
having to debug the hashlib code. I'm sure even Gregory would admit it's
not code he's proud of (probably done under a tight deadline.) No doubt
Gregory normally does high quality work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Mon Jun 15 01:12:39 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Jun 2009 23:12:39 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1245021159.65.0.997946615632.issue6095@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Some comments about the patch:

- It seems wasteful to allocate a new PyUnicode object for the "."; the 
posix implements does it right: a simple wcscopy should be enough (and 
reduces the chances of refcount mistakes)

- the last block is not correctly indented; this code uses tabs.

- no need to test for hasattr(posix, 'listdir'): all supported platforms 
have directories and the posix module always exposes this function.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Mon Jun 15 01:22:38 2009
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 14 Jun 2009 23:22:38 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1245021758.44.0.109222247019.issue6095@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

1. Yeah, I know. At first, that's what I wanted to do, but it resulted 
in a lot of code duplication (alloc, memerror, copy), which I didn't 
much like. But then again, what I ended up writing (because I realized I 
had to decref the  new "po") uses up more lines anyway...

2. oops

3. I did it because all other tests do it. I thought there had to be a 
reason (but then again, that old broken "lsdir" test had been there for 
a while...). Even if there's no reason. the new test would really stand 
out compared to the rest...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Mon Jun 15 01:26:47 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Sun, 14 Jun 2009 23:26:47 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>


New submission from Scott David Daniels <Scott.Daniels at Acm.Org>:

When running Idle on Windows XP, Python 3.1rc2, 
a failure to find an entry in the help documents causes Idle to exit
(with no visible indication of why).  The reason is in a failure of the
call to os.startfile, and apparenly the exception causes Idle to exit
silently.  Here is a patch to .../Lib/idlelib/EditorWindow.py:

@@ -436,20 +436,24 @@ class EditorWindow(object):
     def config_dialog(self, event=None):
         configDialog.ConfigDialog(self.top,'Settings')

     def help_dialog(self, event=None):
        
fn=os.path.join(os.path.abspath(os.path.dirname(__file__)),'help.txt')
         textView.view_file(self.top,'Help',fn)

     def python_docs(self, event=None):
-        if sys.platform[:3] == 'win':
-            os.startfile(self.help_url)
-        else:
-            webbrowser.open(self.help_url)
+        try:
+            if sys.platform[:3] == 'win':
+                os.startfile(self.help_url)
+            else:
+                webbrowser.open(self.help_url)
+        except EnvironmentError as why:
+            tkMessageBox.showerror(title='Document Start Failure',
+                                   message=str(why), parent=self.text)
         return "break"

     def cut(self,event):
         self.text.event_generate("<<Cut>>")
         return "break"

     def copy(self,event):
         if not self.text.tag_ranges("sel"):
@@ -741,20 +745,25 @@ class EditorWindow(object):
         # and update the menu dictionary
         self.menudict['help'] = helpmenu

     def __extra_help_callback(self, helpfile):
         "Create a callback with the helpfile value frozen at definition
time"
         def display_extra_help(helpfile=helpfile):
             if not helpfile.startswith(('www', 'http')):
                 url = os.path.normpath(helpfile)
-            if sys.platform[:3] == 'win':
-                os.startfile(helpfile)
-            else:
-                webbrowser.open(helpfile)
+            try:
+                if sys.platform[:3] == 'win':
+                    os.startfile(helpfile)
+                else:
+                    webbrowser.open(helpfile)
+            except EnvironmentError as why:
+                tkMessageBox.showerror(title='Document Start Failure',
+                                   message=str(why), parent=self.text)
+            return "break"
         return display_extra_help

     def update_recent_files_list(self, new_file=None):
         "Load and update the recent files list and menus"
         rf_list = []
         if os.path.exists(self.recent_files_path):
             rf_list_file = open(self.recent_files_path,'r')
             try:

----------
components: IDLE
messages: 89378
nosy: scott_daniels
severity: normal
status: open
title: Silent abort on XP help document display
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Mon Jun 15 01:31:26 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Jun 2009 23:31:26 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1245022286.33.0.156841680204.issue6280@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do you want to write a patch?
(Note: the time module is written in C)

----------
nosy: +amaury.forgeotdarc
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Mon Jun 15 01:40:35 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Jun 2009 23:40:35 +0000
Subject: [issue6282] In tarfile, compression level cannot be specified
In-Reply-To: <1244980199.28.0.54788876069.issue6282@psf.upfronthosting.co.za>
Message-ID: <1245022835.55.0.227050004787.issue6282@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The TarFile.bz2open function does have a 'compresslevel' parameter.
How do you use TarFile?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6282>
_______________________________________

From report at bugs.python.org  Mon Jun 15 02:52:00 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 15 Jun 2009 00:52:00 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245027120.23.0.173163299101.issue6215@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is a patch to convert open() and io.open() to self.open().

# I didn't change _default_chunk_size() but maybe should this also use
self.open()?

----------
Added file: http://bugs.python.org/file14302/self_open.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Mon Jun 15 02:55:07 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 15 Jun 2009 00:55:07 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245027307.38.0.147129252502.issue6215@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> except in places where it's not used as a test.

I couldn't distinguish which one is that case, so I converted all
open(). ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Mon Jun 15 04:28:18 2009
From: report at bugs.python.org (Alex Shih-Han Lin)
Date: Mon, 15 Jun 2009 02:28:18 +0000
Subject: [issue6283] Cannot build extension in amd64 using msvc9compiler
In-Reply-To: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>
Message-ID: <1245032898.21.0.992514675869.issue6283@psf.upfronthosting.co.za>


Alex Shih-Han Lin <alexsh at mail2000.com.tw> added the comment:

yes, I have already installed VS 2008 (but it is Express Edition for VC,
VB ,C#...I have no money to buy standard edition.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6283>
_______________________________________

From report at bugs.python.org  Mon Jun 15 04:32:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jun 2009 02:32:08 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1245033128.61.0.412554437996.issue6277@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

AMK writes the whatsnew for 2.7 and I write it for 3.1.
In the case of 3.1, I already have an entry.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Mon Jun 15 04:50:57 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jun 2009 02:50:57 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1245034257.98.0.472428315038.issue6277@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I should have been clearer.  There is no need to submit patches for
whatsnew documents.  Those are solely the responsiblity of their
individual maintainers (see the instructions at the top of the file).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Mon Jun 15 06:44:09 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 15 Jun 2009 04:44:09 +0000
Subject: [issue1489051] keyword and topic help broken in Pythonwin IDE
Message-ID: <1245041049.22.0.509147890897.issue1489051@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Very good :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1489051>
_______________________________________

From report at bugs.python.org  Mon Jun 15 07:13:30 2009
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 15 Jun 2009 05:13:30 +0000
Subject: [issue6143] IDLE - an extension to clear the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1245042810.25.0.404944600651.issue6143@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I just tried Squeezer. It's pretty neat and it solves a different
problem. Clearing the contents of the shell window should be a simple
operation.

The undo operation doesn't restore iomark properly, nor does it restore
tags. I've uploaded a newer version of the extension to handle undo.

Binding to the "<<undo>>" virtual event with add="+" didn't work as
expected, so the new undo event handler explicitly calls the older one.
I admit that this code is not ideal.

Should I move this extension to the Cheese Shop and close out this issue?

----------
Added file: http://bugs.python.org/file14303/ClearWindow.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6143>
_______________________________________

From report at bugs.python.org  Mon Jun 15 07:21:11 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 15 Jun 2009 05:21:11 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1245043271.77.0.842433821515.issue5811@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Here is a patch that passes all the tests (I had to change some of them
though, they were expecting erroneous behaviours IMHO).
The biggest problem was the read1 testing, I've tried to get the maximum
of bytes less than or equal to what the user wanted while executing at
most 1 raw_read()'s.

I have created a new test for peek()'ing a number of bytes bigger than
could possibly be stored on the buffer.

----------
Added file: http://bugs.python.org/file14304/peek3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Mon Jun 15 07:22:03 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 15 Jun 2009 05:22:03 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1245043323.3.0.134440866913.issue5811@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Here, it's a patch that passes all the tests (I had to change some of them
though, they were expecting erroneous behaviours IMHO).
The biggest problem was the read1 testing, I've tried to get the maximum
of bytes less than or equal to what the user wanted while executing at
most 1 raw_read()'s.

I have created a new test for peek()'ing a number of bytes bigger than
could possibly be stored on the buffer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Mon Jun 15 07:31:31 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Jun 2009 05:31:31 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1245043891.46.0.251396473269.issue6285@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

How exactly did you trigger the error that you are fixing?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Mon Jun 15 07:40:18 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Mon, 15 Jun 2009 05:40:18 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245043891.46.0.251396473269.issue6285@psf.upfronthosting.co.za>
Message-ID: <4A35E040.9060101@Acm.Org>


Scott David Daniels <Scott.Daniels at Acm.Org> added the comment:

I uninstalled 3.1rc1, installed 3.1rc2, was exercising, and went to look
up something in the docs, and Idle disappeared.  I tried again, same
result.  So I opened a command window, and ran Idle as:
     python -m idlelib.idle
Tried it again and got an error message that I chased down.
Figured out it was an oncovered exception, and ....

--Scott David Daniels
Scott.Daniels at Acm.Org

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Mon Jun 15 07:41:24 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Jun 2009 05:41:24 +0000
Subject: [issue6283] Cannot build extension in amd64 using msvc9compiler
In-Reply-To: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>
Message-ID: <1245044484.85.0.250114952341.issue6283@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So when you run vcvarsall.bat, and then do "set", does it print any of
the variables "include", "lib", "libpath", "path"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6283>
_______________________________________

From report at bugs.python.org  Mon Jun 15 07:49:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Jun 2009 05:49:48 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <4A35E040.9060101@Acm.Org>
Message-ID: <4A35E0F9.5060104@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I uninstalled 3.1rc1, installed 3.1rc2, was exercising, and went to look
> up something in the docs

What does that mean? What exactly did you do to "look up something in
the docs"? (I assume "was exercising" didn't cause IDLE to crash)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Mon Jun 15 08:17:35 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Mon, 15 Jun 2009 06:17:35 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <4A35E0F9.5060104@v.loewis.de>
Message-ID: <4A35E8FD.8010704@Acm.Org>


Scott David Daniels <Scott.Daniels at Acm.Org> added the comment:

Help  /  Python31

Instead of docs showing up, all Idle windows closed.
To demonstrate for yourself, edit ~/.idlerc/config-main.cfg
add a line at the end (where additional docs show up), like:
4 = Python31c1;C:/Python31/Doc/python31c1.chm

(where the 4 is just over what you have already).  In my case, I
had a line much like the above left over from the previous candidate.

--Scott David Daniels
Scott.Daniels at Acm.Org

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Mon Jun 15 09:38:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Jun 2009 07:38:47 +0000
Subject: [issue6278] http.server, BaseHTTPRequestHandler write string error
In-Reply-To: <1244891526.85.0.0899506861309.issue6278@psf.upfronthosting.co.za>
Message-ID: <1245051527.76.0.144983342905.issue6278@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

the HTTP response should be a bytes string:
    self.wfile.write(b'test')

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6278>
_______________________________________

From report at bugs.python.org  Mon Jun 15 09:59:08 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jun 2009 07:59:08 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245052748.28.0.401020071414.issue6250@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm curious to whether this needs to be embedded in the compiler or
whether a standalone tool can be offered.  See
http://code.activestate.com/recipes/277940/ for an example of processing
the bytecodes directly.  FWIW, deadcode can already be detected by some
of the existing code quality tools: 
http://www.doughellmann.com/articles/CompletelyDifferent-2008-03-linters/index.html
.  What does this patch offer beyond what we already have with those tools?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 10:45:59 2009
From: report at bugs.python.org (Omri Shaked)
Date: Mon, 15 Jun 2009 08:45:59 +0000
Subject: [issue6282] In tarfile, compression level cannot be specified
In-Reply-To: <1244980199.28.0.54788876069.issue6282@psf.upfronthosting.co.za>
Message-ID: <1245055559.2.0.553012745593.issue6282@psf.upfronthosting.co.za>


Omri Shaked <omri.shaked at gmail.com> added the comment:

Silly me...  Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6282>
_______________________________________

From report at bugs.python.org  Mon Jun 15 11:54:22 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 15 Jun 2009 09:54:22 +0000
Subject: [issue6286] distutils upload command doesn't work with http proxy
In-Reply-To: <1245059662.2.0.968328150082.issue6286@psf.upfronthosting.co.za>
Message-ID: <1245059662.2.0.968328150082.issue6286@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

upload is base on httplib and doesn't use the http_proxy envrionment
variable. So it's impossible to upload a file behind a firewall.

Let's change the command so it uses a proxy if set

----------
assignee: tarek
components: Distutils
messages: 89398
nosy: tarek
severity: normal
status: open
title: distutils upload command doesn't work with http proxy
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6286>
_______________________________________

From report at bugs.python.org  Mon Jun 15 12:37:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Jun 2009 10:37:08 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1245062228.46.0.199452389931.issue5811@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I haven't read the patch in detail but I don't think you should have
changed read1(). read1() is there for optimization purposes and its
current behaviour makes sense IMO.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Mon Jun 15 12:39:13 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Jun 2009 10:39:13 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1245062353.59.0.57108510086.issue5811@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The doc revision definitely does a better job of characterising the
current underspecified behaviour :)

I agree with Antoine that "at most a single read" would be better wording.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Mon Jun 15 15:02:30 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Mon, 15 Jun 2009 13:02:30 +0000
Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from
	Implementation
In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za>
Message-ID: <1245070950.41.0.579637036454.issue5811@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

Ok
A new patch without read1() changes.
Only one test fails, a read1() test:

======================================================================
FAIL: test_read1 (test.test_io.PyBufferedRWPairTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/lucas/Codes/python-stuff/py3k/Lib/test/test_io.py", line
1139, in test_read1
    self.assertEqual(pair.read1(3), b"abc")
AssertionError: b'a' != b'abc'


Since I've changed peek_unlocked() (which is used once by read1()), I
guess there's a problem with read1() expectations about it.

----------
Added file: http://bugs.python.org/file14305/peek4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5811>
_______________________________________

From report at bugs.python.org  Mon Jun 15 15:39:49 2009
From: report at bugs.python.org (James)
Date: Mon, 15 Jun 2009 13:39:49 +0000
Subject: [issue6205] sdist doesn't include data_files
In-Reply-To: <1244210606.6.0.749223227815.issue6205@psf.upfronthosting.co.za>
Message-ID: <1245073189.08.0.727643467883.issue6205@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

great, thanks for the info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6205>
_______________________________________

From report at bugs.python.org  Mon Jun 15 16:50:31 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 15 Jun 2009 14:50:31 +0000
Subject: [issue6208] path separator output ignores shell's path separator: /
	instead of \
In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za>
Message-ID: <1245077431.41.0.698343421952.issue6208@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

> So is this a cosmetic issue or a functional issue? 

It's a cosmetic issue.

> Also, even if it could figure that out, how would it know whether
> a particular filename "stringification" with os.path.join() was 
> intended for display to the user or to be passed to a Windows API?

The Windows API's (at least every one I've ever called) take either
slashes or backslashes, so it wouldn't matter.

I'm +0 on this request, if we could reliably figure out which separator
we wanted to use based on the shell (or maybe an environment variable).
It would be one more way to let me forget I'm using Windows instead of Unix.

My use case is mostly copying path's that have been print()'d from
within Python, then pasting them into a cygwin bash shell. All of the
backslashes need to be manually escaped (or the whole string quoted). Of
course this doesn't help with other characters that also need escaping
(like spaces). That and the fragile nature of the "which shell am I
running" check are why I'm +0.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6208>
_______________________________________

From report at bugs.python.org  Mon Jun 15 16:54:28 2009
From: report at bugs.python.org (Tim Golden)
Date: Mon, 15 Jun 2009 14:54:28 +0000
Subject: [issue6208] path separator output ignores shell's path separator:
	/	instead of \
In-Reply-To: <1245077431.41.0.698343421952.issue6208@psf.upfronthosting.co.za>
Message-ID: <4A366094.70003@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Eric Smith wrote:
> Eric Smith <eric at trueblade.com> added the comment:
> 
>> So is this a cosmetic issue or a functional issue? 
> 
> It's a cosmetic issue.
> 
>> Also, even if it could figure that out, how would it know whether
>> a particular filename "stringification" with os.path.join() was 
>> intended for display to the user or to be passed to a Windows API?
> 
> The Windows API's (at least every one I've ever called) take either
> slashes or backslashes, so it wouldn't matter.

Just for information's sake, the shell APIs usually only accept backslashes.

TJG

----------
nosy: +tim.golden
title: path separator output ignores shell's path separator: / instead of \ -> path separator output ignores shell's path separator: /	instead of \

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6208>
_______________________________________

From report at bugs.python.org  Mon Jun 15 17:07:00 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 15 Jun 2009 15:07:00 +0000
Subject: [issue6208] path separator output ignores shell's path separator:
	/	instead of \
In-Reply-To: <4A366094.70003@timgolden.me.uk>
Message-ID: <4A36638C.3080609@trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

Tim Golden wrote:
> Just for information's sake, the shell APIs usually only accept backslashes.

That's good to know. Do you have any specific examples?

CreateFile and the like, which is where my experience is, take either. 
90% of my Windows Python programs use slashes exclusively. About the 
only time I get a backslash is when using os.path.join(), and then I end 
up with mixed slashes and backslashes. Windows handles these mixed paths 
correctly, as far as I can tell.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6208>
_______________________________________

From report at bugs.python.org  Mon Jun 15 20:28:16 2009
From: report at bugs.python.org (Collin Winter)
Date: Mon, 15 Jun 2009 18:28:16 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245090496.99.0.769275963246.issue6250@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Standalone bytecode-modifying tools almost never check that they're
outputting correct bytecode. http://code.activestate.com/recipes/277940/
makes no attempt to check what version of Python it's running under;
running it under Unladen Swallow 2009Q1 would have produced completely
incorrect code because we had modified how opcode arguments were stored.

I don't want to encourage people to write tools that operate over
CPython bytecode. As such code proliferates, the alternate
implementations have to chase it down and ask that it be removed. It
complicates the process of verifying that other implementations are
compatible with CPython.

Like I said earlier in this issue, for me this is more a compiler
cleanliness issue rather than a performance issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 20:37:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jun 2009 18:37:45 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245091065.91.0.760644211552.issue6250@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Are you looking for dead code detection (like a lint utility) or
automatic dead code removal (modified code)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 21:08:28 2009
From: report at bugs.python.org (James Abbatiello)
Date: Mon, 15 Jun 2009 19:08:28 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245092908.94.0.917434465219.issue6250@psf.upfronthosting.co.za>


James Abbatiello <abbeyj at gmail.com> added the comment:

I should add that the patch doesn't only address dead user-code.  It
also eliminates code that the compiler generates itself but that would
be unreachable at runtime.  Consider the following function:

def foo(x):
  if x:
    raise Something
  else:
    raise SomethingElse


Without the patch this would compile to:
  2           0 LOAD_FAST                0 (x)
              3 POP_JUMP_IF_FALSE       15

  3           6 LOAD_GLOBAL              0 (Something)
              9 RAISE_VARARGS            1
             12 JUMP_FORWARD             6 (to 21)

  5     >>   15 LOAD_GLOBAL              1 (SomethingElse)
             18 RAISE_VARARGS            1
        >>   21 LOAD_CONST               0 (None)
             24 RETURN_VALUE


With the patch this slims down to:

  2           0 LOAD_FAST                0 (x)
              3 POP_JUMP_IF_FALSE       12

  3           6 LOAD_GLOBAL              0 (Something)
              9 RAISE_VARARGS            1

  5     >>   12 LOAD_GLOBAL              1 (SomethingElse)
             15 RAISE_VARARGS            1


So there are benefits even for normal code.

Also the END_FINALLY handling would be really hard to do in a pure
bytecode walker since context from the AST is needed (am I in a
try-finally or try-except or with statement?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 21:48:37 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jun 2009 19:48:37 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245095317.66.0.230010118101.issue6250@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

James, the peepholer currently assumes that codestrings terminate with
RETURN_VALUE.  Is this assumption invalidated by your code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 22:45:34 2009
From: report at bugs.python.org (Matthew Smart)
Date: Mon, 15 Jun 2009 20:45:34 +0000
Subject: [issue6287] distutils.core.setup does not document the 'license'
	meta-data
In-Reply-To: <1245098733.95.0.286380216958.issue6287@psf.upfronthosting.co.za>
Message-ID: <1245098733.95.0.286380216958.issue6287@psf.upfronthosting.co.za>


New submission from Matthew Smart <mattsmart at gmail.com>:

The 'license' meta-data option is not listed under:

http://docs.python.org/distutils/setupscript.html#meta-data

There are others, too, from:

$ python setup.py --help
.. snip ..
Information display options (just display information, ignore any commands)
?--help-commands ? ? list all available commands
?--name ? ? ? ? ? ? ?print package name
?--version (-V) ? ? ?print package version
?--fullname ? ? ? ? ?print <package name>-<version>
?--author ? ? ? ? ? ?print the author's name
?--author-email ? ? ?print the author's email address
?--maintainer ? ? ? ?print the maintainer's name
?--maintainer-email ?print the maintainer's email address
?--contact ? ? ? ? ? print the maintainer's name if known, else the author's
?--contact-email ? ? print the maintainer's email address if known, else the
? ? ? ? ? ? ? ? ? ? ?author's
?--url ? ? ? ? ? ? ? print the URL for this package
?--license ? ? ? ? ? print the license of the package
?--licence ? ? ? ? ? alias for --license
?--description ? ? ? print the package description
?--long-description ?print the long package description
?--platforms ? ? ? ? print the list of platforms
?--classifiers ? ? ? print the list of classifiers
?--keywords ? ? ? ? ?print the list of keywords
?--provides ? ? ? ? ?print the list of packages/modules provided
?--requires ? ? ? ? ?print the list of packages/modules required
?--obsoletes ? ? ? ? print the list of packages/modules made obsolete

----------
assignee: tarek
components: Distutils
messages: 89410
nosy: mattsmart, tarek
severity: normal
status: open
title: distutils.core.setup does not document the 'license' meta-data
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6287>
_______________________________________

From report at bugs.python.org  Mon Jun 15 22:50:28 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 15 Jun 2009 20:50:28 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1245099028.44.0.222257548491.issue6192@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

On consideration, it is more appropariate to have the 
disable_nagle_algorithm as part of StreamRequestHandler rather than in the 
TCPSockerServer.  It then sits right next to the rfile and wfile that 
affect it.
The RequestHandlers aren't documented as extensively as the socket 
servers, though, so the documentation will have to go.
Attached is a patch.

----------
Added file: http://bugs.python.org/file14306/socketserver2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6192>
_______________________________________

From report at bugs.python.org  Mon Jun 15 23:15:45 2009
From: report at bugs.python.org (James Abbatiello)
Date: Mon, 15 Jun 2009 21:15:45 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245100545.65.0.25342043977.issue6250@psf.upfronthosting.co.za>


James Abbatiello <abbeyj at gmail.com> added the comment:

Raymond, I've updated peephole.c to allow code to terminate with any of
RETURN_VALUE, END_FINALLY or RAISE_VARARGS [0-3].  I also added tests to
test_peepholer.py to make sure the peepholer still works in these cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 23:28:44 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Jun 2009 21:28:44 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245101324.11.0.809600980009.issue6250@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Martin, am transferring this to you for adjudication.  I'm -0 on the patch.

On the plus side, the code is well thought-out and reasonably well
tested.  On the minus side, it complexifies the compiler in a way that
may make it more difficult to maintain.

The benefits to the end-user are almost invisible.  

Developers may possibly benefit from the -r command-line argument as a
way of detecting errors in their own code, but this functionality may be
better suited to lint utilities such as pylint which already supports
detection of unreachable code).

We've rejected previous, less sophisticated patches for dead code
elimination on the theory that there was too little pay-off. And at one
point, Guido expressed a disinclination to any efforts to neaten-up the
generated bytecode (he compared it to rearranging assembly language and
thought there was little point to it).

----------
assignee: rhettinger -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 23:32:23 2009
From: report at bugs.python.org (Miles Kaufmann)
Date: Mon, 15 Jun 2009 21:32:23 +0000
Subject: [issue6234] cgi.FieldStorage is broken when given POST data
In-Reply-To: <1244412456.94.0.493968112391.issue6234@psf.upfronthosting.co.za>
Message-ID: <1245101543.03.0.665878551098.issue6234@psf.upfronthosting.co.za>


Changes by Miles Kaufmann <milesck at umich.edu>:


----------
nosy: +milesck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6234>
_______________________________________

From report at bugs.python.org  Mon Jun 15 23:34:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Jun 2009 21:34:05 +0000
Subject: [issue6250] Python compiles dead code
In-Reply-To: <1244606385.56.0.541524324574.issue6250@psf.upfronthosting.co.za>
Message-ID: <1245101645.39.0.22177530539.issue6250@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm also happy with rejecting the patch, and agree with everything that
has been brought up against it: from an end-user point of view, there is
a negligible-if-any benefit (e.g. if you want to speed up importing, try
to reduce the number of stat() calls instead). For a developer, this
analysis is much better added to pylint.

Thanks for the contribution, anyway - don't get discouraged by this
rejection.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6250>
_______________________________________

From report at bugs.python.org  Mon Jun 15 23:43:09 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Jun 2009 21:43:09 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Just a placeholder to remind me to implement the suggestion from
python-dev of updating the contextlib.nested docs to show:

1. The one remaining valid use case (variable number of context managers)
2. The warnings module incantation needed to suppress the deprecation
warning

----------
assignee: ncoghlan
components: Documentation
messages: 89415
nosy: benjamin.peterson, ncoghlan
priority: release blocker
severity: normal
status: open
title: Update contextlib.nested docs in light of deprecation
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Mon Jun 15 23:50:52 2009
From: report at bugs.python.org (Miles Kaufmann)
Date: Mon, 15 Jun 2009 21:50:52 +0000
Subject: [issue5468] urlencode does not handle "bytes",
	and could easily handle alternate encodings
In-Reply-To: <1236696316.6.0.478633045289.issue5468@psf.upfronthosting.co.za>
Message-ID: <1245102652.67.0.350101735882.issue5468@psf.upfronthosting.co.za>


Miles Kaufmann <milesck at umich.edu> added the comment:

parse_qs and parse_qsl should also grow encoding and errors parameters to 
pass to the underlying unquote().

----------
nosy: +milesck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5468>
_______________________________________

From report at bugs.python.org  Tue Jun 16 00:22:41 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 15 Jun 2009 22:22:41 +0000
Subject: [issue6289] compile() raises SyntaxError with confusing message for
	some decoding problems
In-Reply-To: <1245104560.97.0.54765703858.issue6289@psf.upfronthosting.co.za>
Message-ID: <1245104560.97.0.54765703858.issue6289@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Consider this source file:

  # coding: ascii
  ?

It is not a valid Python program (for several reasons).  The first
problem encountered is that bytes representing SNOWMAN do not fit into
ASCII, so the file cannot be decoded using the declared encoding.

If one tries to import this file, a reasonable thing happens:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "encodingfoo.py", line 2
SyntaxError: 'ascii' codec can't decode byte 0xe2 in position 0: ordinal
not in range(128)

If the builtin compile() is used instead, though, something different
happens:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 0
SyntaxError: unknown encoding: ascii

----------
components: Library (Lib)
messages: 89417
nosy: exarkun
severity: normal
status: open
title: compile() raises SyntaxError with confusing message for some decoding problems
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6289>
_______________________________________

From report at bugs.python.org  Tue Jun 16 00:27:07 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Jun 2009 22:27:07 +0000
Subject: [issue6289] compile() raises SyntaxError with confusing message for
	some decoding problems
In-Reply-To: <1245104560.97.0.54765703858.issue6289@psf.upfronthosting.co.za>
Message-ID: <1245104827.91.0.433080823101.issue6289@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6289>
_______________________________________

From report at bugs.python.org  Tue Jun 16 01:19:55 2009
From: report at bugs.python.org (Alex James)
Date: Mon, 15 Jun 2009 23:19:55 +0000
Subject: [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>


New submission from Alex James <ac.james at shaw.ca>:

When using cPickle to pickle / unpickle an object instance whose
__dict__ contains a dictionary of NumPy Arrays (on a windows32 system),
some of the array elements have the wrong type raising a ValueError:
could not convert string to float.  

On UNIX platform this error does not occur, and the data is read out in
the correct type every time.  
Forcing the caller to use pickle.py module instead removed the issue.

Statements about the imprecision of cPickle (such as issue1536, 655802),
or its deprecaition (now I can't find where that was mentioned), would
assist.  By contrast the current state of the documentation implies that
cPickle is better overall, and thus should be used preferentially.

----------
assignee: georg.brandl
components: Documentation, Extension Modules, Windows
messages: 89418
nosy: ac.james, georg.brandl
severity: normal
status: open
title: cPickle can misread data type
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6290>
_______________________________________

From report at bugs.python.org  Tue Jun 16 01:22:28 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 15 Jun 2009 23:22:28 +0000
Subject: [issue6286] distutils upload command doesn't work with http proxy
In-Reply-To: <1245059662.2.0.968328150082.issue6286@psf.upfronthosting.co.za>
Message-ID: <1245108148.2.0.906239387365.issue6286@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6286>
_______________________________________

From report at bugs.python.org  Tue Jun 16 01:31:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 15 Jun 2009 23:31:39 +0000
Subject: [issue6286] distutils upload command doesn't work with http proxy
In-Reply-To: <1245059662.2.0.968328150082.issue6286@psf.upfronthosting.co.za>
Message-ID: <1245108699.22.0.229615369525.issue6286@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73436. Will merge it into 3.2 after 3.1 is tagged.

I am leaving this issue open until the merge in 3.2 is done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6286>
_______________________________________

From report at bugs.python.org  Tue Jun 16 02:30:35 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Jun 2009 00:30:35 +0000
Subject: [issue6289] compile() raises SyntaxError with confusing message for
	some decoding problems
In-Reply-To: <1245104560.97.0.54765703858.issue6289@psf.upfronthosting.co.za>
Message-ID: <1245112235.48.0.272797586069.issue6289@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r73439.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6289>
_______________________________________

From report at bugs.python.org  Tue Jun 16 03:24:59 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 16 Jun 2009 01:24:59 +0000
Subject: [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245115499.6.0.424570165329.issue6290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Could you provide a test case? The behaviour you are describing sounds
like a bug in cPickle.

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6290>
_______________________________________

From report at bugs.python.org  Tue Jun 16 04:47:10 2009
From: report at bugs.python.org (hippietrail)
Date: Tue, 16 Jun 2009 02:47:10 +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: <1245120430.3.0.619688410492.issue3672@psf.upfronthosting.co.za>


Changes by hippietrail <hippytrail at gmail.com>:


----------
nosy: +hippietrail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3672>
_______________________________________

From report at bugs.python.org  Tue Jun 16 05:19:09 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 16 Jun 2009 03:19:09 +0000
Subject: [issue3407] test_urllib2_localnet fails on MacOS X 10.4.11 (Intel)
In-Reply-To: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za>
Message-ID: <1245122349.44.0.648561159548.issue3407@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Closing it based on the (test pass) comments.
Fix was applied in r67779, r67777.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3407>
_______________________________________

From report at bugs.python.org  Tue Jun 16 06:11:46 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Tue, 16 Jun 2009 04:11:46 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1245125506.38.0.963313213075.issue6277@psf.upfronthosting.co.za>


Vikram U Shenoy <vikram.u.shenoy at gmail.com> added the comment:

I see. OK, so you want me to close this bug ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Tue Jun 16 06:16:34 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Jun 2009 04:16:34 +0000
Subject: [issue6277] Add description of new syntax of with to 2.7 whatsnew
	document.
In-Reply-To: <1244885929.71.0.866974150177.issue6277@psf.upfronthosting.co.za>
Message-ID: <1245125794.23.0.676676225962.issue6277@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks.  BTW, other doc patches are always welcome.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6277>
_______________________________________

From report at bugs.python.org  Tue Jun 16 09:37:07 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 16 Jun 2009 07:37:07 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245137827.12.0.786737957083.issue6288@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Does that mean that nested() can be removed or changed incompatibly in
3.2 at the same time that an alternative way for handling the remaining
use case is introduced?

This would seem to violate the promise in PEP 5, that "users will have
at least a year to test their programs and migrate them from use of the
deprecated construct to the alternative one".

----------
nosy: +hagen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Tue Jun 16 09:46:38 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 16 Jun 2009 07:46:38 +0000
Subject: [issue6287] distutils.core.setup does not document the 'license'
	meta-data
In-Reply-To: <1245098733.95.0.286380216958.issue6287@psf.upfronthosting.co.za>
Message-ID: <1245138398.74.0.317339322124.issue6287@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73441 and merged in all branches. 

Thanks !

----------
components: +Documentation
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6287>
_______________________________________

From report at bugs.python.org  Tue Jun 16 09:54:16 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 16 Jun 2009 07:54:16 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1245138856.8.0.640947894683.issue6164@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This patch will not work with the compiler is gcc or g++

Is that intended ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Tue Jun 16 10:19:54 2009
From: report at bugs.python.org (Milivoj Milani)
Date: Tue, 16 Jun 2009 08:19:54 +0000
Subject: [issue6291] TypeError: b2a_base64() argument 1 must be bytes or
	buffer, not str during SMTP.login
In-Reply-To: <1245140394.87.0.288539266224.issue6291@psf.upfronthosting.co.za>
Message-ID: <1245140394.87.0.288539266224.issue6291@psf.upfronthosting.co.za>


New submission from Milivoj Milani <milivojm at gzr.hr>:

When trying to send an e-mail using a tutorial like example, I get the 
following message:

Traceback (most recent call last):
  File "test.py", line 3, in <module>
    server.login("domena\someuser","somepassword")
  File "C:\Python\lib\smtplib.py", line 583, in login
    "%s %s" % (AUTH_LOGIN, encode_base64(user)))
  File "C:\Python\lib\email\base64mime.py", line 96, in body_encode
    enc = b2a_base64(s[i:i + max_unencoded]).decode("ascii")
TypeError: b2a_base64() argument 1 must be bytes or buffer, not str

----------
components: Library (Lib)
files: test.py
messages: 89428
nosy: milivojm
severity: normal
status: open
title: TypeError: b2a_base64() argument 1 must be bytes or buffer, not str during SMTP.login
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file14307/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6291>
_______________________________________

From report at bugs.python.org  Tue Jun 16 13:57:13 2009
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 16 Jun 2009 11:57:13 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1245153433.56.0.706216948062.issue6284@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

Thanks for the feedback, I wasnt aware of PyErr_Display, its not
documented as far as I know.

http://docs.python.org/dev/py3k/genindex-all.html

For blender, its development id still in progress so we don't yet have
an internal console replacement.

however we use a number of python apis in blender (game engine api, UI
api, wrapping our own data) - So there are a number of places where this
function could come in handy, and completely replacing the stdout isn't
always an option - when running the game engine for instance.

Ill look into using a PyErr_DisplayEx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Tue Jun 16 14:22:49 2009
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 16 Jun 2009 12:22:49 +0000
Subject: [issue6284] C/API PyErr_AsUnicode()
In-Reply-To: <1244999019.35.0.083174578591.issue6284@psf.upfronthosting.co.za>
Message-ID: <1245154969.03.0.873163198495.issue6284@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

Updated with an PyErr_DisplayEx function that accepts a file argument.

----------
Added file: http://bugs.python.org/file14308/PyErr_AsUnicode_r73443.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6284>
_______________________________________

From report at bugs.python.org  Tue Jun 16 14:59:26 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Jun 2009 12:59:26 +0000
Subject: [issue6291] TypeError: b2a_base64() argument 1 must be bytes or
	buffer, not str during SMTP.login
In-Reply-To: <1245140394.87.0.288539266224.issue6291@psf.upfronthosting.co.za>
Message-ID: <1245157166.04.0.833740759627.issue6291@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 5259, and has already been fixed.  Thanks
for the report.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> smtplib is broken in Python3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6291>
_______________________________________

From report at bugs.python.org  Tue Jun 16 15:44:22 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jun 2009 13:44:22 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245159862.19.0.590146858904.issue6288@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That's a good point actually - with 3.1's "in-between" status and the
lack of deprecation in 2.6, nested() is going to have to stick around
for 2.7/3.2 anyway.

So PendingDeprecation now with full deprecation in 2.7/3.2 when we will
hopefully have a better alternative in place is probably the way to go.

Updating the docs to cover only the recommended use case is still
something I want to do this week though (hopefully tomorrow).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Tue Jun 16 19:13:21 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Jun 2009 17:13:21 +0000
Subject: [issue1191964] asynchronous Subprocess
Message-ID: <1245172401.06.0.0389634649603.issue1191964@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Retargeting to 3.2 since 3.1 is now feature-frozen.

----------
nosy: +r.david.murray
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Tue Jun 16 19:25:57 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 16 Jun 2009 17:25:57 +0000
Subject: [issue6292] Fix tests to work with -OO
In-Reply-To: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>
Message-ID: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

The attached patch fixes a number of tests to work when -OO is given to 
Python. The majority of these tests are docstring-related, either doctests 
or making assertions about __doc__, with a handful of tests testing that 
assert statements will trigger and another handful of distutils tests that 
are looking for .pyc files.

With this applied, PYTHONOPTIMIZE=2 ./python.exe -OO Lib/test/regrtest.py 
now passes for trunk.

----------
components: Tests
files: oo_tests.patch
keywords: easy, patch
messages: 89434
nosy: collinwinter, jyasskin, rnk
severity: normal
stage: patch review
status: open
title: Fix tests to work with -OO
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14309/oo_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6292>
_______________________________________

From report at bugs.python.org  Tue Jun 16 19:28:18 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Jun 2009 17:28:18 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245173298.26.0.953214930126.issue6288@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

There is *no* reason to downgrade the warning.  We can leave it as
deprecated in 3.1 and remove it in 3.3 if we want.

A PendingDeprecationWarning is just a plain bad idea, it doesn't
actually warn the users.  We introduced that construct in Python 2.3 to
be used *rarely* for deeply entrenched things like string exceptions
that would be eventually removed.  For the most part, everything else
gets deprecated directly.  Also, remember that this construct is not
being deprecated just because it is duplicative; it is being deprecated
because it is a bug factory when used as advertised -- it is a harmful
construct -- it *needs* a warning.

Someone like Hagan, using it for a corner case, can easily put a copy
and paste version in their own code and use it forever.  There are
likely very few such users now (but there will be more if we fail to
provide a real warning).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Tue Jun 16 19:35:31 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 16 Jun 2009 17:35:31 +0000
Subject: [issue6293] Have regrtest.py echo back sys.flags
In-Reply-To: <1245173731.34.0.991251966726.issue6293@psf.upfronthosting.co.za>
Message-ID: <1245173731.34.0.991251966726.issue6293@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

This patch makes regrtest.py echo back the contents of sys.flags at the 
beginning of a test run. Unladen Swallow has found this useful for 
verifying that the regrtest.py settings in the Makefile and in our 
Buildbot configs are interacting as expected.

Example output:
$ PYTHONOPTIMIZE=2 ./python.exe -OO Lib/test/regrtest.py
Testing with flags: sys.flags(debug=0, py3k_warning=0, 
division_warning=0, division_new=0, inspect=0, interactive=0, 
optimize=2, dont_write_bytecode=0, no_user_site=0, no_site=0, 
ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0)
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
[snip]
$

----------
components: Tests
files: regrtest_flags.patch
keywords: easy, patch
messages: 89436
nosy: collinwinter
severity: normal
stage: patch review
status: open
title: Have regrtest.py echo back sys.flags
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14310/regrtest_flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6293>
_______________________________________

From report at bugs.python.org  Tue Jun 16 21:06:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Jun 2009 19:06:00 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245179160.86.0.708078438792.issue6288@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

To be clear, I'm strongly -1 on switching to a PendingDeprecationWarning.  

That is not what it is for.  There is nothing in the PEP 5 language that
requires it (a PDW isn't even mentioned, the pep is mainly targeted at
deep language changes to the parser and compiler).

I realize that Hagan wants to resurrect this construct, but he needs to
recognize that it is unsalvagable.  

It is likely that most current uses of nested() are replaceable by the
new with-statement.  Some of those uses are buggy (no clean-up for
failed constructors).  The process of converting those cases will fix
the bugs.  We are doing these users a disservice if the warning is made
silent by default.  People *need* to be notified about the potential
bugginess.

Essentially, the new with-statement syntax is a bugfix (the old API was
hopelessly error-prone in a way that is hard to find and fix).  The
statement in the docs that nested() is *equivalent* to two nested withs
is erroneous -- the function is buggy because the equivalence is broken
(a user is much better-off just writing two with-statements than using
nested()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Tue Jun 16 21:45:00 2009
From: report at bugs.python.org (Trent Mick)
Date: Tue, 16 Jun 2009 19:45:00 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1245181500.85.0.285726409094.issue6164@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

Tarek,

This should not affect anyone using gcc or g++ on AIX because of this
check just before the lines added by this patch:

         elif compiler[:3] == "gcc" or compiler[:3] == "g++":
             return "-Wl,-R" + dir

The intention of the patch is to fix linker argument handling with NOT
using gcc, i.e. when using IBM's native AIX compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Wed Jun 17 00:25:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jun 2009 22:25:39 +0000
Subject: [issue6292] Fix tests to work with -OO
In-Reply-To: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>
Message-ID: <1245191139.72.0.022800667751.issue6292@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Rather than silently skipping stuff or writing to stderr, the patch
should, as much as possible, use the new test-skipping API in unittest.
Perhaps DocTestSuite could centralize some of the effort by inspecting
sys.flags and skipping accordingly (but users may also set __doc__
manually).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6292>
_______________________________________

From report at bugs.python.org  Wed Jun 17 00:28:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Jun 2009 22:28:03 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245191283.95.0.537524825642.issue6215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the patch looks ok, so you can commit it if it fixes things on
Windows. (I honestly haven't tested it, though)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Wed Jun 17 02:01:51 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Jun 2009 00:01:51 +0000
Subject: [issue6294] Improve shutdown exception ignored message
In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>
Message-ID: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

When (at least sometimes) exceptions occur during shutdown, warnings
like the following appear:
Exception TypeError: "'NoneType' object is not callable" in  ignored

This is apparently meant to be read as 
Exception <<TypeError: "'NoneType' object is not callable" in ...>>
[was] ignored

instead of, for instance
Exception TypeError: "'NoneType' object is not callable" in ignored

Even when parsed correctly, it is a bit mysterious (who/what ignored the
exception?) to one not in the know and has generated more than one
python-list thread.

Suggestion (from John Machin): reword to something like

Shutdown ignored this exception: TypeError: "'NoneType' object is not
callable"

This would tell people that they might need to find out more about the
shutdown process.

Would it be permissible to change this in 3.1?

----------
keywords: easy
messages: 89441
nosy: tjreedy
severity: normal
status: open
title: Improve shutdown exception ignored message
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6294>
_______________________________________

From report at bugs.python.org  Wed Jun 17 04:50:43 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jun 2009 02:50:43 +0000
Subject: [issue6294] Improve shutdown exception ignored message
In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>
Message-ID: <1245207043.31.0.473872982886.issue6294@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since 3.1 is in final release candidate, a change like this is not
appropriate for 3.1.

This error message is generated in PyErr_WriteUnraisable, which is
called from many contexts, including __del__ methods. A __del__ method
called during shutdown is most likely what is generating the error you
are speaking of, but as far as I know the __del__ method has no way to
know that it is being called during shutdown in particular.  So the
proposed fix to the message won't work.

The reason this message is so mysterious is that in this particular case
there is additional information that normally appears in the message
that has apparently also been nullified during shutdown and that token
is simply omitted.  This appears to be a bug, since the code substitutes
<unknown> for other elements that are substituted into the message if
they are NULL, but does not do so for the object passed in to the
subroutine.  Either the fact that the object prints as the empty string
is a bug, or <unknown> should be substituted for it.  With that bug
fixed, the message would read:

   Exception TypeError: "'NoneType' object is not callable" in <unknown>
ignored

which is more easily parsed correctly.  As long as we're mucking about
in that code, though, perhaps a more generic reformatting of the message
would be clearer even with that bug fixed. I suggest:

   The following Exception of type TypeError was raised in <unknown> but
was ignored: 'NoneType' object is not callable

----------
components: +Interpreter Core
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6294>
_______________________________________

From report at bugs.python.org  Wed Jun 17 06:25:40 2009
From: report at bugs.python.org (John Jackson)
Date: Wed, 17 Jun 2009 04:25:40 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1245212740.94.0.38757308395.issue2622@psf.upfronthosting.co.za>


John Jackson <johnjackson at pobox.com> added the comment:

Also occurs in 2.6...

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
_______________________________________

From report at bugs.python.org  Wed Jun 17 08:27:01 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Jun 2009 06:27:01 +0000
Subject: [issue6294] Improve shutdown exception ignored message
In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>
Message-ID: <1245220021.11.0.772275407398.issue6294@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I should have said 3.1.1.  Ie, would this be a bug fix or really a new
feature that has to wait.  Moot until someone does a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6294>
_______________________________________

From report at bugs.python.org  Wed Jun 17 08:59:35 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 17 Jun 2009 06:59:35 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1245221975.04.0.720683894088.issue6164@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes, I know it will not affect g++ or gcc users,

I was asking that to make sure Sridhar do not intend to make it work on
a system where gcc or g++ are *also* used since they will be picked
prior to this option.

I'll include that patch then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Wed Jun 17 09:07:45 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 17 Jun 2009 07:07:45 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245222465.13.0.980510188118.issue6215@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Committed in r73461.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Wed Jun 17 11:18:33 2009
From: report at bugs.python.org (nojhan)
Date: Wed, 17 Jun 2009 09:18:33 +0000
Subject: [issue6295] curses doc : getch is blocking by default
In-Reply-To: <1245230313.16.0.0482722350238.issue6295@psf.upfronthosting.co.za>
Message-ID: <1245230313.16.0.0482722350238.issue6295@psf.upfronthosting.co.za>


New submission from nojhan <nojhan at gmail.com>:

The documentation of the curses module is not clear on the fact that
getch is blocking by default:
http://docs.python.org/3.0/library/curses.html#curses.window.getch

I suggest the following description instead of the current one:
"Get a character. Note that the integer returned does not have to be in
ASCII range: function keys, keypad keys and so on return numbers higher
than 256. By default, getch() is blocking and wait indefinitely for a
key press. In nodelay() mode, -1 is returned if there is no input."

----------
assignee: georg.brandl
components: Documentation
messages: 89447
nosy: georg.brandl, nojhan
severity: normal
status: open
title: curses doc : getch is blocking by default
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6295>
_______________________________________

From report at bugs.python.org  Wed Jun 17 11:36:39 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 17 Jun 2009 09:36:39 +0000
Subject: [issue6295] curses doc : getch is blocking by default
In-Reply-To: <1245230313.16.0.0482722350238.issue6295@psf.upfronthosting.co.za>
Message-ID: <1245231399.18.0.996795544666.issue6295@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've committed a similar change in r73462.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6295>
_______________________________________

From report at bugs.python.org  Wed Jun 17 11:40:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 17 Jun 2009 09:40:31 +0000
Subject: [issue5641] Local variables not freed when Exception raises in
	function called from cycle
In-Reply-To: <1238575778.52.0.687578256719.issue5641@psf.upfronthosting.co.za>
Message-ID: <1245231631.27.0.360497196843.issue5641@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, it's the basic principle that an object is not destroyed until
there are no more references to it. The documented semantics I referred
to are that a variable assigned to in an "except X, Y" clause lives
beyond the scope of that clause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5641>
_______________________________________

From report at bugs.python.org  Wed Jun 17 11:43:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 17 Jun 2009 09:43:42 +0000
Subject: [issue6255] PyInt_FromSize_t is undocumented.
In-Reply-To: <1244650021.11.0.405068030111.issue6255@psf.upfronthosting.co.za>
Message-ID: <1245231822.05.0.265979351039.issue6255@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Documented in r73463.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6255>
_______________________________________

From report at bugs.python.org  Wed Jun 17 12:09:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jun 2009 10:09:31 +0000
Subject: [issue6294] Improve shutdown exception ignored message
In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>
Message-ID: <1245233371.99.0.919338192903.issue6294@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, in that case then yes, the message bug can be fixed in 3.1.1 and
2.6.3.  As for the message format, the format of messages is not
considered part of the Python API, but changes to message formats can
nonetheless cause compatibility issues that would argue for not
backporting. However, because this is a message you can't even trap it
should be completely safe to change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6294>
_______________________________________

From report at bugs.python.org  Wed Jun 17 14:13:13 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Jun 2009 12:13:13 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245240793.42.0.610074724516.issue6288@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In light of Raymond's comments (which make sense to me), I'm just
updating the documentation and leaving the full deprecation warning in
place.

The new docs are deliberately explicit about *why* trying to use the
current form of nested is almost certainly a bad idea.

Added for 2.7 in r73465.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Wed Jun 17 14:30:11 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Jun 2009 12:30:11 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245241811.36.0.479813786687.issue6288@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And done for 3.1 in r73466

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Wed Jun 17 15:33:50 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 17 Jun 2009 13:33:50 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py sdist
	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

setup.py should be able to generate tarfile distributions on Windows
without requiring tar to be on the path.

Ideally "setup.py sdist" should create the same type of archive (zip or
tarball) by default independent of platform.

At the moment it creates a zip by default on Windows and a tarball on
Linux / OS X.

Packages created on Windows also have CRLF line endings in the MANIFEST
file which is a nuisance for non-Windows consumers of distributions.

----------
assignee: tarek
components: Distutils
messages: 89454
nosy: michael.foord, tarek
severity: normal
status: open
title: Native (and default) tarfile support for setup.py sdist in distutils on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 16:01:42 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 17 Jun 2009 14:01:42 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py sdist
	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245247302.51.0.768621818332.issue6296@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Now that distutils uses tarfile (see #6048) we can propose a tar archive
on all platform by default without requiring "tar" to be installed.

Althoug, the gz compression requires the zlib module. I need to check
what are the requirements of its installation in the sdtlib.

For the MANIFEST file, do you mean the file generated by MANIFEST.in ?

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 16:20:05 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 17 Jun 2009 14:20:05 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py sdist
	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245248405.96.0.490891804023.issue6296@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Given that Windows can't handle tar files by default but all platforms
support zip out of the box wouldn't (unfortunately) zip be a better default?

For the MANIFEST I meant the file called MANIFEST that distutils creates
(and includes in the distribution) when you run "setup.py sdist".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 16:29:40 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 17 Jun 2009 14:29:40 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py sdist
	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245248980.12.0.0255225261761.issue6296@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

As a developer I prefer .tar.gz, but I don't have a strong opinion on
picking zip or tar, I think tar is fine as long as all installers out
there (easy_install, pip, etc) are  working with the archives on every
platform too.

Someone who wants more can handle tar imho.

i'll sen a mail to distutils-SIG

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:00:02 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 15:00:02 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1245250802.61.0.772119634542.issue5800@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

Patch attached.  While I was at it, I also removed stupid whitespace and 
generally made the module more PEP8-compliant.

----------
nosy: +ptn
Added file: http://bugs.python.org/file14311/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:03:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 17 Jun 2009 15:03:37 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1245251017.25.0.91010489497.issue5800@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I have added another issue for PEP 8 compliancy at #5801

----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:06:36 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 15:06:36 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1245251196.47.0.893496252943.issue5801@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

The patch for issue #5800 solves this.

----------
nosy: +ptn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:27:17 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 17 Jun 2009 15:27:17 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py sdist
	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245252437.03.0.716640523964.issue6296@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The point is not for developers who are happy handling .tar.gz but users
of the distribution who don't have a way of handling them.

I prefer .tar.gz myself as well but I don't think the default
distribution format should be one that isn't natively supported by one
of the major platforms that Python runs on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:29:22 2009
From: report at bugs.python.org (Tim Golden)
Date: Wed, 17 Jun 2009 15:29:22 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245252437.03.0.716640523964.issue6296@psf.upfronthosting.co.za>
Message-ID: <4A390BC7.6060600@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

What's superior about .tar.gz? (This is a genuine question).

----------
nosy: +tim.golden
title: Native (and default) tarfile support for setup.py sdist in distutils on Windows -> Native (and default) tarfile support for setup.py sdist	in distutils on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:36:33 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 17 Jun 2009 15:36:33 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245252993.76.0.47940933816.issue6296@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Better compression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:47:02 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 17 Jun 2009 15:47:02 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245253622.21.0.581135799671.issue6296@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

I strongly favor a common approach instead of doing it differently on
different platforms.  (Aside: check out the gratuitous differences for
names and locations of distutils config files:
http://docs.python.org/install/index.html#location-and-names-of-config-files
.)

I weakly favor tar over zip.  The current release of tar features LZMA
compression, for example:

$ ls -lS
-rw-rw-r-- 1 zooko zooko 8355840 2009-06-17 09:48
allmydata-tahoe-1.4.1-r3916.tar
-rw-rw-r-- 1 zooko zooko 2562835 2009-06-17 09:51
allmydata-tahoe-1.4.1-r3916.zip
-rw-rw-r-- 1 zooko zooko 2383653 2009-06-17 09:48
allmydata-tahoe-1.4.1-r3916.tar.gz
-rw-rw-r-- 1 zooko zooko 2250149 2009-06-17 09:49
allmydata-tahoe-1.4.1-r3916.tar.bz2
-rw-rw-r-- 1 zooko zooko 2223425 2009-06-17 09:49
allmydata-tahoe-1.4.1-r3916.tar.rz
-rw-rw-r-- 1 zooko zooko 1818466 2009-06-17 09:52
allmydata-tahoe-1.4.1-r3916.7z
-rw-rw-r-- 1 zooko zooko 1811698 2009-06-17 09:50
allmydata-tahoe-1.4.1-r3916.tar.xz

Presumably the current tar module in Python doesn't yet support LZMA,
but it is a good possibility for the future.  On the other hand, ZIP is
more widely used, e.g. by setuptools and especially by tools which were
born in Windows world.

----------
nosy: +zooko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 17 17:51:16 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 15:51:16 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245253876.36.0.878533497116.issue6064@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

+1, but I can't apply the patch cleanly:

$ patch -p0 < threading.diff
patching file Doc/library/threading.rst
Hunk #1 succeeded at 198 (offset -17 lines).
Hunk #2 succeeded at 211 (offset -17 lines).
Hunk #3 succeeded at 230 (offset -17 lines).
patching file Lib/threading.py
Hunk #1 succeeded at 407 with fuzz 1 (offset -16 lines).
Hunk #2 FAILED at 416.
1 out of 2 hunks FAILED -- saving rejects to file Lib/threading.py.rej
patching file Lib/test/test_threading.py
Hunk #1 succeeded at 350 with fuzz 2 (offset 14 lines).

----------
nosy: +ptn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 18:09:08 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 16:09:08 +0000
Subject: [issue1685] linecache .updatecache fails on utf8 encoded files
In-Reply-To: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za>
Message-ID: <1245254948.17.0.51693773962.issue1685@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

Cannot reproduce on Ubuntu 9.04 with py3k at revision 73267:

$ ./python
Python 3.1rc1+ (py3k:73267, Jun  7 2009, 14:45:03) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb
[49404 refs]
>>> d = pdb.Pdb()
[49446 refs]
>>> fname = r"temp/test.py"
[49448 refs]
>>> print(d.set_break(fname,1))
None
[49505 refs]

----------
nosy: +ptn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685>
_______________________________________

From report at bugs.python.org  Wed Jun 17 18:20:40 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 17 Jun 2009 16:20:40 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245255640.64.0.154071582222.issue6064@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I'm attaching a new diff (svn diff > threading.diff), hope this one's OK.

----------
Added file: http://bugs.python.org/file14312/threading.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 18:21:11 2009
From: report at bugs.python.org (Alexandru V. Mosoi)
Date: Wed, 17 Jun 2009 16:21:11 +0000
Subject: [issue2824] zipfile to handle duplicate files in archive
In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
Message-ID: <1245255671.16.0.401603326553.issue2824@psf.upfronthosting.co.za>


Alexandru V. Mosoi <brtzsnr at gmail.com> added the comment:

a similar problem appears when the zip file contains two files as in:
['_test/tree.pl', '_test/'].

for ZipFile.extractall() when _test/tree.pl is extracted _test/ is
created and the the extraction of _test/ fails because OSError: [Errno
17] File exists: '_test/'

----------
nosy: +brtzsnr
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2824>
_______________________________________

From report at bugs.python.org  Wed Jun 17 18:30:06 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 17 Jun 2009 16:30:06 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245256206.48.0.55443301696.issue6288@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Nice job on the new wording in the docs.

Do you think the docstring should also be updated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Wed Jun 17 19:34:56 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 17:34:56 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245260096.07.0.61985023538.issue6064@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

Nope.  Our working copies seem to be different.  I'm uploading mine, 
which I just update to revision 73468.  Please diff yours against that 
and against HEAD too, just in case.

Hunk 2 on threading.py fails because your attributes use two leading 
underscores and mine use only one.  I have no idea why hunk4 fails.

----------
Added file: http://bugs.python.org/file14313/threading.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 19:38:36 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 17 Jun 2009 17:38:36 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245260316.57.0.210590063182.issue6064@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

I'm diffing against the 2.7 branch, I guess your comes from the 3.2?

Will checkout 3.2 and do it there as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 19:52:41 2009
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 17 Jun 2009 17:52:41 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245261161.61.0.620954230315.issue6064@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Attaching a diff against the py3k branch on revision 73468

----------
Added file: http://bugs.python.org/file14314/threading3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 20:12:36 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 18:12:36 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245262356.49.0.36207675215.issue6064@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

> I'm diffing against the 2.7 branch, I guess your comes from the 3.2?
*forehead meets desktop*

Patch applies cleanly and all tests pass.  I used it for a while and 
everything seemed OK.  After someone else tests, I say we go for it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 20:12:46 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Wed, 17 Jun 2009 18:12:46 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245262366.9.0.448948139339.issue6064@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

+1 to the py3k diff. :)
Hey, I think this daemon property should be set as a keyword argument of
the Thread constructor.

----------
nosy: +conf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 20:23:29 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 18:23:29 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245263009.5.0.328766789841.issue6064@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

+1 on making it a keyword-only argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 21:14:20 2009
From: report at bugs.python.org (Jerry Chen)
Date: Wed, 17 Jun 2009 19:14:20 +0000
Subject: [issue6297] Added Misc/python.pc to 'distclean' Rule
In-Reply-To: <1245266060.76.0.919616953037.issue6297@psf.upfronthosting.co.za>
Message-ID: <1245266060.76.0.919616953037.issue6297@psf.upfronthosting.co.za>


New submission from Jerry Chen <jerry at 3rdengine.com>:

Added Misc/python.pc to 'distclean' rule

Minor issue... After running ./configure, Misc/python.pc is generated
from python.pc.in. Interesting to note in the python2.7 trunk, this file
is added to the svn:ignore property of Misc/ so it doesn't show up to
svn, but in accordance with the rest of the 'distclean' rule, it makes
sense to remove the file completely.

Diff'd against r73468.

----------
assignee: georg.brandl
components: Documentation
files: makefile-clobber.diff
keywords: patch
messages: 89476
nosy: georg.brandl, jcsalterego
severity: normal
status: open
title: Added Misc/python.pc to 'distclean' Rule
versions: Python 3.1
Added file: http://bugs.python.org/file14315/makefile-clobber.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6297>
_______________________________________

From report at bugs.python.org  Wed Jun 17 21:15:45 2009
From: report at bugs.python.org (Jerry Chen)
Date: Wed, 17 Jun 2009 19:15:45 +0000
Subject: [issue6297] Added Misc/python.pc to 'distclean' Rule
In-Reply-To: <1245266060.76.0.919616953037.issue6297@psf.upfronthosting.co.za>
Message-ID: <1245266145.13.0.567559536624.issue6297@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Errata: the patch is for Makefile.pre.in, not Makefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6297>
_______________________________________

From report at bugs.python.org  Wed Jun 17 22:00:19 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 17 Jun 2009 20:00:19 +0000
Subject: [issue6298] http://python.org/download says Python 2.4.5,
	but I think it means Python 2.4.6.
Message-ID: <1245268819.2.0.178643041383.issue6298@psf.upfronthosting.co.za>


Changes by Zooko O'Whielacronx <zooko at zooko.com>:


----------
assignee: georg.brandl
components: Documentation
nosy: georg.brandl, zooko
severity: normal
status: open
title: http://python.org/download says Python 2.4.5, but I think it means Python 2.4.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6298>
_______________________________________

From report at bugs.python.org  Wed Jun 17 22:07:54 2009
From: report at bugs.python.org (Tim Mooney)
Date: Wed, 17 Jun 2009 20:07:54 +0000
Subject: [issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
In-Reply-To: <1245269274.21.0.966496864817.issue6299@psf.upfronthosting.co.za>
Message-ID: <1245269274.21.0.966496864817.issue6299@psf.upfronthosting.co.za>


New submission from Tim Mooney <enchanter at users.sourceforge.net>:

I've built Python 2.6.1 and Python 2.6.2 on x86_64-sun-solaris2.10 using
the Sun Workshop Express (200903) toolchain.  I'm building in 64 bit mode.

Most stuff builds just fine (even warnings are rare), but pyexpat fails
to link with this error:

building 'pyexpat' extension
creating
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -I/usr/local/include
-I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.o
"/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.c", line 1574:
warning: assignment type mismatch:
    pointer to void "=" pointer to function(pointer to void, pointer to
const ch
ar, int) returning void
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -I/usr/local/include
-I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.o
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -I/usr/local/include
-I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.o
cc -xtarget=native -m64 -xarch=native -KPIC -DNDEBUG -Xa -xO4 -xstrconst
-mt -xtarget=native -m64 -xarch=native -I/local/include
-I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI
-I/local/src/RPM/BUILD/Python-2.6.2/./Modules/expat -I.
-I/local/src/RPM/BUILD/Python-2.6.2/./Include -I. -IInclude -I./Include
-I/local/include -I/local/
gnu/include -I/local/BerkeleyDB/include -I/local/openssl/include
-I/usr/local/include -I/local/src/RPM/BUILD/Python-2.6.2/Include
-I/local/src/RPM/BUILD/Python-2.6.2 -c
/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.c -o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.o
cc -xtarget=native -m64 -xarch=native -G -L/local/lib/64
-L/local/gnu/lib/64 -L/local/BerkeleyDB/lib/64 -L/local/openssl/lib/64
-L/local/lib/64 -L/local/gnu/lib/64 -L/local/BerkeleyDB/lib/64
-L/local/openssl/lib/64 -DNDEBUG -Xa -xO4 -xstrconst -mt -xtarget=native
-m64 -xarch=native -I/local/include -I/local/gnu/include
-I/local/BerkeleyDB/include -I/local/openssl/include -I. -IInclude
-I./Include 
-I/local/include -I/local/gnu/include -I/local/BerkeleyDB/include
-I/local/openssl/include
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/pyexpat.o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlparse.o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmlrole.o
build/temp.solaris-2.10-i86pc-2.6/local/src/RPM/BUILD/Python-2.6.2/Modules/expat/xmltok.o
-L/local/lib -L/local/lib/64 -L/local/gnu/lib/64
-L/local/BerkeleyDB/lib/64 -L/local/openssl/lib/64 -L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.6/pyexpat.so
*** WARNING: renaming "pyexpat" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-i86pc-2.6/pyexpat.so: symbol
XML_SetCharacterDataHandler: referenced symbol not found

I never tried any of the 2.5.x Python builds, but I can tell you that I
built several versions in the 2.4.x series, and none of those versions
had problems compiling or linking pyexpat.

I do have expat 2.0.1 (also built with the Sun compiler in 64 bit mode)
installed on the system, but from the comments in setup.py and the
compiler output, it appears clear that the expat components that ship
with Python 2.6.x are the ones that are being compiled and attempted for
use in the link.

Please let me know if I can provide any relevant information.

Thanks,

Tim (the Enchanter)

----------
components: Build
messages: 89478
nosy: enchanter
severity: normal
status: open
title: pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6299>
_______________________________________

From report at bugs.python.org  Wed Jun 17 22:32:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 17 Jun 2009 20:32:22 +0000
Subject: [issue6298] http://python.org/download says Python 2.4.5,
	but I think it means Python 2.4.6.
In-Reply-To: <1245270742.38.0.0429722257026.issue6298@psf.upfronthosting.co.za>
Message-ID: <1245270742.38.0.0429722257026.issue6298@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Fixed in pydotorg r12342.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6298>
_______________________________________

From report at bugs.python.org  Wed Jun 17 22:54:34 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 17 Jun 2009 20:54:34 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245272074.78.0.240265874705.issue6288@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Good point - I forgot about the docstring.

Yes, I think that should be changed to use the new wording up to the new
example (similar to the way the old docstring stopped at the example).

Reopening until that is done (although reducing from release blocker status)

----------
priority: release blocker -> high
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Wed Jun 17 23:14:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jun 2009 21:14:47 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1245273287.67.0.956415682322.issue6064@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1 from me as well.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Wed Jun 17 23:15:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jun 2009 21:15:33 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1245273333.51.0.794661081599.issue5801@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1 for making the source more readable.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________

From report at bugs.python.org  Wed Jun 17 23:17:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Jun 2009 21:17:38 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245273458.74.0.612526045394.issue6215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Everything looks ok, can you merge the commit to py3k so as to minimize
conflicts when merging stuff? Thanks :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Wed Jun 17 23:22:50 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Wed, 17 Jun 2009 21:22:50 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1245273770.06.0.971961887041.issue5800@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

Added a pointer from #5801 to here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Thu Jun 18 01:00:14 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 17 Jun 2009 23:00:14 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1245279614.65.0.0734269899385.issue5801@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________

From report at bugs.python.org  Thu Jun 18 02:00:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 00:00:15 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I repeatedly find myself typing things like
"mybytestring.decode('ASCII', errors='replace')".  This seems like the
natural (I'm tempted to say Pythonic) thing to do, and is more readable
(IMO) than "mybytestring.decode('ASCII', 'replace')".  (replace what?).
 However currently encode and decode complain that they do not take any
keyword arguments.

----------
components: Interpreter Core
messages: 89485
nosy: r.david.murray
priority: low
severity: normal
status: open
title: encode and decode should accept 'errors' as a keyword argument
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Jun 18 02:38:26 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 18 Jun 2009 00:38:26 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245285506.44.0.144712991623.issue6215@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Done in r73169.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Thu Jun 18 03:14:21 2009
From: report at bugs.python.org (david)
Date: Thu, 18 Jun 2009 01:14:21 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>


New submission from david <davix at plasmatronics.com.au>:

http://docs.python.org/tutorial/inputoutput.html#reading-and-writing-
files
"Windows makes a distinction between text and binary files;
"the end-of-line characters in text files are automatically altered
"slightly when data is read or written.

Windows does not make a distinction between text and binary files:
http://msdn.microsoft.com/en-us/library/aa365430(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx

Nor does it automatically alter end-of-line characters.

It is not clear what distinction Python makes between text and binary 
files. Do those options do anything on any platform? Is jPython 
different than cPython? And does Python automatically alter end-of-line 
characters?

----------
assignee: georg.brandl
components: Documentation
messages: 89487
nosy: georg.brandl, melbourne
severity: normal
status: open
title: Error in tutorial section 7.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Thu Jun 18 03:36:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 01:36:16 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

decode_header only accepts str as input.  If the input contains no
encoded words, the output is str (ie: the input string) and None.  If it
does contain encoded words, the output is pairs of bytes plus str
charset identifiers (or None).  This makes it difficult to use this
function to decode headers, since one has to test for the special case
of str output when there are no encoded words.

I think decode_header should take bytes as input, and output (bytes.
str) pairs consistently.

In any case, the documentation is wrong since it says it returns
strings.  The example is also wrong, since the actual output is:

[(b'p\xf6stal', 'iso-8859-1')]

----------
components: Library (Lib)
messages: 89488
nosy: r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: email.header.decode_header data types are inconsistent and incorrectly documented
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6302>
_______________________________________

From report at bugs.python.org  Thu Jun 18 03:37:46 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 01:37:46 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1245289066.58.0.499126690713.issue1685453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +email.header.decode_header data types are inconsistent and incorrectly documented
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685453>
_______________________________________

From report at bugs.python.org  Thu Jun 18 03:43:04 2009
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 18 Jun 2009 01:43:04 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245289384.69.0.880121657486.issue6301@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Thu Jun 18 04:40:57 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 02:40:57 +0000
Subject: [issue6303] print does not appear in the 3.x documentation index
In-Reply-To: <1245292857.22.0.335775123818.issue6303@psf.upfronthosting.co.za>
Message-ID: <1245292857.22.0.335775123818.issue6303@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Since print is now a built in function, it should appear in the library
reference index, but it does not.

----------
assignee: georg.brandl
components: Documentation
messages: 89489
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: print does not appear in the 3.x documentation index
type: behavior
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6303>
_______________________________________

From report at bugs.python.org  Thu Jun 18 04:51:46 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 02:51:46 +0000
Subject: [issue6304] Confusing error message when passing bytes to print with
	file pointing to a binary file
In-Reply-To: <1245293505.96.0.175038220478.issue6304@psf.upfronthosting.co.za>
Message-ID: <1245293505.96.0.175038220478.issue6304@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The documentation for the print function specifies that the input
argument is coerced to string.  However, if bytes are passed and the
file= parameter points to a file open for binary write, the error
message produced is:

>>> out = open('temp', 'wb')
>>> print(b'abc', file=out)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: write() argument 1 must be bytes or buffer, not str

which is, to say the least, confusing, since I clearly passed print a
bytes object as argument 1.

----------
components: IO
messages: 89490
nosy: r.david.murray
priority: low
severity: normal
stage: test needed
status: open
title: Confusing error message when passing bytes to print with file pointing to a binary file
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6304>
_______________________________________

From report at bugs.python.org  Thu Jun 18 08:57:58 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Jun 2009 06:57:58 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245308278.66.0.454416077167.issue6301@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Even if the Win32 API functions do not have a concept of text/binary
files, the C library functions that MS provides, and Python uses, have.

See http://msdn.microsoft.com/en-us/library/yeby3zcb(VS.71).aspx

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Thu Jun 18 09:01:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Jun 2009 07:01:04 +0000
Subject: [issue6303] print does not appear in the 3.x documentation index
In-Reply-To: <1245292857.22.0.335775123818.issue6303@psf.upfronthosting.co.za>
Message-ID: <1245308464.85.0.947042003026.issue6303@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If you're referring to the general index, there is a "print() (built-in
function)" entry in http://docs.python.org/dev/py3k/genindex-P.html. Am
I missing another index?

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6303>
_______________________________________

From report at bugs.python.org  Thu Jun 18 09:03:41 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Jun 2009 07:03:41 +0000
Subject: [issue6304] Confusing error message when passing bytes to print with
	file pointing to a binary file
In-Reply-To: <1245293505.96.0.175038220478.issue6304@psf.upfronthosting.co.za>
Message-ID: <1245308621.69.0.244132300054.issue6304@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

How would you propose to fix this?  print() should certainly not catch
all TypeErrors and raise a new one...

Maybe exception chaining could be used, so that print raises a TypeError
of its own with the cause being the original message?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6304>
_______________________________________

From report at bugs.python.org  Thu Jun 18 09:14:23 2009
From: report at bugs.python.org (Thomas Guest)
Date: Thu, 18 Jun 2009 07:14:23 +0000
Subject: [issue6305] islice doesn't accept large stop values
In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>
Message-ID: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>


New submission from Thomas Guest <tag at wordaligned.org>:

Python 3.0 (r30:67503, Jan  7 2009, 16:22:01) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin

>>> from itertools import islice, count
>>> islice(count(), (1<<31) - 1)
<itertools.islice object at 0x63a0c0>
>>> islice(count(), (1<<31))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Stop argument for islice() must be a non-negative integer or
None.

----------
messages: 89494
nosy: thomasguest
severity: normal
status: open
title: islice doesn't accept large stop values
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6305>
_______________________________________

From report at bugs.python.org  Thu Jun 18 09:30:38 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Thu, 18 Jun 2009 07:30:38 +0000
Subject: [issue6276] Fix contextlib.nested DeprecationWarning for test_signal.
In-Reply-To: <1244885687.02.0.348626094115.issue6276@psf.upfronthosting.co.za>
Message-ID: <1245310238.48.0.978180063401.issue6276@psf.upfronthosting.co.za>


Vikram U Shenoy <vikram.u.shenoy at gmail.com> added the comment:

Ping. This is a legit fix right ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6276>
_______________________________________

From report at bugs.python.org  Thu Jun 18 10:01:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Jun 2009 08:01:42 +0000
Subject: [issue6305] islice doesn't accept large stop values
In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>
Message-ID: <1245312102.41.0.26472045426.issue6305@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6305>
_______________________________________

From report at bugs.python.org  Thu Jun 18 10:18:50 2009
From: report at bugs.python.org (david)
Date: Thu, 18 Jun 2009 08:18:50 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245313130.22.0.115392102529.issue6301@psf.upfronthosting.co.za>


david <davix at plasmatronics.com.au> added the comment:

So, it's wrong, and it's not helpful unless you already know what it 
means, but it works for someone who doesn't need the Python tutorial!

I'm gobsmacked.

If "the C libraries that Python uses" have the concept of Text/Binary, 
why not just say so?

Conversely, if you are ashamed to admit that use of Python requires 
knowledge of C, why not just change the tutorial to TALK ABOUT PYTHON?

I never wanted to back anyone into a corner: I'm just amazed at all 
this. It's wrong, fix it, why defend it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Thu Jun 18 11:03:30 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Jun 2009 09:03:30 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245315810.72.0.52580815211.issue6301@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

A small improvement could be made:

- Windows makes a distinction between text and binary files
+ Python on Windows makes a distinction between text and binary files

The meaning should have been obvious as-is, but the fact of the matter
is that the OP is "gobsmacked" and "amazed" so surely something must be
done ;-)

----------
nosy: +rhettinger
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Thu Jun 18 11:08:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 18 Jun 2009 09:08:25 +0000
Subject: [issue6300] encode and decode should accept 'errors' as a keyword
	argument
In-Reply-To: <1245283215.71.0.778706476044.issue6300@psf.upfronthosting.co.za>
Message-ID: <1245316105.75.0.868852523992.issue6300@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6300>
_______________________________________

From report at bugs.python.org  Thu Jun 18 12:36:15 2009
From: report at bugs.python.org (higer)
Date: Thu, 18 Jun 2009 10:36:15 +0000
Subject: [issue6306] filecmp.cmp can not compare two files from different OS
	with the same content
In-Reply-To: <1245321374.99.0.206303396049.issue6306@psf.upfronthosting.co.za>
Message-ID: <1245321374.99.0.206303396049.issue6306@psf.upfronthosting.co.za>


New submission from higer <higerinbeijing at gmail.com>:

I just want to compare two files,one from windows and the other from
unix. But I do not want to compare them through reading them line by
line. Then I found there is a filecmp module which is used as file and
directory comparisons. However,when I use two same files (one from
unix,one from windows,the content of them is the same) to test its cmp
function, filecmp.cmp told me false.
Later, I found that windows use '\n\r' as new line flag but unix use
'\n', so filecmp.cmp think that they are different,then return false.

I think maybe it's a bug.
If filecmp.cmp can support two platform files with the same content
and only the diffrent last newline flag, that's would be wonderful.

----------
components: Library (Lib)
messages: 89498
nosy: higer
severity: normal
status: open
title: filecmp.cmp can not compare two files from different OS with the same content
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6306>
_______________________________________

From report at bugs.python.org  Thu Jun 18 13:37:27 2009
From: report at bugs.python.org (Viktor Ferenczi)
Date: Thu, 18 Jun 2009 11:37:27 +0000
Subject: [issue6307] AttributeError in traceback.print_last()
In-Reply-To: <1245325047.26.0.892033914272.issue6307@psf.upfronthosting.co.za>
Message-ID: <1245325047.26.0.892033914272.issue6307@psf.upfronthosting.co.za>


New submission from Viktor Ferenczi <python at cx.hu>:

Python 2.5.4, Windows MSI installer, WinXP SP2, 32 bit:

Try the following code: (test script attached)

import traceback

try:
    someundefinedsymbol
except:
    traceback.print_last()

It will raise the following exception:

Traceback (most recent call last):
  File "bug.py", line 6, in <module>
    traceback.print_last()
  File "D:\Python25\lib\traceback.py", line 246, in print_last
    print_exception(sys.last_type, sys.last_value, sys.last_traceback,
AttributeError: 'module' object has no attribute 'last_type'

----------
components: Library (Lib)
messages: 89499
nosy: complex
severity: normal
status: open
title: AttributeError in traceback.print_last()
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6307>
_______________________________________

From report at bugs.python.org  Thu Jun 18 13:41:49 2009
From: report at bugs.python.org (Viktor Ferenczi)
Date: Thu, 18 Jun 2009 11:41:49 +0000
Subject: [issue6307] AttributeError in traceback.print_last()
In-Reply-To: <1245325047.26.0.892033914272.issue6307@psf.upfronthosting.co.za>
Message-ID: <1245325309.63.0.265653253498.issue6307@psf.upfronthosting.co.za>


Viktor Ferenczi <python at cx.hu> added the comment:

>From the manual of the sys module:

"""
last_type 
last_value
last_traceback

These three variables are not always defined; they are set when an
exception is not handled and the interpreter prints an error message and
a stack traceback.
"""

So the AttributeError is normal in this case.

Changed the bug type to "behavior", since a more meaningful error
message than AttributeError would be very useful in this case.

Thanks.

----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6307>
_______________________________________

From report at bugs.python.org  Thu Jun 18 14:21:54 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 12:21:54 +0000
Subject: [issue6303] print does not appear in the 3.x documentation index
In-Reply-To: <1245308464.85.0.947042003026.issue6303@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0906180820440.32513@kimball.webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are right of course.  My alphabetizing skillz need work,
apparently :(.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6303>
_______________________________________

From report at bugs.python.org  Thu Jun 18 14:50:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 12:50:22 +0000
Subject: [issue6306] filecmp.cmp can not compare two files from different OS
	with the same content
In-Reply-To: <1245321374.99.0.206303396049.issue6306@psf.upfronthosting.co.za>
Message-ID: <1245329422.28.0.454056800906.issue6306@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you do not want to compare them by reading line by line, then you are
doing a binary comparison (which is what filecmp does) and the two files
are, indeed, different.  If you want to compare them in text mode, you
are moving into 'diff' territory and could use difflib instead.

If you nevertheless want to propose an additional
text-and-universal-newline-mode version of cmp (it would be best if you
were prepared to write the patch), please bring it up on python-ideas
for community discussion, as it is not clear that it is a good idea.  If
you get a consensus that it is a good idea you can reopen this ticket
with a pointer to the discussion.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> rejected
status: open -> pending
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6306>
_______________________________________

From report at bugs.python.org  Thu Jun 18 15:04:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 13:04:25 +0000
Subject: [issue6307] AttributeError in traceback.print_last()
In-Reply-To: <1245325047.26.0.892033914272.issue6307@psf.upfronthosting.co.za>
Message-ID: <1245330265.95.0.80917275944.issue6307@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In 2.7/3.1 this message is a ValueError saying "no last traceback".

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6307>
_______________________________________

From report at bugs.python.org  Thu Jun 18 15:12:26 2009
From: report at bugs.python.org (Neil Muller)
Date: Thu, 18 Jun 2009 13:12:26 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245330746.8.0.411305557581.issue6233@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Updated patch - adds a test for this.

----------
Added file: http://bugs.python.org/file14316/issue6233_py3k_with_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Thu Jun 18 15:25:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Jun 2009 13:25:16 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245331516.13.0.150354252957.issue6233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This regression is probably annoying enough to make it a blocker.

----------
nosy: +pitrou
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Thu Jun 18 16:17:41 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 18 Jun 2009 14:17:41 +0000
Subject: [issue1685] linecache .updatecache fails on utf8 encoded files
In-Reply-To: <1198300635.1.0.891509425639.issue1685@psf.upfronthosting.co.za>
Message-ID: <1245334661.4.0.915931059204.issue1685@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was probably fixed by issue4016 (r70587)

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685>
_______________________________________

From report at bugs.python.org  Thu Jun 18 18:22:23 2009
From: report at bugs.python.org (Michael Haubenwallner)
Date: Thu, 18 Jun 2009 16:22:23 +0000
Subject: [issue6308] termios fix for QNX breaks HP-UX
In-Reply-To: <1245342143.83.0.0806702305005.issue6308@psf.upfronthosting.co.za>
Message-ID: <1245342143.83.0.0806702305005.issue6308@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner <michael.haubenwallner at salomon.at>:

The patch for issue 1722225 in Include/pyport.h to include
<sys/termio.h> before <termios.h> for QNX does break for HP-UX:
On HP-UX, 'struct termios' gets declared within <sys/termio.h>, but when
included via <termios.h> _only_. Due to the include guard, it does not
declare 'struct termios' when included via <termios.h> the second time.

This is Python-2.6.2, but the code looks unchanged in trunk. As I'm not
sure how best to fix this, for 2.6.2 here I go with:
-#ifdef HAVE_SYS_TERMIO_H
+#if defined(HAVE_SYS_TERMIO_H) && defined(__QNX__)

Thanks!

----------
components: Build
messages: 89507
nosy: haubi
severity: normal
status: open
title: termios fix for QNX breaks HP-UX
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6308>
_______________________________________

From report at bugs.python.org  Thu Jun 18 18:44:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Jun 2009 16:44:51 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1245343491.85.0.183485081865.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Is there any use case for feedparser accepting strings as input that
isn't a design error waiting to bite the programmer?

----------
nosy: +r.david.murray
priority:  -> high
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Thu Jun 18 19:48:32 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Jun 2009 17:48:32 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1245347312.35.0.399556820358.issue4661@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

dato: We've started some branches that try to address this, by exposing
both a read-a-buncha-bytes interface and a read-a-string interface.

rdm: As it turns out, yes.  There are use cases for reading a string
containing only ascii bytes.

In general, this is part of the big tricky problem in fixing the email
package for Python 3.x.  We had great debates about this at Pycon with
no resolution, and I think everyone has just been too busy to engage on
this since then. :(

email-sig is the best place to try to rally some effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Jun 19 00:04:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Jun 2009 22:04:30 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245362670.94.0.686959182071.issue6301@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm -0 about that change.

However, I'd like to defend the original wording; it is *not* Python
that makes the text/binary distinction.  Python just calls fopen(),
which is what portable C programs are supposed to do, with the mode it
is given by the programmer in open().  Python neither ships nor owns the
C library.  For the Python programmer however, it is irrelevant which
part of the system that Python uses has a particular behavior, he just
notes that *on that system* it can be observed.

How about "On Windows, a distinction is made ..."? <half-wink>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Fri Jun 19 00:07:51 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Jun 2009 22:07:51 +0000
Subject: [issue6276] Fix contextlib.nested DeprecationWarning for test_signal.
In-Reply-To: <1244885687.02.0.348626094115.issue6276@psf.upfronthosting.co.za>
Message-ID: <1245362871.25.0.104187366932.issue6276@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6276>
_______________________________________

From report at bugs.python.org  Fri Jun 19 00:19:43 2009
From: report at bugs.python.org (Michael Foord)
Date: Thu, 18 Jun 2009 22:19:43 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245363583.84.0.834173188764.issue6301@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The wording as it stands just seems plain wrong. 

Either "Python on Windows" or "On Windows" is better - the former over
the latter but either...

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Fri Jun 19 00:24:35 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Jun 2009 22:24:35 +0000
Subject: [issue6276] Fix contextlib.nested DeprecationWarning for test_signal.
In-Reply-To: <1244885687.02.0.348626094115.issue6276@psf.upfronthosting.co.za>
Message-ID: <1245363875.05.0.0871772678937.issue6276@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r73471.

----------
assignee: rhettinger -> georg.brandl
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6276>
_______________________________________

From report at bugs.python.org  Fri Jun 19 00:36:36 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 18 Jun 2009 22:36:36 +0000
Subject: [issue6189] subprocess module not compatible with python 2.5
In-Reply-To: <1244035675.71.0.776263383534.issue6189@psf.upfronthosting.co.za>
Message-ID: <1245364596.37.0.0414549715291.issue6189@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r73472

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6189>
_______________________________________

From report at bugs.python.org  Fri Jun 19 01:54:10 2009
From: report at bugs.python.org (Marko Schuetz)
Date: Thu, 18 Jun 2009 23:54:10 +0000
Subject: [issue1074015] current directory in sys.path handles symlinks badly
Message-ID: <1245369250.78.0.140615471763.issue1074015@psf.upfronthosting.co.za>


Marko Schuetz <MarkoSchuetz at web.de> added the comment:

I think this behavior is causing a related problem:

Assume I have directories currentWorkspace and branchRepository.

On branchRepository I have files main.py and module.py. main.py 
imports module.py. In currentWorkspace main.py links to the repository 
version, but module.py has a new version in currentWorkspace. Running 
main.py will not import the module.py from currentWorkspace.

I agree that branchRepository belongs on the search path, but 
currentWorkspace needs to be on the search path also and needs to take 
priority over branchRepository.

The attached file is an edit of the original recreatebug.sh

----------
nosy: +marko
Added file: http://bugs.python.org/file14317/recreatebug.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1074015>
_______________________________________

From report at bugs.python.org  Fri Jun 19 02:12:23 2009
From: report at bugs.python.org (david)
Date: Fri, 19 Jun 2009 00:12:23 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245370343.85.0.678434785364.issue6301@psf.upfronthosting.co.za>


david <davix at plasmatronics.com.au> added the comment:

If this is like to be non-portable to jPython, I'd like to be told.

However, I can see that the tutorial may be the wrong place to mention 
that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Fri Jun 19 02:13:39 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 19 Jun 2009 00:13:39 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245370419.07.0.669313669486.issue6301@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This behavior of Python when reading files is so fundamental that I
can't imagine Jython doesn't behave the same way. (IronPython certainly
has the same behavior.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Fri Jun 19 02:19:01 2009
From: report at bugs.python.org (Erik Antelman)
Date: Fri, 19 Jun 2009 00:19:01 +0000
Subject: [issue6309] Tix needs TCL package require statement
In-Reply-To: <1245370741.24.0.759897657733.issue6309@psf.upfronthosting.co.za>
Message-ID: <1245370741.24.0.759897657733.issue6309@psf.upfronthosting.co.za>


New submission from Erik Antelman <eantelman at acm.org>:

For at least Tix.ComboBox it appears to be necessary to invoke the TCL
package loading explicitly with:
   root.tk.eval('package require Tix')

This was demonstrated on:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32

----------
components: Tkinter
files: TixIssue.py
messages: 89517
nosy: eantelman
severity: normal
status: open
title: Tix needs TCL package require statement
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14318/TixIssue.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6309>
_______________________________________

From report at bugs.python.org  Fri Jun 19 02:57:03 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 19 Jun 2009 00:57:03 +0000
Subject: [issue6301] Error in tutorial section 7.2
In-Reply-To: <1245287661.76.0.495139825921.issue6301@psf.upfronthosting.co.za>
Message-ID: <1245373023.4.0.917046844035.issue6301@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at users.sourceforge.net> added the comment:

Jython 2.5 behaves in the same way

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6301>
_______________________________________

From report at bugs.python.org  Fri Jun 19 07:12:51 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 19 Jun 2009 05:12:51 +0000
Subject: [issue6310] Windows "App Paths" key is not checked when installed for
	current user
In-Reply-To: <1245388371.55.0.866683174508.issue6310@psf.upfronthosting.co.za>
Message-ID: <1245388371.55.0.866683174508.issue6310@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I found that if Python installed only for current user on Windows XP
Home Edition SP3 Python fails to run from Start -> Run dialog or using
ShellExecute() call. It is because it creates "App Paths" key in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe
and not in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe

Can anybody confirm this?

----------
components: Windows
messages: 89519
nosy: techtonik
severity: normal
status: open
title: Windows "App Paths" key is not checked when installed for current user
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6310>
_______________________________________

From report at bugs.python.org  Fri Jun 19 12:15:36 2009
From: report at bugs.python.org (helgekraak)
Date: Fri, 19 Jun 2009 10:15:36 +0000
Subject: [issue6311] virtual memory error with archivemail
In-Reply-To: <1245406536.49.0.871385683543.issue6311@psf.upfronthosting.co.za>
Message-ID: <1245406536.49.0.871385683543.issue6311@psf.upfronthosting.co.za>


New submission from helgekraak <helge at kraak.info>:

Hi,

I'm neither a Python nor a Unix specialist, so please understand that I
can't give a very professional bug report.

My issue seems to be related to issues 1092502 and 1389051. When I run
archivemail with Python 2.6.2 after a couple of minutes the virtual
memory in the activity monitor suddenly goes up to more than 2 GB and
then the python process quits as it seems to have reached a limit of the
virtual memory (the virtual memory available is about 10 GB). Most of
the time the virtual memory is stable around 40 MB and only sporadically
the memory suddenly increases to values between 100 MB and 2 GB but goes
back to 40 MB again until the one time that it goes so high that the
python process quits. The error happens much faster when I use a non
secured imap connection compared to a secured connection.

I get this error message:

command: archivemail --date='23 April 2030' --include-flagged
--output-dir=/temp  --copy  imaps://*****:*****@*****/inbox


error message: Python(1238) malloc: *** vm_allocate(size=15396864)
failed (error code=3)
Python(1238) malloc: *** error: can't allocate region
Python(1238) malloc: *** set a breakpoint in szone_error to debug
Traceback (most recent call last):
  File "/opt/local/bin/archivemail", line 1603, in ?
    main()
  File "/opt/local/bin/archivemail", line 702, in main
    archive(mailbox_path)
  File "/opt/local/bin/archivemail", line 1145, in archive
    _archive_imap(mailbox_name, final_archive_name)
  File "/opt/local/bin/archivemail", line 1424, in _archive_imap
    result, response = imap_srv.fetch(msn, '(RFC822)')
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 426, in fetch
    typ, dat = self._simple_command(name, message_set, message_parts)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 1028, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 858, in _command_complete
    typ, data = self._get_tagged_response(tag)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 959, in _get_tagged_response
    self._get_response()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 921, in _get_response
    data = self.read(size)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/imaplib.py",
line 1123, in read
    data = self.sslobj.read(size-read)
MemoryError


Thanks for your time!

Helge

----------
messages: 89520
nosy: helgekraak
severity: normal
status: open
title: virtual memory error with archivemail
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6311>
_______________________________________

From report at bugs.python.org  Fri Jun 19 15:53:31 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Jun 2009 13:53:31 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Try this code (youtube.com uses "transfer-encoding: chunked"):

import httplib
url = 'www.youtube.com'
conn = httplib.HTTPConnection(url)
conn.request('HEAD', '/') # send an HEAD request
res = conn.getresponse()
print res.getheader('transfer-encoding')

so far it works fine, but when you try:

res.read()

it just hung there, where "there" is:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programs\Python26\lib\httplib.py", line 517, in read
    return self._read_chunked(amt)
  File "C:\Programs\Python26\lib\httplib.py", line 553, in _read_chunked
    line = self.fp.readline()
  File "C:\Programs\Python26\lib\socket.py", line 395, in readline
    data = recv(1)
KeyboardInterrupt

If instead of youtube.com we replace the url with the one of a site that
doesn't use "transfer-encoding: chunked" (e.g. url = 'dpaste.com'),
res.read() returns an empty string.



When an HEAD request is sent, the content of the page is not returned,
so there should be no point in calling .read(), but try this:

import urllib2

class HeadRequest(urllib2.Request):
    def get_method(self):
        return 'HEAD'

url = 'http://www.youtube.com/watch?v=tCVqx2b-c7U'
# Note: I had this problem with this URL, the video 
# is not available in my country (Finland) and it
# may work fine for other countries

req = HeadRequest(url)
page = urllib2.urlopen(req)


This is what happens here with Python 2.5:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/urllib2.py", line 124, in urlopen
    return _opener.open(url, data)
  File "/usr/lib/python2.5/urllib2.py", line 387, in open
    response = meth(req, response)
  File "/usr/lib/python2.5/urllib2.py", line 498, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.5/urllib2.py", line 419, in error
    result = self._call_chain(*args)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 579, in http_error_302
    fp.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: ''


With Python 2.6 the error is slightly different:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programs\Python26\lib\urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\Programs\Python26\lib\urllib2.py", line 389, in open
    response = meth(req, response)
  File "C:\Programs\Python26\lib\urllib2.py", line 502, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\Programs\Python26\lib\urllib2.py", line 421, in error
    result = self._call_chain(*args)
  File "C:\Programs\Python26\lib\urllib2.py", line 361, in _call_chain
    result = func(*args)
  File "C:\Programs\Python26\lib\urllib2.py", line 594, in http_error_302
    fp.read()
  File "C:\Programs\Python26\lib\socket.py", line 327, in read
    data = self._sock.recv(rbufsize)
  File "C:\Programs\Python26\lib\httplib.py", line 517, in read
    return self._read_chunked(amt)
  File "C:\Programs\Python26\lib\httplib.py", line 563, in _read_chunked
    raise IncompleteRead(value)
httplib.IncompleteRead

With Py3.0 it is the same:
[...]
http.client.IncompleteRead: b''


In this case self.fp.readline() (and the data = recv(1) in socket.py)
returns and the error happens a few lines later.
This seems to happen when there's a redirection in between (the video is
not available in my country, the server sends back a 303 status code,
and redirects me to the home page). The redirection is not handled by
httplib so there might be something wrong in urllib2 too (why it's
trying to read the content if we sent and HEAD request and if there is a
redirection in between?), but fixing httplib to return an empty string
or something similar could be enough to solve this problem too. If
there's actually a problem another issue should probably be created.

With the same code and the url of a working youtube video (no
redirections in between), "page = urllib2.urlopen(req)" works even if
there's the "transfer-encoding: chunked" but it fails later if we do
"page.read()": 

Traceback (most recent call last):
  File "C:\Programs\Python30\lib\http\client.py", line 520, in _read_chunked
    chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: ''

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programs\Python30\lib\http\client.py", line 479, in read
    return self._read_chunked(amt)
  File "C:\Programs\Python30\lib\http\client.py", line 525, in _read_chunked
    raise IncompleteRead(value)
http.client.IncompleteRead: b''

----------
components: Library (Lib)
messages: 89521
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: httplib fails with HEAD requests to pages with "transfer-encoding: chunked"
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Fri Jun 19 17:14:57 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 19 Jun 2009 15:14:57 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1245424497.1.0.924978647685.issue5313@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Attached is a patch which calls close() first, and then attempts to close 
the fd. In the case of an attribute errors (fileno doesn't exist) we 
simply set it to devnull. 

This is just a thought, feedback welcome - right now this allows this 
fixes issue 5155 and 5331 (and this issue)

----------
keywords: +patch
Added file: http://bugs.python.org/file14319/stdin-patchv1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Fri Jun 19 17:55:26 2009
From: report at bugs.python.org (OG7)
Date: Fri, 19 Jun 2009 15:55:26 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1245426926.05.0.964162416741.issue5313@psf.upfronthosting.co.za>


OG7 <onyxg7 at users.sourceforge.net> added the comment:

Please do this:

--- a/multiprocessing/process.py
+++ b/multiprocessing/process.py
@@ -225,7 +225,8 @@ class Process(object):
             self._children = set()
             self._counter = itertools.count(1)
             try:
-                os.close(sys.stdin.fileno())
+                sys.stdin.close()
+                sys.stdin = open(os.devnull)
             except (OSError, ValueError):
                 pass
             _current_process = self

One shouldn't close the fileno after the file has been closed. The
stdlib raises an error, and the open(os.devnull) won't be reached. If no
error was thrown, it would be worse. This would be closing a fileno that
doesn't belong to sys.stdin anymore and may be used somewhere else.

The open(os.devnull) bit is both so that no one tries to do anything
with the old stdin anymore, and to let applications attempt to read from
stdin without an IOError.

----------
Added file: http://bugs.python.org/file14320/0001-Fix-issue-5313.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Fri Jun 19 18:22:44 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 19 Jun 2009 16:22:44 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1245428564.8.0.574544329864.issue6275@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I just want to second Kristj?n's position.  I've used assertRaises a lot
over the years (an implementation in a third-party unit testing library)
and it is extremely common that I want the exception object to perform
the kind of checks he is describing.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Fri Jun 19 18:37:33 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jun 2009 16:37:33 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1245429453.99.0.608232961043.issue6285@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Like Martin, I am puzzled as to what you actually did to cause a problem.
3.1rc2 on WinXP
"Help  /  Python31" means what?

Menu: Help / IDLE Help: brings up help box
Menu: Help / Python Docs: brings up doc window same as from Start menu

>>> help('Python31')
no Python documentation found for 'Python31'
>>> help()
...
help> Python31
no Python documentation found for 'Python31'

>>> help(Python31)
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    help(Python31)
NameError: name 'Python31' is not defined

???

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Fri Jun 19 18:51:36 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Fri, 19 Jun 2009 16:51:36 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1245430296.11.0.00243465410727.issue5801@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

I added the patch for #5800

----------
Added file: http://bugs.python.org/file14321/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________

From report at bugs.python.org  Fri Jun 19 21:14:12 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Jun 2009 19:14:12 +0000
Subject: [issue6311] virtual memory error with archivemail
In-Reply-To: <1245406536.49.0.871385683543.issue6311@psf.upfronthosting.co.za>
Message-ID: <1245438852.59.0.405390523526.issue6311@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Unfortunately, without a much more detailed analysis, I don't think
there is much we can do. I recommend to report this to the author of
archivemail first.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6311>
_______________________________________

From report at bugs.python.org  Fri Jun 19 22:57:04 2009
From: report at bugs.python.org (Hugh Myers)
Date: Fri, 19 Jun 2009 20:57:04 +0000
Subject: [issue2977] truncation of text in tables in Library Reference PDF
In-Reply-To: <1244408289.62.0.900107878545.issue2977@psf.upfronthosting.co.za>
Message-ID: <408995400906191356v5629d713x5cf79279da4f643@mail.gmail.com>


Hugh Myers <hsmyers at gmail.com> added the comment:

Sorry to be so late in replying. I'll check for the problem in 2.6.

--hsm

On Sun, Jun 7, 2009 at 2:58 PM, R. David Murray<report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> The (2.6) docs have changed enough that I can't find the tables at issue
> from your page numbers. ?Is this still a problem and if so can you
> please identify the tables rather than the page numbers? ?Thanks.
>
> ----------
> nosy: +r.david.murray
> type: performance -> behavior
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2977>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2977>
_______________________________________

From report at bugs.python.org  Fri Jun 19 23:53:45 2009
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 19 Jun 2009 21:53:45 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1245426926.05.0.964162416741.issue5313@psf.upfronthosting.co.za>
Message-ID: <4222a8490906191453u38ded209y3b71b5a8f2f1d0a0@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Fri, Jun 19, 2009 at 11:55 AM, OG7<report at bugs.python.org> wrote:
>
> OG7 <onyxg7 at users.sourceforge.net> added the comment:
>
> One shouldn't close the fileno after the file has been closed. The
> stdlib raises an error, and the open(os.devnull) won't be reached. If no
> error was thrown, it would be worse. This would be closing a fileno that
> doesn't belong to sys.stdin anymore and may be used somewhere else.
>
> The open(os.devnull) bit is both so that no one tries to do anything
> with the old stdin anymore, and to let applications attempt to read from
> stdin without an IOError.

Fair enough, I was worried a bit about skipping the
os.close(sys.stdin.fileno()) - the tests pass with both (because the
close fixes the basic problem). I need to come up with an appropriate
documentation note about the double flush issue, add in the tests I
gleaned from the other bugs and commit it. I'll post the full
doc/tests/code patch before doing so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Sat Jun 20 00:05:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 19 Jun 2009 22:05:40 +0000
Subject: [issue6313] test_with.py has a couple minor mistakes
In-Reply-To: <1245449139.95.0.492404802638.issue6313@psf.upfronthosting.co.za>
Message-ID: <1245449139.95.0.492404802638.issue6313@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

I found a couple mistakes in test_with.py with Pyflakes.

----------
components: Tests
files: test_with.patch
keywords: patch
messages: 89530
nosy: exarkun
severity: normal
status: open
title: test_with.py has a couple minor mistakes
versions: Python 2.7
Added file: http://bugs.python.org/file14322/test_with.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6313>
_______________________________________

From report at bugs.python.org  Sat Jun 20 00:09:42 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Jun 2009 22:09:42 +0000
Subject: [issue6313] test_with.py has a couple minor mistakes
In-Reply-To: <1245449139.95.0.492404802638.issue6313@psf.upfronthosting.co.za>
Message-ID: <1245449382.89.0.424356015198.issue6313@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks! Fixed in r73485 and r73486.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6313>
_______________________________________

From report at bugs.python.org  Sat Jun 20 01:06:14 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Jun 2009 23:06:14 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1245452774.4.0.346718159967.issue4395@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The current paragraph
"There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the operators
will behave as expected. "
is false.

Please, let us replace it now, for 3.1 release, with the correct
"There is one implied relationship among comparison operators: defining
__eq__ gives an automatic __ne__ (but not the other way).  There is no
similar relationship for the order comparisons."
without waiting for a more extensive rewrite.

----------
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Sat Jun 20 01:17:51 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 19 Jun 2009 23:17:51 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1245453471.6.0.1079340085.issue4395@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

One other thought:  The __ne__ method follows automatically from __eq__
only if __ne__ isn't already defined in a superclass.  So, if you're
inheriting from a builtin, it's best to override both.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Sat Jun 20 01:42:29 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 19 Jun 2009 23:42:29 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1245454949.36.0.433809032979.issue6164@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Hey Tarek, 

Trent was the one who wrote the patch originally and hence I had asked 
him to comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sat Jun 20 04:16:53 2009
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 20 Jun 2009 02:16:53 +0000
Subject: [issue6274] subprocess.Popen() may leak file descriptors
In-Reply-To: <1244840268.32.0.756034248286.issue6274@psf.upfronthosting.co.za>
Message-ID: <1245464213.62.0.945902697235.issue6274@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Applied the patch (slightly modified) to trunk (2.7), 2.6, and 3k branches.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6274>
_______________________________________

From report at bugs.python.org  Sat Jun 20 06:58:50 2009
From: report at bugs.python.org (alexl)
Date: Sat, 20 Jun 2009 04:58:50 +0000
Subject: [issue6314] logging.basicConfig(level='DEBUG', ...
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>


New submission from alexl <alex_lukanin at mail.ru>:

The following code runs w/o exceptions, but log file is empty:

import logging
logging.basicConfig(level='DEBUG', filename='log.txt')
logging.info('Oh hi!')

To avoid such silent error, basicConfig must either throw exception on 
invalid level parameter, or accept string values.

----------
components: Library (Lib)
messages: 89536
nosy: alexl
severity: normal
status: open
title: logging.basicConfig(level='DEBUG', ...
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6314>
_______________________________________

From report at bugs.python.org  Sat Jun 20 10:03:56 2009
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sat, 20 Jun 2009 08:03:56 +0000
Subject: [issue6315] locale._build_localename(locale.getdefaultlocale())
	returns 'C.mac-roman'
In-Reply-To: <1245485035.23.0.886110297482.issue6315@psf.upfronthosting.co.za>
Message-ID: <1245485035.23.0.886110297482.issue6315@psf.upfronthosting.co.za>


New submission from Stephen J. Turnbull <stephen at xemacs.org>:

Which causes the locale machinery to spit exceptions, and the program to 
die, usually (eg, hg).

This manifests naturally on an Intel Mac, Mac OS X 10.5.7, but the 
problem behavior is in _build_localename.  When called as

_build_localename((None,'any_string'))

it returns 'C.any_string'.  I don't know of any system that supports 
anything but the POSIX portable character set in the C/POSIX locale, so
this is clearly wrong.

I suggest that when the first component of the argument is None, the
second component should be ignored.

Probably my Mac is misconfigured, but I think this is still a bug that 
should be fixed.

Observed in all of 2.5.4, 2.6.2, and 3.0.1 (vanilla MacPorts builds).

References: It's possible this is related to issue1699853, issue1176504, 
issue504219, but I don't think fixing this will help with those issues.  
It is not related to issue3067.

----------
components: Library (Lib)
messages: 89537
nosy: sjt
severity: normal
status: open
title: locale._build_localename(locale.getdefaultlocale()) returns 'C.mac-roman'
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6315>
_______________________________________

From report at bugs.python.org  Sat Jun 20 15:43:26 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Jun 2009 13:43:26 +0000
Subject: [issue6314] logging.basicConfig(level='DEBUG', ...
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1245505406.69.0.303498528007.issue6314@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> vsajip
nosy: +vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6314>
_______________________________________

From report at bugs.python.org  Sat Jun 20 15:58:49 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 20 Jun 2009 13:58:49 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1245506329.71.0.287737427169.issue6164@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r73490. Will wait for 3.1 final release to apply it to the py3k
branch.

----------
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sat Jun 20 17:14:12 2009
From: report at bugs.python.org (Jeong-Min Lee)
Date: Sat, 20 Jun 2009 15:14:12 +0000
Subject: [issue6316] format, str.format don't work well with datetime,
	date object
In-Reply-To: <1245510852.42.0.472417043973.issue6316@psf.upfronthosting.co.za>
Message-ID: <1245510852.42.0.472417043973.issue6316@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee <falsetru at gmail.com>:

format(datetime_obj, format_string) return format_string. (when
format_string is not empty.)


>>> import datetime
>>> d = datetime.datetime.now()
>>> format(d)
'2009-06-20 23:51:54.243428'
>>> format(d, '')
'2009-06-20 23:51:54.243428'
>>> d
datetime.datetime(2009, 6, 20, 23, 51, 54, 243428)
>>> '{0}'.format(d)
'2009-06-20 23:51:54.243428'
>>> '{0:30}'.format(d) # odd
'30'
>>> format(d, '30') # odd
'30'
>>> format(str(d), '30') # workaround
'2009-06-20 23:51:54.243428    '
>>> '{0!s:30}'.format(d) # workaround
'2009-06-20 23:51:54.243428    '

----------
components: Extension Modules, Library (Lib)
messages: 89539
nosy: falsetru
severity: normal
status: open
title: format, str.format don't work well with datetime, date object
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6316>
_______________________________________

From report at bugs.python.org  Sat Jun 20 17:24:23 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 20 Jun 2009 15:24:23 +0000
Subject: [issue6316] format, str.format don't work well with datetime,
	date object
In-Reply-To: <1245510852.42.0.472417043973.issue6316@psf.upfronthosting.co.za>
Message-ID: <1245511463.88.0.596086959109.issue6316@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith
components: +Interpreter Core -Extension Modules, Library (Lib)
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6316>
_______________________________________

From report at bugs.python.org  Sat Jun 20 17:32:30 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 20 Jun 2009 15:32:30 +0000
Subject: [issue6316] format, str.format don't work well with datetime,
	date object
In-Reply-To: <1245510852.42.0.472417043973.issue6316@psf.upfronthosting.co.za>
Message-ID: <1245511950.8.0.461900409818.issue6316@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is by design. Where d is a datetime, format(d, format_string)
returns d.strftime(format_string).

>>> d.strftime('30')
'30'

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6316>
_______________________________________

From report at bugs.python.org  Sat Jun 20 17:46:57 2009
From: report at bugs.python.org (Jeong-Min Lee)
Date: Sat, 20 Jun 2009 15:46:57 +0000
Subject: [issue6316] format, str.format don't work well with datetime,
	date object
In-Reply-To: <1245510852.42.0.472417043973.issue6316@psf.upfronthosting.co.za>
Message-ID: <1245512817.14.0.0563282204872.issue6316@psf.upfronthosting.co.za>


Jeong-Min Lee <falsetru at gmail.com> added the comment:

I got it.
By the way, It would be good to document that this behaviour (at least
about datetime.__format__)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6316>
_______________________________________

From report at bugs.python.org  Sat Jun 20 18:28:09 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Jun 2009 16:28:09 +0000
Subject: [issue6099] HTTP/1.1 with keep-alive support for xmlrpclib.ServerProxy
In-Reply-To: <1243198332.08.0.299017339998.issue6099@psf.upfronthosting.co.za>
Message-ID: <1245515289.84.0.388867833816.issue6099@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Superseded by issue6267.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed
superseder:  -> Cumulative patch to http and xmlrpc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6099>
_______________________________________

From report at bugs.python.org  Sat Jun 20 18:28:39 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Jun 2009 16:28:39 +0000
Subject: [issue6096] SimpleXMLRPCServer not suitable for HTTP/1.1 keep-alive
In-Reply-To: <1243184810.28.0.183866106023.issue6096@psf.upfronthosting.co.za>
Message-ID: <1245515319.74.0.61029336793.issue6096@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Superseded by issue6267.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed
superseder:  -> Cumulative patch to http and xmlrpc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6096>
_______________________________________

From report at bugs.python.org  Sat Jun 20 18:55:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Jun 2009 16:55:33 +0000
Subject: [issue1360243] Add XML-RPC Fault Interoperability to XMLRPC libraries
Message-ID: <1245516933.93.0.619519868538.issue1360243@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Rejecting the patch because of lack of responsiveness.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1360243>
_______________________________________

From report at bugs.python.org  Sat Jun 20 19:35:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Jun 2009 17:35:15 +0000
Subject: [issue6215] Backport the IO lib to trunk
In-Reply-To: <1244237358.55.0.232192412038.issue6215@psf.upfronthosting.co.za>
Message-ID: <1245519315.03.0.292656508512.issue6215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Everything looks ok, thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6215>
_______________________________________

From report at bugs.python.org  Sat Jun 20 19:45:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Jun 2009 17:45:04 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1245519904.36.0.559461433241.issue6236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ouch, this is quite annoying. I will try to fix this before the final
release.

----------
assignee:  -> pitrou
nosy: +pitrou
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Sat Jun 20 20:24:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Jun 2009 18:24:52 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1245522292.99.0.502107503917.issue6236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is my current interpretation:

subprocess uses os.pipe() to create the file handles used for
communication. These handles normally always raise an error ([Errno 29]
Illegal seek) when trying to seek() on them, which the IO lib interprets
as meaning the stream is not seekable, which it then handles fine.

However, if the first seek() succeeds, the IO lib thinks the stream is
seekable and treats any subsequent seek() failure as an error which it
reports to the user. It may be what you are witnessing.

Can you try applying the following patch?

----------
keywords: +patch
Added file: http://bugs.python.org/file14323/seek-aix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Sat Jun 20 20:31:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Jun 2009 18:31:33 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1245522693.93.0.428544930022.issue6236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Just before, could you try to type the following commands:

>>> r, w = os.pipe()
>>> os.lseek(r, 0, 1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Sat Jun 20 22:48:20 2009
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 20 Jun 2009 20:48:20 +0000
Subject: [issue1612262] Class Browser doesn't show internal classes
Message-ID: <1245530900.58.0.522099408917.issue1612262@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The class browser relies on the pyclbr module to scan the code. This
module doesn't support classes within classes. Both pyclbr and IDLE's
class browser need to be modified.

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1612262>
_______________________________________

From report at bugs.python.org  Sun Jun 21 01:39:23 2009
From: report at bugs.python.org (nlopes)
Date: Sat, 20 Jun 2009 23:39:23 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1245541163.7.0.259505481139.issue6266@psf.upfronthosting.co.za>


nlopes <shelika.void at gmail.com> added the comment:

This is a pretty dumb patch, but it does it's job.
Basically it decodes the utf-8 encoded prefix and uri. Then, encodes it
into Latin1. Probably there are better ways of doing this and those
ideas are welcome. Patch attached.

----------
keywords: +patch
nosy: +nlopes
Added file: http://bugs.python.org/file14324/_elementtree.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Sun Jun 21 02:15:38 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 21 Jun 2009 00:15:38 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1245543338.63.0.972041328534.issue6266@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Converting from UTF-8 to Unicode is the right thing to do, but 
converting back to Latin-1 is not correct -- note that ET returns a 
Unicode string, not an 8-bit string.  There's a "makestring" helper that 
does the right thing in the library; just changing:

parcel = Py_BuildValue("ss", (prefix) ? prefix : "", uri);

to 

parcel = Py_BuildValue("sN", (prefix) ? prefix : "", makestring(uri));

should work (even if you should probably do that in two steps, and look 
for errors from makestring before proceeding).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Sun Jun 21 02:42:28 2009
From: report at bugs.python.org (nlopes)
Date: Sun, 21 Jun 2009 00:42:28 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1245544948.54.0.145735034986.issue6266@psf.upfronthosting.co.za>


nlopes <shelika.void at gmail.com> added the comment:

You're right about the conversion to Latin1.
I actually played a bit with makestring before going in another
direction (although not very good) because makestring alone wasn't
giving what is intended.

I'll try to check tomorrow a good approach for this (already had that in
mind).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Sun Jun 21 03:29:52 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 21 Jun 2009 01:29:52 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1245547792.74.0.686749307577.issue4395@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The situation appears to be at least slightly different from what Guido
stated. In 3.x, all classes subclass object, which has .__ne__, so if
that stopped inferred != behavior, it would never happen.

>>> class A:
	def __eq__(s,p): return 1

>>> id(object.__ne__)
10703216
>>> id(A.__ne__)
10703216

No new A.__ne__ added.  But

>>> c,d=object(),object()
>>> c==d
False
>>> c!=d
True
>>> a,b = A(),A()
>>> a==b
1
>>> a!=b
False

So it seems that a!=b *is* evaluated as not a==b rather than as
a.__ne__(b). If so, my revised suggested replacement would be:

"There is one implied relationship among comparison operators: defining
__eq__ causes '!=' to be evaluated as 'not ==' (but not the other way).
 There is no similar relationship for the order comparisons."

I am a bit puzzled though. In
ttp://svn.python.org/view/python/branches/py3k/Python/ceval.c?revision=73066&view=markup
I traced compare_op to cmp_outcome to (in object.c) PyOjbect_RichCompare
to do_richcompare to class specific tp_richcompare and I do not see the
special casing of eq. However, I am newbie at codebase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Sun Jun 21 03:36:31 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Jun 2009 01:36:31 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

winsound.PlaySound doesn't accept non-unicode string.

Python 3.1rc2+ (py3k, Jun 14 2009, 14:07:51) [MSC v.1200 32 bit (Intel)]
on win3
2
Type "help", "copyright", "credits" or "license" for more information.
>>> import winsound
>>> winsound.PlaySound("?.wav", winsound.SND_LOOP | winsound.SND_ASYNC)

# Rings bell forever.

It's easy to fix this on python3x. I'm not sure this should be fixed in
python2.x, and if should be fixed, probably needs some code like in
posixmodule.c.

  /* try parse args as unicode */
      /* call PlaySoundW */
  /* if fail, try parse args as ascii */
      /* call PlaySoundA */

----------
components: Extension Modules, Windows
files: py3k_winsound.patch
keywords: patch
messages: 89554
nosy: ocean-city
severity: normal
status: open
title: winsound.PlaySound doesn't accept non-unicode string
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14325/py3k_winsound.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Jun 21 03:38:36 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Jun 2009 01:38:36 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245548316.56.0.615759343323.issue6317@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Jun 21 06:36:52 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Jun 2009 04:36:52 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1245559012.74.0.243166116617.issue4395@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Sun Jun 21 08:29:32 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Jun 2009 06:29:32 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245565772.38.0.292738790747.issue6317@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file14326/py3k_winsound.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Jun 21 08:29:49 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Jun 2009 06:29:49 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245565789.11.0.0579593755562.issue6317@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file14325/py3k_winsound.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Jun 21 08:51:07 2009
From: report at bugs.python.org (Eric)
Date: Sun, 21 Jun 2009 06:51:07 +0000
Subject: [issue6318] HTMLParser Attributes Containing Javascript
In-Reply-To: <1245567067.54.0.00517715480066.issue6318@psf.upfronthosting.co.za>
Message-ID: <1245567067.54.0.00517715480066.issue6318@psf.upfronthosting.co.za>


New submission from Eric <e.rykwalder at gmail.com>:

The line:
n.feed('<a onclick="alert(\\"test\\")">test</a>')

is not matched by the regular expressions for attributes.

----------
components: Library (Lib)
messages: 89555
nosy: ericryk
severity: normal
status: open
title: HTMLParser Attributes Containing Javascript
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6318>
_______________________________________

From report at bugs.python.org  Sun Jun 21 09:05:50 2009
From: report at bugs.python.org (Eric)
Date: Sun, 21 Jun 2009 07:05:50 +0000
Subject: [issue6318] HTMLParser Attributes Containing Escaped Quotes
In-Reply-To: <1245567067.54.0.00517715480066.issue6318@psf.upfronthosting.co.za>
Message-ID: <1245567950.17.0.909816984048.issue6318@psf.upfronthosting.co.za>


Eric <e.rykwalder at gmail.com> added the comment:

More specifically, the attributes cannot contain escaped quotes of the
same kind that the attribute value is wrapped in.

----------
title: HTMLParser Attributes Containing Javascript -> HTMLParser Attributes Containing Escaped Quotes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6318>
_______________________________________

From report at bugs.python.org  Sun Jun 21 09:13:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Jun 2009 07:13:33 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245568413.57.0.0413218861554.issue6317@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Even for 3k, I would defer this patch after the 3.1 release, as it is an
incompatible change (requiring a Unicode string where a byte string was
acceptable before).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Jun 21 09:14:40 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Jun 2009 07:14:40 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245568480.35.0.298520641323.issue6317@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Jun 21 11:50:32 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Jun 2009 09:50:32 +0000
Subject: [issue6318] HTMLParser Attributes Containing Escaped Quotes
In-Reply-To: <1245567067.54.0.00517715480066.issue6318@psf.upfronthosting.co.za>
Message-ID: <1245577832.82.0.341145597099.issue6318@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That snippet is not valid HTML.  The attribute string is not a JS
string, so quotes in it must be escaped with '&quot;', not '\"'.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6318>
_______________________________________

From report at bugs.python.org  Sun Jun 21 12:08:15 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Jun 2009 10:08:15 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1245578895.9.0.718001280853.issue4856@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is an updated patch with Py_GetFileAttributesEx[AW] removal.
I propose to commit this to trunk, and merge it to py3k after 3.1 will
be released.

----------
Added file: http://bugs.python.org/file14327/remove_w9x_code.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Sun Jun 21 15:12:45 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 21 Jun 2009 13:12:45 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1245589965.24.0.913257447289.issue6266@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

It should definitely give what's intended (either a Unicode string, or, if 
the content is plain ASCII, an 8-bit string).  What did you get instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Sun Jun 21 16:15:57 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Jun 2009 14:15:57 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1245593757.46.0.00539977012038.issue6317@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I agree. By the way, I created the patch for trunk experimentally.

----------
Added file: http://bugs.python.org/file14328/py2x_winsound.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Jun 21 16:57:06 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 14:57:06 +0000
Subject: [issue5450] test_tcl testLoadTk fails if DISPLAY defined but connect
	fails, instead of being skipped
In-Reply-To: <1236557215.68.0.756624952877.issue5450@psf.upfronthosting.co.za>
Message-ID: <1245596226.85.0.634041515845.issue5450@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Finally I'm looking into this again. So, for now, I decided to only move
the tk load tests to Lib/lib-tk/test/test_tkinter under a new module
named test_loadtk. Lib/test/test_tcl remains almost the same, except it
no longer it contain those tests related to tk loading.

Patch attached. May I reassign it to me David ?

----------
Added file: http://bugs.python.org/file14329/moving_loadtktests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5450>
_______________________________________

From report at bugs.python.org  Sun Jun 21 16:58:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Jun 2009 14:58:20 +0000
Subject: [issue5450] test_tcl testLoadTk fails if DISPLAY defined but
	connect	fails, instead of being skipped
In-Reply-To: <1245596226.85.0.634041515845.issue5450@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0906211057380.32513@kimball.webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

On Sun, 21 Jun 2009 at 14:57, Guilherme Polo wrote:
> Patch attached. May I reassign it to me David ?

Absolutely.

----------
title: test_tcl testLoadTk fails if DISPLAY defined but connect fails, instead of being skipped -> test_tcl testLoadTk fails if DISPLAY defined but connect	fails, instead of being skipped

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5450>
_______________________________________

From report at bugs.python.org  Sun Jun 21 19:24:37 2009
From: report at bugs.python.org (nlopes)
Date: Sun, 21 Jun 2009 17:24:37 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1245605077.71.0.849516209379.issue6266@psf.upfronthosting.co.za>


nlopes <shelika.void at gmail.com> added the comment:

I got pure gibberish output, but I know why. It was a compilation gone
wrong.

To get the output as ElementTree, I think instead of 

parcel = Py_BuildValue("sN", (prefix) ? prefix : "", makestring(uri));

it should be

parcel = Py_BuildValue("sN", (prefix) ? prefix : "",
PyUnicode_AsUnicode(makestring(uri), strlen(uri)));

Else it will not be the expected result.

Or am I overseeing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Sun Jun 21 19:24:38 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 17:24:38 +0000
Subject: [issue5450] test_tcl testLoadTk fails if DISPLAY defined but
	connect	fails, instead of being skipped
In-Reply-To: <1236557215.68.0.756624952877.issue5450@psf.upfronthosting.co.za>
Message-ID: <1245605078.6.0.811060956898.issue5450@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Running tk tests through both Lib/test/test_tk.py and
Lib/test/regrtest.py show the desired behaviour (from what I understood
from your description and from what I tested).

It has been committed now, r73495 (trunk).

Should 2.6 and 3.0 really receive this patch ? I've removed them from
the list in this issue, please add back if it is really needed.

----------
assignee: r.david.murray -> gpolo
versions:  -Python 2.6, Python 3.0, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5450>
_______________________________________

From report at bugs.python.org  Sun Jun 21 19:30:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Jun 2009 17:30:30 +0000
Subject: [issue5450] test_tcl testLoadTk fails if DISPLAY defined but
	connect	fails, instead of being skipped
In-Reply-To: <1236557215.68.0.756624952877.issue5450@psf.upfronthosting.co.za>
Message-ID: <1245605430.97.0.495402965639.issue5450@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, I don't see any reason to bother backporting.  From my understanding
we're not backporting anything to 3.0 at this point anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5450>
_______________________________________

From report at bugs.python.org  Sun Jun 21 19:41:39 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 17:41:39 +0000
Subject: [issue5450] test_tcl testLoadTk fails if DISPLAY defined but
	connect	fails, instead of being skipped
In-Reply-To: <1236557215.68.0.756624952877.issue5450@psf.upfronthosting.co.za>
Message-ID: <1245606099.54.0.329505734105.issue5450@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Fine, closing then.

Committed as r73497 on py3k.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5450>
_______________________________________

From report at bugs.python.org  Sun Jun 21 19:41:48 2009
From: report at bugs.python.org (nlopes)
Date: Sun, 21 Jun 2009 17:41:48 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1245606108.73.0.222972642794.issue6266@psf.upfronthosting.co.za>


nlopes <shelika.void at gmail.com> added the comment:

Don't mind what I just said. I overlooked the N. I couldn't figure out
what was going wrong with your solution.

That works. Mine is a ... aham.

:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Sun Jun 21 19:42:45 2009
From: report at bugs.python.org (nlopes)
Date: Sun, 21 Jun 2009 17:42:45 +0000
Subject: [issue6266] cElementTree.iterparse & ElementTree.iterparse return
	differently encoded strings
In-Reply-To: <1244717632.74.0.358309884859.issue6266@psf.upfronthosting.co.za>
Message-ID: <1245606165.8.0.456461832528.issue6266@psf.upfronthosting.co.za>


Changes by nlopes <shelika.void at gmail.com>:


Removed file: http://bugs.python.org/file14324/_elementtree.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6266>
_______________________________________

From report at bugs.python.org  Sun Jun 21 19:58:15 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 21 Jun 2009 17:58:15 +0000
Subject: [issue6314] logging.basicConfig(level='DEBUG', ...
In-Reply-To: <1245473929.89.0.283081310598.issue6314@psf.upfronthosting.co.za>
Message-ID: <1245607095.86.0.0144346041627.issue6314@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk and py3k.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6314>
_______________________________________

From report at bugs.python.org  Sun Jun 21 20:28:22 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Jun 2009 18:28:22 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1245608902.81.0.261025186768.issue4856@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think it's easier if the patch just sits here for six more days; 3.1
won't take much longer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Sun Jun 21 20:49:37 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 18:49:37 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox
Message-ID: <1245610177.91.0.311964265439.issue1356969@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Should info_dragsite and info_dropsite be added too ? (I guess I would
be too lucky to get an answer after ~3 years). I'm preparing a patch but
I don't tend to use Tix, so it would be good if someone else wrote tests
and at least tested the patch too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1356969>
_______________________________________

From report at bugs.python.org  Sun Jun 21 20:56:29 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 18:56:29 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox
Message-ID: <1245610589.85.0.602313798496.issue1356969@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

There you go.

----------
Added file: http://bugs.python.org/file14330/missing_tixhlist_info_subcomands.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1356969>
_______________________________________

From report at bugs.python.org  Sun Jun 21 20:57:20 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 18:57:20 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox,
	info_dragsite and info_dropsite
Message-ID: <1245610640.74.0.800745066112.issue1356969@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
title: Tix.py class HList missing info_bbox -> Tix.py class HList missing info_bbox, info_dragsite and info_dropsite

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1356969>
_______________________________________

From report at bugs.python.org  Sun Jun 21 20:59:51 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 18:59:51 +0000
Subject: [issue1230] Tix HList class missing method implementation for
	info_bbox
In-Reply-To: <1205772959.19.0.842538363686.issue1230@psf.upfronthosting.co.za>
Message-ID: <1245610791.36.0.15028681645.issue1230@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing in favour of issue1356969.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Tix.py class HList missing info_bbox, info_dragsite and info_dropsite

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1230>
_______________________________________

From report at bugs.python.org  Sun Jun 21 21:05:32 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 19:05:32 +0000
Subject: [issue3062] Turtle speed() function has no effect under Mac OS X
In-Reply-To: <1212923215.43.0.432854849061.issue3062@psf.upfronthosting.co.za>
Message-ID: <1245611132.17.0.667926506462.issue3062@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Although turtle.py lives inside the tkinter package, this doesn't seem
to be related to tkinter at all. I've set the "no selection" option for
the Components now.

----------
components:  -Tkinter
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3062>
_______________________________________

From report at bugs.python.org  Sun Jun 21 21:10:45 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 21 Jun 2009 19:10:45 +0000
Subject: [issue6319] bdist_msi runs out of memory for large packages
In-Reply-To: <1245611444.58.0.810302302684.issue6319@psf.upfronthosting.co.za>
Message-ID: <1245611444.58.0.810302302684.issue6319@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Right now, bdist_msi can run out of memory when used for larger
packages. (I found this problem working with NLTK.) The solution is
really simple - just add a db.Commit() so that stuff gets flushed to
disk more often. The attached patch does just that.

I set this as a release blocker because I think shipping Python 3.1 with
a bdist_msi in that doesn't work for large packages is probably a
mistake, and the patch to fix it is small and non-invasive.

----------
assignee: bethard
components: Distutils
files: bdist_msi.patch
keywords: patch
messages: 89575
nosy: bethard
priority: release blocker
severity: normal
stage: patch review
status: open
title: bdist_msi runs out of memory for large packages
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14331/bdist_msi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6319>
_______________________________________

From report at bugs.python.org  Sun Jun 21 21:28:01 2009
From: report at bugs.python.org (jwishnie)
Date: Sun, 21 Jun 2009 19:28:01 +0000
Subject: [issue6320] Standard string encodings should include GSM0.38
In-Reply-To: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>
Message-ID: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>


New submission from jwishnie <jwishnie at gmail.com>:

The standard string codecs for converting from unicode to strs does not 
include the GSM 0.38 char mapping used by GSM services (like SMS).

I've written a codec for my use based on 'char_mapper' and the skeleton 
from gencodec.py, though it's a little complicated by the fact that the 
GSM encoding is semi-multibyte and not just a straight table look-up.

Gory details here in the comments:
http://www.unicode.org/Public/MAPPINGS/ETSI/GSM0338.TXT

The codec is available here:
http://github.com/jwishnie/pygsm/tree/f574f6db99c585f785f0c73a080814c043
2c6087/pygsm/gsmcodecs

Please consider it, or an optimized/improved version of it, for 
inclusion with the standard codecs distributed with python

----------
components: Unicode
messages: 89576
nosy: jwishnie
severity: normal
status: open
title: Standard string encodings should include GSM0.38
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6320>
_______________________________________

From report at bugs.python.org  Sun Jun 21 21:36:14 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Jun 2009 19:36:14 +0000
Subject: [issue6319] bdist_msi runs out of memory for large packages
In-Reply-To: <1245611444.58.0.810302302684.issue6319@psf.upfronthosting.co.za>
Message-ID: <1245612974.54.0.296075578489.issue6319@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please apply.

----------
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6319>
_______________________________________

From report at bugs.python.org  Sun Jun 21 21:37:41 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 19:37:41 +0000
Subject: [issue1600182] Tix ComboBox entry is blank when not editable
Message-ID: <1245613061.08.0.326733361004.issue1600182@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I don't have access to this file "issue_1600182.py" but it seems you are
forgetting to instantiate Tix.Tk (which will load the 'tix' package)
before creating the Tix.ComboBox.

I'm closing this as it is not a bug in the python tix wrapper, and I
believe the tix package has been fixed since I just tested it on Windows
and I didn't see the bug.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600182>
_______________________________________

From report at bugs.python.org  Sun Jun 21 21:43:33 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 19:43:33 +0000
Subject: [issue869780] curselection() in Tkinter.py should return ints
Message-ID: <1245613413.9.0.0160642372298.issue869780@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing this in favour of issue6181 as it contains several other minor
fixes in Listbox that now have been tested in the
tk_and_idle_maintenance branch.

----------
status: open -> closed
superseder:  -> Tkinter.Listbox several minor issues

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue869780>
_______________________________________

From report at bugs.python.org  Sun Jun 21 22:04:28 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 20:04:28 +0000
Subject: [issue1522587] Tix.Grid patch
Message-ID: <1245614668.27.0.669178495593.issue1522587@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Weird.. I guess no one ever used Tix.Grid ?

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1522587>
_______________________________________

From report at bugs.python.org  Sun Jun 21 22:49:13 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 20:49:13 +0000
Subject: [issue802310] tkFont may reuse font names
Message-ID: <1245617353.29.0.216423469725.issue802310@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uhm, now I'm getting it at around 3 iterations with python-trunk. So,
can't we just use a simple generator for this ? Patch attached.

The same could be done for widget and callback naming.

----------
keywords: +patch
Added file: http://bugs.python.org/file14332/nonamerepeat.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue802310>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:08:23 2009
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 21 Jun 2009 21:08:23 +0000
Subject: [issue6319] bdist_msi runs out of memory for large packages
In-Reply-To: <1245611444.58.0.810302302684.issue6319@psf.upfronthosting.co.za>
Message-ID: <1245618503.46.0.0492796377125.issue6319@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Done in r73499 and r73500. Thanks!

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6319>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:33:02 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 21 Jun 2009 21:33:02 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245619982.71.0.260391494208.issue6233@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Umm.  Isn't _encode used to encode tags and attribute names?  The charref 
syntax is only valid in CDATA sections and attribute values, which are 
encoded by the corresponding _escape functions.  I suspect this patch will 
make things blow up on a non-ASCII tag/attribute name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:41:40 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 21:41:40 +0000
Subject: [issue4961] Inconsistent/wrong result of askyesno function in
	tkMessageBox
In-Reply-To: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>
Message-ID: <1245620500.6.0.715993261946.issue4961@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I guess this will have to be accepted without any tests, unless someone
can come up with a way to test tk_messageBox under Windows and Mac.

----------
keywords: +patch
Added file: http://bugs.python.org/file14333/stringify.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4961>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:42:04 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 21 Jun 2009 21:42:04 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245620524.03.0.89226197284.issue6233@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Did you look at the 1.3 alpha code base when you came up with this idea?  
Unfortunately, 1.3's _encode is used for a different purpose...

I don't have time to test it tonight, but I suspect that 1.3's 
escape_data/escape_attrib functions might work better under 3.X; they do 
the text.replace dance first, and then an explicit text.encode(encoding, 
"xmlcharrefreplace") at the end.  E.g.

def _escape_cdata(text, encoding):
    # escape character data
    try:
        # it's worth avoiding do-nothing calls for strings that are
        # shorter than 500 character, or so.  assume that's, by far,
        # the most common case in most applications.
        if "&" in text:
            text = text.replace("&", "&amp;")
        if "<" in text:
            text = text.replace("<", "&lt;")
        if ">" in text:
            text = text.replace(">", "&gt;")
        return text.encode(encoding, "xmlcharrefreplace")
    except (TypeError, AttributeError):
        _raise_serialization_error(text)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:53:18 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 21 Jun 2009 21:53:18 +0000
Subject: [issue6267] Cumulative patch to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1245621198.15.0.061614319089.issue6267@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Py-dev, Fredrik Lundh wrote "The xmlrpclib.py changes looks ok.  I'll
leave it to other reviewers to check the rest."

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:56:08 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 21:56:08 +0000
Subject: [issue1250469] Tix: PanedWindow.panes nonfunctional
Message-ID: <1245621368.46.0.965237076395.issue1250469@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Is there some reason to prefer .split over .splitlist ? It is very
likely that .split would still return a string if you had a single pane,
while .splitlist would return a tuple with an item on it.

Patch attached.

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file14334/Tix_PanedWindow_panesfix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1250469>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:56:30 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 21:56:30 +0000
Subject: [issue1250469] Tix: PanedWindow.panes nonfunctional
Message-ID: <1245621390.53.0.963418529942.issue1250469@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1250469>
_______________________________________

From report at bugs.python.org  Sun Jun 21 23:59:21 2009
From: report at bugs.python.org (Erik Gorset)
Date: Sun, 21 Jun 2009 21:59:21 +0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1245621561.32.0.0914916461164.issue1657@psf.upfronthosting.co.za>


Erik Gorset <erik at gorset.no> added the comment:

The kqueue implementation is not working. It has a silly bug:

-				chl[i] = ((kqueue_event_Object *)ei)->e;
+				chl[i++] = ((kqueue_event_Object *)ei)->e;

I've created issue 5910 and included a patch, which also adds another test 
case. Anything else I need to do to get the patch accepted?

----------
nosy: +Erik Gorset

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
_______________________________________

From report at bugs.python.org  Mon Jun 22 00:03:36 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 21 Jun 2009 22:03:36 +0000
Subject: [issue1259434] Tix CheckList 'radio' option cannot be changed
Message-ID: <1245621816.1.0.791308322213.issue1259434@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Just adding patch as a .diff

----------
keywords: +patch
nosy: +gpolo
versions: +Python 2.7, Python 3.1 -Python 2.6
Added file: http://bugs.python.org/file14335/issue1259434.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1259434>
_______________________________________

From report at bugs.python.org  Mon Jun 22 00:19:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Jun 2009 22:19:48 +0000
Subject: [issue6320] Standard string encodings should include GSM0.38
In-Reply-To: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>
Message-ID: <1245622788.74.0.222766562766.issue6320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You should provide your code as a patch against the Python trunk. Also,
unit tests should probably be part of Lib/test/test_codecs.py.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6320>
_______________________________________

From report at bugs.python.org  Mon Jun 22 00:20:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Jun 2009 22:20:19 +0000
Subject: [issue6320] Standard string encodings should include GSM0.38
In-Reply-To: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>
Message-ID: <1245622819.06.0.885334591848.issue6320@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6320>
_______________________________________

From report at bugs.python.org  Mon Jun 22 05:48:02 2009
From: report at bugs.python.org (Michael K. Edwards)
Date: Mon, 22 Jun 2009 03:48:02 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1245642482.43.0.430014964885.issue4395@psf.upfronthosting.co.za>


Michael K. Edwards <m.k.edwards at gmail.com> added the comment:

The implementation you are looking for is in object_richcompare, in
http://svn.python.org/projects/python/branches/py3k/Objects/typeobject.c
.  It would be most accurate to say something like:

    The "object" base class, from which all user-defined classes
inherit, provides a single "rich comparison" method to which all of the
comparison operators (__eq__, __ne__, __lt__, __le__, __ge__, __gt__)
map.  This method returns a non-trivial value (i. e., something other
than NotImplemented) in only two cases:
  * When called as __eq__, if the two objects are identical, this method
returns True.  (If they are not identical, it returns NotImplemented so
that the other object's implementation of __eq__ gets a chance to return
True.)
  * When called as __ne__, it calls the equivalent of "self == other";
if this returns a non-trivial value X, then it returns !X (which is
always either True or False).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Mon Jun 22 07:08:37 2009
From: report at bugs.python.org (Michael K. Edwards)
Date: Mon, 22 Jun 2009 05:08:37 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1245647317.58.0.160965665456.issue4395@psf.upfronthosting.co.za>


Michael K. Edwards <m.k.edwards at gmail.com> added the comment:

It would also be useful to point out that there is a shortcut in the
interpreter itself (PyObject_RichCompareBool, in object.c) which checks
the equivalent of id(a) == id(b) and bypasses __eq__/__ne__ if so. 
Since not every call to __eq__ passes through this function, it's fairly
important that implementations of __eq__ return either True or
NotImplemented when id(a) == id(b).  Ditto for extension modules;
anything that installs its own tp_richcompare should handle object
identity and __ne__ in substantially the same way, so that subclass
authors can rely on the documented behavior when overriding __eq__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Mon Jun 22 07:30:20 2009
From: report at bugs.python.org (samwyse)
Date: Mon, 22 Jun 2009 05:30:20 +0000
Subject: [issue6321] Reload Python modules when running programs
In-Reply-To: <1245648620.51.0.901061764952.issue6321@psf.upfronthosting.co.za>
Message-ID: <1245648620.51.0.901061764952.issue6321@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

Every time IDLE is asked to run a program, it doesn't ensure that the 
modules referenced by the program are completely loaded.  This can cause 
problems if one of those modules is also being edited, because once it 
is loaded, any subsequent changes are not compiled and re-loaded.  
PyUnit faced a similar problem and solved it with a custom importer 
(http://pyunit.sourceforge.net/notes/reloading.html).  Ideally, the 
custom importer would be used in two places:  The obvious choice is when 
a program is run, unloading when it returns.  The less obvious is when 
the Python Shell window is opened, since import statements can be run 
from there as well.  Closing that window should cause all such imports 
to be unloaded.  Of course, care must be taken to insure that all run 
commands are properly nested within the lifetime of a shell window.

----------
components: IDLE
messages: 89593
nosy: samwyse
severity: normal
status: open
title: Reload Python modules when running programs
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6321>
_______________________________________

From report at bugs.python.org  Mon Jun 22 09:33:10 2009
From: report at bugs.python.org (Max Arnold)
Date: Mon, 22 Jun 2009 07:33:10 +0000
Subject: [issue1711603] syslog syscall support for SysLogLogger
Message-ID: <1245655990.32.0.336519146518.issue1711603@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

Can I vote for this issue?  Many systems with syslog aren't configured
to listen on UDP socket and thus out of the box SysLogHandler does not work.

----------
nosy: +LwarX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Mon Jun 22 10:22:29 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 22 Jun 2009 08:22:29 +0000
Subject: [issue1711603] syslog syscall support for SysLogLogger
Message-ID: <1245658949.84.0.670763161878.issue1711603@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

As the docstring and documentation says, you can use
SysLogHandler("/dev/log") or similar to connect to a local syslog using
Unix domain sockets rather than UDP. Doesn't this work for you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Mon Jun 22 15:06:42 2009
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 22 Jun 2009 13:06:42 +0000
Subject: [issue5590] pyexpat defines global symbol template_string
In-Reply-To: <1238277227.85.0.219241873183.issue5590@psf.upfronthosting.co.za>
Message-ID: <1245676002.39.0.823518747901.issue5590@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fixed in rev 73503

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5590>
_______________________________________

From report at bugs.python.org  Mon Jun 22 15:58:54 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 22 Jun 2009 13:58:54 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1245679134.84.0.514818008913.issue4949@psf.upfronthosting.co.za>


Changes by Andreas Kloeckner <inform at tiker.net>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4949>
_______________________________________

From report at bugs.python.org  Mon Jun 22 16:09:14 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 22 Jun 2009 14:09:14 +0000
Subject: [issue6322] Pdb breakpoints don't work on lines without bytecode
In-Reply-To: <1245679754.68.0.982838087844.issue6322@psf.upfronthosting.co.za>
Message-ID: <1245679754.68.0.982838087844.issue6322@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

Take this program:

8< -----------------------------------------------
print "START"

a = [
        1
        for i in range(10)]
8< -----------------------------------------------

as "a.py", run "python -m pdb a.py", say "b 3" to set a breakpoint on
line 3. Say "c" to start execution. Watch the program finish without
ever hitting the breakpoint.

The problem is that line 3 has no bytecode generated for it, so there's
nothing to break on. Pdb should provide feedback in this case. I'm the
author of PuDB, and I've written code to check for this condition Please
feel free to steal that code, here:

http://is.gd/19fvD

----------
components: Library (Lib)
messages: 89597
nosy: inducer
severity: normal
status: open
title: Pdb breakpoints don't work on lines without bytecode
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6322>
_______________________________________

From report at bugs.python.org  Mon Jun 22 16:10:11 2009
From: report at bugs.python.org (Max Arnold)
Date: Mon, 22 Jun 2009 14:10:11 +0000
Subject: [issue1711603] syslog syscall support for SysLogLogger
Message-ID: <1245679811.43.0.75678657703.issue1711603@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

Is it safe to use single handler instance in multiple loggers or single
stream in multiple handlers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Mon Jun 22 16:11:47 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Mon, 22 Jun 2009 14:11:47 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

Steps to reprdocue:

1) Debug a program with a syntax error in pdb. 
2) Get the SyntaxError traceback.
3) Hit "q" to quit.
4) Another SyntaxError traceback, and you're back at the Pdb prompt.

----------
components: Library (Lib)
messages: 89599
nosy: inducer
severity: normal
status: open
title: Py3.1 pdb doesn't deal well with syntax errors
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Mon Jun 22 16:42:31 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 22 Jun 2009 14:42:31 +0000
Subject: [issue1711603] syslog syscall support for SysLogLogger
Message-ID: <1245681751.32.0.596579974203.issue1711603@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Why would you want to use a single handler instance against multiple
loggers? It's safe to do so, but you could get duplicated messages
appearing. I presume you have reviewed the documentation and are aware
that loggers are organised in a hierarchy and that in the normal case,
handlers of all parent loggers are allowed to handle events logged with
a particular logger.

What do you mean by "single stream in multiple handlers"? In general
this could result in garbled output, if you have multiple threads in
your environment.

Are these questions relevant to this SysLogHandler issue? I couldn't see
a connection with your earlier comment. If not relevant, please post
them on comp.lang.python where you will probably get more people looking
at them, so that the quality of answers is likely to be more helpful to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Mon Jun 22 16:56:56 2009
From: report at bugs.python.org (Max Arnold)
Date: Mon, 22 Jun 2009 14:56:56 +0000
Subject: [issue1711603] syslog syscall support for SysLogLogger
Message-ID: <1245682616.75.0.46568647888.issue1711603@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

Sorry, I've read your first reply too fast and incorrectly interpreted
it as recommendation to use stream handler with /dev/log.

Anyway, thank you for clarification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1711603>
_______________________________________

From report at bugs.python.org  Mon Jun 22 17:17:34 2009
From: report at bugs.python.org (Tuk Bredsdorff)
Date: Mon, 22 Jun 2009 15:17:34 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1245683854.62.0.750900429759.issue1100942@psf.upfronthosting.co.za>


Changes by Tuk Bredsdorff <robot at tiktuk.net>:


----------
nosy: +tiktuk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Mon Jun 22 17:21:28 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Mon, 22 Jun 2009 15:21:28 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1245684088.6.0.110219439517.issue6070@psf.upfronthosting.co.za>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

import_patch2.patch doesn't work for me. I patched and compiled Python
2.6.2 and without installing it ran ./python -c "import test" in the
build directory. It copied executable bits from test.py to test.pyc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Mon Jun 22 19:19:09 2009
From: report at bugs.python.org (Marco)
Date: Mon, 22 Jun 2009 17:19:09 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1245691149.24.0.667098574887.issue6070@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

hmm.. the problem is that Windows doesn't support well permissions as
all the other POSIX compliant OSs ...
I've searched for a solution on the web, and I've found a complete
answer on:
http://stackoverflow.com/questions/592448/c-how-to-set-file-permissions-cross-platform

The patch doesn't work well since it only checks for User's permissions
so it works well for that. 
Maybe using the Windows API you can change the permissions as you want.
But since I don't know them, I can't help anymore :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Mon Jun 22 19:25:43 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Mon, 22 Jun 2009 17:25:43 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1245691149.24.0.667098574887.issue6070@psf.upfronthosting.co.za>
Message-ID: <20090622172543.GA16453@phd.pp.ru>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

I am not on Windows. I am on Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Mon Jun 22 20:42:44 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Jun 2009 18:42:44 +0000
Subject: [issue5910] kqueue for more than one event is broken.
In-Reply-To: <1241301488.84.0.663629523973.issue5910@psf.upfronthosting.co.za>
Message-ID: <1245696164.92.0.187765536592.issue5910@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good, but I cannot test it.

----------
assignee:  -> christian.heimes
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5910>
_______________________________________

From report at bugs.python.org  Mon Jun 22 20:57:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Jun 2009 18:57:24 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1245697044.11.0.870525766566.issue6285@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I reproduce the same problem:
In IDLE, add a new entry in "Options/Configure/General/Additional Help 
Sources", and browse to the C:\Python31\Docs\Python31*.chm file.
This new entry appears in the "Help" menu.

Now, if you un-install this version and install another, the file you have 
chosen is no more present, but still listed in the preferences.
This causes errors if you try to open it...

The proposed patch is correct, except that an error in webbrowser is more 
likely to display some 404 error and not raise an exception.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Mon Jun 22 21:27:54 2009
From: report at bugs.python.org (Anthony Foglia)
Date: Mon, 22 Jun 2009 19:27:54 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>


New submission from Anthony Foglia <afoglia at gmail.com>:

I was debugging a class where I defined __getitem__ and __iter__, but 
not __contains__.  The documentation describing this case (at the end of 
section 5.9) is old and hasn't been updated for the iterator protocol.

It should read something like:

"For user-defined classes which do not define __contains__() and do 
define __iter__() or __getitem__(), x in y is true if and only if there 
is a value z reachable from iter(y) before iter(y) throws a 
StopIteration exception. (If any other exception is raised, it is as if 
in raised that exception)."

Or something better worded.

(I'm using Python 2.5, but I really doubt things have changes in 2.6 or 
2.7.  I don't know enough about 3.0 to know either way.)

----------
assignee: georg.brandl
components: Documentation
messages: 89607
nosy: afoglia, georg.brandl
severity: normal
status: open
title: "in" expression falls back to __iter__ before __getitem__
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Mon Jun 22 21:36:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Jun 2009 19:36:16 +0000
Subject: [issue4490] xml/sax/expatreader.py raises AttributeError when run
In-Reply-To: <1228233176.69.0.228694076169.issue4490@psf.upfronthosting.co.za>
Message-ID: <1245699376.09.0.411013747795.issue4490@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

These functions are already tested, but I think that this kind of code 
also serves to show a basic usage of the module.
Fixed with r73509.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4490>
_______________________________________

From report at bugs.python.org  Mon Jun 22 21:50:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Jun 2009 19:50:20 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1245700220.82.0.525525490958.issue6323@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I tried different combinations, and could not reproduce it (for example, 
the debugged function imports a bad module, or eval() a bad expression)
How did you generate the SyntaxError?

----------
nosy: +amaury.forgeotdarc
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Mon Jun 22 21:59:59 2009
From: report at bugs.python.org (nlopes)
Date: Mon, 22 Jun 2009 19:59:59 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1245700799.82.0.176165191177.issue6323@psf.upfronthosting.co.za>


nlopes <shelika.void at gmail.com> added the comment:

I can reproduce it in my OpenBSD 4.5 box (only one I tried).

This simple code:
print(3
seems to break the pdb flow in python 3.1 the way Andreas described it.

When I tried in 2.7, this is what I get:
-bash-3.2$ ./python -m pdb test.py
SyntaxError: ('invalid syntax', ('test.py', 2, 8, ''))
> <string>(1)<module>()
(Pdb) q
[20367 refs]
-bash-3.2$

----------
nosy: +nlopes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Mon Jun 22 22:05:51 2009
From: report at bugs.python.org (Andrew Trick)
Date: Mon, 22 Jun 2009 20:05:51 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1245701151.79.0.667595586667.issue1424152@psf.upfronthosting.co.za>


Andrew Trick <andrew.trick at gmail.com> added the comment:

With this patch, I continued to get the following error 
SSL23_GET_SERVER_HELLO
Until my coworker finally found a fix posted by Philippe Biondi:
+++ b/mercurial/keepalive.py
@@ -237,6 +237,8 @@
              else:
                  # no (working) free connections were found.  Create a
new one.
                  h = http_class(host)
+                if hasattr(req,"_tunnel_host") and req._tunnel_host:
+                    h.set_tunnel(req._tunnel_host)
                  if DEBUG: DEBUG.info("creating new connection to %s (%d)",
                                       host, id(h))
                  self._cm.add(host, h, 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Mon Jun 22 22:16:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Jun 2009 20:16:42 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1245701802.97.0.832402247221.issue6324@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Mon Jun 22 23:01:07 2009
From: report at bugs.python.org (Alex James)
Date: Mon, 22 Jun 2009 21:01:07 +0000
Subject: [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245704467.18.0.148024461366.issue6290@psf.upfronthosting.co.za>


Alex James <ac.james at shaw.ca> added the comment:

I have now pinpointed the error to a list of infinities (see attached).
When using pickle.py to read the cPickle'd data we get a different, and
more, informative error:
ValueError: invalid literal for float(): 1.#INF

----------
Added file: http://bugs.python.org/file14336/cPicktest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6290>
_______________________________________

From report at bugs.python.org  Mon Jun 22 23:03:31 2009
From: report at bugs.python.org (jan matejek)
Date: Mon, 22 Jun 2009 21:03:31 +0000
Subject: [issue1298813] sysmodule.c: realpath() is unsafe
Message-ID: <1245704611.28.0.954201564766.issue1298813@psf.upfronthosting.co.za>


Changes by jan matejek <jmatejek at suse.cz>:


----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298813>
_______________________________________

From report at bugs.python.org  Mon Jun 22 23:34:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Jun 2009 21:34:58 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1245706498.99.0.193981364904.issue6323@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the test case.
It appears that 2.7 actually calls exec("execfile(filename)"),
when 3.1 directly calls exec(file_content).

The indirection seems necessary: the SyntaxError is detected by the pdb 
trace function; but this function has to run somehow...
With the patch below, pdb now runs exec("exec(file_content)").

I'm not sure how to write unit tests for pdb.
I don't know if it will be accepted for 3.1 final.

Index: Lib/pdb.py
===================================================================
--- Lib/pdb.py  (revision 73505)
+++ Lib/pdb.py  (working copy)
@@ -1211,7 +1211,7 @@
         self.mainpyfile = self.canonic(filename)
         self._user_requested_quit = 0
         with open(filename) as fp:
-            statement = fp.read()
+            statement = "exec(%r)" % (fp.read(),)
         self.run(statement)

 # Simplified interface

----------
keywords: +needs review, patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Tue Jun 23 00:12:44 2009
From: report at bugs.python.org (nlopes)
Date: Mon, 22 Jun 2009 22:12:44 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1245708764.75.0.258021729544.issue6323@psf.upfronthosting.co.za>


nlopes <shelika.void at gmail.com> added the comment:

That fixes it.
It seems to be introduced when committing a fix for issue #1038.

-bash-3.2$ svn diff -r 58126:58127 Lib/pdb.py
Index: Lib/pdb.py
===================================================================
--- Lib/pdb.py  (revision 58126)
+++ Lib/pdb.py  (revision 58127)
@@ -1166,12 +1166,8 @@
         self._wait_for_mainpyfile = 1
         self.mainpyfile = self.canonic(filename)
         self._user_requested_quit = 0
-        fp = open(filename)
-        try:
-            script = fp.read()
-        finally:
-            fp.close()
-        statement = 'exec("%s")' % script
+        with open(filename) as fp:
+            statement = fp.read()
         self.run(statement)

 # Simplified interface

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Tue Jun 23 00:29:16 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Jun 2009 22:29:16 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1245709756.4.0.602487960579.issue6070@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patch did not apply for me.  I modified the code by hand based on
the patch file, and on Gentoo linux it worked for me.  Patch that
applies cleanly to trunk attached.

----------
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14337/issue6070.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue Jun 23 00:30:23 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Jun 2009 22:30:23 +0000
Subject: [issue6323] Py3.1 pdb doesn't deal well with syntax errors
In-Reply-To: <1245679907.43.0.120493835283.issue6323@psf.upfronthosting.co.za>
Message-ID: <1245709823.68.0.698929768731.issue6323@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Good point.
So in the end, we just replaced
    exec('%s')        # wrong when the text is "x='a'"
with
    exec(%r)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6323>
_______________________________________

From report at bugs.python.org  Tue Jun 23 02:11:24 2009
From: report at bugs.python.org (Senthil)
Date: Tue, 23 Jun 2009 00:11:24 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1245715884.3.0.2465920041.issue1424152@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

AndrewTrick: I am assuming your last comment is more relevant to
mercurial's use of the set_tunnel, the facility provided by the patch,
that is solving the issue for you. You had earlier pointed out
mercurial's dependency upon this issue too.

The fix as such stands good and may not require any change. Is my
understanding OK?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Tue Jun 23 03:01:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jun 2009 01:01:55 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1245718915.47.0.76058370578.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, I finally had time to come back to this, and figured out what I
think is a final fix.  It passes all the tests we've come up with, at
least.  Let me know if you see any problems with it, and if not I'll
apply it.

----------
assignee:  -> r.david.murray
versions: +Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file14338/issue5230.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________

From report at bugs.python.org  Tue Jun 23 03:02:03 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jun 2009 01:02:03 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1245718923.89.0.847998310181.issue5230@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file14205/issue5230.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________

From report at bugs.python.org  Tue Jun 23 03:24:28 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 23 Jun 2009 01:24:28 +0000
Subject: [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245720268.18.0.369545483877.issue6290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Thanks for the test case. I will take a look.

----------
assignee: georg.brandl -> alexandre.vassalotti
components: +Library (Lib) -Documentation, Extension Modules, Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6290>
_______________________________________

From report at bugs.python.org  Tue Jun 23 03:52:30 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 23 Jun 2009 01:52:30 +0000
Subject: [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245721950.4.0.71440791376.issue6290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Could you give me the output of this?

  import cPickle
  print repr(cPickle.dumps([float('+inf'), float('-inf'), float('nan')]))
  print [float('+inf'), float('-inf'), float('nan')]

By the way, are you sure this bug occurs on Python 2.6? Python 2.6 uses
a platform-independent float to string converter (i.e.,
PyOS_double_to_string) which shouldn't output stuff like "1.#INF"

Also, can you verify that the bug does not occur with pickle protocol 1
and over?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6290>
_______________________________________

From report at bugs.python.org  Tue Jun 23 04:28:40 2009
From: report at bugs.python.org (Andrew Trick)
Date: Tue, 23 Jun 2009 02:28:40 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
In-Reply-To: <1245715884.3.0.2465920041.issue1424152@psf.upfronthosting.co.za>
Message-ID: <16a4b1030906221928w2965399avbaa2df989635e1e@mail.gmail.com>


Andrew Trick <andrew.trick at gmail.com> added the comment:

I should have pointed out that my secondary problem was a mercurial
dependency on the urllib patch. I just wanted Mercurial users to get a
complete fix. I figure they will be looking for a fix in the python bug
report, and need to be told the fix won't work for them.

On Mon, Jun 22, 2009 at 5:11 PM, Senthil <report at bugs.python.org> wrote:

>
> Senthil <orsenthil at gmail.com> added the comment:
>
> AndrewTrick: I am assuming your last comment is more relevant to
> mercurial's use of the set_tunnel, the facility provided by the patch,
> that is solving the issue for you. You had earlier pointed out
> mercurial's dependency upon this issue too.
>
> The fix as such stands good and may not require any change. Is my
> understanding OK?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1424152>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14339/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________
-------------- next part --------------
I should have pointed out that my secondary problem was a mercurial dependency on the urllib patch. I just wanted Mercurial users to get a complete fix. I figure they will be looking for a fix in the python bug report, and need to be told the fix won&#39;t work for them.<br>
<br><div class="gmail_quote">On Mon, Jun 22, 2009 at 5:11 PM, Senthil <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Senthil &lt;<a href="mailto:orsenthil at gmail.com">orsenthil at gmail.com</a>&gt; added the comment:<br>
<br>
AndrewTrick: I am assuming your last comment is more relevant to<br>
mercurial&#39;s use of the set_tunnel, the facility provided by the patch,<br>
that is solving the issue for you. You had earlier pointed out<br>
mercurial&#39;s dependency upon this issue too.<br>
<br>
The fix as such stands good and may not require any change. Is my<br>
understanding OK?<br>
<div><div></div><div class="h5"><br>
----------<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue1424152" target="_blank">http://bugs.python.org/issue1424152</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Jun 23 06:25:51 2009
From: report at bugs.python.org (Brian Slesinsky)
Date: Tue, 23 Jun 2009 04:25:51 +0000
Subject: [issue6325] robotparser doesn't handle URL's with query strings
In-Reply-To: <1245731150.83.0.504271486523.issue6325@psf.upfronthosting.co.za>
Message-ID: <1245731150.83.0.504271486523.issue6325@psf.upfronthosting.co.za>


New submission from Brian Slesinsky <brian at slesinsky.org>:

If a robots.txt file contains a rule of the form:

  Disallow: /some/path?name=value

This pattern will never match a URL passed to can_fetch(), as far as I
can tell.

It's arguable whether this is a bug. The 1994 robots.txt protocol is
silent on whether to treat query strings specially and just says "any
URL that starts with this value will not be retrieved". The 1997 draft
standard talks about the path portion of a URL but doesn't give any
examples about how to treat the '?' character in a robots.txt pattern.

Google extends the protocol to allow wildcard characters in a way that
doesn't treat the '?' character specially. See:
http://www.google.com/support/webmasters/bin/answer.py?answer=40360&cbid=-1rdq1gi8f11xx&src=cb&lev=answer#3

I'll leave aside whether to implement pattern matching, but it seems
like a good idea to do something reasonable when a robots.txt pattern
contains a literal '?', and treating it as a literal character seems
simplest.

Cause: in robotparser.can_fetch(), there is this code which seems to
take only the path (stripping the query string).

 url = urllib.quote(urlparse.urlparse(urllib.unquote(url))[2]) or "/"

Also, when parsing patterns in the robots.txt file, a '?' character
seems to be automatically URL-escaped. There's nothing in a standards
doc about doing this so I think that might be a bug too.

Tested with python 2.4. I looked at the code in Subversion head and it
doesn't look like there were any changes on the trunk.

----------
components: Library (Lib)
messages: 89622
nosy: skybrian
severity: normal
status: open
title: robotparser doesn't handle URL's with query strings
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6325>
_______________________________________

From report at bugs.python.org  Tue Jun 23 07:37:27 2009
From: report at bugs.python.org (Jerry Chen)
Date: Tue, 23 Jun 2009 05:37:27 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245735447.77.0.911688551388.issue6233@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

The attached patch includes Neil's original additions to test_xml_etree.py.


I also noticed that _encode_entity wasn't being called in ElementTree in
py3k, with the important bit being the nested function
escape_entities(), in conjunction with _escape and _escape_map.

In 2.x, _encode_entity() is used after _encode() throws Unicode
exceptions [1], so I figured it would make sense to take the core
functionality of _escape_entities() and integrate it into _encode in the
same fashion -- when an exception is thrown.

Basically, I:
- changed _escape regexp from using "[\x0080-\uffff]" to "[\x80-xff]"
- extracted _encode_entity.escape_entities() and made it
_escape_entities of module scope
- removed _encode_entity()
- added UnicodeEncodeError exception in _encode()

I'm not sure what the expected outcome is supposed to be when the text
is not type bytes but str. With this patch, the output has
b"t&#195;&#163;t" rather than b"t&#227;t".

Hope this is a step in the right direction.

[1] ElementTree.py:814, ElementTree.py:829, python 2.7 HEAD r50941

----------
nosy: +jcsalterego
Added file: http://bugs.python.org/file14340/issue6233-escape_entities.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Tue Jun 23 09:59:42 2009
From: report at bugs.python.org (Marco)
Date: Tue, 23 Jun 2009 07:59:42 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1245743982.56.0.948186919165.issue6070@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

Thank you David.. sorry for my errors :)
but this is my first patch :P 

I've recompiled py2.6 and it works fine on my Debian.

As you can see:
-rwxr-xr-x  1 marco marco    81822 30 set  2008 setup.py

./python -c "import setup"
-rw-r--r--  1 marco marco    42156 23 giu 09:58 setup.pyc


However, the version 2.5 doesn't have this "bug" and I've not recompiled it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Tue Jun 23 13:00:13 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jun 2009 11:00:13 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1245754813.41.0.421340998333.issue6288@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Docstring updated in r73518 (2.7) and r73520 (3.1)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Tue Jun 23 15:12:49 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 23 Jun 2009 13:12:49 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

It is sometimes useful to be able to swap the contents of two lists and 
this patch provides a way to do so using the fastest way possible.

> a = [1, 2]
> b = [3]
> id(a), id(b)
(100, 101)
> a.swap(b)
> a
[3]
> b
[1, 2]
> id(a), id(b)
(100, 101)

One application of this is to make help a performance problem when one 
wants to upgrade a list instance into a subclass instance.
orglist = rawlist_from_server()
mylist = ListSubclass(orglist)

This involves copying duplicating the list, and then discarding, which 
can take a while for long lists.  Much faster is using>
mylist = ListSubclass()
mulist.swap(orglist)

We are using this extension within CCP to decoratate database queries 
from our database engine, that are returned as python lists.  The 
performance gained by shaving off this extra list duplication can be 
significant for large data sets.
to change a list, into a

----------
components: Interpreter Core
files: listswap.patch
keywords: patch, patch
messages: 89626
nosy: krisvale
severity: normal
status: open
title: Add a "swap" method to list
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14341/listswap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Tue Jun 23 16:33:07 2009
From: report at bugs.python.org (Martijn Otto)
Date: Tue, 23 Jun 2009 14:33:07 +0000
Subject: [issue6327] [mimetext] long lines get cut with exclamation mark and
	newline
In-Reply-To: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>
Message-ID: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>


New submission from Martijn Otto <martijntje at gmail.com>:

When using mimetext, long lines are cut at character 990, at which place
an exclamation mark, a newline and a space are inserted. After this the
line continues... For example, this line:

000000000148                                                           
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                   0220090622N0   K.        de       
Boer                                                                     
                                                                  
Badhuisstraat                      36                                       
         2012 CPHAARLEM                            NED20090622       
1500     628215290           19030201keesdeboerisdebeste at hotmail.com     
              0123456789  

will get changed to

000000000148                                                           
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                               0220090622N0   K.        de        Boer 
                                                                       
                                                             
Badhuisstraat                      36                                  
             2012 CPHAARLEM                            NED20090622     
  1500     628215290           19030201keesdeboerisdebeste at hotm!
 ail.com                   0123456789

----------
messages: 89627
nosy: martijntje
severity: normal
status: open
title: [mimetext] long lines get cut with exclamation mark and newline
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6327>
_______________________________________

From report at bugs.python.org  Tue Jun 23 17:27:22 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Tue, 23 Jun 2009 15:27:22 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1245770842.92.0.506421610625.issue5230@psf.upfronthosting.co.za>


Lucas Prado Melo <lukepadawan at gmail.com> added the comment:

I think this patch is ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________

From report at bugs.python.org  Tue Jun 23 18:05:27 2009
From: report at bugs.python.org (Gehua Yang)
Date: Tue, 23 Jun 2009 16:05:27 +0000
Subject: [issue6328] login() function failed in smtplib with message "argument
	1 must be bytes or buffer, not str"
In-Reply-To: <1245773126.97.0.509080047972.issue6328@psf.upfronthosting.co.za>
Message-ID: <1245773126.97.0.509080047972.issue6328@psf.upfronthosting.co.za>


New submission from Gehua Yang <yanggehua at gmail.com>:

Hi folks,

I encountered the following error with this Python code snippet. (I ran
it with Python 3.0.1). Judging from the error as shown in IDLE debugger,
the error was buried inside python. 

  try:
    server = smtplib.SMTP(EmailConfig.smtpServerName)
    server.set_debuglevel(3)
    print(server)
    server.login(bytes(EmailConfig.mailUser, encoding='ascii'),
bytes(EmailConfig.mailPass, encoding='ascii'))
    print('Login is successful.')
    failed = server.sendmail(from_addr, to_addr, text_msg)
  except Exception as ex:
    print('Error in communicating with SMTP server', ex)
  else:
    if failed : print('Failed in sending email with following
reason:\n', failed)


***********************************************
The output from terminal is:
$ c:/tools/Python30/python send_email.py
<smtplib.SMTP object at 0x00F21990>
send: 'ehlo quad-vision.hua\r\n'
reply: b'250-smtp.mxes.net\r\n'
reply: b'250-PIPELINING\r\n'
reply: b'250-SIZE 400000000\r\n'
reply: b'250-ETRN\r\n'
reply: b'250-STARTTLS\r\n'
reply: b'250-AUTH PLAIN LOGIN\r\n'
reply: b'250-AUTH=PLAIN LOGIN\r\n'
reply: b'250-ENHANCEDSTATUSCODES\r\n'
reply: b'250-8BITMIME\r\n'
reply: b'250 DSN\r\n'
reply: retcode (250); Msg: b'smtp.mxes.net\nPIPELINING\nSIZE
400000000\nETRN\nSTARTTLS\nAUTH PLAIN L
OGIN\nAUTH=PLAIN LOGIN\nENHANCEDSTATUSCODES\n8BITMIME\nDSN'
Error in communicating with SMTP server b2a_base64() argument 1 must be
bytes or buffer, not str

----------
files: python-shot.png
messages: 89629
nosy: hdvision
severity: normal
status: open
title: login() function failed in smtplib with message "argument 1 must be bytes or buffer, not str"
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file14342/python-shot.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6328>
_______________________________________

From report at bugs.python.org  Tue Jun 23 18:07:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jun 2009 16:07:30 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1245773250.83.0.420164925149.issue5230@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file14338/issue5230.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________

From report at bugs.python.org  Tue Jun 23 18:10:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jun 2009 16:10:59 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1245773459.26.0.79098372116.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is an updated patch that cleans up the unit test (I wasn't
correctly restoring sys.path).

----------
Added file: http://bugs.python.org/file14343/issue5230.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________

From report at bugs.python.org  Tue Jun 23 18:21:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jun 2009 16:21:50 +0000
Subject: [issue6328] login() function failed in smtplib with message "argument
	1 must be bytes or buffer, not str"
In-Reply-To: <1245773126.97.0.509080047972.issue6328@psf.upfronthosting.co.za>
Message-ID: <1245774110.97.0.0851136154875.issue6328@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue5259, and has been fixed in 3.1.

----------
components: +Library (Lib)
dependencies: +smtplib is broken in Python3
nosy: +r.david.murray
priority:  -> low
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6328>
_______________________________________

From report at bugs.python.org  Tue Jun 23 18:29:09 2009
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 23 Jun 2009 16:29:09 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1245774549.54.0.799604186213.issue2636@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Thanks for this great work!

Does Regexp 2.7 include Unicode Scripts support?
http://www.regular-expressions.info/unicode.html

Perl and Ruby support it and it's pretty handy.

----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Jun 23 18:57:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 16:57:09 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245776229.73.0.772918114531.issue6326@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> One application of this is to make help a performance problem when one 
> wants to upgrade a list instance into a subclass instance.

Since this bypasses the subclass's __init__ and other methods, doesn't
it risk violating subclass invariants?

class CapList(list):
   def __init__(self, iterable=()):
       for elem in iterable:
           self.append(elem.upper())

class NoneCountingList(list):
   def __init__(self, iterable=()):
       list.__init__(self, iterable)
       self.nones = self.count(None)
   def append(self, value):
       list.append(self, value)
       self.nones += 1 if value is None else 0
   def extend(self, iterable):
       for elem in iterable:
           self.append(elem)
   . . .

IOW, a swap() method is problematic for some subclasses because it
bypasses all of the subclass insertion/removal logic.  The problem is
compounded for subclasses written as C extensions because violating the
internal invariants may lead to a crash.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Tue Jun 23 19:01:35 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 23 Jun 2009 17:01:35 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1245776495.45.0.808720336998.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It includes Unicode character properties, but not the Unicode script
identification, because the Python Unicode database contains the former
but not the latter.

Although they could be added to the re module, IMHO their proper place
is in the Unicode database, from which the re module could access them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Jun 23 19:52:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jun 2009 17:52:14 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245779534.79.0.266792021912.issue6326@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There are clearly enough subtleties to this proposal that it should be
discussed on python-ideas first.  If a consensus is reached you can
reopen this ticket, referencing the discussion thread.

----------
nosy: +r.david.murray
priority:  -> low
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Tue Jun 23 20:10:44 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 18:10:44 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245780644.25.0.801662155019.issue6326@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, the technique is useful and fast, but it is complicated in its
effects.  I used something similar in the set_swap_bodies() internal
code for set and frozenset objects but avoided exposing the behavior
externally.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Tue Jun 23 20:40:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 18:40:02 +0000
Subject: [issue6329] Fix iteration for memoryviews
In-Reply-To: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>
Message-ID: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Despite being a sequence (with both __getitem__ and __len__ defined),
memoryview objects were not recognized as being iterable.  The docs say
that all such sequences are iterable, so this is a bug.

>>> b = b'abcde'
>>> m = memoryview(b)
>>> list(m)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    list(m)
TypeError: 'memoryview' object is not iterable

The underlying problem is that the __getitem__ method is listed in the
as_mapping section instead of as_sequence.  This was necessary so that
the ellipsis could be supported (the mapping version accepts arbitrary
objects while the sequence version only accepts integer indices). 
Unfortunately, the logic for Objects/abstract.c::PySeq_Iter() expects to
find the getitem defined in s->ob_type->tp_as_sequence->sq_item slot.  

This patch attaches the appropriate code in that slot.  The code is a
simple cut and paste from the more general memory_subscript() function
listed just above.

----------
assignee: r.david.murray
components: Interpreter Core
files: mview.diff
keywords: patch
messages: 89637
nosy: r.david.murray, rhettinger
priority: high
severity: normal
stage: patch review
status: open
title: Fix iteration for memoryviews
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14344/mview.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6329>
_______________________________________

From report at bugs.python.org  Tue Jun 23 20:40:58 2009
From: report at bugs.python.org (Alex James)
Date: Tue, 23 Jun 2009 18:40:58 +0000
Subject: [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245782458.72.0.62350514621.issue6290@psf.upfronthosting.co.za>


Alex James <ac.james at shaw.ca> added the comment:

Your test prints:
'(1p1\nF1.#INF\naF-1.#INF\naF-1.IND\na.'
[inf, -inf, nan]

My installation is Python 2.6.2 as currently distributed.

Specifying protocol 1 or 2 does circumvent the error.  
Thank you.

----------
components: +Documentation, Extension Modules, Windows -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6290>
_______________________________________

From report at bugs.python.org  Tue Jun 23 20:41:45 2009
From: report at bugs.python.org (Alex James)
Date: Tue, 23 Jun 2009 18:41:45 +0000
Subject: [issue6290] cPickle can misread data type
In-Reply-To: <1245107994.41.0.726587002709.issue6290@psf.upfronthosting.co.za>
Message-ID: <1245782505.13.0.526946419643.issue6290@psf.upfronthosting.co.za>


Changes by Alex James <ac.james at shaw.ca>:


----------
components: +Library (Lib) -Documentation, Extension Modules, Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6290>
_______________________________________

From report at bugs.python.org  Tue Jun 23 20:45:53 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 23 Jun 2009 18:45:53 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245782753.09.0.111548306767.issue6326@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Indeed, I realized that it does allow overriding all kinds of behaviour 
and as such may be dangerous for the unwary.  But isn't it possible to 
do so anyway?

One way to increase safety would be to require that the "other" list is 
not a subclass (PyList_CheckExact(v)) so that no unexpected behaviour 
occurs for it, and so allow the 'target' list to simply override "swap" 
if it deems it unacceptable.

At any rate, I thought I'd share this idea and accept that it needs 
discussion. I'll start a thread on python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Tue Jun 23 20:57:09 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Jun 2009 18:57:09 +0000
Subject: [issue6330] trunk does not build with --enable-unicode=ucs4
In-Reply-To: <1245783429.44.0.152732934194.issue6330@psf.upfronthosting.co.za>
Message-ID: <1245783429.44.0.152732934194.issue6330@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

This was reported a few weeks ago by Benjamin Peterson, but I haven't
gotten around to fixing it. This is a reminder to myself to do it.

This is due to a bug in Objects/stringlib/formatter.h. Before I fix it
trunk, I need to backport some 3.1 code to keep the implementations in sync.

----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 89640
nosy: eric.smith
severity: normal
status: open
title: trunk does not build with --enable-unicode=ucs4
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6330>
_______________________________________

From report at bugs.python.org  Tue Jun 23 21:33:19 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 19:33:19 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245785599.14.0.615283437145.issue6326@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file14345/mview2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Tue Jun 23 21:34:11 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 19:34:11 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245785651.06.0.763541384421.issue6326@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14345/mview2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Tue Jun 23 21:34:40 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 19:34:40 +0000
Subject: [issue6329] Fix iteration for memoryviews
In-Reply-To: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>
Message-ID: <1245785680.62.0.0650112524069.issue6329@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file14346/mview2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6329>
_______________________________________

From report at bugs.python.org  Tue Jun 23 21:40:35 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Jun 2009 19:40:35 +0000
Subject: [issue6329] Fix iteration for memoryviews
In-Reply-To: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>
Message-ID: <1245786035.61.0.454584025848.issue6329@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Given that the original code being copied is correct, it looks to me
like the revision is fine.  The memoryview tests pass for me with the
patch applied.

----------
assignee: r.david.murray -> rhettinger
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6329>
_______________________________________

From report at bugs.python.org  Tue Jun 23 22:05:58 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 20:05:58 +0000
Subject: [issue6329] Fix iteration for memoryviews
In-Reply-To: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>
Message-ID: <1245787558.94.0.721101132772.issue6329@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file14347/mview3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6329>
_______________________________________

From report at bugs.python.org  Tue Jun 23 22:50:59 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 23 Jun 2009 20:50:59 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

This patch adds a function unicodedata.script() that returns information
about the script of the Unicode character.

----------
components: Unicode
files: unicode-script.diff
keywords: patch
messages: 89642
nosy: doerwalter
severity: normal
status: open
title: Add unicode script info to the unicode database
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14348/unicode-script.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Tue Jun 23 22:52:49 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 23 Jun 2009 20:52:49 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1245790369.17.0.712369181996.issue2636@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

http://bugs.python.org/6331 is a patch that adds unicode script info to
the unicode database.

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Jun 23 23:00:09 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 21:00:09 +0000
Subject: [issue6329] Fix iteration for memoryviews
In-Reply-To: <1245782402.41.0.142582030858.issue6329@psf.upfronthosting.co.za>
Message-ID: <1245790809.83.0.7146604026.issue6329@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r73531 and r73532.

----------
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6329>
_______________________________________

From report at bugs.python.org  Tue Jun 23 23:22:09 2009
From: report at bugs.python.org (Lie Ryan)
Date: Tue, 23 Jun 2009 21:22:09 +0000
Subject: [issue6332] typo on man page warning control
In-Reply-To: <1245792129.32.0.2769542898.issue6332@psf.upfronthosting.co.za>
Message-ID: <1245792129.32.0.2769542898.issue6332@psf.upfronthosting.co.za>


New submission from Lie Ryan <lie.1296 at gmail.com>:

A minor typo on the man page

> -W argument
> ...
> such as inside a loop); module to print each warning *only only*
> ...

----------
assignee: georg.brandl
components: Documentation
files: onlyonly.diff
keywords: patch
messages: 89645
nosy: georg.brandl, lieryan
severity: normal
status: open
title: typo on man page warning control
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14349/onlyonly.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6332>
_______________________________________

From report at bugs.python.org  Tue Jun 23 23:28:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Jun 2009 21:28:32 +0000
Subject: [issue6305] islice doesn't accept large stop values
In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>
Message-ID: <1245792512.54.0.777603138201.issue6305@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Clarified the error message in r73535.

Leaving open as a feature request to support arbitrarily large indices.

----------
components: +Extension Modules
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6305>
_______________________________________

From report at bugs.python.org  Tue Jun 23 23:36:01 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 23 Jun 2009 21:36:01 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1245792961.5.0.460725375108.issue6331@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the patch is incorrect: the default value for the script
property ought to be Unknown, not Common (despite UCD.html saying the
contrary; see UTR#24 and Scripts.txt).

I'm puzzled why you use a hard-coded list of script names. The set of
scripts will certainly change across Unicode versions, and I think it
would be better to learn the script names from Scripts.txt.

Out of curiosity: how does the addition of the script property affect
the number of distinct database records, and the total size of the database?

I think a common application would be lower-cases script names, for more
efficient comparison; UCD has also changed the spelling of the script
names over time (from being all-capital before). So I propose that
a) two functions are provided: one with the original script names, and
one with the lower-case script names
b) keep cached versions of interned script name strings in separate
arrays, to avoid PyString_FromString every time.

I'm doubtful that script names need to be provided for old database
versions, so I would be happy to not record the script for old versions,
and raise an exception if somebody tries to get the script for an old
database version - surely applications of the old database records won't
be accessing the script property, anyway.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Tue Jun 23 23:51:06 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 23 Jun 2009 21:51:06 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1245793866.79.0.531538335338.issue2622@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The patch looks pretty good, except that you should not change
test_email.py.  It specifically tests the old names, while
test_email_renamed.py tests the new names.

There's no point in fixing Python 2.5 since there won't be another
maintenance release of that version.  It probably also does not make
sense to change Python 3.x.  You should fix Python 2.6 though.

In the trunk, we should remove all the old names for good.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
_______________________________________

From report at bugs.python.org  Wed Jun 24 00:02:04 2009
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 23 Jun 2009 22:02:04 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1245794524.74.0.0136912172722.issue6331@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Wed Jun 24 00:12:17 2009
From: report at bugs.python.org (Lie Ryan)
Date: Tue, 23 Jun 2009 22:12:17 +0000
Subject: [issue6332] typo on man page warning control
In-Reply-To: <1245792129.32.0.2769542898.issue6332@psf.upfronthosting.co.za>
Message-ID: <1245795137.95.0.387398344819.issue6332@psf.upfronthosting.co.za>


Lie Ryan <lie.1296 at gmail.com> added the comment:

Bored, I grepped the trunk for a few more stuffs that has similar
consecutive duplicate typos. The dup.diff patch corrects these typos.

Not opening a new issue since all of them are minor.

----------
Added file: http://bugs.python.org/file14350/dup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6332>
_______________________________________

From report at bugs.python.org  Wed Jun 24 01:19:01 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Jun 2009 23:19:01 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1245799141.05.0.238440451848.issue1100942@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is an updated patch, with tests.

The only thing that bugs me is the name of the method: date.strptime() 
seems a bit odd, given that it cannot accept a time part...
OTOH 'strptime' refers to the format specification: %Y-%m-%d

----------
keywords: +needs review -patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14351/date-strptime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed Jun 24 01:33:15 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Jun 2009 23:33:15 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <1245799995.94.0.29269471331.issue1677@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Removing the Windows part: on my machine, repeated Ctrl-C's don't exit the 
3.1 interpreter, probably because the io module is now written in C.

----------
assignee:  -> ronaldoussoren
components: +Macintosh -Interpreter Core, Windows
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1677>
_______________________________________

From report at bugs.python.org  Wed Jun 24 01:44:41 2009
From: report at bugs.python.org (Mads Kiilerich)
Date: Tue, 23 Jun 2009 23:44:41 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1245800681.13.0.348898169893.issue2622@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

I have updated the patch. (Applied to 2.6 where it seems like some
casings had been fixed, so I dropped all the rejects. Changes to
test_email.py has been.)

----------
Added file: http://bugs.python.org/file14352/emailcasings2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
_______________________________________

From report at bugs.python.org  Wed Jun 24 03:42:48 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 24 Jun 2009 01:42:48 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

The logging module has a bug that tries to call `flush' on a closed 
file handle (sys.std[out|err] to be specific). This bug was introduced 
by ConsoleHandler as defined in http://code.activestate.com/
recipes/576819/

The fix is simple: change definition of StreamHandler.flush in logging/
__init__.py to:

  def flush(self):
      if self.stream and hasattr(self.stream, 'flush') and not 
self.stream.closed:
          logging.StreamHandler.flush()

----------
components: Library (Lib)
messages: 89653
nosy: srid
severity: normal
status: open
title: logging: ValueError: I/O operation on closed file
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Wed Jun 24 03:46:13 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 24 Jun 2009 01:46:13 +0000
Subject: [issue6333] logging: ValueError: I/O operation on closed file
In-Reply-To: <1245807768.39.0.536701423847.issue6333@psf.upfronthosting.co.za>
Message-ID: <1245807973.06.0.854900645374.issue6333@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

BTW, this only happens when running the tests via py.test - http://
pytest.org ... perhaps threading/multiprocess issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6333>
_______________________________________

From report at bugs.python.org  Wed Jun 24 07:41:12 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 24 Jun 2009 05:41:12 +0000
Subject: [issue1677] Ctrl-C will exit out of Python interpreter in Windows
In-Reply-To: <1198217773.08.0.968759924116.issue1677@psf.upfronthosting.co.za>
Message-ID: <1245822072.63.0.697309712176.issue1677@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I cannot reproduce this on my machine (running OSX) using 2.5, 2.6 and 3.1  
(latest rc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1677>
_______________________________________

From report at bugs.python.org  Wed Jun 24 08:36:17 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Jun 2009 06:36:17 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1245825377.36.0.129843963787.issue6331@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Wed Jun 24 08:41:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Jun 2009 06:41:27 +0000
Subject: [issue6332] typo on man page warning control
In-Reply-To: <1245792129.32.0.2769542898.issue6332@psf.upfronthosting.co.za>
Message-ID: <1245825687.66.0.890684084671.issue6332@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r73544.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6332>
_______________________________________

From report at bugs.python.org  Wed Jun 24 11:17:43 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 24 Jun 2009 09:17:43 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1245835063.76.0.311618028967.issue6192@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Second patch applied in 73546

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6192>
_______________________________________

From report at bugs.python.org  Wed Jun 24 11:37:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Jun 2009 09:37:52 +0000
Subject: [issue6326] Add a "swap" method to list
In-Reply-To: <1245762769.52.0.940605508616.issue6326@psf.upfronthosting.co.za>
Message-ID: <1245836272.66.0.637969067853.issue6326@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

-1 from me. It is too marginal and obscure an use case to warrant a
dedicated method on a builtin type.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6326>
_______________________________________

From report at bugs.python.org  Wed Jun 24 11:45:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Jun 2009 09:45:47 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245836747.82.0.14787298015.issue6296@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Michael said. As a Linux user I prefer tar.gz (or tar.bz2 or tar.xz),
but distutils should go with zip since it has better support everywhere.

It's true that tar supports lzma (although unfortunately there is still
no lzma support bundled in the stdlib), but for most source
distributions I don't think size is really critical.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 24 12:51:43 2009
From: report at bugs.python.org (Markus F.X.J. Oberhumer)
Date: Wed, 24 Jun 2009 10:51:43 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>


New submission from Markus F.X.J. Oberhumer <markus at oberhumer.com>:

Please note that the correct answer is 25, and the last element is missing !

This bug does not show on 64-bit versions (but 46337**2 is near 2**31).

~Markus


C:\Python31>python
Python 3.1rc2 (r31rc2:73414, Jun 13 2009, 16:43:15) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len(list(range(46337**2, 46349**2, 46337)))
24

C:\Python30>python.exe
Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len(list(range(46337**2, 46349**2, 46337)))
24

----------
components: Interpreter Core
messages: 89660
nosy: mfxmfx
severity: normal
status: open
title: 3.0/3.1: Bad bug in range() computation (or possible Integer problem)
type: behavior
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 13:27:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Jun 2009 11:27:44 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245842864.99.0.90641966396.issue6334@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Simpler test case:
Py2.6:
>>> n = 46349**2
>>> n
2148229801L
>>> range(n-10, n, 3)
[2148229791L, 2148229794L, 2148229797L, 2148229800L]

Py3.0:
>>> n = 46349**2
>>> n
2148229801
>>> list(range(n-10, n, 3))
[2148229791, 2148229794, 2148229797]

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 14:57:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Jun 2009 12:57:51 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245848271.47.0.454846680647.issue6334@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 15:03:53 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jun 2009 13:03:53 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1245848633.52.0.615893687498.issue2622@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Looks good; feel free to commit.

----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
_______________________________________

From report at bugs.python.org  Wed Jun 24 15:10:43 2009
From: report at bugs.python.org (smartmobili)
Date: Wed, 24 Jun 2009 13:10:43 +0000
Subject: [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>


New submission from smartmobili <forumer at smartmobili.com>:

Hi,

I can see that python still doesn't support mingw environnment whil
during past years some people provided some patch.
I wanted recently to compile Python-3.0.1 on mingw and I have found a
patch in a svn repository of a opensource project(don't remember which
one)- So I attach it and I hope it will studied by python dev.
Generally it's not very difficult, you should add some #ifdef
__MINGW32__ when needeed and hack around these lines.
Don't understand you still don't support it.

So this patch is a first step because it doesn't work very well, I mean
I had to copy manually errmap.h from PC to include folder.
And after I get an issue :

gcc -L/usr/local/lib  -o python.exe \
                Modules/python.o \
                libpython3.0.a    -lm
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
make: *** [sharedmods] Error 3

----------
components: Build
files: python3-mingw.patch
keywords: patch
messages: 89663
nosy: smartmobili
severity: normal
status: open
title: Add support for mingw
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file14353/python3-mingw.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6335>
_______________________________________

From report at bugs.python.org  Wed Jun 24 15:12:17 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 24 Jun 2009 13:12:17 +0000
Subject: [issue6336] nb_divide missing in docs
In-Reply-To: <1245849137.7.0.528327337133.issue6336@psf.upfronthosting.co.za>
Message-ID: <1245849137.7.0.528327337133.issue6336@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

http://docs.python.org/c-api/typeobj.html#number-object-structures is
missing the entry for nb_divide, this is confusing.

----------
assignee: georg.brandl
components: Documentation
messages: 89664
nosy: flub, georg.brandl
severity: normal
status: open
title: nb_divide missing in docs
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6336>
_______________________________________

From report at bugs.python.org  Wed Jun 24 15:56:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Jun 2009 13:56:50 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245851810.62.0.689653868259.issue6334@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The length calculation in range_iter in Objects/rangeobject.c is 
incorrect, when using a longrangeiterobject.  The length is computed
as:  (stop - start)//step.  It should be ceiling((stop-start)/step), or
1 + (stop - start - 1)//step, provided that start <= stop and step > 0.
It's not clear to me right now whether there may also be problems with 
negative steps, and with cases where start < stop, etc.

I think this is serious enough to be considered a release blocker for 3.1;  
I'm working on a patch, and will post it later today.

----------
assignee:  -> marketdickinson
nosy: +rhettinger
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 16:32:45 2009
From: report at bugs.python.org (Alexey Akimov)
Date: Wed, 24 Jun 2009 14:32:45 +0000
Subject: [issue6337] multiprocessing module: Double close of sys.stdin - ID:
	2811568
In-Reply-To: <1245853965.54.0.75551607338.issue6337@psf.upfronthosting.co.za>
Message-ID: <1245853965.54.0.75551607338.issue6337@psf.upfronthosting.co.za>


New submission from Alexey Akimov <subdir at gmail.com>:

Double close of FD 0 when child process spawns its own child process.
Bug causes wrong file descriptors to be closed.
Bug affects only posix system.

How to reproduce:

>>> import multiprocessing as mp
>>> def child(q):
... print 'current process:', mp.current_process().name
... q.put(1)
... q.get()
... p = mp.Process(None, child, args=(mp.Queue(),))
... p.start()
...
>>> q = mp.Queue()
>>> child(q)
current process: MainProcess
current process: Process-1
current process: Process-1:1
Process Process-1:1:
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/multiprocessing/process.py", line
236, in _bootstrap
self.run()
File "/usr/lib/python2.5/site-packages/multiprocessing/process.py", line
93, in run
self._target(*self._args, **self._kwargs)
File "<stdin>", line 4, in child
File "/usr/lib/python2.5/site-packages/multiprocessing/queues.py", line
91, in get
res = self._recv()
IOError: [Errno 9] Bad file descriptor

----------
components: Extension Modules, Library (Lib)
files: multiprocessing.patch
keywords: patch
messages: 89666
nosy: subdir
severity: normal
status: open
title: multiprocessing module: Double close of sys.stdin - ID: 2811568
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14354/multiprocessing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6337>
_______________________________________

From report at bugs.python.org  Wed Jun 24 16:47:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Jun 2009 14:47:09 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245854829.19.0.932246124342.issue6334@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for py3k.

There are also a whole bunch of tests that are commented
out in BuiltinTest.test_range in Lib/test/test_builtin.py.
Some of those tests fail with the current py3k;  with this
patch applied, they all pass except the one involving 'badzero'.

----------
keywords: +patch
Added file: http://bugs.python.org/file14355/issue6334.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 17:11:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Jun 2009 15:11:37 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245856297.46.0.0567986487848.issue6334@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 18:38:58 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Jun 2009 16:38:58 +0000
Subject: [issue6327] [mimetext] long lines get cut with exclamation mark and
	newline
In-Reply-To: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>
Message-ID: <1245861538.65.0.0386790891382.issue6327@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Are you referring to the email.mime.text.MIMEText class (or
email.MIMEText.MIMEText)?

How did you use it? A basic test (print MIMEText('long'*500)) did not
show any line break.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6327>
_______________________________________

From report at bugs.python.org  Wed Jun 24 20:21:06 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Jun 2009 18:21:06 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245867666.93.0.432594269118.issue6334@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The patch looks good. Please apply.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 20:37:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Jun 2009 18:37:52 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245868672.07.0.859026378779.issue6334@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied to py3k in r73547.  Will backport to 3.0.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 20:56:06 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 24 Jun 2009 18:56:06 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245792961.5.0.460725375108.issue6331@psf.upfronthosting.co.za>
Message-ID: <4A4276BA.2070702@livinglogic.de>


Walter D?rwald <walter at livinglogic.de> added the comment:

Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> I think the patch is incorrect: the default value for the script
> property ought to be Unknown, not Common (despite UCD.html saying the
> contrary; see UTR#24 and Scripts.txt).

Fixed.

> I'm puzzled why you use a hard-coded list of script names. The set of
> scripts will certainly change across Unicode versions, and I think it
> would be better to learn the script names from Scripts.txt.

I hardcoded the list, because I saw no easy way to get the indexes
consistent across both versions of the database.

> Out of curiosity: how does the addition of the script property affect
> the number of distinct database records, and the total size of the database?

I'm not exactly sure how to measure this, but the length of
_PyUnicode_Database_Records goes from 229 entries to 690 entries.

If it's any help I can post the output of makeunicodedata.py.

> I think a common application would be lower-cases script names, for more
> efficient comparison; UCD has also changed the spelling of the script
> names over time (from being all-capital before). So I propose that
> a) two functions are provided: one with the original script names, and
> one with the lower-case script names

It this really neccessary, if we only have one version of the database?

> b) keep cached versions of interned script name strings in separate
> arrays, to avoid PyString_FromString every time.

Implemented.

> I'm doubtful that script names need to be provided for old database
> versions, so I would be happy to not record the script for old versions,
> and raise an exception if somebody tries to get the script for an old
> database version - surely applications of the old database records won't
> be accessing the script property, anyway.

OK, I've removed the script_changes info for the old database. (And with
this change the list of script names is no longer hardcoded).

Here's a new version of the patch (unicode-script-2.diff).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Wed Jun 24 20:56:52 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 24 Jun 2009 18:56:52 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1245869812.88.0.264640450618.issue6331@psf.upfronthosting.co.za>


Changes by Walter D?rwald <walter at livinglogic.de>:


Added file: http://bugs.python.org/file14356/unicode-script-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Wed Jun 24 20:57:01 2009
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Jun 2009 18:57:01 +0000
Subject: [issue6315] locale._build_localename(locale.getdefaultlocale())
	returns 'C.mac-roman'
In-Reply-To: <1245485035.23.0.886110297482.issue6315@psf.upfronthosting.co.za>
Message-ID: <1245869821.59.0.697829647424.issue6315@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This was probably fixed by the checkins for Issue6202.

$ python3.1
Python 3.1rc1+ (py3k, Jun  8 2009, 22:53:59) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale._build_localename(locale.getdefaultlocale())
'en_US.UTF8'
>>> 
$ python3.0
Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale._build_localename(locale.getdefaultlocale())
'C.mac-roman'
>>>

----------
nosy: +nad, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6315>
_______________________________________

From report at bugs.python.org  Wed Jun 24 21:10:19 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 24 Jun 2009 19:10:19 +0000
Subject: [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <4A427A18.3030004@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Don't understand you still don't support it.

Primarily because the patches that have been contributed don't work
well. We see no point in adding patches that don't work, and prefer
to add only patches that actually do work.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6335>
_______________________________________

From report at bugs.python.org  Wed Jun 24 21:24:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Jun 2009 19:24:54 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245871494.25.0.348653887228.issue6334@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Backported to release30-maint branch in r73549.

Thanks for catching this, Markus!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Wed Jun 24 21:31:09 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 24 Jun 2009 19:31:09 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <4A4276BA.2070702@livinglogic.de>
Message-ID: <4A427EFA.8010009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> I'm puzzled why you use a hard-coded list of script names. The set of
>> scripts will certainly change across Unicode versions, and I think it
>> would be better to learn the script names from Scripts.txt.
> 
> I hardcoded the list, because I saw no easy way to get the indexes
> consistent across both versions of the database.

Couldn't you have a global cache, something like

scripts = ['Unknown']
def findscript(script):
  try:
    return scripts.index(script)
  except ValueError:
    scripts.append(script)
    return len(scripts)-1

>> Out of curiosity: how does the addition of the script property affect
>> the number of distinct database records, and the total size of the database?
> 
> I'm not exactly sure how to measure this, but the length of
> _PyUnicode_Database_Records goes from 229 entries to 690 entries.

I think this needs to be fixed, then - we need to study why there are
so many new records (e.g. what script contributes most new records),
and then look for alternatives.

One alternative could be to create a separate Trie for scripts.

I'd also be curious if we can increase the homogeneity of scripts
(i.e. produce longer runs of equal scripts) if we declare that
unassigned code points have the script that corresponds to the block
(i.e. the script that surrounding characters have), and then only
change it to "Unknown" at lookup time if it's unassigned.

> If it's any help I can post the output of makeunicodedata.py.

I'd be interested in "size unicodedata.so", and how it changes.
Perhaps the actual size increase isn't that bad.

>> a) two functions are provided: one with the original script names, and
>> one with the lower-case script names
> 
> It this really neccessary, if we only have one version of the database?

I don't know what this will be used for, but one application is
certainly regular expressions. So we need an efficient test whether
the character is in the expected script or not. It would be bad if
such a test would have to do a .lower() on each lookup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Wed Jun 24 21:42:56 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Jun 2009 19:42:56 +0000
Subject: [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <1245872576.33.0.87201046152.issue6335@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

quote : "Primarily because the patches that have been contributed don't
work well. " :)

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6335>
_______________________________________

From report at bugs.python.org  Wed Jun 24 22:03:31 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Jun 2009 20:03:31 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245873811.17.0.319600445995.issue6296@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Antoine, you may mix container with compression. tar as file container
is suitable for unix like systems. other container like zip-container is
not well designed for unix-like file systems.

I disagree with request. Package distribution is platform dependent.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 24 22:21:49 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 24 Jun 2009 20:21:49 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245874909.95.0.636815593826.issue6296@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Antoine, when you say zip has "better support everywhere", what do you
mean?  I don't want to put words in your mouth, but what I think of is
that users maybe want to pack or unpack distributions with separate
tools instead of with the Python tools.  Is that it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 24 22:24:44 2009
From: report at bugs.python.org (Michael Foord)
Date: Wed, 24 Jun 2009 20:24:44 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245875084.5.0.778111929985.issue6296@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Yup, standard install procedure is (and will probably remain for a
while) - unpack and run python setup.py install

Users should be able to unpack on the most common platforms Python
supports without needing additional tools. All major platforms have
native zip support which isn't true of other formats.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 24 22:28:14 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Jun 2009 20:28:14 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245875294.16.0.411455048484.issue6296@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I do not believe it is true that zip is supported by all platforms out
of the box.  As far as I know Gentoo, for example, does not install
unzip by default.  For that matter, before windows XP one had to
download a utility to unzip files on windows (and that utility handles
tar files just fine).  Since there are still a few pre-XP windows boxes
out there, it is not even true to say that all Windows machines handle
zip out of the box.

Personally I would very much dislike it if python source distributions
were zipfiles by default.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Wed Jun 24 23:08:29 2009
From: report at bugs.python.org (Eric Huss)
Date: Wed, 24 Jun 2009 21:08:29 +0000
Subject: [issue6338] Error message displayed on stderr when no C compiler is
	present with ctypes
In-Reply-To: <1245877709.89.0.124582375066.issue6338@psf.upfronthosting.co.za>
Message-ID: <1245877709.89.0.124582375066.issue6338@psf.upfronthosting.co.za>


New submission from Eric Huss <eric at huss.org>:

Importing the "uuid" module on a posix system (FreeBSD in my case) that
does not have a C compiler causes "cc: not found" to be sent to stderr.
 This is because it imports ctypes and calls ctypes.util.find_library
which attempts to determine if the C compiler is called "gcc" or "cc"
using a shell command.

----------
assignee: theller
components: ctypes
files: ctypes_util.patch
keywords: patch
messages: 89681
nosy: ehuss, theller
severity: normal
status: open
title: Error message displayed on stderr when no C compiler is present with ctypes
versions: Python 2.6
Added file: http://bugs.python.org/file14357/ctypes_util.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6338>
_______________________________________

From report at bugs.python.org  Wed Jun 24 23:12:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Jun 2009 21:12:51 +0000
Subject: [issue6337] multiprocessing module: Double close of sys.stdin - ID:
	2811568
In-Reply-To: <1245853965.54.0.75551607338.issue6337@psf.upfronthosting.co.za>
Message-ID: <1245877971.34.0.978503164151.issue6337@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6337>
_______________________________________

From report at bugs.python.org  Wed Jun 24 23:24:31 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 21:24:31 +0000
Subject: [issue6339] Some functional errors in turtle.py documentation
	(missing links)
In-Reply-To: <1245878670.95.0.838166352982.issue6339@psf.upfronthosting.co.za>
Message-ID: <1245878670.95.0.838166352982.issue6339@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

In the Python3.1rc2 documentation for turtle.py there are the following
functional errors:

In the overview section the (newly added) entries for the functions/methods 

shearfactor
get_shapepoly
onkeypress
numinput

do not have links to the corresponding text sections. These exist but
also have errors, sometimes the leading 'turtle.' is missing, sometimes
the parameter self erroneously appears in the text.

I'm not very educated in restructured Text Syntax respectively the
documentatin system. Nevertheless I inspected the source and I assume
the following causes for this:

In the first lines of the sections for shearfactor and numinput there
are superfluous self, which should be deleted.

In the sections for get_shapepoly, onkeypress and numinput there are
perturbing colons at the end of the first lines, which perhaps should be
deleted.

As I'm not sure if this suggestions are right and/or comlete and I do
not have any means to test them, I cannot submit a patch. 

Please could some docs-guru check my suggestions (and possibly repair
the defects) It would be fine if this errors wouldn't appear in 3.1

Regards,
Gregor

----------
assignee: georg.brandl
components: Documentation
messages: 89682
nosy: georg.brandl, gregorlingl, loewis
severity: normal
status: open
title: Some functional errors in turtle.py documentation (missing links)
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6339>
_______________________________________

From report at bugs.python.org  Wed Jun 24 23:49:42 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 24 Jun 2009 21:49:42 +0000
Subject: [issue6337] multiprocessing module: Double close of sys.stdin - ID:
	2811568
In-Reply-To: <1245853965.54.0.75551607338.issue6337@psf.upfronthosting.co.za>
Message-ID: <1245880182.12.0.421928779722.issue6337@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Dupe of issue 5313

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6337>
_______________________________________

From report at bugs.python.org  Wed Jun 24 23:51:26 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Wed, 24 Jun 2009 21:51:26 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245880286.37.0.276242985199.issue6233@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

That's backwards, unless I'm missing something here: charrefs represent 
Unicode characters, not UTF-8 byte values.  The character "LATIN SMALL 
LETTER A WITH TILDE" with the character value 227 should be represented as 
"&#227;" if serialized to an encoding that doesn't support non-ASCII 
characters.

And there's no need to use RE:s to filter things under 3.X; those parts of 
ET 1.2 are there for pre-2.0 compatibility.

Did you try running the tests with the escape function I posted?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Wed Jun 24 23:53:38 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Wed, 24 Jun 2009 21:53:38 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
	well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1245880418.96.0.12574761276.issue5166@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

For ET, that's very much on purpose.  Validating data provided by every 
single application would kill performance for all of them, even if only a 
small minority would ever try to serialize data that cannot be represented 
in XML.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Thu Jun 25 00:45:20 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 22:45:20 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

I've submitted a replacement, which is functionally 100% equivalent,
but cleaner code, more appropriate for a demo:

four or five superfluous lines, which were remains from some previous
version are deleted now; names and comments are now in English.

Regards,
Gregor

----------
components: Demos and Tools
files: tdemo_chaos.py
messages: 89686
nosy: georg.brandl, gregorlingl, loewis
severity: normal
status: open
title: replace tdemo_chaos.py
versions: Python 3.1
Added file: http://bugs.python.org/file14358/tdemo_chaos.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 00:51:06 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 22:51:06 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245883866.06.0.551367352931.issue6340@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14358/tdemo_chaos.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 00:52:43 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 22:52:43 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245883963.81.0.794156394887.issue6340@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Added file: http://bugs.python.org/file14359/tdemo_chaos.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 00:54:15 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 22:54:15 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245884055.75.0.944362675461.issue6340@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14359/tdemo_chaos.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 00:54:29 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Jun 2009 22:54:29 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245884069.34.0.974478286778.issue6340@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Added file: http://bugs.python.org/file14360/tdemo_chaos.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 01:06:39 2009
From: report at bugs.python.org (nestor)
Date: Wed, 24 Jun 2009 23:06:39 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1245884799.16.0.275523063504.issue6236@psf.upfronthosting.co.za>


nestor <nestornissen at gmail.com> added the comment:

That fails consistently:
Python 2.6.2 (r262:71600, Jun  4 2009, 16:07:26) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> r,w=os.pipe()
>>> os.lseek(r,0,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 29] Illegal seek
>>>
Python 3.0.1 (r301:69556, Jun  4 2009, 16:07:22) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> r,w=os.pipe()
>>> os.lseek(r,0,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 29] Illegal seek
>>>
Python 3.1rc2 (r31rc2:73411, Jun 15 2009, 10:56:49) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> r,w=os.pipe()
>>> os.lseek(r,0,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 29] Illegal seek
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Thu Jun 25 01:40:17 2009
From: report at bugs.python.org (Tanaka Akira)
Date: Wed, 24 Jun 2009 23:40:17 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1245886817.47.0.600954363755.issue5753@psf.upfronthosting.co.za>


Tanaka Akira <akr at fsij.org> added the comment:

src/if_python.c in vim-7.2 has a comment:
/* Set sys.argv[] to avoid a crash in warn(). */

I think the crash is follows.

% python
Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn("foo")
__main__:1: UserWarning: foo
>>> import sys
>>> sys.argv
['']
>>> sys.argv = []
>>> sys.argv
[]
>>> warnings.warn("foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/warnings.py", line 54, in warn
    filename = sys.argv[0]
IndexError: list index out of range
>>>

----------
nosy: +akr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Thu Jun 25 01:50:47 2009
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 24 Jun 2009 23:50:47 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1245887447.93.0.450195889669.issue1424152@psf.upfronthosting.co.za>


Craig McQueen <ces-pub at mcqueen.id.au> added the comment:

@gregory.p.smith:
> This change is not suitable for back porting as it arguably adds a new 
feature.

Speaking as a Mercurial user who can't use Mercurial at work through a
proxy firewall... I beg you to consider that fixing this is not really
adding a "new feature" but fixing a broken implementation requirement.
Surely proxy support is not optional for any serious HTTP library.

----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Jun 25 01:56:05 2009
From: report at bugs.python.org (Jerry Chen)
Date: Wed, 24 Jun 2009 23:56:05 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245887765.93.0.715142441657.issue6233@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Thanks for the explanation -- looks like I was way off base on that one.

I took a look at the code you provided but it doesn't work as a drop-in
replacement for _escape_cdata, since that function returns a string
rather than bytes.

However taking your code, calling it _encode_cdata and then refactoring
all calls _encode(_escape_cdata(x), encoding) to _encode_cdata(x,
encoding) seems to do the trick and passes the tests.

Specific example:

- file.write(_encode(_escape_cdata(node.text), encoding))
+ file.write(_encode_cdata(node.text, encoding))

One minor modification is to return the string as is if encoding=None,
just like _encode:

def _encode_cdata(text, encoding):
    # escape character data
    try:
        text = text.replace("&", "&amp;")
        text = text.replace("<", "&lt;")
        text = text.replace(">", "&gt;")
        if encoding:
            return text.encode(encoding, "xmlcharrefreplace")
        else:
            return text
    except (TypeError, AttributeError):
        _raise_serialization_error(text)

----------
Added file: http://bugs.python.org/file14361/issue6233-encode_cdata.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Thu Jun 25 03:03:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Jun 2009 01:03:01 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245873811.17.0.319600445995.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245891932.5596.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> other container like zip-container is
> not well designed for unix-like file systems.

Well, please be more specific as to why zip it affects "sdist" in
particular. Never before have I heard anyone claim that zip was
ill-suited for source tarballs.

> I disagree with request. Package distribution is platform dependent.

It is not package distribution. It is package generation. If you use the
same command ("sdist"), it would be nicer if it produced the same result
regardless of whether you are under Unix or Windows.

(platform-dependent packages, by the way, are rpm, deb, msi, etc. ;-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Thu Jun 25 03:04:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Jun 2009 01:04:06 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245875294.16.0.411455048484.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245891998.5596.5.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Personally I would very much dislike it if python source distributions
> were zipfiles by default.

Why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Thu Jun 25 04:22:41 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 02:22:41 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245896561.07.0.195809428243.issue6296@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because I'm a unix weenie, and zip files feel like an intrusion from the
Windows world. I expect source tarballs to be, well, tarballs.  I don't
say zip shouldn't be the default, I just noted that I personally would
find that distasteful. ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Thu Jun 25 06:31:27 2009
From: report at bugs.python.org (Senthil)
Date: Thu, 25 Jun 2009 04:31:27 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <20090625043105.GA4194@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

> Craig McQueen comment:
>
> Speaking as a Mercurial user who can't use Mercurial at work through a
> proxy firewall... I beg you to consider that fixing this is not really

We might have to take this up at python-dev. I shall do that
to get other developers opinion on backporting this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Jun 25 08:24:31 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 06:24:31 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1245911071.59.0.929467957586.issue6243@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Verified Bus Error with code snippet in python 2.7 and 3.1 trunks
r73552, e.g.:

(gdb) where
#0  0x925f6f30 in strlen ()
#1  0x0005ea10 in PyString_FromString (str=0x0) at
Objects/stringobject.c:125
#2  0x003c1710 in PyCursesWindow_GetKey (self=0x3320f0, args=0x300030)
at python27/Modules/_cursesmodule.c:891

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Thu Jun 25 08:26:10 2009
From: report at bugs.python.org (Ned Deily)
Date: Thu, 25 Jun 2009 06:26:10 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1245911170.12.0.223185315672.issue4388@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu Jun 25 08:33:39 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 06:33:39 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1245911619.83.0.829188173117.issue6243@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Trundle's original patch against r73301 still works currently, but I
made a minor tweak and rediff'd.

The attached patch is against 2.7 - r73552.

I added knp usage to the NetBSD #ifdef region so a) the compiler doesn't
complain about unused 'knp' on NetBSD and b) for parallelism.  The
alternative solution was to put the declaration of *knp within the
conditional block but that doesn't seem to adhere to the rest of the
module code.

----------
Added file: http://bugs.python.org/file14362/issue6243-py2.7-cursesmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Thu Jun 25 08:36:30 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 06:36:30 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1245911790.67.0.464637730531.issue6243@psf.upfronthosting.co.za>


Changes by Jerry Chen <jerry at 3rdengine.com>:


Removed file: http://bugs.python.org/file14362/issue6243-py2.7-cursesmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Thu Jun 25 08:38:44 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 06:38:44 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1245911924.52.0.55625836794.issue6243@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Sorry -- bad patch, uploading correct one.

----------
Added file: http://bugs.python.org/file14363/issue6243-py2.7-cursesmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Thu Jun 25 08:41:18 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 06:41:18 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1245912078.1.0.792340973861.issue6243@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Another patch for the same code change but against the 3.1 branch.

----------
versions: +Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14364/issue6243-py3.1-cursesmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Thu Jun 25 09:33:34 2009
From: report at bugs.python.org (Denis S. Otkidach)
Date: Thu, 25 Jun 2009 07:33:34 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
	well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1245915214.98.0.668534063514.issue5166@psf.upfronthosting.co.za>


Denis S. Otkidach <denis.otkidach at gmail.com> added the comment:

Every blog engine I've even seen so far pass through comments from
untrusted users to RSS/Atom feeds without proper validation causing
broken XML in feeds. Sure, this is a bug in web applications, but DOM
manipulation packages should prevent from creation broken XML to help
detecting errors earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5166>
_______________________________________

From report at bugs.python.org  Thu Jun 25 09:46:13 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 25 Jun 2009 07:46:13 +0000
Subject: [issue6296] Native (and default) tarfile support for setup.py
	sdist	in distutils on Windows
In-Reply-To: <1245245630.18.0.224607523943.issue6296@psf.upfronthosting.co.za>
Message-ID: <1245915973.75.0.847334501316.issue6296@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> Because I'm a unix weenie, and zip files feel like an intrusion from the
> Windows world. I expect source tarballs to be, well, tarballs.  I don't
> say zip shouldn't be the default, I just noted that I personally would
> find that distasteful. ;)

Agreed :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6296>
_______________________________________

From report at bugs.python.org  Thu Jun 25 11:14:19 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 25 Jun 2009 09:14:19 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1245921259.24.0.150915573848.issue6331@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

I was comparing apples and oranges: The 229 entries for the trunk where
for an UCS2 build (the patched version was UCS4), with UCS4 there are
317 entries for the trunk.

size unicodedata.o gives:

__TEXT  __DATA  __OBJC  others  dec     hex
13622   587057  0       23811   624490  9876a

for trunk

and

__TEXT  __DATA  __OBJC  others  dec     hex
17769   588817  0       24454   631040  9a100

for the patched version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Thu Jun 25 13:31:16 2009
From: report at bugs.python.org (Markus F.X.J. Oberhumer)
Date: Thu, 25 Jun 2009 11:31:16 +0000
Subject: [issue6334] 3.0/3.1: Bad bug in range() computation (or possible
	Integer problem)
In-Reply-To: <1245840703.27.0.965976477326.issue6334@psf.upfronthosting.co.za>
Message-ID: <1245929476.99.0.120926147838.issue6334@psf.upfronthosting.co.za>


Markus F.X.J. Oberhumer <markus at oberhumer.com> added the comment:

Many thanks for your quick fix! ~Markus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6334>
_______________________________________

From report at bugs.python.org  Thu Jun 25 14:27:18 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 12:27:18 +0000
Subject: [issue5230] pydoc reports misleading failure if target module raises
	an ImportError
In-Reply-To: <1234473388.92.0.353382315269.issue5230@psf.upfronthosting.co.za>
Message-ID: <1245932838.29.0.8852403751.issue5230@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied to 2.7 in r73529 and 2.6 in r73530.  Leaving ticket open until I
can apply it to 3.1 and 3.2.

Thanks for your help, Lucas.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
versions:  -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5230>
_______________________________________

From report at bugs.python.org  Thu Jun 25 14:56:45 2009
From: report at bugs.python.org (Georgios Moralis)
Date: Thu, 25 Jun 2009 12:56:45 +0000
Subject: [issue6341] io.path.ismount gives "local variable 'p' referenced
	before assignment" error on Windows versions (ntpath.py)
In-Reply-To: <1245934605.11.0.579466844028.issue6341@psf.upfronthosting.co.za>
Message-ID: <1245934605.11.0.579466844028.issue6341@psf.upfronthosting.co.za>


New submission from Georgios Moralis <g.mwralhs at gmail.com>:

It returns with the following error:
UnboundLocalError: local variable 'p' referenced before assignment

Example causing this:


--- CODE FOLLOWS ---

import os

def show_cwd_list():
    alpha = os.listdir(os.getcwd())
    for dirnm in alpha[:]:
        if os.path.isdir(os.getcwd() + os.sep + dirnm):
            print("d ", dirnm)
        elif os.path.ismount(os.getcwd() + os.sep + dirnm):
            print("m ", dirnm)
        elif os.path.isfile(os.getcwd() + os.sep + dirnm):
            print("f ", dirnm)
        elif os.path.islink(os.getcwd() + os.sep + dirnm):
            print("l ", dirnm)
        elif os.path.isabs(os.getcwd() + os.sep + dirnm):
            print("a ", dirnm)
    return alpha

get_dirs()

--- END OF CODE ---

The definition of ismount from the ntpath.py:


--- CODE FOLLOWS (NTPATH.PY) ---
def ismount(path):
    """Test whether a path is a mount point (defined as root of drive)"""
    unc, rest = splitunc(path)
    seps = _get_bothseps(p)
    if unc:
        return rest in p[:0] + seps
    p = splitdrive(path)[1]
    return len(p) == 1 and p[0] in seps

--- END OF CODE ---

As it seems, variable 'p' is used before it is initialized (_get_bothseps)

----------
components: Windows
messages: 89704
nosy: g.moralis
severity: normal
status: open
title: io.path.ismount  gives "local variable 'p' referenced before assignment" error on Windows versions (ntpath.py)
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6341>
_______________________________________

From report at bugs.python.org  Thu Jun 25 14:56:46 2009
From: report at bugs.python.org (Georgios Moralis)
Date: Thu, 25 Jun 2009 12:56:46 +0000
Subject: [issue6342] io.path.ismount gives "local variable 'p' referenced
	before assignment" error on Windows versions (ntpath.py)
In-Reply-To: <1245934606.89.0.398101008179.issue6342@psf.upfronthosting.co.za>
Message-ID: <1245934606.89.0.398101008179.issue6342@psf.upfronthosting.co.za>


New submission from Georgios Moralis <g.mwralhs at gmail.com>:

It returns with the following error:
UnboundLocalError: local variable 'p' referenced before assignment

Example causing this:


--- CODE FOLLOWS ---

import os

def show_cwd_list():
    alpha = os.listdir(os.getcwd())
    for dirnm in alpha[:]:
        if os.path.isdir(os.getcwd() + os.sep + dirnm):
            print("d ", dirnm)
        elif os.path.ismount(os.getcwd() + os.sep + dirnm):
            print("m ", dirnm)
        elif os.path.isfile(os.getcwd() + os.sep + dirnm):
            print("f ", dirnm)
        elif os.path.islink(os.getcwd() + os.sep + dirnm):
            print("l ", dirnm)
        elif os.path.isabs(os.getcwd() + os.sep + dirnm):
            print("a ", dirnm)
    return alpha

get_dirs()

--- END OF CODE ---

The definition of ismount from the ntpath.py:


--- CODE FOLLOWS (NTPATH.PY) ---
def ismount(path):
    """Test whether a path is a mount point (defined as root of drive)"""
    unc, rest = splitunc(path)
    seps = _get_bothseps(p)
    if unc:
        return rest in p[:0] + seps
    p = splitdrive(path)[1]
    return len(p) == 1 and p[0] in seps

--- END OF CODE ---

As it seems, variable 'p' is used before it is initialized (_get_bothseps)

----------
components: Windows
messages: 89705
nosy: g.moralis
severity: normal
status: open
title: io.path.ismount  gives "local variable 'p' referenced before assignment" error on Windows versions (ntpath.py)
type: compile error
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6342>
_______________________________________

From report at bugs.python.org  Thu Jun 25 15:26:41 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 13:26:41 +0000
Subject: [issue6342] io.path.ismount gives "local variable 'p' referenced
	before assignment" error on Windows versions (ntpath.py)
In-Reply-To: <1245934606.89.0.398101008179.issue6342@psf.upfronthosting.co.za>
Message-ID: <1245936401.93.0.169993574917.issue6342@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Duplicate of http://bugs.python.org/issue5595

Fixed in r70676

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6342>
_______________________________________

From report at bugs.python.org  Thu Jun 25 15:27:58 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 13:27:58 +0000
Subject: [issue6341] io.path.ismount gives "local variable 'p' referenced
	before assignment" error on Windows versions (ntpath.py)
In-Reply-To: <1245934605.11.0.579466844028.issue6341@psf.upfronthosting.co.za>
Message-ID: <1245936478.62.0.760984163533.issue6341@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Duplicate of http://bugs.python.org/issue5595

Fixed in r70676

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6341>
_______________________________________

From report at bugs.python.org  Thu Jun 25 15:30:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 13:30:09 +0000
Subject: [issue6342] io.path.ismount gives "local variable 'p' referenced
	before assignment" error on Windows versions (ntpath.py)
In-Reply-To: <1245934606.89.0.398101008179.issue6342@psf.upfronthosting.co.za>
Message-ID: <1245936609.83.0.909996230644.issue6342@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +Wrong dump of floats
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6342>
_______________________________________

From report at bugs.python.org  Thu Jun 25 15:31:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 13:31:02 +0000
Subject: [issue6341] io.path.ismount gives "local variable 'p' referenced
	before assignment" error on Windows versions (ntpath.py)
In-Reply-To: <1245934605.11.0.579466844028.issue6341@psf.upfronthosting.co.za>
Message-ID: <1245936662.2.0.6629524844.issue6341@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6341>
_______________________________________

From report at bugs.python.org  Thu Jun 25 15:33:22 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Jun 2009 13:33:22 +0000
Subject: [issue6342] io.path.ismount gives "local variable 'p' referenced
	before assignment" error on Windows versions (ntpath.py)
In-Reply-To: <1245934606.89.0.398101008179.issue6342@psf.upfronthosting.co.za>
Message-ID: <1245936802.52.0.128247597176.issue6342@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
dependencies: +os.path.ismount (ntpath) gives UnboundLocalError for any input -Wrong dump of floats

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6342>
_______________________________________

From report at bugs.python.org  Thu Jun 25 15:38:37 2009
From: report at bugs.python.org (Jerry Chen)
Date: Thu, 25 Jun 2009 13:38:37 +0000
Subject: [issue6315] locale._build_localename(locale.getdefaultlocale())
	returns 'C.mac-roman'
In-Reply-To: <1245485035.23.0.886110297482.issue6315@psf.upfronthosting.co.za>
Message-ID: <1245937117.75.0.0455170362046.issue6315@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Also seeing this was resolved by Issue6202.


Python 3.1rc2+ (py3k:73552, Jun 24 2009, 23:11:23) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale._build_localename(locale.getdefaultlocale())
'en_US.UTF8'


Python 3.0.1+ (release30-maint:73553, Jun 25 2009, 08:35:35) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale._build_localename(locale.getdefaultlocale())
'C.mac-roman'

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6315>
_______________________________________

From report at bugs.python.org  Thu Jun 25 15:48:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 13:48:42 +0000
Subject: [issue6315] locale._build_localename(locale.getdefaultlocale())
	returns 'C.mac-roman'
In-Reply-To: <1245485035.23.0.886110297482.issue6315@psf.upfronthosting.co.za>
Message-ID: <1245937722.39.0.604215837041.issue6315@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6315>
_______________________________________

From report at bugs.python.org  Thu Jun 25 16:21:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 14:21:24 +0000
Subject: [issue6339] Some functional errors in turtle.py documentation
	(missing links)
In-Reply-To: <1245878670.95.0.838166352982.issue6339@psf.upfronthosting.co.za>
Message-ID: <1245939684.23.0.574685536952.issue6339@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: georg.brandl -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6339>
_______________________________________

From report at bugs.python.org  Thu Jun 25 16:28:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 14:28:02 +0000
Subject: [issue6339] Some functional errors in turtle.py documentation
	(missing links)
In-Reply-To: <1245878670.95.0.838166352982.issue6339@psf.upfronthosting.co.za>
Message-ID: <1245940082.28.0.805154105637.issue6339@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r73555.  Thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6339>
_______________________________________

From report at bugs.python.org  Thu Jun 25 17:29:22 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 15:29:22 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245943762.66.0.21095752815.issue6340@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks good to me (runs like the old one under both 2.7 and 3.1).  Do you
want to do the commit or would you like me to?  I think a demo program
is in the same class as a doc fix, so I don't see any problem with
committing it to 3.1 right away.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> accepted
stage:  -> commit review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 18:59:45 2009
From: report at bugs.python.org (Dale Nagata)
Date: Thu, 25 Jun 2009 16:59:45 +0000
Subject: [issue6343] TimedRotatingFileHandler permission denied rename failure
	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>


New submission from Dale Nagata <nagata at telus.net>:

Traceback (most recent call last):
  File "C:\python24\lib\logging\handlers.py", line 74, in emit
    self.doRollover()
  File "C:\python24\lib\logging\handlers.py", line 271, in doRollover
    os.rename(self.baseFilename, dfn)
OSError: [Errno 13] Permission denied

originally hit on W2K3 but could not see evidence as it was running as a
service with stderr not going anywhere, but deeply suspicious since it
failed right at midnight each time. 

whittled down to bare essentials, repro'd on XP running in console
window, test case will fail in 2 min when rollover is attempted

logging set up as follows:

def initlog():
    #h = logging.handlers.TimedRotatingFileHandler( LOGFILEPATH,
'MIDNIGHT', 1, 7 )
    h = logging.handlers.TimedRotatingFileHandler( LOGFILEPATH, 'M', 2, 7 )
    h.setLevel( logging.DEBUG )
    f = logging.Formatter( '%(asctime)s %(levelname)s %(message)s',
'%Y-%m-%d %H:%M:%S' )
    h.setFormatter( f )
    logging.root.addHandler( h )
    logging.root.setLevel( logging.DEBUG )

searched issue tracker for TimedRotatingFileHandler, no hits

----------
components: Library (Lib)
files: testlog.py
messages: 89711
nosy: dnagata
severity: normal
status: open
title: TimedRotatingFileHandler permission denied rename failure on Windows
type: crash
versions: Python 2.4
Added file: http://bugs.python.org/file14365/testlog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6343>
_______________________________________

From report at bugs.python.org  Thu Jun 25 19:02:33 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 25 Jun 2009 17:02:33 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245949353.06.0.918486942015.issue6340@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

So do I.

I'd like to ask you to do the commit.

And I'd also like to suggest that - in the first three comment-lines of
the script - you replace

Datei:                by      File:
Autor:                by      Author:
Datum: 24. 6. 2009    by      Date: 2009-06-24

Then (hopefully) we will never need to touch it any more ;-)

Thanks in advance
Gregor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 19:09:11 2009
From: report at bugs.python.org (Dale Nagata)
Date: Thu, 25 Jun 2009 17:09:11 +0000
Subject: [issue6343] TimedRotatingFileHandler permission denied rename failure
	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1245949751.23.0.759081526873.issue6343@psf.upfronthosting.co.za>


Changes by Dale Nagata <nagata at telus.net>:


Removed file: http://bugs.python.org/file14365/testlog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6343>
_______________________________________

From report at bugs.python.org  Thu Jun 25 19:10:58 2009
From: report at bugs.python.org (Dale Nagata)
Date: Thu, 25 Jun 2009 17:10:58 +0000
Subject: [issue6343] TimedRotatingFileHandler permission denied rename failure
	on Windows
In-Reply-To: <1245949185.33.0.897995880567.issue6343@psf.upfronthosting.co.za>
Message-ID: <1245949858.34.0.180247252155.issue6343@psf.upfronthosting.co.za>


Changes by Dale Nagata <nagata at telus.net>:


Added file: http://bugs.python.org/file14366/testlog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6343>
_______________________________________

From report at bugs.python.org  Thu Jun 25 19:33:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Jun 2009 17:33:44 +0000
Subject: [issue6340] replace tdemo_chaos.py
In-Reply-To: <1245883520.56.0.469281631359.issue6340@psf.upfronthosting.co.za>
Message-ID: <1245951224.33.0.821640196936.issue6340@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Done in r73557 and r73558.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6340>
_______________________________________

From report at bugs.python.org  Thu Jun 25 23:22:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Jun 2009 21:22:29 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

mmap.read() crashes when passed a negative count:

    def test_read_negative(self):
        f = open(TESTFN, 'w+')
        f.write("ABCDE\0abcde")
        f.flush()

        mf = mmap.mmap(f.fileno(), 0)

        self.assertEqual(mf.read(2),  "AB")    # OK
        self.assertEqual(mf.read(-1), "CDE")   # ??
        self.assertEqual(mf.read(-1), "BCDE")  # ??
        self.assertEqual(mf.read(-1), "ABCDE") # ??
        mf.read(-1)                            # crash!!

I don't know what mf.read(-1) should do: raise a ValueError, return the empty 
string, or return everything from the current pos to len(mf)?

----------
components: Library (Lib)
messages: 89714
nosy: amaury.forgeotdarc, ocean-city
priority: high
severity: normal
status: open
title: mmap.read() crashes when passed a negative argument
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Thu Jun 25 23:26:52 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 25 Jun 2009 21:26:52 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245965212.16.0.285685479184.issue6233@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

effbot, do you have an opinion about the latest patch? It'd be nice to
not have to delay the release for this.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Fri Jun 26 00:37:44 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Jun 2009 22:37:44 +0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1245969464.38.0.101230484209.issue2016@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed in trunk with r73564.

I performed performance tests: differences with pybench were negligible 
(<1%), but a specially crafted case like:
   kw = dict(a=1, b=2, c=3)
   for x in xrange(self.rounds):
      f(**kw)
showed an improvement of 21%!

Will backport to various branches after 3.1 is out.

----------
assignee:  -> amaury.forgeotdarc
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
_______________________________________

From report at bugs.python.org  Fri Jun 26 03:00:41 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Jun 2009 01:00:41 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1245978041.38.0.30815646392.issue6344@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> I don't know what mf.read(-1) should do
I'm not sure neither.

I think the problem is that mmap uses size_t as length, but uses
Py_ssize_t for PyArg_ParseTuple. (PyArg_ParseTuple doesn't support
size_t) I think this discrepancy should be fixed.

If mmap should use size_t because it should cover all possible memory
region which size_t can represent but Py_ssize_t cannot, maybe should
PyArg_ParseTuple support size_t?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Fri Jun 26 03:12:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 26 Jun 2009 01:12:30 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245978750.2.0.0226173625779.issue6233@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I disagree with this report being classified as release-critical - it is
*not* a regression over 3.0 (i.e. 3.0 already behaved in the same way).
That it is a regression relative to 2.x should not make it
release-critical - we can still fix such regressions in 3.2.

In addition, there is an easy work-around for applications that run into
the problem - just use utf-8 as the output encoding always:

py> e = ET.XML(b"<?xml version='1.0'
encoding='iso-8859-1'?><body>t\xe3t</body>")
py> ET.tostring(e,encoding='utf-8')
b'<body>t\xc3\xa3t</body>'

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Fri Jun 26 04:20:30 2009
From: report at bugs.python.org (Mark Tolonen)
Date: Fri, 26 Jun 2009 02:20:30 +0000
Subject: [issue6345] extra characters displayed when writing to
	sys.stdout.buffer
In-Reply-To: <1245982830.09.0.978078619889.issue6345@psf.upfronthosting.co.za>
Message-ID: <1245982830.09.0.978078619889.issue6345@psf.upfronthosting.co.za>


New submission from Mark Tolonen <metolone at hotmail.com>:

According to Issue xxxx, sys.stdout.buffer is the binary stream 
underlying stdout.  I see the following behavior on 3.0.1 and 3.1rc2 
when writing to a console window:

Python 3.1rc2 (r31rc2:73414, Jun 13 2009, 16:43:15) [MSC v.1500 32 bit 
(Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 
sys.stdout.buffer.write('hello\u200bworld'.encode('cp437','replace'))
hello?world11

Notice the extra '11' at the end of the string.

----------
components: IO
messages: 89719
nosy: metolone
severity: normal
status: open
title: extra characters displayed when writing to sys.stdout.buffer
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6345>
_______________________________________

From report at bugs.python.org  Fri Jun 26 04:23:07 2009
From: report at bugs.python.org (Mark Tolonen)
Date: Fri, 26 Jun 2009 02:23:07 +0000
Subject: [issue6345] extra characters displayed when writing to
	sys.stdout.buffer
In-Reply-To: <1245982830.09.0.978078619889.issue6345@psf.upfronthosting.co.za>
Message-ID: <1245982987.36.0.828706163435.issue6345@psf.upfronthosting.co.za>


Mark Tolonen <metolone at hotmail.com> added the comment:

Sorry, msg.replace('Issue xxxx','Issue 4571').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6345>
_______________________________________

From report at bugs.python.org  Fri Jun 26 04:37:08 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Jun 2009 02:37:08 +0000
Subject: [issue6345] extra characters displayed when writing to
	sys.stdout.buffer
In-Reply-To: <1245982830.09.0.978078619889.issue6345@psf.upfronthosting.co.za>
Message-ID: <1245983828.29.0.839856748876.issue6345@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is because write() is returning the number of characters it wrote
and that is displayed at the prompt.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6345>
_______________________________________

From report at bugs.python.org  Fri Jun 26 05:30:58 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Jun 2009 03:30:58 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1245987058.01.0.920626322442.issue6233@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for Py3.1.1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Fri Jun 26 10:19:29 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 26 Jun 2009 08:19:29 +0000
Subject: [issue1202] zlib.crc32() and adler32() return value
In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za>
Message-ID: <1246004369.78.0.204601863084.issue1202@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fix for J. David's issue submitted to trunk r73565 and py3k r73566 just in 
time for the 3.1 release.

release30-maint r73567
release26-maint r73568

----------
status: open -> closed
versions: +Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1202>
_______________________________________

From report at bugs.python.org  Fri Jun 26 10:20:10 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 26 Jun 2009 08:20:10 +0000
Subject: [issue1202] zlib.crc32() and adler32() return value
In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za>
Message-ID: <1246004410.93.0.401821619518.issue1202@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1202>
_______________________________________

From report at bugs.python.org  Fri Jun 26 10:51:40 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Jun 2009 08:51:40 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1246006300.21.0.454162794194.issue6344@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, I would not care that much: you can never read more than
PY_SSIZE_T_MAX, because the mapped area and the string would not fit in
the addressable space of the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Fri Jun 26 12:56:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Jun 2009 10:56:28 +0000
Subject: [issue6304] Confusing error message when passing bytes to print with
	file pointing to a binary file
In-Reply-To: <1245293505.96.0.175038220478.issue6304@psf.upfronthosting.co.za>
Message-ID: <1246013788.2.0.143113245857.issue6304@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem here is not the bytes object: it is correctly coerced to a
string. 

The problem is the binary stream, which cannot accept strings.
We could maybe detect common errors and add a check at the beginning of
the print() function? something like
    if isinstance(file, (BufferedWriter, RawIOBase)):
        raise ValueError("file should be a text stream")

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6304>
_______________________________________

From report at bugs.python.org  Fri Jun 26 13:13:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Jun 2009 11:13:06 +0000
Subject: [issue6236] os.popen causes illegal seek on AIX in Python 3.1rc
In-Reply-To: <1244427618.5.0.797941537993.issue6236@psf.upfronthosting.co.za>
Message-ID: <1246014786.12.0.341919929897.issue6236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, then I don't know what happens...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6236>
_______________________________________

From report at bugs.python.org  Fri Jun 26 13:13:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Jun 2009 11:13:39 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1246014819.23.0.56904019074.issue6233@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: release blocker -> critical
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Fri Jun 26 13:59:55 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Fri, 26 Jun 2009 11:59:55 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1245743982.56.0.948186919165.issue6070@psf.upfronthosting.co.za>
Message-ID: <20090626115954.GC5701@phd.pp.ru>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

Sorry, found the bug in my process of testing. ./python uses /usr/lib/python26.so instead of ./python26.so. Setting LD_LIBRARY_PATH=. fixes the problem and the test passes. The patch is ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri Jun 26 16:21:20 2009
From: report at bugs.python.org (Jerry Chen)
Date: Fri, 26 Jun 2009 14:21:20 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1246026080.52.0.168464972509.issue6233@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Either way, it would be nice to get feedback so we can iterate on the
patch or close out this issue already :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6233>
_______________________________________

From report at bugs.python.org  Fri Jun 26 16:21:37 2009
From: report at bugs.python.org (Marco)
Date: Fri, 26 Jun 2009 14:21:37 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1246026097.57.0.118821202133.issue6070@psf.upfronthosting.co.za>


Marco <marcusbu at gmail.com> added the comment:

Thank you for your report :P

Otherwise I really didn't know how solve it, thank you :P

However, on *NIX-like systems it can work well; 
but can someone try it on Windows? Since I know that only NTFS (and
versions >= XP) supports permissions, if a user have a FATfs (or Win98,
95,..) I think it raises error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri Jun 26 17:27:11 2009
From: report at bugs.python.org (Tim Golden)
Date: Fri, 26 Jun 2009 15:27:11 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1246026097.57.0.118821202133.issue6070@psf.upfronthosting.co.za>
Message-ID: <4A44E8D0.8010807@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Making something executable on Windows has nothing to
do with file permissions. You can set them as much
as you like, but executability is determined by file
associations, possibly in association with PATHEXT
settings. AFAICT, the current Python installer does
this already for pyc / pyo files. (When I say "nothing
to do with file permissions", obviously the file in
question must be readable)

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri Jun 26 17:37:02 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Jun 2009 15:37:02 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1242817129.44.0.860392010944.issue6070@psf.upfronthosting.co.za>
Message-ID: <1246030622.53.0.682262176046.issue6070@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So we should just do #ifndef MS_WINDOWS?  Do we have any non-windows
non-posix platforms?  (People on #python-dev don't think so.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri Jun 26 18:17:26 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Fri, 26 Jun 2009 16:17:26 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1246030622.53.0.682262176046.issue6070@psf.upfronthosting.co.za>
Message-ID: <20090626161727.GA26181@phd.pp.ru>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

I can confirm the patch works on WinXP on NTFS partition and Samba-shared network drive. I have WinXP running in an emulator (VirtualBox) and I compiled Python using MSVC90 Express.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri Jun 26 18:17:55 2009
From: report at bugs.python.org (Oleg Broytmann)
Date: Fri, 26 Jun 2009 16:17:55 +0000
Subject: [issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
In-Reply-To: <1246030622.53.0.682262176046.issue6070@psf.upfronthosting.co.za>
Message-ID: <20090626161756.GB26181@phd.pp.ru>


Oleg Broytmann <phd at phd.pp.ru> added the comment:

Yes, I think #ifndef MS_WINDOWS is enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6070>
_______________________________________

From report at bugs.python.org  Fri Jun 26 19:10:24 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Jun 2009 17:10:24 +0000
Subject: [issue1592241] Stepping into a generator throw does not work
Message-ID: <1246036224.85.0.626798340003.issue1592241@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem does reproduce with 2.5.1, but not with 2.5.2.

This is actually the same as issue1265 (since closing a paused generator
throws it a GeneratorExit exception, and of course pdb must use
generators somewhere)

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1592241>
_______________________________________

From report at bugs.python.org  Fri Jun 26 20:53:17 2009
From: report at bugs.python.org (Filipe Fernandes)
Date: Fri, 26 Jun 2009 18:53:17 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1246042397.52.0.904580805223.issue4660@psf.upfronthosting.co.za>


Filipe Fernandes <fernandes.fd at gmail.com> added the comment:

I ran into the same problem and am greatful to Brian for reporting this
as I thought I was loosing my mind.

Brian noted that he was running windows and I can confirm that Brian's
test case is reproducable on my laptop running:

Ubuntu 9.04
python 2.6.2

Although I'm reluctant to try Brian's suggestions without additional
comments even if they do work.  I'll be using this in production.

----------
nosy: +ffernand

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________

From report at bugs.python.org  Fri Jun 26 20:58:20 2009
From: report at bugs.python.org (Matt Kubilus)
Date: Fri, 26 Jun 2009 18:58:20 +0000
Subject: [issue6346] Rstrip Incorrectly Strips Some Strings
In-Reply-To: <1246042700.02.0.587103805178.issue6346@psf.upfronthosting.co.za>
Message-ID: <1246042700.02.0.587103805178.issue6346@psf.upfronthosting.co.za>


New submission from Matt Kubilus <kubilus1 at yahoo.com>:

Rstrip has unexpected behavior with some strings.  Example:

-----

>>> "proxa.py".rstrip(".py")
'proxa'
>>> "proxy.py".rstrip(".py")
'prox'

-----

Tested with Python 2.6.1

----------
components: Library (Lib)
messages: 89736
nosy: mkubilus
severity: normal
status: open
title: Rstrip Incorrectly Strips Some Strings
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6346>
_______________________________________

From report at bugs.python.org  Fri Jun 26 21:02:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Jun 2009 19:02:25 +0000
Subject: [issue6346] Rstrip Incorrectly Strips Some Strings
In-Reply-To: <1246042700.02.0.587103805178.issue6346@psf.upfronthosting.co.za>
Message-ID: <1246042945.07.0.115319218831.issue6346@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is expected. rstrip() strips a set of characters, not a string.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6346>
_______________________________________

From report at bugs.python.org  Fri Jun 26 21:40:23 2009
From: report at bugs.python.org (Erik Antelman)
Date: Fri, 26 Jun 2009 19:40:23 +0000
Subject: [issue6309] Tix needs TCL package require statement
In-Reply-To: <1245370741.24.0.759897657733.issue6309@psf.upfronthosting.co.za>
Message-ID: <1246045223.96.0.76842007214.issue6309@psf.upfronthosting.co.za>


Erik Antelman <eantelman at acm.org> added the comment:

Documentation gives proper usage of Tix to be replacing Tkinter.Tk()
with Tix.Tk(). This solves the problem. 

I think this was an RTFM issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6309>
_______________________________________

From report at bugs.python.org  Fri Jun 26 21:42:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Jun 2009 19:42:37 +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: <1246045357.15.0.874792939833.issue3392@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good to me, but I don't use Linux regularly. Another review 
is needed!

----------
keywords: +needs review
nosy: +amaury.forgeotdarc
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Fri Jun 26 21:43:03 2009
From: report at bugs.python.org (Erik Antelman)
Date: Fri, 26 Jun 2009 19:43:03 +0000
Subject: [issue6309] Tix needs TCL package require statement
In-Reply-To: <1245370741.24.0.759897657733.issue6309@psf.upfronthosting.co.za>
Message-ID: <1246045383.03.0.569758009765.issue6309@psf.upfronthosting.co.za>


Erik Antelman <eantelman at acm.org> added the comment:

BTW: It should be given to the future searchers, that the mistake
results in the following error:
    _tkinter.TclError: invalid command name "tixComboBox"

The solution is simple:

Documentation gives proper usage of Tix to be replacing Tkinter.Tk()
with Tix.Tk(). This solves the problem. 

I think this was an RTFM issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6309>
_______________________________________

From report at bugs.python.org  Fri Jun 26 22:32:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Jun 2009 20:32:20 +0000
Subject: [issue5390] Item 'Python x.x.x' in Add/Remove Programs list still
	lacks an icon
In-Reply-To: <1235806015.04.0.902011396347.issue5390@psf.upfronthosting.co.za>
Message-ID: <1246048340.28.0.152522162771.issue5390@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I found the cause: in msi.py, the DisplayIcon registry variable is attached to 
"REGISTRY.def" i.e the "Register extensions" feature.
The following patch attaches it to the parent group.

Index: msi.py
===================================================================
--- msi.py	(revision 73575)
+++ msi.py	(working copy)
@@ -1258,7 +1258,7 @@
                "", r"[TARGETDIR]Python.exe", "REGISTRY.def"),
               ("DisplayIcon", -1,
                r"Software\Microsoft\Windows\CurrentVersion\Uninstall\%s" % 
product_code,
-               "DisplayIcon", "[TARGETDIR]python.exe", "REGISTRY.def")
+               "DisplayIcon", "[TARGETDIR]python.exe", "REGISTRY")
               ])
     # Shortcuts, see "Shortcut Table"
     add_data(db, "Directory",

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5390>
_______________________________________

From report at bugs.python.org  Fri Jun 26 23:15:07 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Jun 2009 21:15:07 +0000
Subject: [issue6346] Rstrip Incorrectly Strips Some Strings
In-Reply-To: <1246042700.02.0.587103805178.issue6346@psf.upfronthosting.co.za>
Message-ID: <1246050907.74.0.72659880272.issue6346@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

And you should probably use
http://docs.python.org/library/os.path.html#os.path.splitext instead of
.rstrip().

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6346>
_______________________________________

From report at bugs.python.org  Fri Jun 26 23:25:58 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jun 2009 21:25:58 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1246051558.44.0.681793095281.issue6324@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.1, Section 5.9 has
"
For user-defined classes which define the __contains__() method, x in y
is true if and only if y.__contains__(x) is true.

For user-defined classes which do not define __contains__() and do
define __getitem__(), x in y is true if and only if there is a
non-negative integer index i such that x == y[i], and all lower integer
indices do not raise IndexError exception. (If any other exception is
raised, it is as if in raised that exception).
"
However, discussion of how user-defined classes emulate builtins is
mostly in 3.3. Special method names. I think some of the above should be
moved, with or without revision, (or copied) to 3.3.5. Emulating
container types.

The current entry there says only 
"
object.__contains__(self, item) 
Called to implement membership test operators. Should return true if
item is in self, false otherwise. For mapping objects, this should
consider the keys of the mapping rather than the values or the key-item
pairs.
"
which seems to me inadequate, as it does not discuss the alternative, as
many other entries in 3.3 do.

Regardless of that, I verified that in 3.1, __iter__ is called in
preference to __getitem__:

class C():
    def __iter__(s):
        print('in iter')
        return iter([])
    def __getitem(s,i):
        print('in getitem')

print(1 in C())

prints
in iter
False

so some change is needed.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Fri Jun 26 23:37:18 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jun 2009 21:37:18 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1246052238.27.0.121240007726.issue6324@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Side note: 2.5, including, I believe, the docs, is frozen except for
security fixes. If you find 2.5 doc issues, please check the current 2.x
development version, currently http://docs.python.org/dev/ to see if
they have been fixed or not.

----------
versions: +Python 3.0, Python 3.1, Python 3.2 -Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Fri Jun 26 23:49:14 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Jun 2009 21:49:14 +0000
Subject: [issue6324] "in" expression falls back to __iter__ before __getitem__
In-Reply-To: <1245698874.13.0.640137390853.issue6324@psf.upfronthosting.co.za>
Message-ID: <1246052954.53.0.634979700292.issue6324@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

3.0 is no longer supported either

----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6324>
_______________________________________

From report at bugs.python.org  Sat Jun 27 00:34:29 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jun 2009 22:34:29 +0000
Subject: [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <1246055669.12.0.0738846246297.issue6335@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In a few days, when 3.1 comes out, 3.0 will be mostly dead.
I think it would be more useful to put energy into a 3.1 port.

Other thoughts:

Your patch amounts to a in-development version of a new feature. To me,
that belongs on a separate branch or repository where those interested
can work on it. I am surprised that no one has set up a py-mingw project
on SourceForge, Google Code, or wherever, if indeed no one has. If not,
someone should. New modules from 3rd party developers are expected to be
publicly released for testing and use for some months, at least, before
adoption. Though it is not my decision, I would require the same of a
new port

I am not sure that minor-platform code like this belongs in the central
repository, especially when we transition to mercurial, where central
repository loses some of its meaning. To me, every ifdef from yet
another system makes the code harder to read.

So I recommend that you think in terms of maintaining a separate
Py-Mingw mecurial or whatever repository indefinitely as a public
project site where you and others interested can have your own wiki,
tracker, mail list, and release schedule -- all without permission from
the PSF developers.

I notice that your patch has a lot of FIXMEs. I presume that they only
apply to mingw, so that would be wrong for inclusion into the core. The
freedom to put platform-specific notes in the code is to me a reason to
have a platform-specific repository.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6335>
_______________________________________

From report at bugs.python.org  Sat Jun 27 01:42:38 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Jun 2009 23:42:38 +0000
Subject: [issue6170] Mac 'make frameworkinstall' error:
	[...]/Python.framework/Versions/3.1/bin/2to3: Too many levels
	of symbolic links
In-Reply-To: <1243900841.29.0.115602903603.issue6170@psf.upfronthosting.co.za>
Message-ID: <1246059758.25.0.889415450122.issue6170@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ok, I am no longer relying on internal targets .. and this problem is 
fixed for me. It needs to be closed, correct?

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6170>
_______________________________________

From report at bugs.python.org  Sat Jun 27 01:46:16 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Jun 2009 23:46:16 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

(...)
cc +DAportable -Ae -D_REENTRANT +Z -c  -DNDEBUG -O  -I. -IInclude -I./
Include   -DPy_BUILD_CORE -o Python/pystrtod.o Python/pystrtod.c
cc +DAportable -Ae -D_REENTRANT +Z -c  -DNDEBUG -O  -I. -IInclude -I./
Include   -DPy_BUILD_CORE -o Python/dtoa.o Python/dtoa.c
cpp: "Python/dtoa.c", line 158: error 4062: "Failed to find an exact-
width 32-bit integer type"
make: *** [Python/dtoa.o] Error 1

Entire build log is attached (just look at the configure/make output of 
Python).

----------
components: Build
files: apy31-hpux11.00-parisc-bertha.log
messages: 89748
nosy: srid
severity: normal
status: open
title: hpux11.00-parisc: dtoa.c: "Failed to find an exact-width 32-bit integer type"
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file14367/apy31-hpux11.00-parisc-bertha.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Sat Jun 27 01:49:22 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Jun 2009 23:49:22 +0000
Subject: [issue6348] solaris/aix: Py_Initialize: can't initialize sys standard
	streams
In-Reply-To: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>
Message-ID: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I wonder which commit introduced this regression which used to work 
before (I think till rc1).

This error occurs on solaris10-x86, solaris8-sparc, solaris8-sparc64 
and aix5-powerpc.

(...)
ranlib libpython3.1.a
cc   -o python \
                Modules/python.o \
                libpython3.1.a -lresolv -lsocket -lnsl -lintl -lrt -
ldl   -lm  
Fatal Python error: Py_Initialize: can't initialize sys standard streams
IOError: [Errno 29] Illegal seek
*** Error code 134
The following command caused the error:
case $MAKEFLAGS in \
*s*)  CC='cc' LDSHARED='cc -G' OPT='-DNDEBUG -O' ./python -E ./setup.py 
-q build;; \
*)  CC='cc' LDSHARED='cc -G' OPT='-DNDEBUG -O' ./python -E ./setup.py 
build;; \
esac
make: Fatal error: Command failed for target `sharedmods'


Entire build log (solaris10-x86) is attached.

----------
components: Build
files: apy31-ginsu.log
messages: 89749
nosy: srid
severity: normal
status: open
title: solaris/aix: Py_Initialize: can't initialize sys standard streams
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14368/apy31-ginsu.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6348>
_______________________________________

From report at bugs.python.org  Sat Jun 27 01:55:29 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Jun 2009 23:55:29 +0000
Subject: [issue6348] solaris/aix: Py_Initialize: can't initialize sys standard
	streams
In-Reply-To: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>
Message-ID: <1246060529.28.0.44784624851.issue6348@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it the same as #6236?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6348>
_______________________________________

From report at bugs.python.org  Sat Jun 27 05:43:10 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 27 Jun 2009 03:43:10 +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: <1246074190.26.0.88345175871.issue2389@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here's a patch that implements the solution I described in msg85298.

Please give it a good review:
http://codereview.appspot.com/87072

----------
Added file: http://bugs.python.org/file14369/portable_array_pickling.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
_______________________________________

From report at bugs.python.org  Sat Jun 27 16:03:41 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 27 Jun 2009 14:03:41 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246111421.66.0.562304629145.issue6347@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> marketdickinson
nosy: +marketdickinson
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Sat Jun 27 16:49:38 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 27 Jun 2009 14:49:38 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246114178.68.0.022341008891.issue6347@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!

Is the operating system you're using HP-UX 11.00, or am I misunderstanding 
the issue title?  Isn't HP-UX 11.00 quite old?  (wikipedia says 1997).  
Does the problem exist with more recent versions of HP-UX 11?

>From the log file you supplied (thank you!) it looks as though the issue 
is that this version of HP-UX doesn't have the stdint.h standard header 
file that's required by C99.  This would hardly be surprising if the 1997 
date is accurate.

I have some questions and requests:

1. Please could you attach your post-configuration pyconfig.h file,
and also, if possible, the config.log file?

2. Does inttypes.h on your system define int32_t and uint32_t?

3. Does inttypes.h on your system define INT32_MAX and UINT32_MAX?

4. Does the attached patch fix the problem for you?  (Note: I'm not
yet proposing applying such a patch to the Python source;  I'm just
trying to diagnose the problem.)

For questions 2 and 3, be aware that there might be some #ifdef magic in 
inttypes.h so that what's actually defined depends on various compiler 
flags or preprocessor constants.  (For example, on some systems, I believe 
exports of INT32_MAX and friends from stdint.h are suppressed when using a 
C++ compiler instead of a C compiler.)

----------
keywords: +patch
Added file: http://bugs.python.org/file14370/issue6347.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Sat Jun 27 16:52:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 27 Jun 2009 14:52:09 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246114329.04.0.918874719524.issue6347@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry:  additional bit for question 2:

2a:  if inttypes.h defines int32_t and uint32_t, are they C macros or 
typedefs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Sat Jun 27 17:04:16 2009
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Jun 2009 15:04:16 +0000
Subject: [issue6226] Inconsistent 'file' vs 'stream' kwarg in pprint,
	other stdlibs
In-Reply-To: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>
Message-ID: <1246115056.55.0.0690171875916.issue6226@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6226>
_______________________________________

From report at bugs.python.org  Sat Jun 27 23:16:28 2009
From: report at bugs.python.org (David Bremner)
Date: Sat, 27 Jun 2009 21:16:28 +0000
Subject: [issue6349] email.Maildir cannot roundtrip messages.
In-Reply-To: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>
Message-ID: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>


New submission from David Bremner <bremner at unb.ca>:

if mailbox is an email.Maildir object  the following lines 
cause an exception for me.

for key in mailbox.keys():
	msg=mailbox[key]
        mailbox[key]=msg

I attach the whole script. I'm happy to send a tar file of the maildir
I used to test with.

----------
files: test.py
messages: 89754
nosy: bremner
severity: normal
status: open
title: email.Maildir cannot roundtrip messages.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14371/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6349>
_______________________________________

From report at bugs.python.org  Sat Jun 27 23:34:07 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 27 Jun 2009 21:34:07 +0000
Subject: [issue6350] Example at end of HTMLParser documentation uses old-style
	print syntax
In-Reply-To: <1246138447.18.0.57026515802.issue6350@psf.upfronthosting.co.za>
Message-ID: <1246138447.18.0.57026515802.issue6350@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Change the print statements in the example at the bottom of the
documentation for HTMLParser to function calls.

----------
assignee: georg.brandl
components: Documentation
messages: 89755
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Example at end of HTMLParser documentation uses old-style print syntax
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6350>
_______________________________________

From report at bugs.python.org  Sat Jun 27 23:38:05 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 27 Jun 2009 21:38:05 +0000
Subject: [issue6350] Example at end of HTMLParser documentation uses old-style
	print syntax
In-Reply-To: <1246138447.18.0.57026515802.issue6350@psf.upfronthosting.co.za>
Message-ID: <1246138685.64.0.527156449944.issue6350@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

Also, while you're at it I think the example should show a call to feed
since HTMLParser is unusual in not taking a contents argument when it is
created. Nothing wrong with the design, and it is clearly stated at the
beginning, but I like examples to be comprehensible at a glance and as
self-sufficient as can be conveniently achieved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6350>
_______________________________________

From report at bugs.python.org  Sat Jun 27 23:59:06 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 27 Jun 2009 21:59:06 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1246139946.68.0.363019904098.issue6344@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Hmm, I cannot reproduce the crash. I created the patch experimentally,
but I'm not confident with this patch. Especially here

+	if (n < 0)
+		n = PY_SSIZE_T_MAX;

because I don't have so much memory.

----------
keywords: +patch
Added file: http://bugs.python.org/file14372/fix_mmap_read.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Sun Jun 28 00:05:27 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Jun 2009 22:05:27 +0000
Subject: [issue6349] email.Maildir cannot roundtrip messages.
In-Reply-To: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>
Message-ID: <1246140327.82.0.193734871174.issue6349@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please cut and paste the traceback.

----------
components: +Library (Lib)
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6349>
_______________________________________

From report at bugs.python.org  Sun Jun 28 01:01:38 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Jun 2009 23:01:38 +0000
Subject: [issue6350] Example at end of HTMLParser documentation uses old-style
	print syntax
In-Reply-To: <1246138447.18.0.57026515802.issue6350@psf.upfronthosting.co.za>
Message-ID: <1246143698.24.0.415678227403.issue6350@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r73592.
Thanks!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6350>
_______________________________________

From report at bugs.python.org  Sun Jun 28 01:29:00 2009
From: report at bugs.python.org (David Bremner)
Date: Sat, 27 Jun 2009 23:29:00 +0000
Subject: [issue6349] email.Maildir cannot roundtrip messages.
In-Reply-To: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>
Message-ID: <1246145340.43.0.0922621406844.issue6349@psf.upfronthosting.co.za>


David Bremner <bremner at unb.ca> added the comment:

[ 61 pivot ~/config/scripts ] python test.py
Traceback (most recent call last):
  File "test.py", line 11, in <module>
    mailbox[key]=msg
  File "/usr/lib/python2.5/mailbox.py", line 293, in __setitem__
    temp_key = self.add(message)
  File "/usr/lib/python2.5/mailbox.py", line 245, in add
    self._dump_message(message, tmp_file)
  File "/usr/lib/python2.5/mailbox.py", line 220, in _dump_message
    raise TypeError('Invalid message type: %s' % type(message))
TypeError: Invalid message type: <type 'instance'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6349>
_______________________________________

From report at bugs.python.org  Sun Jun 28 01:47:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Jun 2009 23:47:44 +0000
Subject: [issue5896] timeit documentation
In-Reply-To: <1241200430.17.0.749564261591.issue5896@psf.upfronthosting.co.za>
Message-ID: <1246146464.02.0.94634357414.issue5896@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r73595.
Thanks!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5896>
_______________________________________

From report at bugs.python.org  Sun Jun 28 01:57:50 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Jun 2009 23:57:50 +0000
Subject: [issue5555] optparse
In-Reply-To: <1237917675.54.0.817122476849.issue5555@psf.upfronthosting.co.za>
Message-ID: <1246147070.65.0.364497838204.issue5555@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +gward
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5555>
_______________________________________

From report at bugs.python.org  Sun Jun 28 03:18:23 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Jun 2009 01:18:23 +0000
Subject: [issue5254] Formatting error in "findertools" header
In-Reply-To: <1234559905.46.0.79171819004.issue5254@psf.upfronthosting.co.za>
Message-ID: <1246151903.61.0.864553775531.issue5254@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The original source of that page is:
:mod:`findertools` --- The :program:`finder`'s Apple Events interface
Apparently the ' is automatically replaced by a ? when Sphinx generates
the doc but if it's preceded by `something` Sphinx uses ? instead of ?.

----------
nosy: +ezio.melotti
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5254>
_______________________________________

From report at bugs.python.org  Sun Jun 28 05:25:41 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 28 Jun 2009 03:25:41 +0000
Subject: [issue6351] Compiler warning in _cursesmodule.c
In-Reply-To: <1246159541.88.0.944376557705.issue6351@psf.upfronthosting.co.za>
Message-ID: <1246159541.88.0.944376557705.issue6351@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

My gcc complains that the variables x and y might be used uninitialized
in the function PyCurses_getsyx in Modules/_cursesmodule.c. This is
because the macro getsyx of curses.h apparently only sets x and y if
newscr is not NULL. There seems to have been a related discussion last year:

http://mail.python.org/pipermail/python-dev/2008-March/077496.html

----------
components: Build
messages: 89763
nosy: hagen
severity: normal
status: open
title: Compiler warning in _cursesmodule.c
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6351>
_______________________________________

From report at bugs.python.org  Sun Jun 28 05:57:55 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 28 Jun 2009 03:57:55 +0000
Subject: [issue6352] Compiler warning in unicodeobject.c
In-Reply-To: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>
Message-ID: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

Compiling --with-wide-unicode there's a warning that encodeUCS4 is
defined, but not used. A trivial patch for this is attached.

----------
files: warning.patch
keywords: patch
messages: 89764
nosy: hagen
severity: normal
status: open
title: Compiler warning in unicodeobject.c
versions: Python 3.1
Added file: http://bugs.python.org/file14373/warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6352>
_______________________________________

From report at bugs.python.org  Sun Jun 28 07:19:51 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 28 Jun 2009 05:19:51 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1246166391.05.0.520710521541.issue4856@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

OK, 3.1 was out. Can I commit this to trunk and merge it to py3k?

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Sun Jun 28 09:37:27 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Jun 2009 07:37:27 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1246174647.26.0.701799554483.issue4856@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Sure, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Sun Jun 28 09:55:05 2009
From: report at bugs.python.org (Pierre Bourdon)
Date: Sun, 28 Jun 2009 07:55:05 +0000
Subject: [issue6353] "L" integer suffix in Python 3.1 tutorial
In-Reply-To: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>
Message-ID: <1246175705.48.0.727392252197.issue6353@psf.upfronthosting.co.za>


New submission from Pierre Bourdon <root at delroth.is-a-geek.org>:

Chapter 14 (Floating Point Arithmetic: Issues and Limitations) of the
Python 3.x tutorial contains integers with long suffix (424242L) when
talking about as_integer_ratio.

Patch is attached.

----------
assignee: georg.brandl
components: Documentation
files: fp-tutorial.diff
keywords: patch
messages: 89767
nosy: delroth, georg.brandl
severity: normal
status: open
title: "L" integer suffix in Python 3.1 tutorial
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14374/fp-tutorial.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6353>
_______________________________________

From report at bugs.python.org  Sun Jun 28 09:58:46 2009
From: report at bugs.python.org (Pierre Bourdon)
Date: Sun, 28 Jun 2009 07:58:46 +0000
Subject: [issue6354] Old floating point representation in 3.1 tutorial
In-Reply-To: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>
Message-ID: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>


New submission from Pierre Bourdon <root at delroth.is-a-geek.org>:

In part 3.1.1 of the Python 3.1 tutorial, the following code sample is
obsolete :

>>> 8/5 # Fractions aren't lost when dividing integers
1.6000000000000001


In a fresh Python 3.1, 8/5 is now displayed as 1.6. The note below the
code sample should be updated too.

----------
assignee: georg.brandl
components: Documentation
messages: 89768
nosy: delroth, georg.brandl
severity: normal
status: open
title: Old floating point representation in 3.1 tutorial
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6354>
_______________________________________

From report at bugs.python.org  Sun Jun 28 11:34:37 2009
From: report at bugs.python.org (Benjamin Kramer)
Date: Sun, 28 Jun 2009 09:34:37 +0000
Subject: [issue6355] bogus NULL check in PyCapsule
In-Reply-To: <1246181677.92.0.360590014109.issue6355@psf.upfronthosting.co.za>
Message-ID: <1246181677.92.0.360590014109.issue6355@psf.upfronthosting.co.za>


New submission from Benjamin Kramer <benny.kra at gmail.com>:

Objects/capsule.c contains the following code:

if (!name1 || !name2) {
    /* they're only the same if they're both NULL. */
    return name2 == name2;
}

The result of this comparison will always be true. The comment says it 
should be 'name1 == name2'.

----------
components: Interpreter Core
files: capsulecompare.patch
keywords: patch
messages: 89769
nosy: bkramer
severity: normal
status: open
title: bogus NULL check in PyCapsule
versions: Python 3.1
Added file: http://bugs.python.org/file14375/capsulecompare.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6355>
_______________________________________

From report at bugs.python.org  Sun Jun 28 11:43:31 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Jun 2009 09:43:31 +0000
Subject: [issue5390] Item 'Python x.x.x' in Add/Remove Programs list still
	lacks an icon
In-Reply-To: <1235806015.04.0.902011396347.issue5390@psf.upfronthosting.co.za>
Message-ID: <1246182211.05.0.399565167446.issue5390@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the analysis and the patch. Fixed in r73599, r73600, r73601,
r73602.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5390>
_______________________________________

From report at bugs.python.org  Sun Jun 28 11:47:54 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 28 Jun 2009 09:47:54 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1246182474.13.0.59101730474.issue6344@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> +	if (n < 0)

I suggest a comment like:

/* The difference can overflow, only if self->size is greater than
 * PY_SSIZE_T_MAX.  But then the operation cannot possibly succeed,
 * because the mapped area and the returned string each need more 
 * than half of the addressable memory.  So we clip the size, and let
 * the code below raise MemoryError.
 */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Sun Jun 28 11:51:44 2009
From: report at bugs.python.org (str1442)
Date: Sun, 28 Jun 2009 09:51:44 +0000
Subject: [issue6356] Segfault of sys.setrecursionlimit if limit exceeds the
	value 18063 (GNU/Linux)
In-Reply-To: <1246182704.52.0.334692905676.issue6356@psf.upfronthosting.co.za>
Message-ID: <1246182704.52.0.334692905676.issue6356@psf.upfronthosting.co.za>


New submission from str1442 <lancerstr at freenet.de>:

After playing around with the setrecursionlimit() Function in the sys
module, i noticed it crashes if you set the limit to a value that is too
high. I explored this further until i noticed the value from which the
crashing begins is exactly 18063. I know that the highest setable value
is platformdependent, but crashing seems inappropriate if a value is
given that is too high.

I'm using Debian GNU/Linux Testing, last upgrade one month ago.

uname -svomr:

Linux 2.6.27.7 #4 SMP Fri Nov 28 01:44:17 CET 2008 i686 GNU/Linux

(Kernel is a pure kernel.org Kernel, self compiled)

Python Version in question is 2.5.4. Searching through the tracker for
setrecursionlimit brought no corresponding issues.

This is a the test script I used:

import sys

sys.setrecursionlimit(18063)

def f():
    g()

def g():
    f()

f()

----------
components: Interpreter Core, Library (Lib)
messages: 89772
nosy: str1442
severity: normal
status: open
title: Segfault of sys.setrecursionlimit if limit exceeds the value 18063 (GNU/Linux)
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6356>
_______________________________________

From report at bugs.python.org  Sun Jun 28 12:53:56 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Jun 2009 10:53:56 +0000
Subject: [issue6356] Segfault of sys.setrecursionlimit	if limit exceeds the
	value 18063 (GNU/Linux)
In-Reply-To: <1246182704.52.0.334692905676.issue6356@psf.upfronthosting.co.za>
Message-ID: <4A474BC1.2080208@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I know that the highest setable value
> is platformdependent, but crashing seems inappropriate if a value is
> given that is too high.

No, it's not inappropriate. It's the only possible reaction.

Closing as won't fix.

----------
nosy: +loewis
title: Segfault of sys.setrecursionlimit if limit exceeds the value 18063 (GNU/Linux) -> Segfault of sys.setrecursionlimit	if limit exceeds the value 18063 (GNU/Linux)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6356>
_______________________________________

From report at bugs.python.org  Sun Jun 28 12:54:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Jun 2009 10:54:11 +0000
Subject: [issue6356] Segfault of sys.setrecursionlimit	if limit exceeds the
	value 18063 (GNU/Linux)
In-Reply-To: <1246182704.52.0.334692905676.issue6356@psf.upfronthosting.co.za>
Message-ID: <1246186451.32.0.386038581707.issue6356@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/issue6356>
_______________________________________

From report at bugs.python.org  Sun Jun 28 13:08:26 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 28 Jun 2009 11:08:26 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1246187306.08.0.98466145411.issue4856@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, committed in r73603(trunk) and r73604(py3k).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Sun Jun 28 15:36:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Jun 2009 13:36:35 +0000
Subject: [issue6267] Cumulative patch to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246196195.56.0.255711523956.issue6267@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Patch set 4 looks fine to me, please apply it to 2.7 and 3.2.

----------
assignee:  -> krisvale
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Sun Jun 28 18:18:58 2009
From: report at bugs.python.org (Funda Wang)
Date: Sun, 28 Jun 2009 16:18:58 +0000
Subject: [issue6237] Build errors when using LDFLAGS="-Wl,--no-undefined"
In-Reply-To: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za>
Message-ID: <1246205938.71.0.435936729466.issue6237@psf.upfronthosting.co.za>


Funda Wang <fundawang at gmail.com> added the comment:

How is this issue going?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6237>
_______________________________________

From report at bugs.python.org  Sun Jun 28 18:24:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Jun 2009 16:24:16 +0000
Subject: [issue6355] bogus NULL check in PyCapsule
In-Reply-To: <1246181677.92.0.360590014109.issue6355@psf.upfronthosting.co.za>
Message-ID: <1246206256.66.0.276599731449.issue6355@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Fixed in r73618.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6355>
_______________________________________

From report at bugs.python.org  Sun Jun 28 18:51:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Jun 2009 16:51:25 +0000
Subject: [issue6354] Old floating point representation in 3.1 tutorial
In-Reply-To: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>
Message-ID: <1246207885.65.0.904890419867.issue6354@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
nosy: +eric.smith, marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6354>
_______________________________________

From report at bugs.python.org  Sun Jun 28 18:58:57 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 28 Jun 2009 16:58:57 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1246208337.07.0.439001563964.issue2919@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Yesterday, I ported the _lsprof module to Python as an experiment. I
still have a few issues to iron out, but the core of the functionality
is there.  

I am not sure yet how this experiment will fit in the profile/cProfile
merge. I wrote the port mainly to get a better idea of what is needed
for the merge and how the profiler works.

----------
Added file: http://bugs.python.org/file14376/lsprof.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Sun Jun 28 19:01:52 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 28 Jun 2009 17:01:52 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1246208512.3.0.606415870875.issue2919@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file14377/pyprofile.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2919>
_______________________________________

From report at bugs.python.org  Sun Jun 28 19:32:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Jun 2009 17:32:37 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1246210357.76.0.962835344996.issue1424152@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Senthil, are you still working on the 3.x version of the patch?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Sun Jun 28 19:35:53 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Jun 2009 17:35:53 +0000
Subject: [issue5254] Formatting error in "findertools" header
In-Reply-To: <1234559905.46.0.79171819004.issue5254@psf.upfronthosting.co.za>
Message-ID: <1246210553.55.0.862789628287.issue5254@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5254>
_______________________________________

From report at bugs.python.org  Sun Jun 28 21:16:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Jun 2009 19:16:20 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246216580.13.0.554480083473.issue5388@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It's probably better to split long lines (at 80 chars?) than adding an
empty line in every box. Scrolling horizontally is annoying enough even
without the problem you mentioned.

I don't know if it's possible to split grammar lines like
id_start/id_continue[1], but in this specific case is probably better to
keep the definitions short and explain it further in the following
paragraph.

I don't have any idea about how Windows Help works, but if it uses
something like CSS, some extra padding at bottom could solve the problem
without having to add an empty line.

[1]: http://docs.python.org/3.1/reference/lexical_analysis.html#identifiers

----------
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Sun Jun 28 21:46:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Jun 2009 19:46:05 +0000
Subject: [issue6349] email.Maildir cannot roundtrip messages.
In-Reply-To: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>
Message-ID: <1246218365.52.0.304478413771.issue6349@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Did you specify 'factory=None', as instructed by the documentation? 
(The default is fixed in py3, by the way).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6349>
_______________________________________

From report at bugs.python.org  Sun Jun 28 22:24:26 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 28 Jun 2009 20:24:26 +0000
Subject: [issue6357] tempfile.NamedTemporaryFile does not accept the delete=
	parameter on Windows
In-Reply-To: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>
Message-ID: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Likely affects Python 2.7 and Python3.x as well, but I have not checked.

Under Windows:
>>> tempfile.NamedTemporaryFile('w', delete = False)
TypeError: NamedTemporaryFile() got an unexpected keyword argument 'delete'

Under Unix:
>>> tempfile.NamedTemporaryFile('w', delete=True)
<open file '<fdopen>', mode 'w' at 0x7ff199d0>

----------
messages: 89782
nosy: stutzbach
severity: normal
status: open
title: tempfile.NamedTemporaryFile does not accept the delete= parameter on Windows
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6357>
_______________________________________

From report at bugs.python.org  Sun Jun 28 22:27:58 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 28 Jun 2009 20:27:58 +0000
Subject: [issue1474680] pickling files works with protocol=2.
Message-ID: <1246220878.18.0.920102194554.issue1474680@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

That seems easy to fix by adding a dummy __reduce__ method to file. My
only worry is this could break file subclasses which may have ad-hoc
mechanisms implemented for pickling files.

----------
keywords: +patch
nosy: +alexandre.vassalotti
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14378/disable_file_pickling-py2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1474680>
_______________________________________

From report at bugs.python.org  Sun Jun 28 22:58:19 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Jun 2009 20:58:19 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246222699.24.0.540716045852.issue5388@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The lines in the green box do not have to be long in an absolute sense,
just longer than the current window width allows. As soon as the the
window is narrow enough to require a horizontal scroll bar, a vertical
scroll bar is added too because the horizonal scroll bar is added into
the box on top of where the bottom margin and part of the last line was.

I just discovered that if the vertical scroll bar is exactly centered,
everything is visible because the horizontal bar is a bit under twice
the width of the top and bottom margins. If only it started there...

----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:03:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Jun 2009 21:03:31 +0000
Subject: [issue6354] Old floating point representation in 3.1 tutorial
In-Reply-To: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>
Message-ID: <1246223011.95.0.248404993238.issue6354@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!  I've stolen this from Georg (sorry, Georg)
and fixed this and a few other similar repr-related problems in r73636 
(py3k) and r73637 (release31-maint).

----------
assignee: georg.brandl -> marketdickinson
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6354>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:05:01 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 28 Jun 2009 21:05:01 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246223101.2.0.697288017375.issue6267@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Commited to 2.7 in revision 73638

----------
title: Cumulative patch to http and xmlrpc -> Cumulative patcc:h to http and xmlrpc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:12:50 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 28 Jun 2009 21:12:50 +0000
Subject: [issue6117] Fix O(n**2) performance problem in socket._fileobject
In-Reply-To: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>
Message-ID: <1246223570.49.0.244456219936.issue6117@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

There is no need to port this to 3.2, it uses a completely different IO 
system for socket fileobjects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6117>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:14:13 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 28 Jun 2009 21:14:13 +0000
Subject: [issue6248] TCP Sockets not closed by TCPServer and
	StreamRequestHandler
In-Reply-To: <1244566538.72.0.477638958657.issue6248@psf.upfronthosting.co.za>
Message-ID: <1246223653.81.0.317183944772.issue6248@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
status: open -> closed
superseder:  -> Cumulative patcc:h to http and xmlrpc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6248>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:20:25 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Jun 2009 21:20:25 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246224025.16.0.0835909435879.issue5388@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That's why I think that the Windows Help problem still need to be fixed,
but limiting the length of the lines is a good idea regardless of this,
since having long lines and horizontal scroll bars is annoying on the
browser too.

Is the Windows Help python31.chm?
I installed Python 3.1 on Windows XP and tried to open that section.
Here the width of the page depends on the longest line, so the whole
page is large enough to contain both id_start and id_continue (however,
even if this long lines go over the right limit of the page, all the
other lines fit in the visible part of the page). There are no
scrollbars inside the green box, just "global" scrollbars for the page

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:21:56 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Jun 2009 21:21:56 +0000
Subject: [issue6354] Old floating point representation in 3.1 tutorial
In-Reply-To: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>
Message-ID: <1246224116.13.0.258906597863.issue6354@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also r73640 and r73641, which take into account Pierre's point
that the note below the code sample should be updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6354>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:26:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Jun 2009 21:26:21 +0000
Subject: [issue6354] Old floating point representation in 3.1 tutorial
In-Reply-To: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>
Message-ID: <1246224381.24.0.941179914534.issue6354@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

What about http://docs.python.org/3.1/tutorial/floatingpoint.html ?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6354>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:28:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Jun 2009 21:28:08 +0000
Subject: [issue6354] Old floating point representation in 3.1 tutorial
In-Reply-To: <1246175926.72.0.81229799374.issue6354@psf.upfronthosting.co.za>
Message-ID: <1246224488.68.0.872362019206.issue6354@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ezio:  I think Raymond updated that recently, so it should be okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6354>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:31:30 2009
From: report at bugs.python.org (James Abbatiello)
Date: Sun, 28 Jun 2009 21:31:30 +0000
Subject: [issue6358] os.popen exit code inconsistent
In-Reply-To: <1246224690.37.0.731708410356.issue6358@psf.upfronthosting.co.za>
Message-ID: <1246224690.37.0.731708410356.issue6358@psf.upfronthosting.co.za>


New submission from James Abbatiello <abbeyj at gmail.com>:

Start a process with os.popen() and then try to get its exit code by
closing the resulting file handle.  The value returned is inconsistent
between 2.x and 3.x.  Example:

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> f = os.popen("exit 42", "r")
>>> f.close()
42


Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> f = os.popen("exit 42", "r")
>>> f.close()
10752
>>> divmod(10752, 256)
(42, 0)


The docs for 2.6.2 say that the return value is the exit status of the
process as returned by wait()
(http://docs.python.org/library/os.html#os.popen).  That's what 3.1 is
doing(*) but not what 2.6 has actually been doing.  In 2.6 the exit code
(not exit status) is returned; if the process didn't exit cleanly then
an exception is thrown.

The docs for 3.1 say that os.popen() is documented in the section "File
Object Creation" but it is not.
http://docs.python.org/3.1/library/os.html#process-management
http://docs.python.org/3.1/library/os.html#file-object-creation
It doesn't seem to be documented at all in 3.1 although it is mentioned
many times on that page.

Since os.popen() is mostly for backward compatibility, should the 3.x
behavior be changed to match the actual 2.6 behavior?

(*) It looks like 3.1 doesn't return the right value if the subprocess
is killed by a signal but I can't test this on win32.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 89792
nosy: abbeyj, georg.brandl
severity: normal
status: open
title: os.popen exit code inconsistent
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6358>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:32:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Jun 2009 21:32:24 +0000
Subject: [issue6286] distutils upload command doesn't work with http proxy
In-Reply-To: <1245059662.2.0.968328150082.issue6286@psf.upfronthosting.co.za>
Message-ID: <1246224744.67.0.0747289462193.issue6286@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

merged in 3.2 in r73645

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6286>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:33:25 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Jun 2009 21:33:25 +0000
Subject: [issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used
	for 'runtime_library_dirs'
In-Reply-To: <1243876957.94.0.533443517724.issue6164@psf.upfronthosting.co.za>
Message-ID: <1246224805.21.0.278579488126.issue6164@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

merged in 3.2 in r73647

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6164>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:35:24 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 28 Jun 2009 21:35:24 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1246224924.34.0.91105395368.issue6192@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Merged into py3k in revision 73648

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6192>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:36:06 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 28 Jun 2009 21:36:06 +0000
Subject: [issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
In-Reply-To: <1244111562.06.0.62559579479.issue6192@psf.upfronthosting.co.za>
Message-ID: <1246224966.74.0.349321825979.issue6192@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6192>
_______________________________________

From report at bugs.python.org  Sun Jun 28 23:49:30 2009
From: report at bugs.python.org (David Bremner)
Date: Sun, 28 Jun 2009 21:49:30 +0000
Subject: [issue6349] email.Maildir cannot roundtrip messages.
In-Reply-To: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>
Message-ID: <1246225770.47.0.0431553456782.issue6349@psf.upfronthosting.co.za>


David Bremner <bremner at unb.ca> added the comment:

that seems to fix my test script. Thanks. I guess the bug can be
closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6349>
_______________________________________

From report at bugs.python.org  Mon Jun 29 00:13:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Jun 2009 22:13:13 +0000
Subject: [issue6349] email.Maildir cannot roundtrip messages.
In-Reply-To: <1246137388.38.0.130457686116.issue6349@psf.upfronthosting.co.za>
Message-ID: <1246227193.08.0.0265652104886.issue6349@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yep :)

----------
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6349>
_______________________________________

From report at bugs.python.org  Mon Jun 29 00:43:23 2009
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 28 Jun 2009 22:43:23 +0000
Subject: [issue6359] pyexpat.c calls trace function incorrectly for exceptions
In-Reply-To: <1246229003.36.0.107970043042.issue6359@psf.upfronthosting.co.za>
Message-ID: <1246229003.36.0.107970043042.issue6359@psf.upfronthosting.co.za>


New submission from Ned Batchelder <nedbat at users.sourceforge.net>:

Pyexpat.c calls the tracing function explicitly (not sure why).  When it
intercepts an exception, it calls the function with PyTrace_EXCEPTION,
but then leaves the scope without calling PyTrace_RETURN.  This is
incorrect.  There should always be a PyTrace_RETURN for every PyTrace_CALL.

I've attached domshow.py to demonstrate the problem.

Running it produces many lines of output, including:

                     line expatbuilder.py 222
                     line expatbuilder.py 223
                     call pyexpat.c 905
                        call expatbuilder.py 892
                           line expatbuilder.py 894
                           line expatbuilder.py 900
                           exception expatbuilder.py 900
                           return expatbuilder.py 900
                        exception pyexpat.c 905
                        exception expatbuilder.py 223
                        line expatbuilder.py 225
                        line expatbuilder.py 226

The exception at line 905 in pyexpat.c should be followed with a return
from line 905 in pyexpat.c, but is not.  After that exception, the
nesting is off by one because the Calls and Returns don't match.

----------
components: XML
files: domshow.py
messages: 89798
nosy: nedbat
severity: normal
status: open
title: pyexpat.c calls trace function incorrectly for exceptions
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14379/domshow.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6359>
_______________________________________

From report at bugs.python.org  Mon Jun 29 00:49:07 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 28 Jun 2009 22:49:07 +0000
Subject: [issue6267] Cumulative patcc:h to http and xmlrpc
In-Reply-To: <1244734235.6.0.17264314682.issue6267@psf.upfronthosting.co.za>
Message-ID: <1246229347.44.0.68952923898.issue6267@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I'm working on the 3.2 port, it needs some manual work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6267>
_______________________________________

From report at bugs.python.org  Mon Jun 29 02:07:37 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Jun 2009 00:07:37 +0000
Subject: [issue1502517] crash in expat when compiling with --enable-profiling
Message-ID: <1246234057.79.0.740022101931.issue1502517@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I got this warning compiling Python3.1:
/home/wolf/Python-3.1/Modules/expat/xmlparse.c: In function ?doProlog?:
/home/wolf/Python-3.1/Modules/expat/xmlparse.c:3771: warning: passing
argument 1 of ?normalizePublicId? discards qualifiers from pointer
target type

I don't know if it's in any way related to this problem, but I found
this issue while searching for 'doProlog' and 'xmlparse'.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1502517>
_______________________________________

From report at bugs.python.org  Mon Jun 29 02:10:38 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 00:10:38 +0000
Subject: [issue6360] Simplify string decoding in xmlrpc.client.
In-Reply-To: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>
Message-ID: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

The following patch tries to improve how xmlrpc.client handles strings.
In particular, it simplifies the decoding of strings by keeping them as
unicode str.

----------
files: simplify_xmlrpc_string_decoding.diff
keywords: patch
messages: 89801
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify string decoding in xmlrpc.client.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14380/simplify_xmlrpc_string_decoding.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6360>
_______________________________________

From report at bugs.python.org  Mon Jun 29 02:19:35 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 00:19:35 +0000
Subject: [issue2480] eliminate recursion in pickling
In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
Message-ID: <1246234775.32.0.543185024395.issue2480@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I am closing this issue in favour of #3119, since Aaron's patch is
cleaner and slightly faster.

Thank you Daniel for the idea!

----------
dependencies:  -pickle.py is limited by python's call stack
resolution:  -> duplicate
status: open -> closed
superseder:  -> pickle.py is limited by python's call stack

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2480>
_______________________________________

From report at bugs.python.org  Mon Jun 29 02:49:53 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 00:49:53 +0000
Subject: [issue6361] I/O object wrappers shouldn't close their underlying file
	when deleted.
In-Reply-To: <1246236592.97.0.944471121329.issue6361@psf.upfronthosting.co.za>
Message-ID: <1246236592.97.0.944471121329.issue6361@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

Here's an example of the behaviour:

import io

def test(buf):
   textio = io.TextIOWrapper(buf)

buf = io.BytesIO()
test(buf)
print(buf.closed)  # This prints True currently


The problem here is TextIOWrapper closes its buffer when deleted.
BufferedRWPair behalves similarly. The solution is simply to override
the __del__ method of TextIOWrapper inherited from IOBase.

----------
messages: 89803
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: I/O object wrappers shouldn't close their underlying file when deleted.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6361>
_______________________________________

From report at bugs.python.org  Mon Jun 29 02:55:54 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Mon, 29 Jun 2009 00:55:54 +0000
Subject: [issue6362] multiprocessing: handling of errno after signals in
	sem_acquire()
In-Reply-To: <1246236953.98.0.347685302465.issue6362@psf.upfronthosting.co.za>
Message-ID: <1246236953.98.0.347685302465.issue6362@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

While developing an application, an inconsistency was noted where,
depending on the particular signal handler in use,
multiprocessing.Queue.put() may (or may not) raise OSError() after
sys.exit() was called by the handler. The following example, which was
tested with Python 2.6.1 on Linux, demonstrates this.

#!/usr/bin/env python

import multiprocessing
import signal
import sys

def handleKill(signum, frame):
   #sys.stdout.write("Exit requested by signal.\n")
   print "Exit requested by signal."
   sys.exit(1)
signal.signal(signal.SIGTERM, handleKill)

queue = multiprocessing.Queue(maxsize=1)
queue.put(None)
queue.put(None)

When the script is run, the process will block (as expected) on the
second queue.put(). If (from another terminal) I send the process
SIGTERM, I consistently see:

$ ./q.py
Exit requested by signal.
$

Now, if I modify the above program by commenting out the 'print', and
uncommenting the 'sys.stdout' (a very subtle change), I would expect
the result to be the same when killing the process. Instead, I
consistently see:

$ ./q.py
Exit requested by signal.
Traceback (most recent call last):
 File "./q.py", line 15, in <module>
   queue.put(None)
 File "python2.6/multiprocessing/queues.py", line 75, in put
   if not self._sem.acquire(block, timeout):
OSError: [Errno 0] Error
$ 

After debugging this further, the issue appears to be in
semlock_acquire() or semaphore.c in Modules/_multiprocessing:
http://svn.python.org/view/python/trunk/Modules/_multiprocessing/semaphore.c?revision=71009&view=markup

The relevant code from (the Unix version of) semlock_acquire() is:

do {
               Py_BEGIN_ALLOW_THREADS
               if (blocking && timeout_obj == Py_None)
                       res = sem_wait(self->handle);
               else if (!blocking)
                       res = sem_trywait(self->handle);
               else
                       res = sem_timedwait(self->handle, &deadline);
               Py_END_ALLOW_THREADS
               if (res == MP_EXCEPTION_HAS_BEEN_SET)
                       break;
       } while (res < 0 && errno == EINTR && !PyErr_CheckSignals());

       if (res < 0) {
               if (errno == EAGAIN || errno == ETIMEDOUT)
                       Py_RETURN_FALSE;
               else if (errno == EINTR)
                       return NULL;
               else
                       return PyErr_SetFromErrno(PyExc_OSError);
       }

In both versions of the program (print vs. sys.stdout), sem_wait() is
being interrupted and is returning -1 with errno set to EINTR. This is
what I expected. Also, in both cases it seems that the loop is
(correctly) terminating with PyErr_CheckSignals() returning non-zero.
This makes sense too; the call is executing our signal handler, and then
returning -1 since our particular handler raises SystemExit.

However, I suspect that depending on the exact code executed
for the signal handler, errno may or may not wind up being reset in
some nested call of PyErr_CheckSignals(). I believe that the
error checking code below the do-while (where sem_wait() is called),
needed errno to have the value set by sem_wait(), and the author
wasn't expecting anything else to have changed it. In the "print"
version, errno apparently winds up unchanged with EINTR, resulting in
the `return NULL' statement. In the "sys.stdout" version (and probably
many others), errno winds up being reset to 0, and the error handling
results in the `return PyErr_SetFromErrno(PyExc_OSError)' statement.

To patch this up, we can probably just save errno as, say, `wait_errno'
at the end of the loop body, and then use it within the error handling
block that follows. However, the rest of the code should probably be
checked for this type of issue.

----------
components: Library (Lib)
messages: 89804
nosy: ryles
severity: normal
status: open
title: multiprocessing: handling of errno after signals in sem_acquire()
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6362>
_______________________________________

From report at bugs.python.org  Mon Jun 29 02:56:45 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Mon, 29 Jun 2009 00:56:45 +0000
Subject: [issue6362] multiprocessing: handling of errno after signals in
	sem_acquire()
In-Reply-To: <1246236953.98.0.347685302465.issue6362@psf.upfronthosting.co.za>
Message-ID: <1246237005.75.0.856023634928.issue6362@psf.upfronthosting.co.za>


Changes by Ryan Leslie <rylesny at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6362>
_______________________________________

From report at bugs.python.org  Mon Jun 29 03:35:13 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Jun 2009 01:35:13 +0000
Subject: [issue6362] multiprocessing: handling of errno after signals in
	sem_acquire()
In-Reply-To: <1246236953.98.0.347685302465.issue6362@psf.upfronthosting.co.za>
Message-ID: <1246239313.07.0.87176534711.issue6362@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Thank you Ryan

----------
assignee:  -> jnoller
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6362>
_______________________________________

From report at bugs.python.org  Mon Jun 29 03:57:50 2009
From: report at bugs.python.org (Senthil)
Date: Mon, 29 Jun 2009 01:57:50 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
In-Reply-To: <1246210357.76.0.962835344996.issue1424152@psf.upfronthosting.co.za>
Message-ID: <20090629015739.GA4741@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

> 
> Senthil, are you still working on the 3.x version of the patch?

Sorry for the delay. I got to work on it. Shall start and shall try
to get it in soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Mon Jun 29 04:27:30 2009
From: report at bugs.python.org (Poor Yorick)
Date: Mon, 29 Jun 2009 02:27:30 +0000
Subject: [issue6363] __future__ statements break doctest
In-Reply-To: <1246242450.27.0.0341374672588.issue6363@psf.upfronthosting.co.za>
Message-ID: <1246242450.27.0.0341374672588.issue6363@psf.upfronthosting.co.za>


New submission from Poor Yorick <pooryorick at users.sourceforge.net>:

(this error also occurs with "print_function")

Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import unicode_literals
>>> import doctest
>>> def func1():
...    '''
...    >>> func1()
...    hello
...    '''
...    print('hello')
...
>>> doctest.testmod()
**********************************************************************
File "__main__", line 3, in __main__.func1
Failed example:
    func1()
Exception raised:
    Traceback (most recent call last):
      File "c:\Python31\lib\doctest.py", line 1242, in __run
        compileflags, 1), test.globs)
    ValueError: compile(): unrecognised flags
**********************************************************************
1 items had failures:
   1 of   1 in __main__.func1
***Test Failed*** 1 failures.
TestResults(failed=1, attempted=1)

----------
components: Library (Lib)
messages: 89807
nosy: pooryorick
severity: normal
status: open
title: __future__ statements break doctest
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6363>
_______________________________________

From report at bugs.python.org  Mon Jun 29 05:15:49 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 29 Jun 2009 03:15:49 +0000
Subject: [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>
Message-ID: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The freeze tool seems to be severely broken in Python 3.x. Applying it
to a "hello world" script produces:

Warning: unknown modules remain: _bisect _collections _ctypes _hashlib
_heapq _multiprocessing _pickle _random _socket _ssl _struct _tkinter
array atexit binascii datetime fcntl itertools math mmap operator
pyexpat readline select termios time

and a subsequent make results in

config.o:(.data+0x8): undefined reference to `init_codecs'
config.o:(.data+0x18): undefined reference to `init_functools'
config.o:(.data+0x28): undefined reference to `init_io'
config.o:(.data+0x38): undefined reference to `init_locale'
config.o:(.data+0x48): undefined reference to `init_sre'
config.o:(.data+0x58): undefined reference to `init_thread'
config.o:(.data+0x68): undefined reference to `init_weakref'
config.o:(.data+0x78): undefined reference to `initerrno'
config.o:(.data+0x88): undefined reference to `initgc'
config.o:(.data+0x98): undefined reference to `initimp'
config.o:(.data+0xa8): undefined reference to `initposix'
config.o:(.data+0xb8): undefined reference to `initpwd'
config.o:(.data+0xc8): undefined reference to `initsignal'
config.o:(.data+0xd8): undefined reference to `initzipimport'

----------
components: Demos and Tools
messages: 89808
nosy: hagen
severity: normal
status: open
title: freeze tool broken in Python 3.x
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6364>
_______________________________________

From report at bugs.python.org  Mon Jun 29 07:35:42 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Jun 2009 05:35:42 +0000
Subject: [issue6360] Simplify string decoding in xmlrpc.client.
In-Reply-To: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>
Message-ID: <1246253742.31.0.146738579062.issue6360@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Did you try these changes? Can you provide a test case?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6360>
_______________________________________

From report at bugs.python.org  Mon Jun 29 07:40:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Jun 2009 05:40:11 +0000
Subject: [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>
Message-ID: <1246254011.5.0.0329220633795.issue6364@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you like to provide a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6364>
_______________________________________

From report at bugs.python.org  Mon Jun 29 07:45:53 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 29 Jun 2009 05:45:53 +0000
Subject: [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246254011.5.0.0329220633795.issue6364@psf.upfronthosting.co.za>
Message-ID: <4A485496.7070804@gmx.net>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

> Would you like to provide a patch?

I wouldn't mind if someone beat me to it. But if that doesn't happen,
I'll look into it when I have some time to spare.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6364>
_______________________________________

From report at bugs.python.org  Mon Jun 29 07:55:06 2009
From: report at bugs.python.org (Brian)
Date: Mon, 29 Jun 2009 05:55:06 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1246254906.67.0.472909256824.issue4660@psf.upfronthosting.co.za>


Brian <brian at merrells.org> added the comment:

Filipe,

Thanks for the confirmation.  While I think the second option (ie 
properly protecting JoinableQueue.put()) is best, the first option 
(simply removing the 'task_done() called too many times' check) should 
be safe (presuming your get() and put() calls actually match).  

Jesse, any luck sorting out the best fix for this?  I really think that 
JoinableQueue (in my opinion the most useful form of multiprocessing 
queues) can't be guaranteed to work on any system right now.

-brian

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________

From report at bugs.python.org  Mon Jun 29 08:20:42 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 29 Jun 2009 06:20:42 +0000
Subject: [issue6365] distutils duplicates package directory for C extensions
	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

When compiling a C extension (lxml in this case) in Py3.1, calling the
"build_ext -i" distutils target duplicates the package path when writing
the dynlib. In this case, I get "lxml/lxml/etree.so" instead of
"lxml/etree.so". Obviously, the extension module cannot be found
afterwards, as it's not inside its package anymore. The extension is
named "lxml.etree" when creating the Extension object.

This is a regression from 3.1rc1 AFAICT.

----------
assignee: tarek
components: Distutils
messages: 89813
nosy: scoder, tarek
severity: normal
status: open
title: distutils duplicates package directory for C extensions in 3.1 final
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6365>
_______________________________________

From report at bugs.python.org  Mon Jun 29 08:27:11 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 06:27:11 +0000
Subject: [issue6360] Simplify string decoding in xmlrpc.client.
In-Reply-To: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>
Message-ID: <1246256831.34.0.557186270494.issue6360@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I didn't test the changes extensively. I ran the test suite and the
changes seemed to be correct.

It is a bit difficult to provide a test case, since the patch shouldn't
change how the code currently behave. Nevertheless, here is a simple
example:

#!/usr/bin/python3.2
# xmlclient.py
import xmlrpc.client
server_proxy = xmlrpc.client.ServerProxy("http://localhost:8000")
print(server_proxy.print_str("?tre ? montr?al"))

#!/usr/bin/python2.6
# xmlserve.py
from SimpleXMLRPCServer import SimpleXMLRPCServer
def print_str(s):
  return (repr(type(s)), repr(s)) 
server = SimpleXMLRPCServer(("localhost", 8000))
server.register_function(print_str)
server.serve_forever()

And here's a sample run:

alex at helios:py3k$ python2.6 ./xmlserve.py > /dev/null &
alex at helios:py3k$ ./python ./xmlclient.py 
["<type 'str'>", "'Bonjour'"]
["<type 'unicode'>", "u'Je suis \\xe0 Montr\\xe9al'"]
[56836 refs]
alex at helios:py3k$ patch -p0 < simplify_xmlrpc_string_decoding.diff 
patching file Lib/xmlrpc/client.py
alex at helios:py3k$ ./python ./xmlclient.py 
["<type 'str'>", "'Bonjour'"]
["<type 'unicode'>", "u'Je suis \\xe0 Montr\\xe9al'"]
[56877 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6360>
_______________________________________

From report at bugs.python.org  Mon Jun 29 08:30:06 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 06:30:06 +0000
Subject: [issue6360] Simplify string decoding in xmlrpc.client.
In-Reply-To: <1246234237.97.0.0894396904771.issue6360@psf.upfronthosting.co.za>
Message-ID: <1246257006.23.0.37537253246.issue6360@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Oops, I forgot to update my client in my last message. The sample trace
run should make more sense now.

#!/usr/bin/python3.2
# xmlclient.py
import xmlrpc.client
server_proxy = xmlrpc.client.ServerProxy("http://localhost:8000")
print(server_proxy.print_str("Bonjour"))
print(server_proxy.print_str("Je suis ? Montr?al"))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6360>
_______________________________________

From report at bugs.python.org  Mon Jun 29 08:33:16 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 06:33:16 +0000
Subject: [issue1761028] pickle - cannot unpickle circular deps with custom
	__hash__
Message-ID: <1246257196.99.0.0737701312703.issue1761028@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1761028>
_______________________________________

From report at bugs.python.org  Mon Jun 29 08:42:17 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 06:42:17 +0000
Subject: [issue558238] Pickling bound methods
Message-ID: <1246257737.78.0.580166657894.issue558238@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I am leaving this issue open for now.

I reconsidered whether we should add pickle support for methods and I
now think it would probably be a good idea. For example, the
multiprocessing module would benefit from a having built-in support for
method pickling (right now, it has to subclass Pickler to pickle methods).

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue558238>
_______________________________________

From report at bugs.python.org  Mon Jun 29 08:52:03 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 06:52:03 +0000
Subject: [issue1214] Timeout in CGIXMLRPCRequestHandler under IIS
In-Reply-To: <1190910356.54.0.93332478952.issue1214@psf.upfronthosting.co.za>
Message-ID: <1246258323.21.0.938863616583.issue1214@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

This has been fixed in 2.6 and 3.x.

Closing.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1214>
_______________________________________

From report at bugs.python.org  Mon Jun 29 08:57:50 2009
From: report at bugs.python.org (obamausa8)
Date: Mon, 29 Jun 2009 06:57:50 +0000
Subject: [issue558238] Pickling bound methods
Message-ID: <1246258670.21.0.999530243332.issue558238@psf.upfronthosting.co.za>


obamausa8 <obamausa8 at gmail.com> added the comment:

This is an interesting discussion.. thank you for sharing.



[url=http://pret-auto.org][color=#FFFFFF][u]pret auto[/u][/color][/url]

----------
nosy: +obamausa8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue558238>
_______________________________________

From report at bugs.python.org  Mon Jun 29 09:10:10 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 29 Jun 2009 07:10:10 +0000
Subject: [issue558238] Pickling bound methods
Message-ID: <1246259410.98.0.812755749268.issue558238@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue558238>
_______________________________________

From report at bugs.python.org  Mon Jun 29 09:22:09 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Jun 2009 07:22:09 +0000
Subject: [issue6365] distutils duplicates package directory for C extensions
	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246260129.59.0.711838104118.issue6365@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I've spotted the problem, it's a wrong usage of build_py.get_package_dir
in build_ext.get_ext_fullpath,

I'll add a test + a fix today asap,

----------
priority:  -> normal
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6365>
_______________________________________

From report at bugs.python.org  Mon Jun 29 10:13:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 08:13:14 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1246263194.46.0.66032474934.issue4856@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The functions Py_GetFileAttributesExA and Py_GetFileAttributesExW were
not removed. Is it intended?

----------
assignee:  -> ocean-city
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Mon Jun 29 11:50:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 09:50:56 +0000
Subject: [issue6357] tempfile.NamedTemporaryFile does not accept the delete=
	parameter on Windows
In-Reply-To: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>
Message-ID: <1246269056.29.0.664736847786.issue6357@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Are you sure to use the same version? 'delete' is new in 2.7.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6357>
_______________________________________

From report at bugs.python.org  Mon Jun 29 11:55:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Jun 2009 09:55:37 +0000
Subject: [issue6365] distutils duplicates package directory for C extensions
	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246269337.35.0.480828494642.issue6365@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I figured out the problem after writing the test. This is not a problem
on distutils side but on setuptools side. If you remove setuptools from
lxml setup.py, it'll work perfectly.

setuptools patches distutils's build_ext and remove temporarely the
inplace option, so the code on distutils side that goes with the inplace
option is not called...

extract from setuptools.

{{{
    def run(self):
        """Build extensions in build directory, then copy if --inplace"""
        old_inplace, self.inplace = self.inplace, 0
        _build_ext.run(self)
        self.inplace = old_inplace
        if old_inplace:
            self.copy_extensions_to_source()

}}}

So this problem should be fixed on setuptools side.

----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6365>
_______________________________________

From report at bugs.python.org  Mon Jun 29 11:57:59 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 29 Jun 2009 09:57:59 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1246269479.1.0.302471879997.issue4856@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Oops, sorry. This function is not needed if GetFileAttributesEx never
fail with ERROR_CALL_NOT_IMPLEMENTED. I believe this won't happen on win
NT. How about this patch?

----------
Added file: http://bugs.python.org/file14381/remove_unused_function.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Mon Jun 29 12:13:51 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Jun 2009 10:13:51 +0000
Subject: [issue6365] distutils duplicates package directory for C extensions
	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246270431.01.0.540330606029.issue6365@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6365>
_______________________________________

From report at bugs.python.org  Mon Jun 29 12:14:02 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Jun 2009 10:14:02 +0000
Subject: [issue6365] distutils duplicates package directory for C extensions
	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246270442.82.0.767016331195.issue6365@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution: invalid -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6365>
_______________________________________

From report at bugs.python.org  Mon Jun 29 13:04:25 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 29 Jun 2009 11:04:25 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1246273465.2.0.863096167535.issue6344@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

OK, how about this patch?

----------
Added file: http://bugs.python.org/file14382/fix_mmap_read.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Mon Jun 29 13:09:29 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 11:09:29 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1246273769.54.0.383402296595.issue4856@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, that's what I had in mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Mon Jun 29 13:39:24 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 29 Jun 2009 11:39:24 +0000
Subject: [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1246275564.63.0.919694475071.issue4856@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, committed in r73675(trunk) and r73676(py3k).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4856>
_______________________________________

From report at bugs.python.org  Mon Jun 29 13:46:07 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 11:46:07 +0000
Subject: [issue6361] I/O object wrappers shouldn't close their underlying file
	when deleted.
In-Reply-To: <1246236592.97.0.944471121329.issue6361@psf.upfronthosting.co.za>
Message-ID: <1246275967.55.0.634394959558.issue6361@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can call the detach() method if you don't want to the underlying
stream to be closed.
We could also add a close_parent attribute defaulting to True.

----------
components: +IO
nosy: +benjamin.peterson, pitrou
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6361>
_______________________________________

From report at bugs.python.org  Mon Jun 29 13:46:24 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Jun 2009 11:46:24 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1246275984.03.0.474769425381.issue4660@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'm leaning towards the properly protecting JoinableQueue.put() fix, I'm 
not a terribly big fan of removing error checking. I'm trying to carve off 
time this week to beat on my bug queue, so I'm hoping to be able to commit 
something (once I have docs+tests) this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________

From report at bugs.python.org  Mon Jun 29 13:48:34 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 11:48:34 +0000
Subject: [issue1474680] pickling files works with protocol=2.
Message-ID: <1246276114.8.0.394467493424.issue1474680@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pickling a file is tricky. You can't just pickle the construction
parameters, you also need to save (and restore) the whole buffering
state. I'm not sure a half-working pickle solution would make a good
service to the user.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1474680>
_______________________________________

From report at bugs.python.org  Mon Jun 29 14:04:15 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 12:04:15 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1246277055.66.0.310876162353.issue6344@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

OK for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Mon Jun 29 14:58:19 2009
From: report at bugs.python.org (Jerry Chen)
Date: Mon, 29 Jun 2009 12:58:19 +0000
Subject: [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>
Message-ID: <1246280299.0.0.628250812343.issue6364@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

I am unable to reproduce with py3k latest r73676 after making and
installing, and running

$ python3.2 freeze.py hello.py

# on OS X 10.5.7
$ uname -a
Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009;
root:xnu-1228.12.14~1/RELEASE_I386 i386

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6364>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:27:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 13:27:06 +0000
Subject: [issue6366] rare assertion failure in test_multiprocessing
In-Reply-To: <1246282026.12.0.299929398487.issue6366@psf.upfronthosting.co.za>
Message-ID: <1246282026.12.0.299929398487.issue6366@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Just got the following non-reproducible failure in test_multiprocessing
on py3k. Python was compiled in non-debug mode so I assume the strange
failure message is a multiprocessing feature?

8e25dcc:       refcount=1
    <queue.Queue object at 0x8e25dcc>
  8e25f6c:       refcount=1
    <threading._Event object at 0x8e25f6c>
  8e3774c:       refcount=1
    <queue.Queue object at 0x8e3774c>
  8e377ac:       refcount=1
    <threading._Event object at 0x8e377ac>
  b785a08c:       refcount=2
    <multiprocessing.pool.Pool object at 0xb785a08c>
  8e25dcc:       refcount=1
    <queue.Queue object at 0x8e25dcc>
  8e25f6c:       refcount=1
    <threading._Event object at 0x8e25f6c>
  8e3774c:       refcount=1
    <queue.Queue object at 0x8e3774c>
  8e377ac:       refcount=1
    <threading._Event object at 0x8e377ac>
  b785a08c:       refcount=2
    <multiprocessing.pool.Pool object at 0xb785a08c>
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 1070, in test_number_of_objects
    self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 5 != 1

----------
assignee: jnoller
components: Library (Lib)
messages: 89832
nosy: jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: rare assertion failure in test_multiprocessing
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6366>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:30:40 2009
From: report at bugs.python.org (vinoth)
Date: Mon, 29 Jun 2009 13:30:40 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>
Message-ID: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>


New submission from vinoth <4vinoth at gmail.com>:

HI all 

I am not the too technical guy, but thinking about the new way of
controlling the flow instead of throwing an error.

as of now if we need to break a control and go back exceptions helps,
but it is not a actual way. 

it would be great if we have a control over the frames execution, I mean

A  calls B calls C calls D 

at that point if we think to move directly to B (what error handler do
if that B has the handler defined of the error), changing the frames
instruction pointer to back to the B's position (in python code without
raising an exception) is a really useful for this web applications.

Please excuse me if we have this control already, (can u explain?)

Thanks 
Vinoth

----------
components: Interpreter Core
messages: 89833
nosy: vinoth
severity: normal
status: open
title: Change the instruction pointer in python
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:35:38 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 29 Jun 2009 13:35:38 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>
Message-ID: <1246282538.83.0.920641943094.issue6367@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

You're talking about adding a non-local goto feature to the language. 
This would be a huge change, and not one that is generally in the
direction that any widespread languages (let alone Python itself) are
going these days.

Please raise this on one of the mailing lists (python-list or
python-ideas), fill out all of the details of how this would work, build
some community support for the feature, write a PEP, and then submit the
PEP to python-dev for consideration.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:38:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Jun 2009 13:38:13 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>
Message-ID: <1246282693.68.0.681545246799.issue6367@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:44:46 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 29 Jun 2009 13:44:46 +0000
Subject: [issue6357] tempfile.NamedTemporaryFile does not accept the delete=
	parameter on Windows
In-Reply-To: <1246269056.29.0.664736847786.issue6357@psf.upfronthosting.co.za>
Message-ID: <eae285400906290644p341a255kbdf1ef3b8dc0c55@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Yes, I'm sure.? See below.

Also, the 2.6 docs mention it as being new in 2.6:
http://docs.python.org/library/tempfile.html

Cashew:~$ python2.6
Python 2.6.2 (r262:71600, Apr 15 2009, 07:20:39)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.NamedTemporaryFile('w', delete=True)
<open file '<fdopen>', mode 'w' at 0x7ff1e480>
>>>

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6357>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:50:06 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Jun 2009 13:50:06 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1246283406.24.0.308151169574.issue6064@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

+1 to this, and I'd need to make the same patch/change to 
multiprocessing.Process as well

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:50:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 29 Jun 2009 13:50:50 +0000
Subject: [issue4536] SystemError if invalid arguments passed to range() and
	step=-1
In-Reply-To: <1228425636.98.0.0937158312047.issue4536@psf.upfronthosting.co.za>
Message-ID: <1246283450.57.0.546858971926.issue4536@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Seems to be fixed in current 3k head.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4536>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:52:10 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Jun 2009 13:52:10 +0000
Subject: [issue6269] threading documentation makes no mention of the GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1246283530.73.0.465037954352.issue6269@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I strongly disagree with the wording of the patch as-is. It makes no 
mention of the simple fact that I/O blocked threads get a benefit with 
threading, and so on.

I do agree with adding some details about this in the core documentation 
however.

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:54:35 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Jun 2009 13:54:35 +0000
Subject: [issue5879] multiprocessing - example "pool of http servers " fails
	on windows "socket has no attribute fromfd"
In-Reply-To: <1241019482.48.0.575158847578.issue5879@psf.upfronthosting.co.za>
Message-ID: <1246283675.43.0.0637731277309.issue5879@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5879>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:54:40 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Mon, 29 Jun 2009 13:54:40 +0000
Subject: [issue6368] Fix unused variable warning introduced by commit r73603.
In-Reply-To: <1246283680.73.0.478947993554.issue6368@psf.upfronthosting.co.za>
Message-ID: <1246283680.73.0.478947993554.issue6368@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attach patch fixes an unused variable warning introduced by commit r73603.

----------
components: Build
files: fix_unused_var_jun_29_2009.patch
keywords: patch
messages: 89839
nosy: vshenoy
severity: normal
status: open
title: Fix unused variable warning introduced by commit r73603.
versions: Python 2.7
Added file: http://bugs.python.org/file14383/fix_unused_var_jun_29_2009.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6368>
_______________________________________

From report at bugs.python.org  Mon Jun 29 15:55:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 13:55:32 +0000
Subject: [issue6152] Parallel regression testing
In-Reply-To: <1243732308.89.0.428199385474.issue6152@psf.upfronthosting.co.za>
Message-ID: <1246283732.38.0.841114456926.issue6152@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ported to py3k in r73678.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6152>
_______________________________________

From report at bugs.python.org  Mon Jun 29 16:31:11 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 14:31:11 +0000
Subject: [issue6357] tempfile.NamedTemporaryFile does not accept the delete=
	parameter on Windows
In-Reply-To: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>
Message-ID: <1246285871.71.0.594118044898.issue6357@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Which version do you use on Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6357>
_______________________________________

From report at bugs.python.org  Mon Jun 29 16:36:19 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 14:36:19 +0000
Subject: [issue6369] binhex buggy in py3k
In-Reply-To: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>
Message-ID: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The binhex module is buggy in py3k, witness the following example (it
works ok on trunk):

>>> binhex.binhex("README", "testA")
>>> binhex.hexbin("testA", "outA")
>>> binhex.binhex("LICENSE", "testB")
>>> binhex.hexbin("testB", "outB")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 445, in hexbin
    ifp = HexBin(inp)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 364, in __init__
    self._readheader()
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 384, in _readheader
    rest = self._read(1 + 4 + 4 + 2 + 4 + 4)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 367, in _read
    data = self.ifp.read(len)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 300, in read
    self._fill(wtd - len(self.post_buffer))
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 337, in _fill
    binascii.rledecode_hqx(self.pre_buffer[:mark])
binascii.Error: Orphaned RLE code at start

----------
components: Library (Lib)
messages: 89842
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: binhex buggy in py3k
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6369>
_______________________________________

From report at bugs.python.org  Mon Jun 29 16:39:15 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 29 Jun 2009 14:39:15 +0000
Subject: [issue6357] tempfile.NamedTemporaryFile does not accept the delete=
	parameter on Windows
In-Reply-To: <1246285871.71.0.594118044898.issue6357@psf.upfronthosting.co.za>
Message-ID: <eae285400906290739p74f45d57la4d551d6d7199d31@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

C:\>c:\python26\python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.NamedTemporaryFile('w', delete=true)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'true' is not defined
>>>

Hope that helps :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6357>
_______________________________________

From report at bugs.python.org  Mon Jun 29 16:44:07 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 14:44:07 +0000
Subject: [issue6357] tempfile.NamedTemporaryFile does not accept the delete=
	parameter on Windows
In-Reply-To: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>
Message-ID: <1246286647.03.0.8564230635.issue6357@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, please try with a capitalized "True"...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6357>
_______________________________________

From report at bugs.python.org  Mon Jun 29 16:50:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Jun 2009 14:50:25 +0000
Subject: [issue6369] binhex buggy in py3k
In-Reply-To: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>
Message-ID: <1246287025.24.0.710832148778.issue6369@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The bug is due to bytes-indexing returning an int in py3k while it
returns another bytes object in trunk. Here is a patch. I don't know how
to reliably test for it, though.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file14384/binhex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6369>
_______________________________________

From report at bugs.python.org  Mon Jun 29 16:56:28 2009
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Jun 2009 14:56:28 +0000
Subject: [issue6370] Bad performance of colllections.Counter at initialisation
	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>


New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:

I'm comparing initialisation of Counter from an iterable with the
following function:

def unique(seq):
	"""Dict of unique values (keys) & their counts in original sequence"""

	out_dict = dict.fromkeys(set(seq), 0)
	for i in seq:
		out_dict[i] += 1
	return out_dict


iterable = list(range(43)) + list(range(43, 0, -1))

The timeit-obtained values show that it takes Counter four (4) times
longer to finish. As it's obvious from comparing my function and lines
429-430 of collections.py the only difference is preallocating the final
dictionary. When line 430 of collections is replaced with:

self[elem] = self.get(elem, 0) + 1

I was able to get about 25% time-performance increase (I assume
__missing__ is bypassed). I hope that it's possible to improve its
implementation even further.

----------
components: Library (Lib)
messages: 89846
nosy: SilentGhost
severity: normal
status: open
title: Bad performance of colllections.Counter at initialisation from an iterable
type: performance
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6370>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:04:04 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 29 Jun 2009 15:04:04 +0000
Subject: [issue6371] Minor internal link errors in Optparse doc
In-Reply-To: <1246287843.59.0.00928118566027.issue6371@psf.upfronthosting.co.za>
Message-ID: <1246287843.59.0.00928118566027.issue6371@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

A minor detail in optparse documentation :
"If optparse?s default error-handling behaviour does not suit your
needs, you?ll need to subclass OptionParser and override its exit()
and/or error() methods."
-> the links put on exit() and error() are wrong (the latter isn't set,
the former links to another exit() symbol.

Regards, 
Pascal

----------
assignee: georg.brandl
components: Documentation
messages: 89847
nosy: georg.brandl, pakal
severity: normal
status: open
title: Minor internal link errors in Optparse doc
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6371>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:07:32 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jun 2009 15:07:32 +0000
Subject: [issue6370] Bad performance of colllections.Counter at initialisation
	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246288052.63.0.942147633647.issue6370@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6370>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:09:12 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 29 Jun 2009 15:09:12 +0000
Subject: [issue6357] tempfile.NamedTemporaryFile does not accept the delete=
	parameter on Windows
In-Reply-To: <1246220666.51.0.756681443001.issue6357@psf.upfronthosting.co.za>
Message-ID: <1246288152.21.0.720687492673.issue6357@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Oy vey.  That's what I get for not reading carefully.  And in my
original example it seems I had a python 2.5 install wandering around in
my path.  My apologies.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6357>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:10:29 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 29 Jun 2009 15:10:29 +0000
Subject: [issue6344] mmap.read() crashes when passed a negative argument
In-Reply-To: <1245964948.96.0.802532537301.issue6344@psf.upfronthosting.co.za>
Message-ID: <1246288229.33.0.380218729981.issue6344@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, committed in r73677(trunk), r73682(release26-maint),
r73684(py3k), r73685(release31-maint).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6344>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:21:04 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Mon, 29 Jun 2009 15:21:04 +0000
Subject: [issue6372] Make all switches keyword-only
In-Reply-To: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>
Message-ID: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>


New submission from Pablo Torres Navarrete <tn.pablo at gmail.com>:

I propose that all formal parameters that really act as options/switches
be made keyword-only.  Examples of switches are all flags, timeouts,
'verbose' bools, maximums and minimums, etc.

This stresses the difference between needed input for a function and an
argument that changes/extends the behavior.  Besides, the code would be
more readable, because instead of having some cryptic function call like
register('Pablo Torres', 2, 4, 5, False) you would have the prettier
register('Pablo Torres', hour=2, min=4, sec=5, had_reservation=False).

The implementation would just require putting a star '*' before all
options, according to pep 3102.

If needed, I can rewrite this as a PEP.

----------
components: Library (Lib)
messages: 89850
nosy: ptn
severity: normal
status: open
title: Make all switches keyword-only
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6372>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:30:03 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Jun 2009 15:30:03 +0000
Subject: [issue6372] Make all switches keyword-only
In-Reply-To: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>
Message-ID: <1246289403.22.0.457091790207.issue6372@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I suspect it would require a PEP, since it would mean breaking backward
compatibility in a rather extensive fashion.  I suggest floating this
idea on python-ideas first for feedback.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6372>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:31:25 2009
From: report at bugs.python.org (Glynn Clements)
Date: Mon, 29 Jun 2009 15:31:25 +0000
Subject: [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>


New submission from Glynn Clements <glynn at gclements.plus.com>:

Test case:

> "\udce4\udceb\udcef\udcf6\udcfc".encode("iso-8859-1", "surrogateescape")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/bytesobject.c:3182: bad argument to internal function

The line number corresponds to _PyBytes_Resize()

----------
components: Interpreter Core, Unicode
messages: 89852
nosy: glynnc
severity: normal
status: open
title: SystemError in encoder
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6373>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:45:46 2009
From: report at bugs.python.org (Jerry Chen)
Date: Mon, 29 Jun 2009 15:45:46 +0000
Subject: [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246290346.2.0.689462956691.issue6373@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

gdb trace

Breakpoint 1, _PyBytes_Resize (pv=0xbfffec3c, newsize=-495723) at
Objects/bytesobject.c:3179
3179		if (!PyBytes_Check(v) || Py_REFCNT(v) != 1 || newsize < 0) {
(gdb) where
#0  _PyBytes_Resize (pv=0xbfffec3c, newsize=-495723) at
Objects/bytesobject.c:3179
#1  0x0006fc07 in unicode_encode_ucs1 (p=0x3c3b8a, size=-1073746884,
errors=0x441ad0 "surrogateescape", limit=256) at
Objects/unicodeobject.c:4253
#2  0x000fafe7 in latin_1_encode (self=0x334490, args=0xbfffec3c) at
_codecsmodule.c:939
#3  0x000084a9 in PyObject_Call (func=0x3419b8, arg=0x3c9d28, kw=0x0) at
Objects/abstract.c:2160
#4  0x000a203e in PyEval_CallObjectWithKeywords (func=0x3419b8,
arg=0x441ae0, kw=0xbfffec3c) at Python/ceval.c:3694
#5  0x000b6c3b in PyCodec_Encode (object=0xbfffec3c, encoding=0xbfffec3c
"?\032D", errors=0x441d70 "surrogateescape") at Python/codecs.c:354
#6  0x000701c6 in PyUnicodeUCS2_AsEncodedString (unicode=0x4497c0,
encoding=0x441a30 "iso-8859-1", errors=0x441d70 "surrogateescape") at
Objects/unicodeobject.c:1420
#7  0x0007038c in unicode_encode (self=0x4497c0, args=0xbfffec3c) at
Objects/unicodeobject.c:7150
#8  0x000a71d8 in PyEval_EvalFrameEx (f=0x22e590, throwflag=0) at
Python/ceval.c:3814
#9  0x000a8beb in PyEval_EvalCodeEx (co=0x3aa698, globals=0x34c270,
locals=0x34c270, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3237
#10 0x000a8dbf in PyEval_EvalCode (co=0xbfffec3c, globals=0xbfffec3c,
locals=0xbfffec3c) at Python/ceval.c:651
#11 0x000cf473 in PyRun_InteractiveOneFlags (fp=0xa02e15e0,
filename=0x123994 "<stdin>", flags=0xbffff77c) at Python/pythonrun.c:1697
#12 0x000cf723 in PyRun_InteractiveLoopFlags (fp=0xa02e15e0,
filename=0x123994 "<stdin>", flags=0xbffff77c) at Python/pythonrun.c:993
#13 0x000cfa89 in PyRun_AnyFileExFlags (fp=0xa02e15e0, filename=0x123994
"<stdin>", closeit=0, flags=0xbffff77c) at Python/pythonrun.c:962
#14 0x000e47d0 in Py_Main (argc=1, argv=0x2015b0) at Modules/main.c:625
#15 0x00002599 in main (argc=1, argv=0xbffff8cc) at python.c:152

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6373>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:47:38 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 29 Jun 2009 15:47:38 +0000
Subject: [issue6374] Confused by subprocess API documentation
In-Reply-To: <1246290458.09.0.216781852955.issue6374@psf.upfronthosting.co.za>
Message-ID: <1246290458.09.0.216781852955.issue6374@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

I feel the description of the subprocess.popen semantics is a little
incomplete/confusing to me, on some points, eg. :
- what does the "shell" argument do on windows, exactly ? The beginning
of the description states that nothing changes (createProcess() is used
in any way), but later "COMSPEC" and "shell" are quoted, and their
effect is unclear on windows...  
-"If cwd is not None, the child?s current directory will be changed to
cwd before it is executed. Note that this directory is not considered
when searching the executable, so you can?t specify the program?s path
relative to cwd." -> maybe we should precise that only the "executable"
argument is concerned, not the 'executable' program name which might be
given as first item in "args" argument (and which is, on the contrary,
searched relatively to "cwd" argument)
-for the "bufsize" argument, it would be handy to precise which buffer
size is set (of which file descriptors exactly ? Of Pipes only ?)

Regards, 
P. Chambon

----------
assignee: georg.brandl
components: Documentation
messages: 89854
nosy: georg.brandl, pakal
severity: normal
status: open
title: Confused by subprocess API documentation
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6374>
_______________________________________

From report at bugs.python.org  Mon Jun 29 17:58:51 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Jun 2009 15:58:51 +0000
Subject: [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246291131.41.0.339488120055.issue6373@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +loewis
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6373>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:00:31 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 29 Jun 2009 16:00:31 +0000
Subject: [issue6368] Fix unused variable warning introduced by commit r73603.
In-Reply-To: <1246283680.73.0.478947993554.issue6368@psf.upfronthosting.co.za>
Message-ID: <1246291231.09.0.210799727354.issue6368@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Fixed in r73686(trunk).

----------
nosy: +ocean-city
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6368>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:07:18 2009
From: report at bugs.python.org (Tim Golden)
Date: Mon, 29 Jun 2009 16:07:18 +0000
Subject: [issue6374] Confused by subprocess API documentation
In-Reply-To: <1246290458.09.0.216781852955.issue6374@psf.upfronthosting.co.za>
Message-ID: <4A48E6BD.4060802@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Attached is a patch against r73685 of the documentation for subprocess
which adds some information about using shell=True on Windows. I plan
to do some more general-purpose docs for subprocess on Windows, but as 
I've failed to get round to them for a year or so, let's get this small
change in at least!

----------
keywords: +patch
nosy: +tim.golden
Added file: http://bugs.python.org/file14385/doc-subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6374>
_______________________________________
-------------- next part --------------
Index: subprocess.rst
===================================================================
--- subprocess.rst	(revision 73685)
+++ subprocess.rst	(working copy)
@@ -73,7 +73,11 @@
    needed: Usually, the program to execute is defined by the *args* argument. If
    ``shell=True``, the *executable* argument specifies which shell to use. On Unix,
    the default shell is :file:`/bin/sh`.  On Windows, the default shell is
-   specified by the :envvar:`COMSPEC` environment variable.
+   specified by the :envvar:`COMSPEC` environment variable. The only reason you
+   would need to specify ``shell=True`` on Windows is where the command you
+   wish to execute is actually built in to the shell, eg ``dir``, ``copy``.
+   You don't need ``shell=True`` to run a batch file, nor to run a console-based
+   executable.
 
    *stdin*, *stdout* and *stderr* specify the executed programs' standard input,
    standard output and standard error file handles, respectively.  Valid values

From report at bugs.python.org  Mon Jun 29 18:11:16 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jun 2009 16:11:16 +0000
Subject: [issue6370] Bad performance of colllections.Counter at initialisation
	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246291876.47.0.886916138579.issue6370@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Your proposed function assumes the input is a sequence and it cannot
handle not a general purpose iterable (it gives the wrong answer when
the latter is submitted).

Also, it does two lookups per item which can be expensive if the
elements have costly hash functions (such as Decimal objects, tuple
objects, and strings that haven't been interned).  

And, it does not return a dict subclass, so it cannot provide all of the
methods currently offered by Counter (such as most_common() and
elements()), nor does it override regular dict methods that do not make
sense for counters (such as the update() method).

Test data:

# case that give *wrong* answer because the input isn't reiterable
>>> unique(c.lower() for c in 'Abracadabra')

# case that is slower because of expensive multiple lookups
>>> unique([abs(Decimal(x)/4) for x in range(-2000, 2000)])

# case that fails because update() was not overridden
>>> c = unique(range(10))
>>> c.update(range(5))

# cases that do not provide needed subclass methods
>>> unique('abracadabra').most_common()
>>> unique('abracadabra').elements()

Though the code for unique() is hopeless, I will take a look at the
"self[elem] = self.get(elem, 0) + 1" approach.  That shows some promise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6370>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:17:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 16:17:16 +0000
Subject: [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246292236.64.0.798207580559.issue6373@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's a bug in unicode_encode_ucs1: the result string is resized, so 
   str = PyBytes_AS_STRING(res) + (someOffset)
is not valid anymore.

Attached patch+test.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14386/issue6373.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6373>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:23:24 2009
From: report at bugs.python.org (Jerry Chen)
Date: Mon, 29 Jun 2009 16:23:24 +0000
Subject: [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246292604.96.0.0479973140019.issue6373@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

Confirmed patch and test are working

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6373>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:30:41 2009
From: report at bugs.python.org (Adam Golebiowski)
Date: Mon, 29 Jun 2009 16:30:41 +0000
Subject: [issue6375] compile failure in Modules/python.c
In-Reply-To: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>
Message-ID: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>


New submission from Adam Golebiowski <adamg at pld-linux.org>:

Python-3.1 fails to compile with:
./Modules/python.c: In function 'wchar_t* char2wchar(char*)':
./Modules/python.c:60: error: invalid conversion from 'void*' to 'wchar_t*'

The attached patch fixes this.

----------
files: python3-cast-fix.patch
keywords: patch
messages: 89860
nosy: adamg
severity: normal
status: open
title: compile failure in Modules/python.c
versions: Python 3.1
Added file: http://bugs.python.org/file14387/python3-cast-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6375>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:33:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 29 Jun 2009 16:33:27 +0000
Subject: [issue6372] Make all switches keyword-only
In-Reply-To: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>
Message-ID: <1246293207.01.0.389039378165.issue6372@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing this for now; it really needs some serious discussion so a
tracker item is not appropriate.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6372>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:34:47 2009
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Mon, 29 Jun 2009 16:34:47 +0000
Subject: [issue6376] description of Decinal.logical_invert is incorrect
In-Reply-To: <1246293287.33.0.612180884137.issue6376@psf.upfronthosting.co.za>
Message-ID: <1246293287.33.0.612180884137.issue6376@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

The library reference of Decimal.logical_invert:
   .. method:: logical_invert(other[, context])

      :meth:`logical_invert` is a logical operation.  The argument must
      be a *logical operand* (see :ref:`logical_operands_label`).  The
      result is the digit-wise inversion of the operand.

There should not be "other" argument, since it's an unary operation.

----------
assignee: georg.brandl
components: Documentation
messages: 89862
nosy: georg.brandl, mft
severity: normal
status: open
title: description of Decinal.logical_invert is incorrect
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6376>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:36:37 2009
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Jun 2009 16:36:37 +0000
Subject: [issue6370] Bad performance of colllections.Counter at initialisation
	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246293397.43.0.379866932366.issue6370@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

I've never meant to suggest any kind of replacement of the Counter with
my example. I just tried to show that 

self[elem] += 1    # line 430 of collections.py

which at initialisation naturally propagates to __missing__ is somewhat
slow. and had it been possible to always have key in the Counter, it
might have speed up initialisation and/or update

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6370>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:42:55 2009
From: report at bugs.python.org (Jerry Chen)
Date: Mon, 29 Jun 2009 16:42:55 +0000
Subject: [issue6375] compile failure in Modules/python.c
In-Reply-To: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>
Message-ID: <1246293775.68.0.701109321522.issue6375@psf.upfronthosting.co.za>


Jerry Chen <jerry at 3rdengine.com> added the comment:

On OpenBSD by chance? Looks similar to Issue4146

----------
nosy: +jcsalterego

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6375>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:48:39 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Jun 2009 16:48:39 +0000
Subject: [issue6365] distutils duplicates package directory for C extensions
	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246294119.33.0.223308089485.issue6365@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed in r73688 (trunk), r73689 (py3k), r73692 (3.1.x)

Thanks for the feedback, Stefan.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6365>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:48:46 2009
From: report at bugs.python.org (Adam Golebiowski)
Date: Mon, 29 Jun 2009 16:48:46 +0000
Subject: [issue6375] compile failure in Modules/python.c
In-Reply-To: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>
Message-ID: <1246294126.5.0.915948003287.issue6375@psf.upfronthosting.co.za>


Adam Golebiowski <adamg at pld-linux.org> added the comment:

nope, a gcc-4.4 based Linux distribution.

It looks like the same problem happens with Issue4146, but it touches
other part of that file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6375>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:48:50 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Jun 2009 16:48:50 +0000
Subject: [issue6365] distutils duplicates package directory for C extensions
	in 3.1 final
In-Reply-To: <1246256442.36.0.248287671796.issue6365@psf.upfronthosting.co.za>
Message-ID: <1246294130.88.0.436534281329.issue6365@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6365>
_______________________________________

From report at bugs.python.org  Mon Jun 29 18:56:58 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Jun 2009 16:56:58 +0000
Subject: [issue5388] Green-box doc glitch: winhelp version only
In-Reply-To: <1235763954.97.0.134032530958.issue5388@psf.upfronthosting.co.za>
Message-ID: <1246294618.82.0.314616452358.issue5388@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

WinXP, updated, Py3.1.
Start / Programs / Python3.1 / Python Docs
I presume this uses .chm file.
I most definitely have scrollbars covering text in green box.
See screenshot for what I see.

----------
Added file: http://bugs.python.org/file14388/Py31doc.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5388>
_______________________________________

From report at bugs.python.org  Mon Jun 29 19:03:27 2009
From: report at bugs.python.org (chandrasekar)
Date: Mon, 29 Jun 2009 17:03:27 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1246295007.77.0.516650991866.issue6312@psf.upfronthosting.co.za>


chandrasekar <chkneo at gmail.com> added the comment:

HEAD request wont return any data. So before calling _read_chunked we
have to check the amt is none or not.If its none simply return b''

I've attached the patch too which is take in py3k branch

----------
keywords: +patch
nosy: +chkneo
Added file: http://bugs.python.org/file14389/6312.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Mon Jun 29 20:12:22 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jun 2009 18:12:22 +0000
Subject: [issue6372] Make all switches keyword-only
In-Reply-To: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>
Message-ID: <1246299142.49.0.283533564667.issue6372@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Let me get this right, you don't like it when people use positional
arguments for options and switches.  So, you want to force them to
change to a style you do like by breaking their existing code.  And once
they've changed, their code will be slower, more verbose, and won't work
with a star-args calling pattern. 

I think your odds of success are slim.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6372>
_______________________________________

From report at bugs.python.org  Mon Jun 29 20:21:06 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Jun 2009 18:21:06 +0000
Subject: [issue5906] Risk of confusion in multiprocessing module - daemonic
	processes
In-Reply-To: <1241281680.28.0.426890622653.issue5906@psf.upfronthosting.co.za>
Message-ID: <1246299666.52.0.528799880413.issue5906@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

committed, r73693 on trunk

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5906>
_______________________________________

From report at bugs.python.org  Mon Jun 29 20:22:20 2009
From: report at bugs.python.org (Anthony Tuininga)
Date: Mon, 29 Jun 2009 18:22:20 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>


New submission from Anthony Tuininga <anthony.tuininga at gmail.com>:

With the release of Python 3.1 the --compiler switch is ignored in
Lib/distutils/command/build_ext.py. The attached patch fixes that issue.
Once that was fixed there was another issue with get_version() in
cygwincompiler but that appears to be fixed in the 3.1 branch. The
revision that introduced this problem is 72596 (from 72593 in trunk).

----------
assignee: tarek
components: Distutils
files: distutils_compiler.patch
keywords: patch
messages: 89871
nosy: atuining, tarek
severity: normal
status: open
title: distutils compiler switch ignored
versions: Python 3.1
Added file: http://bugs.python.org/file14390/distutils_compiler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Mon Jun 29 20:25:36 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Jun 2009 18:25:36 +0000
Subject: [issue5740] multiprocessing.connection.Client API documentation
	incorrect
In-Reply-To: <1239529527.71.0.759387601738.issue5740@psf.upfronthosting.co.za>
Message-ID: <1246299936.68.0.195463219462.issue5740@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Committed, r73694 on trunk - will merge to 3k

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5740>
_______________________________________

From report at bugs.python.org  Mon Jun 29 20:39:08 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 29 Jun 2009 18:39:08 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>
Message-ID: <1246300748.18.0.141396551525.issue6367@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________

From report at bugs.python.org  Mon Jun 29 21:11:30 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jun 2009 19:11:30 +0000
Subject: [issue6370] Bad performance of colllections.Counter at initialisation
	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246302690.12.0.783190300209.issue6370@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I run many timings and the dict.get() approach is decidedly faster. 
Thanks for pointing that out.  Applied in r73695, r73696, and 73697.

FWIW, a timing suite is attached.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14391/tmp_time_missing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6370>
_______________________________________

From report at bugs.python.org  Mon Jun 29 21:19:41 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Mon, 29 Jun 2009 19:19:41 +0000
Subject: [issue3955] maybe doctest doesn't understand unicode_literals?
In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za>
Message-ID: <1246303181.77.0.222322123115.issue3955@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

OutputChecker.check_output() seems to be responsible for comparing
'example.want' and 'got' literals and this is obviously done literally.
So as "u'1'" is different to "'1'" this is reflected in the result.
This gets more complicated with literals like "[u'1', u'2']" I believe.
So, eval() could be used for testing for equality:

>>> repr(['1', '2']) == repr([u'1', u'2'])
False

but

>>> eval(repr(['1', '2'])) == eval(repr([u'1', u'2']))
True

doctests are already compiled and executed, but evaluating the doctest
code's result is probably a security issue, so a method doing the
invers of repr() could be used, that only works on variables; something
like Pickle, but without its own protocol.

----------
nosy: +christoph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3955>
_______________________________________

From report at bugs.python.org  Mon Jun 29 22:45:22 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 20:45:22 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

On Mon, 29 Jun 2009 09:56:53 -0700, Trent Mick <trentm at activestate.com>
wrote:

> Sridhar Ratnakumar wrote:
>> I installed ActivePython-3.1 to C:\Python31 but disabled the 
installer
>> option "Register as default Python" .. because, I use Python-2.6 by  
>> default.
>>
>> However, this disabling broke 3.1's IDLE. Clicking on 'idle.bat' or
>> 'idle.py' or 'idle.pyw' in C:\Python31\Lib\idle\ directory opens 
Python
>> 2.6's IDLE.
>>
>> Since the installer knows the path to Python - C:
\Python31\python.exe -
>> does it make sense to patch the idle.bat file to use this binary?
>
> IIRC there is a special NT batch file syntax that you can use do that
> idle.bat will look for python.exe in a relative path, so that you 
won't
> have to patch idle.bat after install (which would be a pain).
>
> Here, use this for idle.bat:
>
>    @echo off
>    set CURRDIR=%~dp0
>    start %CURRDIR%..\..\pythonw.exe idle.pyw
>
> Perhaps you could add a bug to core Python to change idle.bat to be 
that?
>
>
> Trent
>

----------
components: IDLE, Windows
files: idle-use-curr-py.patch
keywords: patch
messages: 89875
nosy: srid
severity: normal
status: open
title: Patch to make 'idle.bat' run idle.pyw using appropriate Python interpreter (so 3.1's idle.bat does not accidently use python26.exe)
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14392/idle-use-curr-py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Mon Jun 29 22:46:45 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 29 Jun 2009 20:46:45 +0000
Subject: [issue775544] Tk.quit leads to crash in python.exe
Message-ID: <1246308405.43.0.611167949895.issue775544@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've tried reproducing this on Windows XP using both Python 2.3.5 and
2.2.3 (and also some newer ones) and couldn't duplicate the issue. I
also tested the file attached on issue837234 and got nothing, changed it
a bit and still got nothing.

I can reproduce the IDLE freeze, but that is a different problem.

Closing this as rejected for lack of information.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775544>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:10:59 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Jun 2009 21:10:59 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>
Message-ID: <1246309859.92.0.223657052247.issue6367@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Actually, Python has non-local gotos already, and in a structured way:
by means of exceptions. I don't understand why it is "not a actual way"
- please do consider using a custom exception for that.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:14:04 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Jun 2009 21:14:04 +0000
Subject: [issue6372] Make all switches keyword-only
In-Reply-To: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>
Message-ID: <1246310044.64.0.580921932251.issue6372@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Just to add another voice: I would be opposed if such breakage is added
before Python 4.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6372>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:20:26 2009
From: report at bugs.python.org (Zbigniew Braniecki)
Date: Mon, 29 Jun 2009 21:20:26 +0000
Subject: [issue6379] Add first() function that would take first matching case
	from an iterator
In-Reply-To: <1246310426.36.0.617825815292.issue6379@psf.upfronthosting.co.za>
Message-ID: <1246310426.36.0.617825815292.issue6379@psf.upfronthosting.co.za>


New submission from Zbigniew Braniecki <zbigniew.braniecki at gmail.com>:

Python has a very useful function any() that will iterate over a list
and break on the first matching case.

Now, it would be great to have similar function but with:
a) ability to use a callback for matching test
b) that would return the first match

so something like:

key = first(['es-AR','es','en-US'], lambda x:self._value.has_key(x))

instead of:

for k in ['es-AR','es','en-US']:
    if self._value.has_key(k):
        key = k
        break

It would be also nice to be able to capture the first match and return it:
value = first(['es-AR','es','en-US'], lambda x:self._value[x])

I'm not sure which one is more generically applicable.

----------
components: None
messages: 89879
nosy: gandalf
severity: normal
status: open
title: Add first() function that would take first matching case from an iterator
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6379>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:21:11 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Jun 2009 21:21:11 +0000
Subject: [issue6375] compile failure in Modules/python.c
In-Reply-To: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>
Message-ID: <1246310471.33.0.454766455813.issue6375@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can somebody explain the error? The conversion looks quite valid to me,
so it seems to be a compiler bug.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6375>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:26:16 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 21:26:16 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246310776.03.0.499917932717.issue6347@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file14393/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:26:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 21:26:33 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246310793.6.0.631318984589.issue6347@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file14394/pyconfig.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:27:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 29 Jun 2009 21:27:59 +0000
Subject: [issue6379] Add first() function that would take first matching case
	from an iterator
In-Reply-To: <1246310426.36.0.617825815292.issue6379@psf.upfronthosting.co.za>
Message-ID: <1246310879.71.0.970702721097.issue6379@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please propose this on the python-ideas list first.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6379>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:33:07 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Jun 2009 21:33:07 +0000
Subject: [issue6379] Add first() function that would take first matching case
	from an iterator
In-Reply-To: <1246310426.36.0.617825815292.issue6379@psf.upfronthosting.co.za>
Message-ID: <1246311187.93.0.774973469596.issue6379@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python already supports that, in the itertools module:

itertools.ifilter(lambda x:self._value.has_key(x),
                  ['es-AR','es','en-US']).next()

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6379>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:36:54 2009
From: report at bugs.python.org (Trent Mick)
Date: Mon, 29 Jun 2009 21:36:54 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1246311414.12.0.120584951494.issue6378@psf.upfronthosting.co.za>


Changes by Trent Mick <trentm at gmail.com>:


----------
nosy: +trentm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:37:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 29 Jun 2009 21:37:37 +0000
Subject: [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246311457.95.0.836655063001.issue6373@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The patch looks good.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6373>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:43:47 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 21:43:47 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246311827.54.0.254437660333.issue6347@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Hi Mark,

Thanks for showing interest on this bug.

[Mark] Is the operating system you're using HP-UX 11.00, or am I 
misunderstanding the issue title?

# Yes. output of platinfo: hpux-parisc (hpux11.00-parisc2.0)

[Mark] Does the problem exist with more recent versions of HP-UX 11?

# I'm yet to verify that as currently HP-UX 11.22 has another build 
issue: http://bugs.python.org/issue5999

[Mark] Please could you attach your post-configuration pyconfig.h file,
and also, if possible, the config.log file?

# I've attached 'config.log' and 'pyconfig.h' a few minutes ago.

[Mark] Does inttypes.h on your system define int32_t and uint32_t?

# Yes. See http://files.getdropbox.com/u/87045/tmp/hpux_test.c.txt

[Mark] if inttypes.h defines int32_t and uint32_t, are they C macros or 
typedefs?

# Interesting I can't find int32_t at all in /usr/include/inttypes.h -- 
so I'm attaching that file.

[Mark] Does inttypes.h on your system define INT32_MAX and UINT32_MAX?

# Yes. See http://files.getdropbox.com/u/87045/tmp/hpux_test.c.txt

[Mark] Does the attached patch fix the problem for you? 

# The patch "issue6347.patch" fixes the compile error! The build also 
succeeds without further errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Mon Jun 29 23:44:59 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 21:44:59 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246311899.44.0.478478052611.issue6347@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file14395/inttypes.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:16:42 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 22:16:42 +0000
Subject: [issue6348] solaris/aix: Py_Initialize: can't initialize sys standard
	streams
In-Reply-To: <1246060162.58.0.439928346048.issue6348@psf.upfronthosting.co.za>
Message-ID: <1246313802.53.0.820744248001.issue6348@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Yes, I get the same "Illegal seek" traceback for nestor's ``os.popen
('cat', 'w')`` even though it happens on all of: solaris10-x86, 
solaris8-sparc, solaris8-sparc64 and aix5-powerpc.

Hmm, so this is a duplicate bug?

----------
nosy: +nestor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6348>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:21:39 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jun 2009 22:21:39 +0000
Subject: [issue6379] Add first() function that would take first matching case
	from an iterator
In-Reply-To: <1246310426.36.0.617825815292.issue6379@psf.upfronthosting.co.za>
Message-ID: <1246314099.43.0.164438409657.issue6379@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

We've already got one.  Thanks ;-)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6379>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:32:20 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 29 Jun 2009 22:32:20 +0000
Subject: [issue1522587] Tix.Grid patch
Message-ID: <1246314740.14.0.384862450661.issue1522587@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've reviewed it now and produced a patch based on it, but it doesn't
include undocumented Tix features that were added.

I'm separating this new patch into two parts, the first part isn't
supposed to affect Tix users, so it should be safe to commit. The second
part is just a minor change in Tix.Grid.entrycget which adds a '-'
before an option name (.diff not attached).

There are also problems regarding xview/yview, but I decided to not fix
them here. I expect to solve this in issue1135.

----------
Added file: http://bugs.python.org/file14396/revised_1522587.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1522587>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:34:13 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 29 Jun 2009 22:34:13 +0000
Subject: [issue1522587] Tix.Grid patch
Message-ID: <1246314853.34.0.377298801454.issue1522587@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I forgot to include the new Grid constants, but I'm ok on adding them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1522587>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:39:20 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 22:39:20 +0000
Subject: [issue6373] SystemError in encoder
In-Reply-To: <1246289485.02.0.752200550546.issue6373@psf.upfronthosting.co.za>
Message-ID: <1246315160.65.0.562142199659.issue6373@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Fixed with r73698 (py3k) and r73699.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6373>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:47:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 22:47:04 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used
	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1246315624.11.0.556380540303.issue5999@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Hello Martin,

My apologies for responding so late.


[Martin] Also, please confirm a few things: a. configure has detected 
that your system has mbrtowc (...)

# Yes, as can be seen in the attached config.log

[Martin] (...) b. configure's analysis is correct, i.e. your system has 
mbrtowc indeed.

# Yes, `mbrtowc` is present as the following C programs compiles and 
runs successfully:

  #include <wchar.h>
  int main()
  {
    printf("Init\n");
    mbrtowc(NULL, "", 1, NULL);
  }

[Martin] does your system provide the mbstate_t type? if so, what 
header file needs to be included?

`mbstate_t` seems to exist in /usr/include/wchar.h .. however, 
including <wchar.h> does not seem to work:

bash-2.04$ cc +DD64 -Ae -D_REENTRANT +Z --version              
cc: HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]
bash-2.04$ cat test.c
#include <wchar.h>
int main()
{
  mbstate_t foo;
  printf("Init\n");
  mbrtowc(NULL, "", 1, NULL);
}
bash-2.04$ cc test.c -o test                     
Error 419: "test.c", line 6 # 'mbstate_t' is used as a type, but has 
not been defined as a type.
      mbstate_t foo;
      ^^^^^^^^^     
bash-2.04$ aCC test.c -o test
Error 403: "test.c", line 8 # Undeclared variable 'mbrtowc'. Perhaps 
'mbtowc' as in "int mbtowc(wchar_t *,const char *,unsigned long)" ["/
usr/include/stdlib.h", line 169] was intended.
      mbrtowc(NULL, "", 1, NULL);
      ^^^^^^^   

cf. http://www.mail-archive.com/lftp-devel at uniyar.ac.ru/msg00602.html

----------
Added file: http://bugs.python.org/file14397/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:47:04 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jun 2009 22:47:04 +0000
Subject: [issue6370] Bad performance of colllections.Counter at initialisation
	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246315624.45.0.99275003896.issue6370@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file14391/tmp_time_missing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6370>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:47:20 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 22:47:20 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used
	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1246315640.31.0.71082517286.issue5999@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
components: +Unicode
Added file: http://bugs.python.org/file14398/pyconfig.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:47:27 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Jun 2009 22:47:27 +0000
Subject: [issue6370] Bad performance of colllections.Counter at initialisation
	from an iterable
In-Reply-To: <1246287388.55.0.75208877327.issue6370@psf.upfronthosting.co.za>
Message-ID: <1246315647.9.0.014808193278.issue6370@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file14399/tmp_time_missing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6370>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:48:12 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Jun 2009 22:48:12 +0000
Subject: [issue6369] binhex buggy in py3k
In-Reply-To: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>
Message-ID: <1246315692.86.0.699967462659.issue6369@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Believe it or not, the failing test is already in svn:
http://mail.python.org/pipermail/python-checkins/2009-June/084616.html

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6369>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:49:20 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 29 Jun 2009 22:49:20 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used
	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1246315760.14.0.579028936442.issue5999@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


Added file: http://bugs.python.org/file14400/wchar.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:52:14 2009
From: report at bugs.python.org (Dmitriy Khramtsov)
Date: Mon, 29 Jun 2009 22:52:14 +0000
Subject: [issue6380] Deadlock during the "import" in the fork()'ed child
	process if fork() happened while import_lock was held
In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za>
Message-ID: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za>


New submission from Dmitriy Khramtsov <highdn at gmail.com>:

Greetings,

The 2.4 and 2.5 versions of python contains a deadlock caused by
possibility to hold import_lock while doing fork() and not resetting it
in the child (on the linux platform).


The prove of concept code is:

--BEGIN (import_lock.py)--

#!/usr/bin/python2.4

import os
import time
import threading

class SecondThread(threading.Thread):
  def run(self):
    # Give the main thread time to hold import_lock and start importing.
    time.sleep(1)

    # Fork the process while holding import_lock in the main thread.
    pid = os.fork()

    if pid == 0:  # Child process
      print "child begin"

      # The import lock is still taken by main thread which is now not
the part
      # of the child process.  The import lock will never be released in the
      # child process.  Effectively, any import is a deadlock from now on.
      import types

      # This statement will never be executed.
      print "child end"

def main():
  second_thread = SecondThread()
  second_thread.start()

  # Take the import_lock and then release global interpreter lock in the
  # import_lock_helper module by calling any blocking operation.
  import import_lock_helper

  second_thread.join()

main()

--END (import_lock.py)--


--BEGIN (import_lock_helper.py)--

#!/usr/bin/python2.4

import time

# Release the global interpreter lock by calling any blocking operation.
time.sleep(10)

--END (import_lock_helper.py)--


The stack of the child python interpreter at the time of dead lock:

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xf7f81700 in sem_wait at GLIBC_2.0 () from
/usr/grte/v1/lib/libpthread.so.0
#2  0x081ab500 in ?? ()
#3  0x080e1855 in PyThread_acquire_lock (lock=0x0, waitflag=1) at
../../Python/thread_pthread.h:313
#4  0x080d1f3b in lock_import () at ../../Python/import.c:247
#5  0x080d52a4 in PyImport_ImportModuleEx (name=0xf7e0f8f4 "types",
globals=0xf7def824, locals=0x8123cb8, fromlist=0x8123cb8) at
../../Python/import.c:1976
#6  0x080af2d0 in builtin___import__ (self=0x0, args=0xf7db7cd4) at
../../Python/bltinmodule.c:45
#7  0x08058d77 in PyObject_Call (func=0x0, arg=0xf7db7cd4, kw=0x0) at
../../Objects/abstract.c:1795
#8  0x080b30ec in PyEval_CallObjectWithKeywords (func=0xf7ddfd6c,
arg=0xf7db7cd4, kw=0x0) at ../../Python/ceval.c:3435
#9  0x080b5ca6 in PyEval_EvalFrame (f=0x8167a04) at
../../Python/ceval.c:2020
#10 0x080b942c in PyEval_EvalFrame (f=0x81ab57c) at
../../Python/ceval.c:3651
. . . .

(gdb) pystack
import_lock.py (26): run
/usr/lib/python2.4/threading.py (443): __bootstrap


The code directly responsible for import locking (Python/import.c):

--BEGIN--
static PyThread_type_lock import_lock = 0;
static long import_lock_thread = -1;
static int import_lock_level = 0;

static void
lock_import(void)
{
       long me = PyThread_get_thread_ident();
       if (me == -1)
               return; /* Too bad */
       if (import_lock == NULL) {
               import_lock = PyThread_allocate_lock();
               if (import_lock == NULL)
                       return;  /* Nothing much we can do. */
       }
       if (import_lock_thread == me) {
               import_lock_level++;
               return;
       }
       if (import_lock_thread != -1 ||
!PyThread_acquire_lock(import_lock, 0))
       {
               PyThreadState *tstate = PyEval_SaveThread();
               PyThread_acquire_lock(import_lock, 1);
               PyEval_RestoreThread(tstate);
       }
       import_lock_thread = me;
       import_lock_level = 1;
}

static int
unlock_import(void)
{
       long me = PyThread_get_thread_ident();
       if (me == -1 || import_lock == NULL)
               return 0; /* Too bad */
       if (import_lock_thread != me)
               return -1;
       import_lock_level--;
       if (import_lock_level == 0) {
               import_lock_thread = -1;
               PyThread_release_lock(import_lock);
       }
       return 1;
}

/* This function is called from PyOS_AfterFork to ensure that newly
  created child processes do not share locks with the parent. */

void
_PyImport_ReInitLock(void)
{
#ifdef _AIX
       if (import_lock != NULL)
               import_lock = PyThread_allocate_lock();
#endif
}
--END--


The possible solution is to reset import_lock in the
_PyImport_ReInitLock() not only for _AIX but also for Linux and maybe
other platforms (do you know why _AIX-only guard is there?).

--CUT HERE--
void
_PyImport_ReInitLock(void)
{
       if (import_lock != NULL)
               import_lock = PyThread_allocate_lock();
}
--CUT HERE--

Prove of concept example above works fine (w/o deadlocks) on the python
interpreter rebuilt with the _PyImport_ReInitLock() modification above.


Also this bug can be worked around in Python code by holding import_lock
before fork() and releasing import_lock right after fork() in both
parent and child.

The workaround code is:

--BEGIN (workaround_fork_import_bug.py)--

import imp
import os

def __fork():
  imp.acquire_lock()
  try:
    return _os_fork()
  finally:
    imp.release_lock()

try:
  _os_fork
except NameError:
  _os_fork = os.fork
  os.fork = __fork

--END (workaround_fork_import_bug.py)--


This workaround can also be implemented in Python interpreter in C and
could be other solution for this bug.


Thanks,
Dmitriy


$ uname -srvmpio
Linux 2.6.24-gg24-generic #1 SMP Wed Apr 22 21:48:06 PDT 2009 x86_64
unknown unknown GNU/Linux

P.S. The problem described above is probably causes (some) effects
described in http://bugs.python.org/issue1590864.

----------
components: Interpreter Core
messages: 89892
nosy: abaron, astrand, brett.cannon, hdn, kosuha, michaeltsai, ronaldoussoren
severity: normal
status: open
title: Deadlock during the "import" in the fork()'ed child process if fork() happened while import_lock was held
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6380>
_______________________________________

From report at bugs.python.org  Tue Jun 30 00:54:44 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Mon, 29 Jun 2009 22:54:44 +0000
Subject: [issue6372] Make all switches keyword-only
In-Reply-To: <1246288864.0.0.660684882906.issue6372@psf.upfronthosting.co.za>
Message-ID: <1246316084.12.0.782793031663.issue6372@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

OK, bad idea it is then.  Thank you for your time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6372>
_______________________________________

From report at bugs.python.org  Tue Jun 30 01:02:10 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 29 Jun 2009 23:02:10 +0000
Subject: [issue6380] Deadlock during the "import" in the fork()'ed child
	process if fork() happened while import_lock was held
In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za>
Message-ID: <1246316530.2.0.605276390354.issue6380@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/issue6380>
_______________________________________

From report at bugs.python.org  Tue Jun 30 02:02:17 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 30 Jun 2009 00:02:17 +0000
Subject: [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246280299.0.0.628250812343.issue6364@psf.upfronthosting.co.za>
Message-ID: <4A49558C.9010403@gmx.net>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I get the same error as before with a fresh install of r73676 on Linux.

$ uname -a
Linux zhuangzi 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC
2009 x86_64 GNU/Linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6364>
_______________________________________

From report at bugs.python.org  Tue Jun 30 03:03:29 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 30 Jun 2009 01:03:29 +0000
Subject: [issue1447222] tkinter Dialog fails when more than four buttons are
	used
Message-ID: <1246323809.91.0.37201705038.issue1447222@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Interesting.. I tried testing Dialog for that bug, but generating
<Return> keypress (you can combine with keyrelease too) doesn't trigger
the problem (very weird to me). I will be simulating mouse clicks to see
if, for some reason, the bug gets noticed.

Attaching the test I tried just in case.

----------
Added file: http://bugs.python.org/file14401/test_dialog.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1447222>
_______________________________________

From report at bugs.python.org  Tue Jun 30 03:40:20 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jun 2009 01:40:20 +0000
Subject: [issue6381] test_urllib2_localnet sporadic failures closing socket
In-Reply-To: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>
Message-ID: <1246326020.83.0.77401775469.issue6381@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Gentoo linux, r73699, I'm seeing sporadic failures in
test_urllib2_localnet in the following two tests:

test_sending_headers
test_proxy_with_no_password_raises_httperror

It happens about once every other run in one or the other of those.  I
don't see any problems on 2.6-maint or py3k.

In both cases it is failing in the close.  Here is an example traceback:

test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ...
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 46051)
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 281, in
_handle_request_noblock
    self.process_request(request, client_address)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 308, in
process_request
    self.close_request(request)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 448, in
close_request
    request.shutdown(socket.SHUT_WR)
  File "/home/rdmurray/python/trunk/Lib/socket.py", line 219, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected
----------------------------------------
Exception in thread Thread-12:
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/threading.py", line 524, in
__bootstrap_inner
    self.run()
  File "/home/rdmurray/python/trunk/Lib/test/test_urllib2_localnet.py",
line 65, in run
    self.httpd.handle_request()
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 266, in
handle_request
    self._handle_request_noblock()
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 284, in
_handle_request_noblock
    self.close_request(request)
  File "/home/rdmurray/python/trunk/Lib/SocketServer.py", line 448, in
close_request
    request.shutdown(socket.SHUT_WR)
  File "/home/rdmurray/python/trunk/Lib/socket.py", line 219, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected

----------
components: Tests
messages: 89896
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_urllib2_localnet sporadic failures closing socket
type: security
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6381>
_______________________________________

From report at bugs.python.org  Tue Jun 30 03:58:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jun 2009 01:58:44 +0000
Subject: [issue6382] test_socketserver fails on trunk in test_ForkingTCPServer
In-Reply-To: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>
Message-ID: <1246327124.37.0.772968679477.issue6382@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Gentoo linux, trunk r73699.  test_socketserver fails with the following
tracebacks:

======================================================================
FAIL: test_ForkingTCPServer (test.test_socketserver.SocketServerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
189, in test_ForkingTCPServer
    self.stream_examine)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
147, in run_server
    testfunc(svrcls.address_family, addr)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
161, in stream_examine
    self.assertEquals(buf, TEST_STR)
AssertionError: '' != 'hello world\n'

======================================================================
FAIL: test_ForkingUnixStreamServer (test.test_socketserver.SocketServerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
207, in test_ForkingUnixStreamServer
    self.stream_examine)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
147, in run_server
    testfunc(svrcls.address_family, addr)
  File "/home/rdmurray/python/trunk/Lib/test/test_socketserver.py", line
161, in stream_examine
    self.assertEquals(buf, TEST_STR)
AssertionError: '' != 'hello world\n'

----------
components: Library (Lib)
messages: 89897
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_socketserver fails on trunk in test_ForkingTCPServer
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6382>
_______________________________________

From report at bugs.python.org  Tue Jun 30 04:15:17 2009
From: report at bugs.python.org (Jae Kwon)
Date: Tue, 30 Jun 2009 02:15:17 +0000
Subject: [issue5973] re-usable generators / generator expressions should
	return iterables
In-Reply-To: <1241817979.06.0.302346555746.issue5973@psf.upfronthosting.co.za>
Message-ID: <1246328117.73.0.998110890568.issue5973@psf.upfronthosting.co.za>


Jae Kwon <jkwon.work at gmail.com> added the comment:

I second this feature request, and will try to get consensus in
python-ideas. 

Meanwhile, here's a sample workaround.

>>> def gen2iterable(genfunc):
...     def wrapper(*args, **kwargs):
...         class _iterable(object):
...             def __iter__(self):
...                 return genfunc(*args, **kwargs)
...         return _iterable()
...     return wrapper
... 
>>> 
>>> @gen2iterable
... def foo():
...   for i in range(10):
...     yield i
... 
>>> a = foo()
>>> 
>>> max(a)
9
>>> max(a)
9
>>> def secondmax(iterable):
...     """return the second largest value in iterable"""
...     m = max(iterable)
...     return max(i for i in iterable if i<m)
... 
>>> secondmax(a)
8

----------
nosy: +Jae

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5973>
_______________________________________

From report at bugs.python.org  Tue Jun 30 04:43:04 2009
From: report at bugs.python.org (Vernon Cole)
Date: Tue, 30 Jun 2009 02:43:04 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>


New submission from Vernon Cole <vernondcole at gmail.com>:

I am making a demo program, a class which is a subset of int, which
implements a partial implementation of PEP313 (Roman numeral literals).

I discover that my conversion routines fail for values > 50000 due to an
error in unicodedata for the two code points 2187 and 2188. The return
value of unicodedata.numeric() for those two points should be 50,000.0
and 100,000.0 respectively. See the following console dump which
includes code point 2181 which works correctly.

----- console dump follows -----

c:\BZR\roman>c:\python26\python.exe
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.name(u"\u2187")
'ROMAN NUMERAL FIFTY THOUSAND'
>>> unicodedata.numeric(u"\u2187")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not a numeric character
>>> unicodedata.name(u"\u2188")
'ROMAN NUMERAL ONE HUNDRED THOUSAND'
>>> unicodedata.numeric(u"\u2188")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not a numeric character
>>> unicodedata.name(u"\u2181")
'ROMAN NUMERAL FIVE THOUSAND'
>>> unicodedata.numeric(u"\u2181")
5000.0
>>>

----------
components: Unicode
messages: 89899
nosy: vernondcole
severity: normal
status: open
title: error in unicodedata.numeric(u"\u2187") and 2188
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 05:03:47 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 03:03:47 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1246331027.65.0.0897189319078.issue5313@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Attached is a patch with docs, tests and the fix as suggested by OG7 (whom 
I can't add to the ACKS without a real name). Please check the additional 
doc note I added to the all platforms programming guidelines.

----------
Added file: http://bugs.python.org/file14402/stdin_patch_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Tue Jun 30 05:04:16 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 03:04:16 +0000
Subject: [issue5331] multiprocessing hangs when Pool used within Process
In-Reply-To: <1235146028.47.0.682929217877.issue5331@psf.upfronthosting.co.za>
Message-ID: <1246331056.78.0.415535192634.issue5331@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Patch attached to issue 5313, please review

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5331>
_______________________________________

From report at bugs.python.org  Tue Jun 30 05:04:31 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 03:04:31 +0000
Subject: [issue5155] Multiprocessing.Queue created by sub-process fails when
	used in sub-sub-process ("bad file descriptor" in q.get())
In-Reply-To: <1233798773.64.0.357189782395.issue5155@psf.upfronthosting.co.za>
Message-ID: <1246331071.33.0.965367624714.issue5155@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Patch attached to issue 5313, please review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5155>
_______________________________________

From report at bugs.python.org  Tue Jun 30 05:10:55 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 03:10:55 +0000
Subject: [issue5503] multiprocessing/connection.py wrong pipe name under win32
In-Reply-To: <1237342644.17.0.0547422221967.issue5503@psf.upfronthosting.co.za>
Message-ID: <1246331455.91.0.215515714526.issue5503@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Closing; without the exception/more details, and with multiprocessing 
working on WIN32 I don't have anything to go on.

----------
resolution:  -> wont fix
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5503>
_______________________________________

From report at bugs.python.org  Tue Jun 30 06:03:47 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 30 Jun 2009 04:03:47 +0000
Subject: [issue6384] Permalink to built-in exception class hierarchy
	documentation
In-Reply-To: <1246334627.57.0.503103979691.issue6384@psf.upfronthosting.co.za>
Message-ID: <1246334627.57.0.503103979691.issue6384@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I think it would be useful to have a permalink to the built-in exception
class hierarchy at the end of the library exceptions documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 89904
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Permalink to built-in exception class hierarchy documentation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6384>
_______________________________________

From report at bugs.python.org  Tue Jun 30 06:06:25 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 30 Jun 2009 04:06:25 +0000
Subject: [issue6385] two lines of typographical inconsistency in doc of
	exception class hierarchy
In-Reply-To: <1246334785.12.0.590617897829.issue6385@psf.upfronthosting.co.za>
Message-ID: <1246334785.12.0.590617897829.issue6385@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the documentation of the built-in exception class hierarhcy in the
library documentation WindowsError (Windows) and VMSError (VMS) are not
in the same color as the rest of the exception names.

----------
messages: 89905
nosy: MLModel
severity: normal
status: open
title: two lines of typographical inconsistency in doc of exception class hierarchy
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6385>
_______________________________________

From report at bugs.python.org  Tue Jun 30 07:28:44 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 05:28:44 +0000
Subject: [issue6385] two lines of typographical inconsistency in doc of
	exception class hierarchy
In-Reply-To: <1246334785.12.0.590617897829.issue6385@psf.upfronthosting.co.za>
Message-ID: <1246339724.57.0.964097598386.issue6385@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6385>
_______________________________________

From report at bugs.python.org  Tue Jun 30 07:29:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 05:29:20 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246339760.08.0.825917037265.issue6383@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 07:29:40 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 05:29:40 +0000
Subject: [issue6384] Permalink to built-in exception class hierarchy
	documentation
In-Reply-To: <1246334627.57.0.503103979691.issue6384@psf.upfronthosting.co.za>
Message-ID: <1246339780.37.0.871991899847.issue6384@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6384>
_______________________________________

From report at bugs.python.org  Tue Jun 30 07:38:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 30 Jun 2009 05:38:16 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1246315624.11.0.556380540303.issue5999@psf.upfronthosting.co.za>
Message-ID: <4A49A4C2.3060301@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> `mbstate_t` seems to exist in /usr/include/wchar.h

I can't infer that from the copy of wchar.h that you provided. I
see that mbstate_t* is used, but I fail to find any definition
of mbstate_t.

I see that sys/_mbstate_t.h is included. This inclusion is conditional
on  _INCLUDE__STDC_A1_SOURCE, so a first check should be done whether
this is defined. In addition, it would be interesting to know what
_mbstate_t.h contains.

> bash-2.04$ cat test.c
> #include <wchar.h>
> int main()
> {
>   mbstate_t foo;
>   printf("Init\n");
>   mbrtowc(NULL, "", 1, NULL);
> }

It's best to focus on this example. Produce preprocessor output for
it, and attach that to the bug report.

This is standard C, AFAICT, so if the compiler fails to compile
it, something is wrong with the compiler, or you are using it incorrectly.

As a wild guess, try defining _XOPEN_SOURCE to 500, i.e.
-D_XOPEN_SOURCE=500.

> cf. http://www.mail-archive.com/lftp-devel at uniyar.ac.ru/msg00602.html

I don't think this is relevant. Somehow, they managed to #define
mbstate_t to int, breaking the header - this should not happen here.

----------
title: compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used as a type, but has not been defined as a type -> compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used	as a type, but has not been defined as a type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Tue Jun 30 07:40:36 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 30 Jun 2009 05:40:36 +0000
Subject: [issue6380] Deadlock during the "import" in the fork()'ed child
	process if fork() happened while import_lock was held
In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za>
Message-ID: <1246340436.35.0.538141940823.issue6380@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Does the problem also exist in Python 2.6? We will definitely not fix it
anymore for 2.4 and 2.5.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6380>
_______________________________________

From report at bugs.python.org  Tue Jun 30 08:06:35 2009
From: report at bugs.python.org (vinoth)
Date: Tue, 30 Jun 2009 06:06:35 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246309859.92.0.223657052247.issue6367@psf.upfronthosting.co.za>
Message-ID: <6176a14d0906292306q6d507736k73043ceb237d2836@mail.gmail.com>


vinoth <4vinoth at gmail.com> added the comment:

I hope exceptions are not created for that purpose,and it is not the actual*
/*right way i hope. because,

if any of the called methods has the try: except: block, it fails..

and we can't guide other coders, "Don't use try: except:" as it is the
language neutral power.

But it is easy to implement.  Just do as we do in case of exception, but in
a user defined way. I hope.

Thanks
Vinoth

On Tue, Jun 30, 2009 at 2:41 AM, Martin v. L??wis <report at bugs.python.org>wrote:

>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> Actually, Python has non-local gotos already, and in a structured way:
> by means of exceptions. I don't understand why it is "not a actual way"
> - please do consider using a custom exception for that.
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6367>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14403/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________
-------------- next part --------------
<br>I hope exceptions are not created for that purpose,and it is not the actual<b>/</b>right way i hope. because, <br><br>if any of the called methods has the try: except: block, it fails.. <br><br>and we can&#39;t guide other coders, &quot;Don&#39;t use try: except:&quot; as it is the language neutral power.<br>
<br>But it is easy to implement.?? Just do as we do in case of exception, but in a user defined way. I hope.<br><br>Thanks<br>Vinoth<br><br><div class="gmail_quote">On Tue, Jun 30, 2009 at 2:41 AM, Martin v. L??wis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Martin v. L??wis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<br>
Actually, Python has non-local gotos already, and in a structured way:<br>
by means of exceptions. I don&#39;t understand why it is &quot;not a actual way&quot;<br>
- please do consider using a custom exception for that.<br>
<br>
----------<br>
nosy: +loewis<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6367" target="_blank">http://bugs.python.org/issue6367</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>vin<br>

From report at bugs.python.org  Tue Jun 30 08:11:56 2009
From: report at bugs.python.org (Dmitriy Khramtsov)
Date: Tue, 30 Jun 2009 06:11:56 +0000
Subject: [issue6380] Deadlock during the "import" in the fork()'ed child
	process if fork() happened while import_lock was held
In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za>
Message-ID: <1246342316.03.0.789596726975.issue6380@psf.upfronthosting.co.za>


Dmitriy Khramtsov <highdn at gmail.com> added the comment:

> Does the problem also exist in Python 2.6? We will definitely not fix it
> anymore for 2.4 and 2.5.

Yep.  Exactly same problem in Python 2.6.

This problem does probably exist in all newer versions as well but I 
didn't explicitly test for that.

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6380>
_______________________________________

From report at bugs.python.org  Tue Jun 30 08:44:32 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 30 Jun 2009 06:44:32 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246282240.82.0.405033347803.issue6367@psf.upfronthosting.co.za>
Message-ID: <1246344272.12.0.611771436981.issue6367@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So there is a language feature there already that solves your problem
exactly, and you don't want to use it? Exceptions are *exactly* the
right way to provide non-local gotos in a structured manner.

I'm opposed to any change to the language because the desired feature is
already there. Use it. Don't tell that it is the wrong way, it is
exactly the right way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________

From report at bugs.python.org  Tue Jun 30 08:47:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 06:47:54 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246344474.45.0.00521382213016.issue6383@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Python 2.6 and all the following versions use the Unicode database
version 5.1.0 [1] (unicodedata.unidata_version).

The numeric value is in the database for all the codepoints from U+2185
to U+2188 (included), so the problem shouldn't be there.

[1]: ftp://ftp.unicode.org/Public/5.1.0/ucd/UnicodeData.txt

----------
priority:  -> normal
versions: +Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 11:13:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Jun 2009 09:13:08 +0000
Subject: [issue6385] two lines of typographical inconsistency in doc of
	exception class hierarchy
In-Reply-To: <1246334785.12.0.590617897829.issue6385@psf.upfronthosting.co.za>
Message-ID: <1246353188.85.0.729897108235.issue6385@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in Pygments trunk.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6385>
_______________________________________

From report at bugs.python.org  Tue Jun 30 11:31:46 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Jun 2009 09:31:46 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246354306.17.0.258375349026.issue6383@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The _PyUnicode_ToNumeric() function was not in line with the unicode
database.
Here is a new version of this function, together with the script to
generate its code.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file14404/unicode_tonumeric.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 12:05:44 2009
From: report at bugs.python.org (jbeulich)
Date: Tue, 30 Jun 2009 10:05:44 +0000
Subject: [issue6386] importing yields unexpected results when initial script
	is a symbolic link
In-Reply-To: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za>
Message-ID: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za>


New submission from jbeulich <jbeulich at novell.com>:

Due to the way PySys_SetArgv() works, when the initial script is a
symbolic link, importing from normal files in the same directory does
not work. This is particularly surprising when the work tree is a
symlinked clone (cp -s) of an original (i.e. snapshot) tree with a few
modifications (patches) applied to one or more of the modules imported
from: Due the the erratum, the modifications made will appear to not
take effect until one realizes that the wrong module is being imported from.

The solution would in my opinion be to not only add the path left after
the readlink()/realpath() processing to the import search path list, but
also any intermediately encountered ones (in the order processed) as
long as the leaf component continues to be a symlink.

(Note: It seems pointless to use readlink() in the current [3.1 and
earlier] implementation, since the result gets passed to realpath()
anyway. Also, the documentation doesn't seem to mention this behavior,
and from the sources it remains unclear why this processing is needed at
all.)

----------
messages: 89914
nosy: jbeulich
severity: normal
status: open
title: importing yields unexpected results when initial script is a symbolic link
type: behavior
versions: 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/issue6386>
_______________________________________

From report at bugs.python.org  Tue Jun 30 12:12:16 2009
From: report at bugs.python.org (jan matejek)
Date: Tue, 30 Jun 2009 10:12:16 +0000
Subject: [issue6386] importing yields unexpected results when initial script
	is a symbolic link
In-Reply-To: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za>
Message-ID: <1246356736.93.0.762848910095.issue6386@psf.upfronthosting.co.za>


Changes by jan matejek <jmatejek at suse.cz>:


----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6386>
_______________________________________

From report at bugs.python.org  Tue Jun 30 12:55:42 2009
From: report at bugs.python.org (David Jones)
Date: Tue, 30 Jun 2009 10:55:42 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>


New submission from David Jones <drj at pobox.com>:

Consider: x//y != x//float(y) for some integer values of x and y.

For example, x = 2**54-1, and y = 2:

>>> x=2**54-1
>>> y=2
>>> x//y
9007199254740991L
>>> x//float(y)
9007199254740992.0
>>> _==x//y
False

I have no idea whether this should actually be a bug or not.  The 
behaviour (above) _is_ the documented behaviour (because the operands 
are documented as being converted to a common type).  But... I think 
there's a good case for computing the mathematically correct answer 
regardless of the types of the inputs.  For one thing, one of the 
reasons behind introducing the // operator was to make division the same 
regardless of whether the inputs were floating point or int.  Computing 
the mathematically correct answer (which since the answer is an integer 
is always exactly representable in Python) would be better, and simpler 
to document.

----------
components: Interpreter Core
messages: 89915
nosy: drj
severity: normal
status: open
title: floor division gives different result for int versus float.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 13:08:17 2009
From: report at bugs.python.org (Tim Peters)
Date: Tue, 30 Jun 2009 11:08:17 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246360097.73.0.995876464759.issue6387@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Do you realize that 2**54-1 isn't exactly representable as a float?  It
requires 54 bits of precision, but the Python float format only has 53
bits available (on all popular boxes).

>>> 2**54-1
18014398509481983L
>>> float(_)  # rounds to closest representable float
18014398509481984.0

In fact, x//y == x//float(y) for only a small subset of integer x and y
values, mostly because only a small subset of integer x and y values are
exactly representable as floats (given that Python integers enjoy
unbounded precision, but floats only retain 53 bits).

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 13:27:46 2009
From: report at bugs.python.org (Thomas Bleier)
Date: Tue, 30 Jun 2009 11:27:46 +0000
Subject: [issue6388] platform.python_implementation does not work on IronPython
In-Reply-To: <1246361266.54.0.86756549192.issue6388@psf.upfronthosting.co.za>
Message-ID: <1246361266.54.0.86756549192.issue6388@psf.upfronthosting.co.za>


New submission from Thomas Bleier <thomas at bleier.at>:

platform.python_implementation as of CPython 2.6 does not work on
IronPython 2.0.1

It obviously crashes because it fails determining that it run's on
IronPython.

>>> platform.python_implementation()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\IronPython2\Lib\platform.py", line 1409, in python_implementation
  File "C:\IronPython2\Lib\platform.py", line 1359, in _sys_version
ValueError: failed to parse CPython sys.version: '2.5.0 (IronPython 2.0
(2.0.0.0) on .NET 2.0.50727.4918)'

----------
components: Library (Lib)
messages: 89917
nosy: tbleier
severity: normal
status: open
title: platform.python_implementation does not work on IronPython
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6388>
_______________________________________

From report at bugs.python.org  Tue Jun 30 13:53:01 2009
From: report at bugs.python.org (David Jones)
Date: Tue, 30 Jun 2009 11:53:01 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246362781.57.0.906397760813.issue6387@psf.upfronthosting.co.za>


David Jones <drj at pobox.com> added the comment:

I do realise that.  I still think the mathematically correct answer should 
be computed, since it can be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 14:22:43 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 12:22:43 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1246364563.69.0.185368525113.issue5313@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file14319/stdin-patchv1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Tue Jun 30 14:22:55 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 12:22:55 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1246364575.21.0.0511553921681.issue5313@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


Removed file: http://bugs.python.org/file14320/0001-Fix-issue-5313.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Tue Jun 30 14:32:58 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jun 2009 12:32:58 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246365178.73.0.563031025853.issue6383@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Wouldn't it make more sense to move this into unicode_db.h?

----------
nosy: +benjamin.peterson, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 14:34:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jun 2009 12:34:40 +0000
Subject: [issue6388] platform.python_implementation does not work on IronPython
In-Reply-To: <1246361266.54.0.86756549192.issue6388@psf.upfronthosting.co.za>
Message-ID: <1246365280.62.0.611354277553.issue6388@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It should in 2.7, when that is released.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6388>
_______________________________________

From report at bugs.python.org  Tue Jun 30 14:44:29 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jun 2009 12:44:29 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246365869.04.0.50524437867.issue6387@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +eric.smith, marketdickinson
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 14:59:23 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Jun 2009 12:59:23 +0000
Subject: [issue6369] binhex buggy in py3k
In-Reply-To: <1246286179.9.0.0098379045157.issue6369@psf.upfronthosting.co.za>
Message-ID: <1246366763.6.0.515588616135.issue6369@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, failure or success of the current tests seems to rely on the
length of the filename being tested! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6369>
_______________________________________

From report at bugs.python.org  Tue Jun 30 15:05:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 30 Jun 2009 13:05:42 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246367142.61.0.881336730265.issue6387@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is definitely a feature request rather than a bug.

As I understand it, you want to special-case floor division so that
if the argument types are (int, float) or (float, int) then the result is 
computed exactly.  Is that correct?  Note that the result of the floor 
division in your examples is a float, so it won't always be able to 
represent the result exactly anyway.  Or are you also proposing to change 
the return type to int/long?  What should (2**55-2)//2.0 return with your 
proposed change, and why?

Why single out floor division for this treatment?  What about the other 
binary operations?

I think this change adds complication to the language semantics without 
giving significant benefits.  It's true that there are a couple of places 
in Python that *do* special-case integers instead of converting to float 
(I'm thinking particularly of int <-> float comparisons, and math.log), 
but there are good reasons for those special cases and I don't think we 
should add to them.

Big -1 from me, I'm afraid.

----------
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 15:56:34 2009
From: report at bugs.python.org (Eric Smith)
Date: Tue, 30 Jun 2009 13:56:34 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246370194.62.0.793958455625.issue6387@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with Mark: -1.

Do you have any specific use cases where this has caused problems, or is
this academic?

Maybe you can get some support for this on python-ideas, but I suggest
we close it in the meantime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 16:06:31 2009
From: report at bugs.python.org (Yitz Gale)
Date: Tue, 30 Jun 2009 14:06:31 +0000
Subject: [issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with
	macports libintl
In-Reply-To: <1243755260.42.0.755665912346.issue6154@psf.upfronthosting.co.za>
Message-ID: <1246370791.65.0.0203285627257.issue6154@psf.upfronthosting.co.za>


Changes by Yitz Gale <gale at sefer.org>:


----------
nosy: +ygale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________

From report at bugs.python.org  Tue Jun 30 16:16:44 2009
From: report at bugs.python.org (Tim Peters)
Date: Tue, 30 Jun 2009 14:16:44 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246371404.11.0.18336994862.issue6387@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Yup, -1 here too.  For dyadic arithmetic operations (+ - * / % //) on
mixed numeric types, Python's execution model coerces the operands to a
common type before computation begins.  Besides just being the way it's
worked "forever" in Python, it's consistent and explainable.  Growing a
wart for one case of one case would be inconsistent and deeply
surprising at a higher level.  Live with it ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 16:18:02 2009
From: report at bugs.python.org (Poor Yorick)
Date: Tue, 30 Jun 2009 14:18:02 +0000
Subject: [issue6363] __future__ statements break doctest
In-Reply-To: <1246242450.27.0.0341374672588.issue6363@psf.upfronthosting.co.za>
Message-ID: <1246371482.94.0.431102675287.issue6363@psf.upfronthosting.co.za>


Poor Yorick <pooryorick at users.sourceforge.net> added the comment:

It seems that "compile" does not recognize some flags:

Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import __future__
>>> compile('a=5', '<string>', 'single',
__future__.print_function.compiler_flag
)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: compile(): unrecognised flags

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6363>
_______________________________________

From report at bugs.python.org  Tue Jun 30 16:26:11 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jun 2009 14:26:11 +0000
Subject: [issue6387] floor division gives different result for int versus
	float.
In-Reply-To: <1246359342.27.0.481159962703.issue6387@psf.upfronthosting.co.za>
Message-ID: <1246371971.58.0.780455230627.issue6387@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6387>
_______________________________________

From report at bugs.python.org  Tue Jun 30 16:28:48 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Jun 2009 14:28:48 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246372128.83.0.854694365306.issue6383@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Right. Actually unicodetype_db.h is the one included in unicodectype.c,
I moved my script into makeunicodedata.py.

Here is a new patch. The code generated for _PyUnicode_ToNumeric is the
same as before (except for some tabs), see the old patch if you want to
check the actual changes in the function.

----------
Added file: http://bugs.python.org/file14405/unicode-tonumeric-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 17:03:20 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Tue, 30 Jun 2009 15:03:20 +0000
Subject: [issue3955] maybe doctest doesn't understand unicode_literals?
In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za>
Message-ID: <1246374200.3.0.696775501321.issue3955@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

This problem seems more severe as the appended test case shows.

That gives me:

Expected:
    u'?'
Got:
    u'\u012b'

Both literals are the same.

Unicode literals in doc strings are not treated as other escaped
characters: 

>>> repr(r'\n')
"'\\\\n'"
>>> repr('\n')
"'\\n'"

but:

>>> repr(ur'\u012b')
"u'\\u012b'"
>>> repr(u'\u012b')
"u'\\u012b'"

So there is no work around in the docstring's reference itself.

I file this here, even though the problems are not strictly equal. I do
believe though that there is or should be a common solution to these
issues. Both results need to be interpreted on a more abstract scale.

----------
Added file: http://bugs.python.org/file14406/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3955>
_______________________________________

From report at bugs.python.org  Tue Jun 30 17:04:08 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Tue, 30 Jun 2009 15:04:08 +0000
Subject: [issue1293741] doctest runner cannot handle non-ascii characters
Message-ID: <1246374248.96.0.647069717238.issue1293741@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

See attached patch which works for error reporting and verbose output.

----------
keywords: +patch
nosy: +christoph
Added file: http://bugs.python.org/file14407/doctest.unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1293741>
_______________________________________

From report at bugs.python.org  Tue Jun 30 17:09:11 2009
From: report at bugs.python.org (Poor Yorick)
Date: Tue, 30 Jun 2009 15:09:11 +0000
Subject: [issue6363] __future__ statements break doctest
In-Reply-To: <1246242450.27.0.0341374672588.issue6363@psf.upfronthosting.co.za>
Message-ID: <1246374551.71.0.655434406445.issue6363@psf.upfronthosting.co.za>


Poor Yorick <pooryorick at users.sourceforge.net> added the comment:

here is a monkey patch to work around the problem:

import __future__
import doctest
if sys.version_info.major > 2:
        _extract_future_flags_old = doctest._extract_future_flags
        def _extract_future_flags(globs):
                flags = _extract_future_flags_old(globs)
                flags = flags & ~__future__.division.compiler_flag
                flags = flags & ~__future__.absolute_import.compiler_
                flags = flags & ~__future__.nested_scopes.compiler_fl
                flags = flags & ~__future__.print_function.compiler_f
                flags = flags & ~__future__.unicode_literals.compiler
                flags = flags & ~__future__.with_statement.compiler_f
                return flags
        doctest._extract_future_flags = _extract_future_flags

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6363>
_______________________________________

From report at bugs.python.org  Tue Jun 30 17:25:00 2009
From: report at bugs.python.org (vinoth)
Date: Tue, 30 Jun 2009 15:25:00 +0000
Subject: [issue6367] Change the instruction pointer in python
In-Reply-To: <1246344272.12.0.611771436981.issue6367@psf.upfronthosting.co.za>
Message-ID: <6176a14d0906300824j26fe66beh6a549e3d179756a@mail.gmail.com>


vinoth <4vinoth at gmail.com> added the comment:

HI

Exceptions are doing exactly the right way. but what I am telling is a new
way of flow control which no languages currently having.

On Tue, Jun 30, 2009 at 12:14 PM, Martin v. L??wis <report at bugs.python.org>wrote:

>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> So there is a language feature there already that solves your problem
> exactly, and you don't want to use it? Exceptions are *exactly* the
> right way to provide non-local gotos in a structured manner.
>
> I'm opposed to any change to the language because the desired feature is
> already there. Use it. Don't tell that it is the wrong way, it is
> exactly the right way.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6367>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14408/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6367>
_______________________________________
-------------- next part --------------
HI<br><br>Exceptions are doing exactly the right way. but what I am telling is a new way of flow control which no languages currently having.<br><br><br><div class="gmail_quote">On Tue, Jun 30, 2009 at 12:14 PM, Martin v. L??wis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Martin v. L??wis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<br>
So there is a language feature there already that solves your problem<br>
exactly, and you don&#39;t want to use it? Exceptions are *exactly* the<br>
right way to provide non-local gotos in a structured manner.<br>
<br>
I&#39;m opposed to any change to the language because the desired feature is<br>
already there. Use it. Don&#39;t tell that it is the wrong way, it is<br>
exactly the right way.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6367" target="_blank">http://bugs.python.org/issue6367</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>vin<br>

From report at bugs.python.org  Tue Jun 30 17:46:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 30 Jun 2009 15:46:57 +0000
Subject: [issue6347] hpux11.00-parisc: dtoa.c: "Failed to find an exact-width
	32-bit integer type"
In-Reply-To: <1246059976.81.0.366952581709.issue6347@psf.upfronthosting.co.za>
Message-ID: <1246376817.61.0.220424333746.issue6347@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  That all seems fairly clear cut:  HP-UX defines everything 
integer-related that C99 expects it to, but puts it in inttypes.h rather 
than stdint.h.  Given that the autoconf tests for uint32_t and friends 
are checking both stdint.h and inttypes.h, and that this problem 
apparently exists on other platforms as well (some versions of Solaris, 
according to the autoconf manual), I think it makes sense to update 
pyport.h to include both stdint.h and inttypes.h.

Patch committed, r73701 (trunk), r73702 (py3k) and r73703 (release31-
maint).  I don't think there's any need to backport to 3.0 or 2.6: 
neither should have this build problem.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6347>
_______________________________________

From report at bugs.python.org  Tue Jun 30 17:49:03 2009
From: report at bugs.python.org (Michael)
Date: Tue, 30 Jun 2009 15:49:03 +0000
Subject: [issue6389] os.chmod() documentation refers to non-existent
	documentation in stat
In-Reply-To: <1246376943.24.0.988862914661.issue6389@psf.upfronthosting.co.za>
Message-ID: <1246376943.24.0.988862914661.issue6389@psf.upfronthosting.co.za>


New submission from Michael <mhearne808 at yahoo.com>:

If you look at the documentation for os.chmod(), it says:
"mode may take one of the following values (as defined in the stat
module)..."

and then lists a number of constants from the stat module (stat.S_ISUID,
stat.S_ISGID, etc.)

I cannot seem to find these constants defined anywhere on the stat
module page.  May I suggest that these constants be defined in the
documentation for os.chmod(), to make it easier on the user?

----------
assignee: georg.brandl
components: Documentation
messages: 89932
nosy: georg.brandl, mhearne808
severity: normal
status: open
title: os.chmod() documentation refers to non-existent documentation in stat
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6389>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:15:53 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Jun 2009 16:15:53 +0000
Subject: [issue6376] description of Decinal.logical_invert is incorrect
In-Reply-To: <1246293287.33.0.612180884137.issue6376@psf.upfronthosting.co.za>
Message-ID: <1246378553.75.0.992834530094.issue6376@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r73704.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6376>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:17:38 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Jun 2009 16:17:38 +0000
Subject: [issue6374] Confused by subprocess API documentation
In-Reply-To: <1246290458.09.0.216781852955.issue6374@psf.upfronthosting.co.za>
Message-ID: <1246378658.51.0.32257968534.issue6374@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed in r73705.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6374>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:17:43 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Jun 2009 16:17:43 +0000
Subject: [issue6389] os.chmod() documentation refers to non-existent
	documentation in stat
In-Reply-To: <1246376943.24.0.988862914661.issue6389@psf.upfronthosting.co.za>
Message-ID: <1246378663.17.0.714629988796.issue6389@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since the constants are listed in the os.chmod section of the manual, do
I understand that you are suggesting that the eplanations of the
meanings of the flags from the chmod man page be added to that list?

I observe that in the unix man pages the flags are documented both in
the chmod(2) man page and the stat(2) man page, with somewhat different
text.  I'm not sure this informational redundancy is good...and I'd be
inclined to put the docs in the stat module docs where the flags are
actually defined.  They will then be hotlinked from the flag list in
os.chmod.

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6389>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:19:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Jun 2009 16:19:26 +0000
Subject: [issue6384] Permalink to built-in exception class hierarchy
	documentation
In-Reply-To: <1246334627.57.0.503103979691.issue6384@psf.upfronthosting.co.za>
Message-ID: <1246378766.96.0.394594162813.issue6384@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I added a new heading there in r73706.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6384>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:21:27 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Jun 2009 16:21:27 +0000
Subject: [issue6389] os.chmod() documentation refers to non-existent
	documentation in stat
In-Reply-To: <1246376943.24.0.988862914661.issue6389@psf.upfronthosting.co.za>
Message-ID: <1246378887.21.0.646281936069.issue6389@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree with David.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6389>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:23:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Jun 2009 16:23:56 +0000
Subject: [issue1367628] use PyOS_ReadlineFunctionPointer in non-interractive
	input
Message-ID: <1246379036.04.0.906226898.issue1367628@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Isn't the same functionality already implemented by code.interact()?

----------
nosy: +amaury.forgeotdarc
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367628>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:34:15 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Jun 2009 16:34:15 +0000
Subject: [issue1388872] Polymorphic getters / setters
Message-ID: <1246379655.59.0.471447429281.issue1388872@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is normal behavior: the property is created with the functions
created just above, even before they belong to any class.

To make the property search the class hierarchy, you could write: 
  foo = property(lambda x: x.get_foo(), lambda x, v: x.set_foo(v))

or make it a function:
  def polymorphic_property(getter, setter):
      return property(lambda x  : getattr(x, getter)(),
                      lambda x,v: getattr(x, setter)(v))
  [...]
  foo = polymorphic_property('get_foo', 'set_foo')

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1388872>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:35:22 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Jun 2009 16:35:22 +0000
Subject: [issue6371] Minor internal link errors in Optparse doc
In-Reply-To: <1246287843.59.0.00928118566027.issue6371@psf.upfronthosting.co.za>
Message-ID: <1246379722.95.0.103694242842.issue6371@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r73707.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6371>
_______________________________________

From report at bugs.python.org  Tue Jun 30 18:52:50 2009
From: report at bugs.python.org (Brian Mearns)
Date: Tue, 30 Jun 2009 16:52:50 +0000
Subject: [issue6390] File reads past EOF in "w+b" mode
In-Reply-To: <1246380770.16.0.615703374982.issue6390@psf.upfronthosting.co.za>
Message-ID: <1246380770.16.0.615703374982.issue6390@psf.upfronthosting.co.za>


New submission from Brian Mearns <bmearns at ieee.org>:

Open a file in "w+b" mode: if you write to the file, then read from it
without seeking backward, it reads past the EOF, apparently out into
memory, which could be a pretty bad security concern. Have not checked
if "w+" mode does the same.

### Bad behavior...
>>> fid = open("temp", "w+b")
>>> fid.read()
''
>>> fid.write("foobar")
#Read while positioned on EOF
>>> fid.read(10)
'\xc2\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> fid.seek(0)
>>> fid.read(10)
'foobar\xc2\x00\x00\x00'
>>> fid.close()

###Correct behavior after seeking backwards:
>>> fid = open("temp2", "w+b")
>>> fid.read()
''
>>> fid.write("foobar")
>>> fid.seek(0)
>>> fid.read(10)
'foobar'
>>> fid.close()

Interestingly, it appears that any seek works, you don't necessarily
have to go backwards:

>>> fid = open("temp2", "w+b")
>>> fid.write("foobar")
>>> fid.tell()
6L
>>> fid.seek(6)
>>> fid.read()
''

----------
components: IO
messages: 89941
nosy: bmearns
severity: normal
status: open
title: File reads past EOF in "w+b" mode
type: security
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6390>
_______________________________________

From report at bugs.python.org  Tue Jun 30 19:11:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Jun 2009 17:11:47 +0000
Subject: [issue6390] File reads past EOF in "w+b" mode
In-Reply-To: <1246380770.16.0.615703374982.issue6390@psf.upfronthosting.co.za>
Message-ID: <1246381907.03.0.612945799405.issue6390@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, see the discussion in issue3207, specially this part:

http://www.cplusplus.com/reference/clibrary/cstdio/fopen.html
"""
For the modes where both read and writing (or appending) are allowed
(those which include a "+" sign), the stream should be flushed (fflush)
or repositioned (fseek, fsetpos, rewind) between either a reading
operation followed by a writing operation or a writing operation
followed by a reading operation.
"""

Python 2.x relies on the fopen functions to implement files, and
inherits this behavior.
Python 3.x has a completely new implementation and doesn't have this
problem.

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6390>
_______________________________________

From report at bugs.python.org  Tue Jun 30 19:13:44 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 17:13:44 +0000
Subject: [issue5313] multiprocessing.process using os.close(sys.stdin.fileno)
	instead of sys.stdin.close()
In-Reply-To: <1235020872.08.0.0158488308351.issue5313@psf.upfronthosting.co.za>
Message-ID: <1246382024.96.0.821170249545.issue5313@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Committed in r73708 on trunk

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5313>
_______________________________________

From report at bugs.python.org  Tue Jun 30 19:14:18 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 17:14:18 +0000
Subject: [issue5155] Multiprocessing.Queue created by sub-process fails when
	used in sub-sub-process ("bad file descriptor" in q.get())
In-Reply-To: <1233798773.64.0.357189782395.issue5155@psf.upfronthosting.co.za>
Message-ID: <1246382058.9.0.637875321034.issue5155@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Committed in r73708 on trunk

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5155>
_______________________________________

From report at bugs.python.org  Tue Jun 30 19:14:57 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Jun 2009 17:14:57 +0000
Subject: [issue5331] multiprocessing hangs when Pool used within Process
In-Reply-To: <1235146028.47.0.682929217877.issue5331@psf.upfronthosting.co.za>
Message-ID: <1246382097.15.0.642696422582.issue5331@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Committed in r73708 on trunk

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5331>
_______________________________________

From report at bugs.python.org  Tue Jun 30 19:31:12 2009
From: report at bugs.python.org (Vernon Cole)
Date: Tue, 30 Jun 2009 17:31:12 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246372128.83.0.854694365306.issue6383@psf.upfronthosting.co.za>
Message-ID: <b7eb4a700906301031y1ec55e78gec62c14deeb31e0@mail.gmail.com>


Vernon Cole <vernondcole at gmail.com> added the comment:

Wow! Quick response! My outstanding bug on IronPython has been hanging out
there since August of last year.
  I don't really want to try compiling the standard library on my laptop,
but I do want to fully test my code soon. What is the first place I can
expect to see this in binary form? 3.2 alpha?
--
Vernon

On Tue, Jun 30, 2009 at 8:28 AM, Amaury Forgeot d'Arc <
report at bugs.python.org> wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Right. Actually unicodetype_db.h is the one included in unicodectype.c,
> I moved my script into makeunicodedata.py.
>
> Here is a new patch. The code generated for _PyUnicode_ToNumeric is the
> same as before (except for some tabs), see the old patch if you want to
> check the actual changes in the function.
>
> ----------
> Added file: http://bugs.python.org/file14405/unicode-tonumeric-2.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6383>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14409/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________
-------------- next part --------------
Wow! Quick response! My outstanding bug on IronPython has been hanging out there since August of last year. <br>?? I don&#39;t really want to try compiling the standard library on my laptop, but I do want to fully test my code soon. What is the first place I can expect to see this in binary form? 3.2 alpha?<br>
--<br>Vernon<br><br><div class="gmail_quote">On Tue, Jun 30, 2009 at 8:28 AM, Amaury Forgeot d&#39;Arc <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
Amaury Forgeot d&#39;Arc &lt;<a href="mailto:amauryfa at gmail.com">amauryfa at gmail.com</a>&gt; added the comment:<br>
<br>
</div>Right. Actually unicodetype_db.h is the one included in unicodectype.c,<br>
I moved my script into makeunicodedata.py.<br>
<br>
Here is a new patch. The code generated for _PyUnicode_ToNumeric is the<br>
same as before (except for some tabs), see the old patch if you want to<br>
check the actual changes in the function.<br>
<br>
----------<br>
Added file: <a href="http://bugs.python.org/file14405/unicode-tonumeric-2.patch" target="_blank">http://bugs.python.org/file14405/unicode-tonumeric-2.patch</a><br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6383" target="_blank">http://bugs.python.org/issue6383</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Jun 30 21:11:48 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 30 Jun 2009 19:11:48 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246389108.69.0.301464427609.issue6383@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Notice that this is a duplicate of the longstanding issue1571184, which
has a patch that is more comprehensive than the one proposed here. So
rather than accepting Amaury's patch, I'd prefer to see Anders' patch
reviewed, and revised as necessary.

----------
dependencies: +Generate numeric/space/linebreak from Unicode database.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 21:43:09 2009
From: report at bugs.python.org (En-Ran Zhou)
Date: Tue, 30 Jun 2009 19:43:09 +0000
Subject: [issue6391] Incorrect description of unittest.TestCase.run
In-Reply-To: <1246390989.67.0.115182745273.issue6391@psf.upfronthosting.co.za>
Message-ID: <1246390989.67.0.115182745273.issue6391@psf.upfronthosting.co.za>


New submission from En-Ran Zhou <zhouer at gmail.com>:

In Python 2.6 Document, Library reference 26.3 unittest
(http://docs.python.org/library/unittest.html#unittest.TestCase.run)
The description of TestCase.run method says that ``If result is omitted
or None, a temporary result object is created (by calling the
defaultTestCase() method) and used'', but I think it should be
defaultTestResult() instead of defaultTestCase().

----------
assignee: georg.brandl
components: Documentation
messages: 89948
nosy: georg.brandl, zhouer
severity: normal
status: open
title: Incorrect description of unittest.TestCase.run
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6391>
_______________________________________

From report at bugs.python.org  Tue Jun 30 23:29:32 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Jun 2009 21:29:32 +0000
Subject: [issue6383] error in unicodedata.numeric(u"\u2187") and 2188
In-Reply-To: <1246329784.46.0.00677223147699.issue6383@psf.upfronthosting.co.za>
Message-ID: <1246397372.32.0.590951440233.issue6383@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, my patch is entirely contained in the one from issue1571184.
I mark this one as a duplicate, and will review and update the other.

----------
dependencies:  -Generate numeric/space/linebreak from Unicode database.
resolution:  -> duplicate
status: open -> closed
superseder:  -> Generate numeric/space/linebreak from Unicode database.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6383>
_______________________________________

From report at bugs.python.org  Tue Jun 30 23:54:55 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Jun 2009 21:54:55 +0000
Subject: [issue6391] Incorrect description of unittest.TestCase.run
In-Reply-To: <1246390989.67.0.115182745273.issue6391@psf.upfronthosting.co.za>
Message-ID: <1246398895.31.0.5052966193.issue6391@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>>> class MyTest(TestCase):
...   def runTest(self): pass
...   def defaultTestCase(self):
...     print('defaultTestCase called')
...
>>> test = MyTest()
>>> test.run()
>>> class MyTest(TestCase):
...   def runTest(self): pass
...   def defaultTestResult(self):
...     print('defaultTestResult called')
...
>>> test = MyTest()
>>> test.run()
defaultTestResult called
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programmi\Python31\lib\unittest.py", line 461, in run
    result.startTest(self)
AttributeError: 'NoneType' object has no attribute 'startTest'

I think you are right, here only "defaultTestResult called" is printed
(just before the traceback). Also there's no doc about
defaultTestCase(). The doc can also be clearer about 'result object',
possibly replacing that part with 'a temporary TestResult instance'.

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
versions: +Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6391>
_______________________________________

From report at bugs.python.org  Tue Jun 30 23:56:56 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Tue, 30 Jun 2009 21:56:56 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1246399016.54.0.676888433874.issue5801@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

I cleaned the rest of the module by shortening lines that are too long,
removing useless blocks of empty lines and adding whitespace around
operators and after commas.  Nothing in the programming logic was changed.

----------
Added file: http://bugs.python.org/file14410/wsgiref-patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________

From report at bugs.python.org  Tue Jun 30 23:58:34 2009
From: report at bugs.python.org (Pablo Torres Navarrete)
Date: Tue, 30 Jun 2009 21:58:34 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1246399114.98.0.184507905192.issue5801@psf.upfronthosting.co.za>


Pablo Torres Navarrete <tn.pablo at gmail.com> added the comment:

The patch applies to rev 73702 of the py3k branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________