From report at bugs.python.org  Mon Sep  1 00:38:48 2008
From: report at bugs.python.org (Ron Adam)
Date: Sun, 31 Aug 2008 22:38:48 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1220222328.41.0.36794041076.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

New patch to replace outdated patch due to other changes to pydoc.

The easies way to try this out is to:

>> import pydoc
>> pydoc.gui()

Try it before and after the patch.  I think most people will prefer the
patch.

Added file: http://bugs.python.org/file11321/pydoc_gui_.diff

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

From report at bugs.python.org  Mon Sep  1 00:38:55 2008
From: report at bugs.python.org (Ron Adam)
Date: Sun, 31 Aug 2008 22:38:55 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1220222335.24.0.496238344563.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file9350/pydocnotk.diff

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

From report at bugs.python.org  Mon Sep  1 00:39:01 2008
From: report at bugs.python.org (Ron Adam)
Date: Sun, 31 Aug 2008 22:39:01 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1220222341.85.0.677321844759.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file9423/pydocnotk.diff

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

From report at bugs.python.org  Mon Sep  1 00:39:07 2008
From: report at bugs.python.org (Ron Adam)
Date: Sun, 31 Aug 2008 22:39:07 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1220222347.21.0.642781680411.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file9448/pydocnotk.diff

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

From report at bugs.python.org  Mon Sep  1 03:49:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 01:49:08 +0000
Subject: [issue3740] PEP 3121 --- module state is not nul-initalized as
	claimed in the PEP
In-Reply-To: <1220109289.56.0.0975805859845.issue3740@psf.upfronthosting.co.za>
Message-ID: <1220233748.55.0.236065837407.issue3740@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> loewis
nosy: +loewis

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

From report at bugs.python.org  Mon Sep  1 03:56:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 01:56:40 +0000
Subject: [issue3735] allow multiple threads to efficiently send the same
	requests to a processing.Pool without incurring duplicate processing
In-Reply-To: <1220051229.09.0.236623735385.issue3735@psf.upfronthosting.co.za>
Message-ID: <1220234200.65.0.32136833612.issue3735@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Sep  1 04:23:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 02:23:30 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220235810.66.0.0931415038826.issue3719@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> lemburg
nosy: +lemburg

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

From report at bugs.python.org  Mon Sep  1 04:29:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 02:29:41 +0000
Subject: [issue3738] logging.Handler.close does something
In-Reply-To: <1220098393.98.0.954077896829.issue3738@psf.upfronthosting.co.za>
Message-ID: <1220236181.03.0.618223982372.issue3738@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee: georg.brandl -> vsajip
nosy: +vsajip

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

From report at bugs.python.org  Mon Sep  1 05:36:57 2008
From: report at bugs.python.org (Viktor Ferenczi)
Date: Mon, 01 Sep 2008 03:36:57 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1220240217.19.0.0649203073114.issue3160@psf.upfronthosting.co.za>


Viktor Ferenczi <python at cx.hu> added the comment:

Thanks. I've tested the patch, it worked for me. However, I had to apply
it manually. No big deal, since not a big patch, anyway. :-)

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

From report at bugs.python.org  Mon Sep  1 05:38:05 2008
From: report at bugs.python.org (Viktor Ferenczi)
Date: Mon, 01 Sep 2008 03:38:05 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1220240285.62.0.568466497133.issue3160@psf.upfronthosting.co.za>


Viktor Ferenczi <python at cx.hu> added the comment:

Note: I tested the patch with the latest beta 2 release. The Windows
installer is beta2, but beta3 is announced. I don't understand why,
Guido should know...

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

From report at bugs.python.org  Mon Sep  1 09:38:21 2008
From: report at bugs.python.org (Uli Kunitz)
Date: Mon, 01 Sep 2008 07:38:21 +0000
Subject: [issue3744] make altinstall installs pydoc instead of pydoc3.0
In-Reply-To: <1220254701.93.0.57934772161.issue3744@psf.upfronthosting.co.za>
Message-ID: <1220254701.93.0.57934772161.issue3744@psf.upfronthosting.co.za>


New submission from Uli Kunitz <kune at deine-taler.de>:

make altinstall in Python3.0-b3 doesn't install pydoc as pydoc3.0.
Renaming pydoc to pydoc3.0 doesn't create any issues.

----------
components: Installation
messages: 72219
nosy: kune
severity: normal
status: open
title: make altinstall installs pydoc instead of pydoc3.0
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Sep  1 11:27:06 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 01 Sep 2008 09:27:06 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

Whereas openssl-based _hashlib refuses to accept unencoded strings:

>>> _hashlib.openssl_sha256("\xff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object supporting the buffer API required

the _sha256 version encodes to UTF-8 by default:

>>> _sha256.sha256("\xff").digest() ==
_sha256.sha256("\xff".encode("utf-8")).digest()
True

I think refusing is better, but at least the behaviour should be
consistent. Same for the other algorithms in hashlib.

----------
components: Library (Lib)
messages: 72220
nosy: hagen
severity: normal
status: open
title: _sha256 et al. encode to UTF-8 by default
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Sep  1 12:02:17 2008
From: report at bugs.python.org (Graham Higgins)
Date: Mon, 01 Sep 2008 10:02:17 +0000
Subject: [issue3746] Sphinx producing duplicate id attributes,
	HTML fails validation.
In-Reply-To: <1220263337.27.0.506394651597.issue3746@psf.upfronthosting.co.za>
Message-ID: <1220263337.27.0.506394651597.issue3746@psf.upfronthosting.co.za>


New submission from Graham Higgins <gjh-python at bel-epa.com>:

It seems Sphinx creates duplicate ids for <span> elements in Permalink 
headers. This causes Sphinx-generated HTML to fail W3C validation. 
Example:

http://docs.python.org/dev/tutorial/interpreter.html

where "id2" appears twice.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 72221
nosy: georg.brandl, gjhiggins
severity: normal
status: open
title: Sphinx producing duplicate id attributes, HTML fails validation.
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Sep  1 12:04:45 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 10:04:45 +0000
Subject: [issue3747] Fix caching in ABCMeta.__subclasscheck__
In-Reply-To: <1220263485.83.0.336107969335.issue3747@psf.upfronthosting.co.za>
Message-ID: <1220263485.83.0.336107969335.issue3747@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Two of the return paths from ABCMeta.__subclasscheck__ store the
subclass being checked in _abc_registry instead of _abc_cache.

The attached patch corrects the issue.

----------
files: meta_subclass_fix.diff
keywords: needs review, patch, patch
messages: 72222
nosy: ncoghlan
priority: critical
severity: normal
status: open
title: Fix caching in ABCMeta.__subclasscheck__
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11322/meta_subclass_fix.diff

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

From report at bugs.python.org  Mon Sep  1 12:07:04 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 10:07:04 +0000
Subject: [issue3747] Fix caching in ABCMeta.__subclasscheck__
In-Reply-To: <1220263485.83.0.336107969335.issue3747@psf.upfronthosting.co.za>
Message-ID: <1220263624.72.0.941545014451.issue3747@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep  1 12:18:13 2008
From: report at bugs.python.org (Graham Higgins)
Date: Mon, 01 Sep 2008 10:18:13 +0000
Subject: [issue3746] Sphinx producing duplicate id attributes,
	HTML fails validation.
In-Reply-To: <1220263337.27.0.506394651597.issue3746@psf.upfronthosting.co.za>
Message-ID: <1220264293.54.0.0895796964512.issue3746@psf.upfronthosting.co.za>


Graham Higgins <gjh-python at bel-epa.com> added the comment:

Um, hang fire. I need to do more analysis in order to reproduce the 
problem properly.

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

From report at bugs.python.org  Mon Sep  1 12:21:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 10:21:58 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1220264518.3.0.234771924268.issue3160@psf.upfronthosting.co.za>


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

Hi Viktor

I believe no installer was released for beta3 because Martin von L?wis
was on holidays and couldn't handle it.
Now we are in release candidate phase, the patch needs another reviewer
though.

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

From report at bugs.python.org  Mon Sep  1 13:27:07 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Sep 2008 11:27:07 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220268427.5.0.558746419294.issue3719@psf.upfronthosting.co.za>


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

Is adding the double-quotes enough to solve the problem ?

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

From report at bugs.python.org  Mon Sep  1 13:42:46 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 11:42:46 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220269366.96.0.984325550139.issue3352@psf.upfronthosting.co.za>


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

I found further PEP 8 non-compliances in the multiprocessing API while
working on a patch for issue 3589, mainly in the area of function names
that start with a capital letter, making them look like classes when
they definitely are not.

After noticing a few of these, I went through checked more thoroughly,
and found all of the following to be functions that claimed to be
classes by way of their naming convention (a far worse sin than using
camelCase instead of underscores):
multiprocessing.Pipe (aka multiprocessing.connection.Pipe)
multiprocessing.RawValue (aka multiprocessing.sharedctypes.RawValue)
multiprocessing.RawArray (aka multiprocessing.sharedctypes.RawArray)
multiprocessing.Value (aka multiprocessing.sharedctypes.Value)
multiprocessing.Array (aka multiprocessing.sharedctypes.Array)
multiprocessing.connection.Client
multiprocessing.connection.SocketClient
multiprocessing.connection.PipeClient
multiprocessing.connection.XmlClient
multiprocessing.managers.RebuildProxy
multiprocessing.managers.MakeProxyType
multiprocessing.managers.AutoProxy
multiprocessing.managers.Array

These should all be converted to start with a lowercase letter and use
underscores, otherwise people are going to assume they can be treated
like classes.

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

From report at bugs.python.org  Mon Sep  1 13:42:49 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 11:42:49 +0000
Subject: [issue3748] [py3k] platform.architecture() prints vogus messege on
	windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

As title, platform.architecture() prints vogus messege.

>>> import platform
>>> platform.architecture()
????????????????
('32bit', 'WindowsPE')

It says "speicied path is not found".

----------
components: Library (Lib)
messages: 72227
nosy: ocean-city
severity: normal
status: open
title: [py3k] platform.architecture() prints vogus messege on windows
versions: Python 3.0

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

From report at bugs.python.org  Mon Sep  1 13:46:24 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 11:46:24 +0000
Subject: [issue3732] bdist_msi gives a deprecation warning when run with
	Python 2.6
In-Reply-To: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>
Message-ID: <1220269584.55.0.174624099524.issue3732@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +needs review

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

From report at bugs.python.org  Mon Sep  1 13:57:53 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 11:57:53 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220270273.74.0.451591496893.issue3589@psf.upfronthosting.co.za>


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

Patch attached that removes the misleading "convenience" functions,
replacing them with explicit imports of the appropriate names.

The patch also adds docstrings to some of the original class definitions
that were missing them.

No changes were needed to the multiprocessing tests - they all still
passed with this change, and the docs are still accurate as well (I
would actually say this change makes the docs MORE accurate).

Python 2.6b3+ (trunk:66083, Aug 31 2008, 19:00:32)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing as mp
>>> isinstance(mp.Lock(), mp.Lock)
True
>>> mp.Lock.__name__
'Lock'
>>> mp.Lock.__module__
'multiprocessing.synchronize'

----------
keywords: +patch
Added file: http://bugs.python.org/file11323/issue3589_true_aliases_in_multiprocessing.diff

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

From report at bugs.python.org  Mon Sep  1 14:02:12 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 12:02:12 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220270532.7.0.0131249902344.issue3352@psf.upfronthosting.co.za>


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

Benjamin's patch was applied in r65982

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

From report at bugs.python.org  Mon Sep  1 14:03:08 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 12:03:08 +0000
Subject: [issue3748] [py3k] platform.architecture() prints vogus messege on
	windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220270588.45.0.0695448735746.issue3748@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This difference between trunk and py3k would go down to this.

import os
os.popen(r'file e:\python-dev\py3k\PC\VC6\python_d.exe 2> /dev/null')

trunk prints nothing, but py3k prints that message.

I don't know which is popen's correct behavior, we can supress this
message by using subprocess.Popen instead.

Index: Lib/platform.py
===================================================================
--- Lib/platform.py     (revision 66090)
+++ Lib/platform.py     (working copy)
@@ -110,7 +110,7 @@

 __version__ = '1.0.6'

-import sys, os, re
+import sys, os, re, subprocess

 ### Platform specific APIs

@@ -942,7 +942,7 @@
     """
     target = _follow_symlinks(target)
     try:
-        f = os.popen('file %s 2> /dev/null' % target)
+        f = subprocess.Popen('file %s 2> /dev/null' % target,
stdout=subprocess
.PIPE, stderr=subprocess.PIPE).stdout
     except (AttributeError,os.error):
         return default
     output = f.read().strip()

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

From report at bugs.python.org  Mon Sep  1 14:27:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 12:27:45 +0000
Subject: [issue3748] [py3k] platform.architecture() prints vogus messege on
	windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220272065.59.0.789835722202.issue3748@psf.upfronthosting.co.za>


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

The call to _syscmd_file() should be avoided on windows platforms:
- the "file" program does not exist
- the stderr is redirected to /dev/null, which does not necessarily exists!

On my machine, there is a "c:\dev" directory. Now it contains a file
named "null", which content is "'file' is not recognized as an internal
or external command, operable program or batch file."
No comment.

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

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

From report at bugs.python.org  Mon Sep  1 14:29:49 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 12:29:49 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220272189.49.0.98779209743.issue3352@psf.upfronthosting.co.za>


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

Patch added that removes the incorrect Py3k warnings from the threading
module (also restores the methods to the same __name__ attributes as
they had in 2.5).

Added file: http://bugs.python.org/file11324/issue3352_remove_threading_py3k_warnings.diff

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

From report at bugs.python.org  Mon Sep  1 14:30:01 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Sep 2008 12:30:01 +0000
Subject: [issue3748] platform.architecture() prints bogus message on windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220272201.64.0.498436273321.issue3748@psf.upfronthosting.co.za>


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

I think it's better to disable that function in the same way as done for
_syscmd_uname:

    if sys.platform in ('dos','win32','win16','os2'):
        # XXX Others too ?
        return default

BTW: I assume you are running this on win32, right ?

----------
nosy: +lemburg
title: [py3k] platform.architecture() prints vogus messege on windows -> platform.architecture() prints bogus message on windows
versions: +Python 2.6

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

From report at bugs.python.org  Mon Sep  1 14:31:16 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Sep 2008 12:31:16 +0000
Subject: [issue3748] platform.architecture() prints bogus message on windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220272276.21.0.592331028654.issue3748@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee:  -> lemburg

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

From report at bugs.python.org  Mon Sep  1 14:50:05 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 12:50:05 +0000
Subject: [issue3748] platform.architecture() prints bogus message on windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220273405.79.0.762221437647.issue3748@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've attached patch. (trunk)

>BTW: I assume you are running this on win32, right ?

Yes, I'm running win2k.

----------
assignee: lemburg -> 
keywords: +patch
versions:  -Python 2.6
Added file: http://bugs.python.org/file11325/fix.patch

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

From report at bugs.python.org  Mon Sep  1 14:53:16 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 12:53:16 +0000
Subject: [issue3735] allow multiple threads to efficiently send the same
	requests to a processing.Pool without incurring duplicate processing
In-Reply-To: <1220234200.71.0.578754773323.issue3735@psf.upfronthosting.co.za>
Message-ID: <38F4CAEF-B1DC-4339-95ED-3168EC099410@gmail.com>


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

Thanks for adjusting the targets ben

On Aug 31, 2008, at 9:56 PM, Benjamin Peterson  
<report at bugs.python.org> wrote:

>
> Changes by Benjamin Peterson <musiccomposition at gmail.com>:
>
>
> ----------
> versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3735>
> _______________________________________

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

From report at bugs.python.org  Mon Sep  1 14:58:14 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 12:58:14 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220273894.79.0.925246442848.issue3352@psf.upfronthosting.co.za>


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

Second patch added that removes the deprecation warnings from the Py3k
version of the threading module.

Added file: http://bugs.python.org/file11326/issue3352_remove_threading_deprecation_warnings.diff

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

From report at bugs.python.org  Mon Sep  1 14:58:31 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 12:58:31 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220273911.51.0.929622573073.issue3352@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +needs review -patch

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

From report at bugs.python.org  Mon Sep  1 14:58:41 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 12:58:41 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220273921.57.0.479168906591.issue3352@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: jnoller -> 

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

From report at bugs.python.org  Mon Sep  1 14:58:58 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 12:58:58 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220273938.97.0.320457907102.issue3352@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch

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

From report at bugs.python.org  Mon Sep  1 15:07:53 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 13:07:53 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220274473.13.0.297611914604.issue3589@psf.upfronthosting.co.za>


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

Interesting - in some of the other work I was doing regarding the PEP 8
compliant alternative threading API, I noticed that the threading module
contains similar gems such as:

def Event(*args, **kwds):
  return _Event(*args, **kwds)

Using a factory function to discourage subclassing is one thing, but why
name the factory function as if it was a still a class?

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

From report at bugs.python.org  Mon Sep  1 15:19:36 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 13:19:36 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220275176.6.0.922259669823.issue3352@psf.upfronthosting.co.za>


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

It turns out threading uses the odd "class-that-is-not-a-class" naming
scheme as well:
threading.Lock
threading.RLock
threading.Condition
threading.Semaphore
threading.BoundedSemaphore
threading.Event
threading.Timer

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

From report at bugs.python.org  Mon Sep  1 15:27:34 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 13:27:34 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220275654.08.0.924349623173.issue3352@psf.upfronthosting.co.za>


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

Patch added to tone down note regarding the PEP 8 compliant aliases that
have been added to the threading module.

Added file: http://bugs.python.org/file11327/issue3352_tone_down_26_threading_docs.diff

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

From report at bugs.python.org  Mon Sep  1 15:46:20 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 13:46:20 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220276780.45.0.255012704849.issue3352@psf.upfronthosting.co.za>


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

And one last patch to adjust the threading docs in Py3k to reflect the
fact that the 2.x API is still supported, even if it is no longer
documented.

Added file: http://bugs.python.org/file11328/issue3352_update_30_threading_docs.diff

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

From report at bugs.python.org  Mon Sep  1 15:50:32 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 13:50:32 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220277032.42.0.986385035535.issue3352@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file11324/issue3352_remove_threading_py3k_warnings.diff

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

From report at bugs.python.org  Mon Sep  1 15:51:56 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 13:51:56 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220277116.39.0.823534297687.issue3352@psf.upfronthosting.co.za>


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

Updated the 2.6 threading patch to also remove the warnings from the
methods that are being replaced by properties.

Added file: http://bugs.python.org/file11329/issue3352_remove_threading_py3k_warnings.diff

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

From report at bugs.python.org  Mon Sep  1 15:54:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 13:54:23 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220277263.16.0.0740808624086.issue3352@psf.upfronthosting.co.za>


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

The patches look good to me. Please apply.

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

From report at bugs.python.org  Mon Sep  1 15:59:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 13:59:18 +0000
Subject: [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1220277558.01.0.00459561886089.issue3712@psf.upfronthosting.co.za>


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

I think the patch looks good.

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

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

From report at bugs.python.org  Mon Sep  1 16:03:01 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 14:03:01 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1220274473.13.0.297611914604.issue3589@psf.upfronthosting.co.za>
Message-ID: <BAF53CAB-E53B-4211-AA71-23C07B694001@gmail.com>


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

This is why multiprocessing had them nick - the threading module does

On Sep 1, 2008, at 9:07 AM, Nick Coghlan <report at bugs.python.org> wrote:

>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Interesting - in some of the other work I was doing regarding the  
> PEP 8
> compliant alternative threading API, I noticed that the threading  
> module
> contains similar gems such as:
>
> def Event(*args, **kwds):
>  return _Event(*args, **kwds)
>
> Using a factory function to discourage subclassing is one thing, but  
> why
> name the factory function as if it was a still a class?
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3589>
> _______________________________________

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

From report at bugs.python.org  Mon Sep  1 16:04:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 14:04:23 +0000
Subject: [issue3732] bdist_msi gives a deprecation warning when run with
	Python 2.6
In-Reply-To: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>
Message-ID: <1220277863.52.0.327101376946.issue3732@psf.upfronthosting.co.za>


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

Go ahead and apply.

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

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

From report at bugs.python.org  Mon Sep  1 16:08:13 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Sep 2008 14:08:13 +0000
Subject: [issue3748] platform.architecture() prints bogus message on windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220278093.92.0.112813889116.issue3748@psf.upfronthosting.co.za>


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

Looks good. Could you apply it to both trunk and the py3k branch ?!

Mark it "Reviewed by Marc-Andre Lemburg" to keep folks happy ;-)

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

From report at bugs.python.org  Mon Sep  1 16:13:22 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Mon, 01 Sep 2008 14:13:22 +0000
Subject: [issue3749] incrementalencoder and incrementalencoder
In-Reply-To: <1220278402.04.0.0826579275703.issue3749@psf.upfronthosting.co.za>
Message-ID: <1220278402.04.0.0826579275703.issue3749@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

In the codecs module section of the Library Reference, an explanation
about incrementalencoder and decoder starts with "incrementalencoder and
incrementalencoder:" (both are 'encoder's).
Moreover, the corresponding class name for incrementaldecoder is also
referred as "IncrementalEncoder".

----------
assignee: georg.brandl
components: Documentation
messages: 72247
nosy: georg.brandl, mft
severity: normal
status: open
title: incrementalencoder and incrementalencoder
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Sep  1 16:14:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 14:14:01 +0000
Subject: [issue3703] open() on directory raises IOError with unhelpful message
In-Reply-To: <1219847162.49.0.00805052293115.issue3703@psf.upfronthosting.co.za>
Message-ID: <1220278441.93.0.678508810278.issue3703@psf.upfronthosting.co.za>


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

Fixed in r66097.

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

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

From report at bugs.python.org  Mon Sep  1 16:16:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 01 Sep 2008 14:16:19 +0000
Subject: [issue3749] incrementalencoder and incrementalencoder
In-Reply-To: <1220278402.04.0.0826579275703.issue3749@psf.upfronthosting.co.za>
Message-ID: <1220278579.4.0.424716072166.issue3749@psf.upfronthosting.co.za>


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

Thanks, fixed in r66098.

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

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

From report at bugs.python.org  Mon Sep  1 16:18:45 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 14:18:45 +0000
Subject: [issue3683] compilation --without-threads fails
In-Reply-To: <1219714513.04.0.272760224775.issue3683@psf.upfronthosting.co.za>
Message-ID: <1220278725.93.0.514334069833.issue3683@psf.upfronthosting.co.za>


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

Fixed in r66099.

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

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

From report at bugs.python.org  Mon Sep  1 16:20:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 14:20:19 +0000
Subject: [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1220278819.71.0.0545166326135.issue3712@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords:  -needs review

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

From report at bugs.python.org  Mon Sep  1 16:25:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 14:25:26 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1220279126.84.0.293921023079.issue3639@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords:  -needs review

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

From report at bugs.python.org  Mon Sep  1 16:25:26 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 14:25:26 +0000
Subject: [issue3732] bdist_msi gives a deprecation warning when run with
	Python 2.6
In-Reply-To: <1220046171.76.0.656167236844.issue3732@psf.upfronthosting.co.za>
Message-ID: <1220279126.18.0.721713534184.issue3732@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66100.

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

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

From report at bugs.python.org  Mon Sep  1 16:26:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 14:26:18 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1220279178.81.0.332170819443.issue3160@psf.upfronthosting.co.za>


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


----------
nosy: +ocean-city

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

From report at bugs.python.org  Mon Sep  1 16:26:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 14:26:39 +0000
Subject: [issue3697] "Fatal Python error: Cannot recover from stack overflow"
	on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1220279199.4.0.718431970588.issue3697@psf.upfronthosting.co.za>


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


----------
nosy: +ocean-city

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

From report at bugs.python.org  Mon Sep  1 16:27:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 14:27:55 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1220279275.58.0.0321103489099.issue3602@psf.upfronthosting.co.za>


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

I think the patch can now go in.

----------
keywords:  -needs review

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

From report at bugs.python.org  Mon Sep  1 16:34:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 14:34:11 +0000
Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1220279651.5.0.357688467063.issue2501@psf.upfronthosting.co.za>


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

The patch looks great. (I love enabling disabled tests!)

----------
keywords:  -needs review
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Sep  1 16:34:49 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 01 Sep 2008 14:34:49 +0000
Subject: [issue3653] segfault calling sys.excepthook with non-Exception
	argument
In-Reply-To: <1219510555.19.0.327680854391.issue3653@psf.upfronthosting.co.za>
Message-ID: <1220279689.23.0.792610273701.issue3653@psf.upfronthosting.co.za>


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

I think you need to clear the exception again before returning.

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

From report at bugs.python.org  Mon Sep  1 16:36:13 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 14:36:13 +0000
Subject: [issue3748] platform.architecture() prints bogus message on windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220279773.16.0.965310292933.issue3748@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66104(trunk) and r66106(py3k)

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

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

From report at bugs.python.org  Mon Sep  1 16:40:17 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 01 Sep 2008 14:40:17 +0000
Subject: [issue3520] New Global Module Index glitch on WinXP
In-Reply-To: <1218147204.29.0.833867911272.issue3520@psf.upfronthosting.co.za>
Message-ID: <1220280017.27.0.866896308529.issue3520@psf.upfronthosting.co.za>


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

Should be fixed in sphinx trunk with r66107, and in the next beta/rc.

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

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

From report at bugs.python.org  Mon Sep  1 16:58:00 2008
From: report at bugs.python.org (Vincent Legoll)
Date: Mon, 01 Sep 2008 14:58:00 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1220281080.08.0.834554812157.issue3548@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

- Added "shut pylint up" comment for ** keyword expansion
- Added Copyright & license header

Added file: http://bugs.python.org/file11330/pipeline.py

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

From report at bugs.python.org  Mon Sep  1 16:58:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 14:58:04 +0000
Subject: [issue3750] test_bsddb3 skipped -- cannot import name test_support
In-Reply-To: <1220281084.82.0.280393977589.issue3750@psf.upfronthosting.co.za>
Message-ID: <1220281084.82.0.280393977589.issue3750@psf.upfronthosting.co.za>


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

This is what I get with the current py3k branch:

test_bsddb3 skipped -- cannot import name test_support

In py3k test/test_support.py has been renamed to test/support.py. The
fix should be simple enough :)

----------
assignee: jcea
components: Library (Lib), Tests
messages: 72258
nosy: jcea, pitrou
priority: critical
severity: normal
status: open
title: test_bsddb3 skipped -- cannot import name test_support
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Sep  1 17:09:06 2008
From: report at bugs.python.org (Forest Bond)
Date: Mon, 01 Sep 2008 15:09:06 +0000
Subject: [issue3751] str.rpartition fails silently with unicode argument
In-Reply-To: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>
Message-ID: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>


New submission from Forest Bond <forest at alittletooquiet.net>:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> u'/foo/bar'.rpartition(u'/')
(u'/foo', u'/', u'bar')
>>> '/foo/bar'.rpartition(u'/')
(u'', u'/', u'foo/bar')

----------
components: None
messages: 72259
nosy: forest_atq
severity: normal
status: open
title: str.rpartition fails silently with unicode argument
versions: Python 2.5

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

From report at bugs.python.org  Mon Sep  1 17:09:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 15:09:12 +0000
Subject: [issue3752] test_bsddb broken
In-Reply-To: <1220281752.22.0.128006401133.issue3752@psf.upfronthosting.co.za>
Message-ID: <1220281752.22.0.128006401133.issue3752@psf.upfronthosting.co.za>


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

Since the latest bsddb merge, test_bsddb is basically broken, all tests
fail with the same error (see also the buildbots):

======================================================================
ERROR: test_update (test.test_bsddb.TestBTree_InMemory_Truncate)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_bsddb.py", line 20, in
setUp
    self.f = self.do_open(self.fname, self.openflag, cachesize=32768)
  File "/home/antoine/py3k/__svn__/Lib/test/test_bsddb.py", line 17, in
do_open
    return bsddb.StringValues(bsddb.StringKeys(self.openmethod[0](*args,
**kw)))
AttributeError: 'module' object has no attribute 'StringValues'

----------
assignee: jcea
components: Tests
messages: 72260
nosy: jcea, pitrou
priority: critical
severity: normal
status: open
title: test_bsddb broken
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Sep  1 17:10:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 15:10:59 +0000
Subject: [issue3712] memoryview leaks references
In-Reply-To: <1219921309.45.0.320042219605.issue3712@psf.upfronthosting.co.za>
Message-ID: <1220281859.85.0.810655026232.issue3712@psf.upfronthosting.co.za>


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

Fixed in r66111.

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

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

From report at bugs.python.org  Mon Sep  1 17:13:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 15:13:55 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1220282035.3.0.780937629508.issue3548@psf.upfronthosting.co.za>


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

Vincent,
GPL licenced code is incompatible with the inclusion into python.
And if I am correct, you should sign a contributor agreement. Then the
licence text is not necessary.

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

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

From report at bugs.python.org  Mon Sep  1 17:20:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 15:20:57 +0000
Subject: [issue3751] str.rpartition fails silently with unicode argument
In-Reply-To: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>
Message-ID: <1220282457.14.0.250614259004.issue3751@psf.upfronthosting.co.za>


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

It's not failing, it's simply calling unicode.partition instead of
unicode.rpartition!

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file11331/rpartition.patch

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

From report at bugs.python.org  Mon Sep  1 17:33:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 15:33:31 +0000
Subject: [issue3751] str.rpartition fails silently with unicode argument
In-Reply-To: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>
Message-ID: <1220283211.67.0.794794056611.issue3751@psf.upfronthosting.co.za>


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

Adding a few tests wouldn't hurt :)

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

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

From report at bugs.python.org  Mon Sep  1 17:48:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 15:48:06 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1220284086.43.0.882058613172.issue2874@psf.upfronthosting.co.za>


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

Deferring to 2.7/3.1 as discussed on the mailing list.

----------
priority: release blocker -> critical
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From report at bugs.python.org  Mon Sep  1 18:03:43 2008
From: report at bugs.python.org (Pyry Pakkanen)
Date: Mon, 01 Sep 2008 16:03:43 +0000
Subject: [issue3753] bytearray incompatible with bytes
In-Reply-To: <1220285023.36.0.49129522463.issue3753@psf.upfronthosting.co.za>
Message-ID: <1220285023.36.0.49129522463.issue3753@psf.upfronthosting.co.za>


New submission from Pyry Pakkanen <frostburn at suomi24.fi>:

I was expecting that the API function PyArg_ParseTuple(args, "y#:foo",
&cp, &size) would accept a bytearray and implicitly convert it to bytes.
Currently it throws the error:
TypeError: foo() argument 1 must be bytes or read-only buffer, not bytearray

----------
messages: 72266
nosy: Frostburn
severity: normal
status: open
title: bytearray incompatible with bytes
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Sep  1 18:06:53 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 01 Sep 2008 16:06:53 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1220285213.99.0.822620475997.issue1424152@psf.upfronthosting.co.za>


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

As indicated by other posters, this *IS A* serious issue with urllib2 as
it does not do CONNECT for HTTPS through Proxy and it fails.

chrisl, I verified your patch and it works properly. I made some minor
changes (make a method private and changes w.r.t code in the trunk) and
also added tests and NEWS to support its inclusion in the trunk. 

Facundo, we should try to include this in py26/py3k, I have attached the
patch for both.

There is a extra patch for test_urllib2net.py which tests real-time
HTTPS connectivity taking the proxies from environment variables
(HTTPS_PROXY). However, that has a serious dependency on Issue1251,
which is still in Open state.  When the bug Issue1251 is fixed, we can
include the  issue1424152-py26-test_urllib2net.diff separately.

----------
keywords: +patch
Added file: http://bugs.python.org/file11332/issue1424152-py26.diff

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

From report at bugs.python.org  Mon Sep  1 18:07:23 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 01 Sep 2008 16:07:23 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1220285243.15.0.164071557365.issue1424152@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
components: +Library (Lib) -None
versions: +Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11333/issue1424152-py3k.diff

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

From report at bugs.python.org  Mon Sep  1 18:10:59 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 01 Sep 2008 16:10:59 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1220285459.31.0.561905633455.issue1424152@psf.upfronthosting.co.za>


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

Test issue1424152-py26-test_urllib2net.diff and
issue1424152-py3k-test_urllib2net.diff patches has a dependency on
Issue1251 for failure scenarios.

Issue1251 deals with ssl module not support non-blocking handshakes. So,
when the HTTPS environment is NOT SET, while HTTPS Proxy is used, this
test will try to a do_handshake()  in ssl module and will return as it
wont get timed-out. 

This test case can be included after Issue1251 is fixed.

Added file: http://bugs.python.org/file11334/issue1424152-py26-test_urllib2net.diff

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

From report at bugs.python.org  Mon Sep  1 18:11:18 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 01 Sep 2008 16:11:18 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1220285478.62.0.374090576593.issue1424152@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file11335/issue1424152-py3k-test_urllib2net.diff

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

From report at bugs.python.org  Mon Sep  1 18:14:42 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 01 Sep 2008 16:14:42 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1220285682.0.0.522651693534.issue1251@psf.upfronthosting.co.za>


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

This issue is yet not fixed for both Py2.6 and Py3k. The tests which are
present in code are not run (or disabled) in test_ssl.py

I understand, customers have a good chance of hitting upon this issue.
When ssl do_handshake() does not timeout and application just hangs!

Janssen, would you like to close on this?

Issue1424152 (for certain scenarios) has a dependency upon this one.

----------
nosy: +orsenthil
versions: +Python 3.0

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

From report at bugs.python.org  Mon Sep  1 18:17:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 16:17:12 +0000
Subject: [issue3753] bytearray incompatible with y#
In-Reply-To: <1220285023.36.0.49129522463.issue3753@psf.upfronthosting.co.za>
Message-ID: <1220285832.85.0.859286282281.issue3753@psf.upfronthosting.co.za>


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

Yes, you must use y* instead: see
http://docs.python.org/dev/3.0/c-api/arg.html

y# would not be safe to use with bytearray since another thread could
mutate the bytearray in-between, possibly reallocating the internal
buffer (to shrink or grow it), and lead to a segfault when your thread
uses the obsolete pointer.

IMO, the documentation should mention that the '*' codes (y*, s*, etc.)
must be used in preference to the '#' codes, which are there for
backwards compatibility.

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl, pitrou
title: bytearray incompatible with bytes -> bytearray incompatible with y#
versions: +Python 2.6

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

From report at bugs.python.org  Mon Sep  1 18:26:56 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 16:26:56 +0000
Subject: [issue3735] allow multiple threads to efficiently send the same
	requests to a processing.Pool without incurring duplicate processing
In-Reply-To: <1220051229.09.0.236623735385.issue3735@psf.upfronthosting.co.za>
Message-ID: <1220286416.72.0.433470752384.issue3735@psf.upfronthosting.co.za>


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

Another place this could go is in the examples FWIW

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

From report at bugs.python.org  Mon Sep  1 18:34:09 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 16:34:09 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1220286849.05.0.34673350768.issue3125@psf.upfronthosting.co.za>


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

Working on the py3k patch now, bumping to rel. blocker

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

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

From report at bugs.python.org  Mon Sep  1 18:45:50 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 01 Sep 2008 16:45:50 +0000
Subject: [issue3753] bytearray incompatible with y#
In-Reply-To: <1220285023.36.0.49129522463.issue3753@psf.upfronthosting.co.za>
Message-ID: <1220287550.33.0.766933775196.issue3753@psf.upfronthosting.co.za>


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

Documented in r66113.

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

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

From report at bugs.python.org  Mon Sep  1 18:45:59 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 16:45:59 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220287559.66.0.909900946617.issue3589@psf.upfronthosting.co.za>


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


----------
keywords: +needs review -patch

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

From report at bugs.python.org  Mon Sep  1 18:47:54 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 16:47:54 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220287674.25.0.67026204582.issue3589@psf.upfronthosting.co.za>


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

Patch reviewed/tested and I also confirmed that this doesn't affect the 
examples. I submitted the patch in r66114

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

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

From report at bugs.python.org  Mon Sep  1 18:48:49 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 16:48:49 +0000
Subject: [issue3731] import warning in multiprocessing
In-Reply-To: <1220033737.12.0.773803477499.issue3731@psf.upfronthosting.co.za>
Message-ID: <1220287729.43.0.457370373554.issue3731@psf.upfronthosting.co.za>


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

Prior to you getting this error: Did you get a compilation error during 
the make?

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

From report at bugs.python.org  Mon Sep  1 18:51:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 01 Sep 2008 16:51:53 +0000
Subject: [issue3747] Fix caching in ABCMeta.__subclasscheck__
In-Reply-To: <1220263485.83.0.336107969335.issue3747@psf.upfronthosting.co.za>
Message-ID: <1220287913.38.0.99559703367.issue3747@psf.upfronthosting.co.za>


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

Looks good.

----------
nosy: +georg.brandl
resolution:  -> accepted

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

From report at bugs.python.org  Mon Sep  1 19:09:05 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 17:09:05 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220288945.69.0.0375280897269.issue3589@psf.upfronthosting.co.za>


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

Reopening, there's a bug that the tests/examples/etc didn't catch (and 
nor did I), after the patch application:

woot:python-trunk jesse$ ./python.exe 
Python 2.6b3+ (trunk:66112:66114M, Sep  1 2008, 13:00:19) 
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _multiprocessing
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/jesse/open_source/subversion/python-
trunk/Lib/multiprocessing/__init__.py", line 148, in <module>
    from multiprocessing.synchronize import (Lock, RLock, Condition, 
Event,
  File "/Users/jesse/open_source/subversion/python-
trunk/Lib/multiprocessing/synchronize.py", line 29, in <module>
    SEM_VALUE_MAX = _multiprocessing.SemLock.SEM_VALUE_MAX
AttributeError: 'module' object has no attribute 'SemLock'
>>>

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

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

From report at bugs.python.org  Mon Sep  1 19:09:20 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 01 Sep 2008 17:09:20 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220288960.07.0.681786996598.issue3589@psf.upfronthosting.co.za>


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

Ben is backing out the patch now

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

From report at bugs.python.org  Mon Sep  1 19:11:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 17:11:42 +0000
Subject: [issue3731] import warning in multiprocessing
In-Reply-To: <1220033737.12.0.773803477499.issue3731@psf.upfronthosting.co.za>
Message-ID: <1220289102.61.0.301531617592.issue3731@psf.upfronthosting.co.za>


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

Indeed. _multiprocessing.so compiles fine but afterwards I get:

*** WARNING: importing extension "_multiprocessing" failed with <type
'exceptions.AttributeError'>: 'module' object has no attribute 'SemLock'


And if I try manually:

>>> import _multiprocessing
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/__svn__/Lib/multiprocessing/__init__.py",
line 148, in <module>
    from multiprocessing.synchronize import (Lock, RLock, Condition, Event,
  File
"/home/antoine/cpython/__svn__/Lib/multiprocessing/synchronize.py", line
29, in <module>
    SEM_VALUE_MAX = _multiprocessing.SemLock.SEM_VALUE_MAX
AttributeError: 'module' object has no attribute 'SemLock'


Removing the .pyc files doesn't help.

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

From report at bugs.python.org  Mon Sep  1 19:13:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 17:13:20 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1220289200.44.0.31274211021.issue3125@psf.upfronthosting.co.za>


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

Jesse,
It seems that the patch was merged into py3k by r65883.
The trick was
    from pickle import _Pickler as Pickler
to get the subclassable python implementation.

The only remaining point is the handling of dictionary views
(see rebuild_as_list() in managers.py).
I had to register them with copyreg.pickle, because the C function
connection_send_obj() uses the original pickler.

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

From report at bugs.python.org  Mon Sep  1 19:15:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 17:15:44 +0000
Subject: [issue3731] import warning in multiprocessing
In-Reply-To: <1220033737.12.0.773803477499.issue3731@psf.upfronthosting.co.za>
Message-ID: <1220289344.69.0.58758550076.issue3731@psf.upfronthosting.co.za>


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

Mmmh, after doing "svn up" again and recompiling, the extension imports
fine and the ImportWarning disappears.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Mon Sep  1 19:46:48 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 01 Sep 2008 17:46:48 +0000
Subject: [issue3738] logging.Handler.close does something
In-Reply-To: <1220098393.98.0.954077896829.issue3738@psf.upfronthosting.co.za>
Message-ID: <1220291208.57.0.0649233234107.issue3738@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Documentation fix checked in. The current behaviour is by design - but
the documentation was wrong and needed fixing.

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

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

From report at bugs.python.org  Mon Sep  1 19:47:44 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 01 Sep 2008 17:47:44 +0000
Subject: [issue3726] Allow ',
	<whitespace>' delimiters in logging.config.fileConfig()
In-Reply-To: <1220017483.8.0.409780209991.issue3726@psf.upfronthosting.co.za>
Message-ID: <1220291264.02.0.224881472813.issue3726@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vsajip
nosy: +vsajip

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

From report at bugs.python.org  Mon Sep  1 20:37:43 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 01 Sep 2008 18:37:43 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1220294263.94.0.355594270246.issue1251@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I believe this is now implemented in all the branches.  And when I run the 
tests, they run fine.  There's still an issue with unwrap; it does a 
blocking tear-down of the SSL session, and can block when you don't want 
it to.  I'll have to look further at that.

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

From report at bugs.python.org  Mon Sep  1 20:37:53 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 01 Sep 2008 18:37:53 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1220294273.59.0.886250947588.issue1251@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file10337/unnamed

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

From report at bugs.python.org  Mon Sep  1 20:52:28 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 01 Sep 2008 18:52:28 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1220295148.46.0.666868776588.issue600362@psf.upfronthosting.co.za>


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

Senthil, please update the patchs, adding a DeprecationWarning in 3.0 and
a PendingDeprecationWarning in 2.6.

Thanks!

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

From report at bugs.python.org  Mon Sep  1 21:31:37 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 19:31:37 +0000
Subject: [issue3697] "Fatal Python error: Cannot recover from stack overflow"
	on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1220297497.32.0.418096436449.issue3697@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I don't know about interpreter core, and I cannot reproduce this
error. I believe Trent is more familiar with buildbot and python core
than me.

----------
nosy: +Trent.Nelson

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

From report at bugs.python.org  Mon Sep  1 21:34:35 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Mon, 01 Sep 2008 19:34:35 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1220297675.43.0.831869054562.issue1424152@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Mon Sep  1 21:43:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 19:43:54 +0000
Subject: [issue3751] str.rpartition fails silently with unicode argument
In-Reply-To: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>
Message-ID: <1220298234.78.0.347556886215.issue3751@psf.upfronthosting.co.za>


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

Updated patch, with tests.
This is a 2.5 backport candidate.

----------
keywords: +needs review
Added file: http://bugs.python.org/file11336/rpartition.patch

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

From report at bugs.python.org  Mon Sep  1 21:46:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 19:46:43 +0000
Subject: [issue3751] str.rpartition fails silently with unicode argument
In-Reply-To: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>
Message-ID: <1220298403.43.0.441674204712.issue3751@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file11331/rpartition.patch

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

From report at bugs.python.org  Mon Sep  1 21:47:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 19:47:28 +0000
Subject: [issue3751] str.rpartition fails silently with unicode argument
In-Reply-To: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>
Message-ID: <1220298448.51.0.279814082431.issue3751@psf.upfronthosting.co.za>


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

Go ahead with the patch and backporting; it looks fine to me.

----------
keywords:  -needs review
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Sep  1 22:00:15 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 01 Sep 2008 20:00:15 +0000
Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1220299215.1.0.737839784429.issue2501@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Looks like this is a duplicate of issue3590, so this patch fixes two
release blockers ;)

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

From report at bugs.python.org  Mon Sep  1 22:05:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 20:05:35 +0000
Subject: [issue3751] str.rpartition fails silently with unicode argument
In-Reply-To: <1220281746.27.0.0425746690909.issue3751@psf.upfronthosting.co.za>
Message-ID: <1220299535.41.0.208399206731.issue3751@psf.upfronthosting.co.za>


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

Committed r66119 (trunk) and r66121 (python2.5)
Thanks for the report!

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

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

From report at bugs.python.org  Mon Sep  1 22:09:00 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Sep 2008 20:09:00 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1220045591.76.0.520722098503.issue3297@psf.upfronthosting.co.za>
Message-ID: <48BC4BD8.10508@egenix.com>


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

On 2008-08-29 23:33, Terry J. Reedy wrote:
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> "Just to clarify: Python can be built as UCS2 or UCS4 build (not UTF-16
> vs. UTF-32)"
> 
> I recently read most of the Unicode 5 standard and as near as I could
> tell it no longer uses the term UCS, if it ever did. 

UCS2 and UCS4 are terms which stem from the versions of Unicode
that were current at the time of adding Unicode support to Python,
ie. in the year 2000 when ISO 10646 and the Unicode spec co-existed.

See http://en.wikipedia.org/wiki/Universal_Character_Set for details.

UTF-16 is a transfer encoding that is based on UCS2 by adding
surrogate pair interpretations. UTF-32 is the same for UCS4,
but also restricting the range of valid code points to the range
covered by UTF-16.

Whether surrogates are supported or not and how they are supported
depends entirely on the codecs you use to convert the internal
format to some encoding.

> "If it really was UCS-2, the repr wouldn't be u'\U00010123' on windows. 
> It'd be a pair of ill-formed code units instead."

You are mixing the internal representation of Unicode code points
with the result of passing those values through one of the codecs,
e.g. the unicode-escape codec is responsible for converting between
the string representation u'\U00010123' and the internal representation.

Also note that because Python can be built using two different internal
representations, the results of the codecs may vary depending on
platform.

BTW: There's no such thing as an ill-formed code unit. What you probably
mean is an "ill-formed code unit sequence". However, those refer
to the output or accepted input values of a codec, not the internal
representation.

Please also note that because Python can be used to build valid
and parse possibly invalid Unicode encoding data, it has to have
the ability to work with Unicode code points regardless of whether
they can be interpreted as lone surrogates or not (hence the usage
of the terms UCS2/UCS4 which don't support surrogates).

Whether the codecs should raise exceptions and possibly let an
error handler decide whether or not to accept and/or generate
ill-formed code unit sequences is another question.

I hope that clears up the reasoning for using UCS2/UCS4 rather
than UTF-16/UTF-32 when referring to the internal Unicode representation
of Python.

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

From report at bugs.python.org  Mon Sep  1 22:08:59 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 20:08:59 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1220299739.68.0.858755528425.issue3708@psf.upfronthosting.co.za>


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

The patch looks fine to me as well.

----------
keywords:  -needs review
nosy: +amaury.forgeotdarc
resolution:  -> accepted

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

From report at bugs.python.org  Mon Sep  1 22:26:49 2008
From: report at bugs.python.org (Ionut Turturica)
Date: Mon, 01 Sep 2008 20:26:49 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1220300809.05.0.251996823758.issue1767370@psf.upfronthosting.co.za>


Ionut Turturica <jonozzz at yahoo.com> added the comment:

Note that win32 Python's socket module doesn't have a MSG_DONTWAIT
constant defined. So the following code will fail on windows machines.

+                self.__connection.sock.recv(1,
+                                            socket.MSG_PEEK | 
+                                            socket.MSG_DONTWAIT)

Good job with this patch. It would've been interesting to have a flag to
switch to old http1.0 and see the differences in terms of performance.

Ionut

----------
nosy: +jonozzz
type:  -> behavior

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

From report at bugs.python.org  Mon Sep  1 22:31:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 01 Sep 2008 20:31:30 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1220301090.26.0.151130338928.issue3602@psf.upfronthosting.co.za>


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


----------
assignee:  -> brett.cannon

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

From report at bugs.python.org  Mon Sep  1 22:58:09 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 01 Sep 2008 20:58:09 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220302689.68.0.162406018543.issue3743@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Since not all platforms support "%zd" the patch has to be rewritten.
May be PY_FORMAT_SIZE_T isn't correctly defined in Include/pyport.h for
the used "C" library.

----------
nosy: +rpetrov

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

From report at bugs.python.org  Mon Sep  1 23:22:17 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 21:22:17 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220304137.57.0.970812175873.issue3589@psf.upfronthosting.co.za>


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

Given how long I've been using the threading module without realising it
does the same thing, I'm actually prepared to live with the wrapper
functions rather than messing with this so close to release.

As Fredrik noted in the python-dev thread, the threading versions of
these are already explicitly documented as being factory functions
rather than classes (and as a reference to _thread.allocate_lock,
threading.Lock has good reason to be a factory function rather than a
class), so it may be appropriate to do the same thing for multiprocessing.

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

From report at bugs.python.org  Mon Sep  1 23:30:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 21:30:11 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220304611.8.0.302301739887.issue3743@psf.upfronthosting.co.za>


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

No, and this is the reason of the patch:
PyUnicode_FromFormat and PyErr_Format do not use the platform printf.

The code (in Objects/unicodeobject.c) is platform-independent; %zd is
the way to print a ssize_t variable on all platforms.

My only observation is that %zd does not exist before python2.5, and the
code of "multiprocessing" currently seems to be compatible with python
2.4. I don't know if this is important.

----------
keywords: +needs review

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

From report at bugs.python.org  Mon Sep  1 23:31:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 21:31:07 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220304667.42.0.857403763964.issue3743@psf.upfronthosting.co.za>


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

> You're right, Chris, I didn't think of that...
Did I miss something? or some joke I do not understand?

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

From report at bugs.python.org  Mon Sep  1 23:31:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 21:31:44 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220304704.89.0.256545465007.issue3589@psf.upfronthosting.co.za>


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

Sounds good to me. :)

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

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

From report at bugs.python.org  Mon Sep  1 23:32:35 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 21:32:35 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220304755.74.0.735228544046.issue3352@psf.upfronthosting.co.za>


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

Regarding the factory functions that are named as if they were classes,
Fredrik noted on python-dev that the ones from the threading module are
explicitly documented as being factory functions, and the
multiprocessing API really just follows that example (note that without
applying the patch from issue 3589, all of the names that are factory
functions in the threading API are also factory functions in the
multiprocessing API).

So perhaps the best course at this stage is to just leave these alone
for 2.6/3.0?

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

From report at bugs.python.org  Mon Sep  1 23:49:19 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 01 Sep 2008 21:49:19 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

This is minimal patch that add basic cross-compilation possibilities for
python build (configure script).

The patch add macro AC_CANONICAL_HOST.
This macro require files config.guess, config.sub. The patch don't
include them. You may obtain them from GNU automake tarbal.

As result of macro new variable $host ("host triplet":=cpu-verdor-os) is
used to detect so called "host system".

Since this is basic patch, detection of build system in native builds
based on $ac_sys_system and/or $ac_sys_release isn't replaced. This
detection isn't appropriate for cross-compilation environment as contain
values for "build system" and has to be replaces in addition by future
patches.


Also the patch posted in http://bugs.python.org/issue3718 (about
environment variable MACHDEP) isn't required for native builds, but will
help in case of cross-compilation.

----------
files: python-trunk-CROSS.patch
keywords: patch
messages: 72299
nosy: rpetrov
severity: normal
status: open
title: minimal cross-compilation support for configure
Added file: http://bugs.python.org/file11337/python-trunk-CROSS.patch

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

From report at bugs.python.org  Mon Sep  1 23:53:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2008 21:53:22 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220306002.45.0.610499412947.issue3352@psf.upfronthosting.co.za>


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

Ben, if you get a chance to apply those patches, feel free, otherwise I
should be able to get to them this evening (my time - about 10 hours
from now).

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

From report at bugs.python.org  Tue Sep  2 00:01:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Sep 2008 22:01:41 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220306501.84.0.345422407007.issue3720@psf.upfronthosting.co.za>


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

Did you notice that the definition of PyIter_Check() also changed?

>>> class T(object):
...   def __iter__(self): return self
...
>>> iter(T())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: iter() returned non-iterator of type 'T'

Or did you refer to .so extensions modules that are not recompiled
between 2.5 and 2.6? (I don't know if this still works)

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

From report at bugs.python.org  Tue Sep  2 00:08:48 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Mon, 01 Sep 2008 22:08:48 +0000
Subject: [issue3750] test_bsddb3 skipped -- cannot import name test_support
In-Reply-To: <1220281084.82.0.280393977589.issue3750@psf.upfronthosting.co.za>
Message-ID: <1220306928.25.0.869999789985.issue3750@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Patch summitted as r66123 and r66124.

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

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

From report at bugs.python.org  Tue Sep  2 00:11:26 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 22:11:26 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1220304137.57.0.970812175873.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220307083.5602.9.camel@fsol>


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

Le lundi 01 septembre 2008 ? 21:22 +0000, Nick Coghlan a ?crit :
> As Fredrik noted in the python-dev thread, the threading versions of
> these are already explicitly documented as being factory functions
> rather than classes (and as a reference to _thread.allocate_lock,
> threading.Lock has good reason to be a factory function rather than a
> class), so it may be appropriate to do the same thing for multiprocessing.

"Foolish consistency, etc.". :-)
I think we should fix this before the releases rather than live with a
stupid indirection that doesn't seem to serve any useful purposes.
Unless the fix is too complicated of course.

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

From report at bugs.python.org  Tue Sep  2 01:13:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Sep 2008 23:13:34 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220310814.67.0.561478299657.issue3352@psf.upfronthosting.co.za>


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

Ok. patches applied in r66126 and r66127.

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

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

From report at bugs.python.org  Tue Sep  2 02:55:01 2008
From: report at bugs.python.org (supernova_hq)
Date: Tue, 02 Sep 2008 00:55:01 +0000
Subject: [issue3755] Lists propagate through new instances of class if using
	append
In-Reply-To: <1220316901.15.0.690452835039.issue3755@psf.upfronthosting.co.za>
Message-ID: <1220316901.15.0.690452835039.issue3755@psf.upfronthosting.co.za>


New submission from supernova_hq <supernova_hq at hotmail.com>:

I have located a bug where every instance of an identical class (or a
class that extends it) will use the same copy of any list element
created before __init__.

The only way I have found to fix this is to explicitly empty the list
inside the __init__ function before the list is used.

Please view and run the attached code for the example.

----------
components: None
files: bug_reproduction_test.py
messages: 72305
nosy: supernova_hq
severity: normal
status: open
title: Lists propagate through new instances of class if using append
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11338/bug_reproduction_test.py

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

From report at bugs.python.org  Tue Sep  2 02:57:18 2008
From: report at bugs.python.org (supernova_hq)
Date: Tue, 02 Sep 2008 00:57:18 +0000
Subject: [issue3755] Lists propagate through new instances of class if using
	append
In-Reply-To: <1220316901.15.0.690452835039.issue3755@psf.upfronthosting.co.za>
Message-ID: <1220317038.44.0.65982297356.issue3755@psf.upfronthosting.co.za>


supernova_hq <supernova_hq at hotmail.com> added the comment:

I have located a bug where every instance of an identical class (or a
class that extends it) will use the same copy of any list element
created before __init__.

The only way I have found to fix this is to explicitly empty the list
inside the __init__ function before the list is used.

Please view and run the attached code for the example.

Added file: http://bugs.python.org/file11339/bug_reproduction_test.py

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

From report at bugs.python.org  Tue Sep  2 03:28:25 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Sep 2008 01:28:25 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1220318905.73.0.139764623741.issue3602@psf.upfronthosting.co.za>


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

Applied in the trunk under r66135. Working on merging in 3.0.

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

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

From report at bugs.python.org  Tue Sep  2 03:57:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Sep 2008 01:57:35 +0000
Subject: [issue3755] Lists propagate through new instances of class if using
	append
In-Reply-To: <1220316901.15.0.690452835039.issue3755@psf.upfronthosting.co.za>
Message-ID: <1220320655.06.0.063609561787.issue3755@psf.upfronthosting.co.za>


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

This is the expected behavior. By declaring variables outside class
methods, they become class variables and are associated with the class
instead of the instance.

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

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

From report at bugs.python.org  Tue Sep  2 04:19:41 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Tue, 02 Sep 2008 02:19:41 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>


New submission from Andrew McNamara <andrewm at object-craft.com.au>:

In python 2, re.escape() works with either str or unicode, but in 
python 3, re.escape() no longer works correctly with the bytes type.

----------
components: Regular Expressions
messages: 72309
nosy: andrewmcnamara
severity: normal
status: open
title: re.escape() does not work with bytes()
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Sep  2 04:40:09 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Tue, 02 Sep 2008 02:40:09 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220323209.6.0.682630990235.issue3756@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

The attached "re_escape.py" is a (somewhat crappy) fix for re.escape()

Added file: http://bugs.python.org/file11340/re_escape.py

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

From report at bugs.python.org  Tue Sep  2 04:48:38 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Sep 2008 02:48:38 +0000
Subject: [issue3602] Move test.test_suport.catch_warning() to the 'warnings'
	module
In-Reply-To: <1219170947.01.0.817487779131.issue3602@psf.upfronthosting.co.za>
Message-ID: <1220323718.95.0.169464751849.issue3602@psf.upfronthosting.co.za>


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

r66139 has the 3.0 work. Had to rip out an outdated DeprecationWarning.
Also moved over to keyword-only arguments as stated in the 2.6 docs.

----------
resolution:  -> accepted
status: pending -> closed

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

From report at bugs.python.org  Tue Sep  2 06:02:13 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Sep 2008 04:02:13 +0000
Subject: [issue3639] segfaults calling warnings.warn() with non-string message
In-Reply-To: <1219357827.01.0.105768400803.issue3639@psf.upfronthosting.co.za>
Message-ID: <1220328133.42.0.6776033645.issue3639@psf.upfronthosting.co.za>


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

Checked in r66140.

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

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

From report at bugs.python.org  Tue Sep  2 07:31:10 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Sep 2008 05:31:10 +0000
Subject: [issue3678] Ignored LDFLAGS during linking libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1220333470.92.0.428993384697.issue3678@psf.upfronthosting.co.za>


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

committed to trunk r66141.

leaving open until i verify that this makes it into py3k and for a
backport to release25-maint.

----------
keywords:  -needs review
versions:  -Python 2.6

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

From report at bugs.python.org  Tue Sep  2 07:36:36 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Sep 2008 05:36:36 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1220333796.75.0.590378730565.issue3708@psf.upfronthosting.co.za>


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

committed to trunk r66142

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

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

From report at bugs.python.org  Tue Sep  2 07:38:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Sep 2008 05:38:31 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1220333911.37.0.234002918532.issue3704@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 2.6

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

From report at bugs.python.org  Tue Sep  2 07:48:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Sep 2008 05:48:31 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1220334511.53.0.582626917394.issue1868@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Tue Sep  2 08:11:31 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Tue, 02 Sep 2008 06:11:31 +0000
Subject: [issue3747] Fix caching in ABCMeta.__subclasscheck__
In-Reply-To: <1220263485.83.0.336107969335.issue3747@psf.upfronthosting.co.za>
Message-ID: <1220335891.14.0.96135902415.issue3747@psf.upfronthosting.co.za>


Changes by Andrew McNamara <andrewm at object-craft.com.au>:


----------
nosy: +andrewmcnamara

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

From report at bugs.python.org  Tue Sep  2 08:42:53 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Sep 2008 06:42:53 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1220337773.04.0.891943971977.issue1868@psf.upfronthosting.co.za>


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

this is ready for more review at http://codereview.appspot.com/3641

Added file: http://bugs.python.org/file11341/threading_local4.patch

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

From report at bugs.python.org  Tue Sep  2 08:44:56 2008
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Sep 2008 06:44:56 +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: <1220337896.63.0.220668258025.issue3672@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/issue3672>
_______________________________________

From report at bugs.python.org  Tue Sep  2 08:51:54 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 02 Sep 2008 06:51:54 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1220338314.81.0.154303338973.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Marc, I don't understand what you're saying.  UTF-16's surrogates are
not optional.  Unicode 2.0 and later require them, and Python is
supposed to support it.

Likewise, UCS-4 originally allowed a much larger range of code points,
but it no longer does; allowing them would mean supporting only old,
archaic versions of the standards (which is clearly not desirable.)

You are right in that I shouldn't have said "a pair of ill-formed code
units".  I should have said "a pair of unassigned code points", which is
how UCS-2 always have and always will classify them.

Although python may allow ill-formed sequences to be created internally
(primarily lone surrogates on UTF-16 builds), it cannot encode or decode
them.  The standard is clear that these are to be treated as errors,
which the .decode()'s "errors" argument controls.  You could add a new
value for "errors" to pass-through the garbage, but I fail to see a use
case for it.

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

From report at bugs.python.org  Tue Sep  2 08:57:29 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 02 Sep 2008 06:57:29 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1220338649.15.0.59584365536.issue3297@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

I've got another report open about the codecs not properly reporting
errors relating to surrogates: issue 3672

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

From report at bugs.python.org  Tue Sep  2 10:26:02 2008
From: report at bugs.python.org (Legoll Vincent)
Date: Tue, 02 Sep 2008 08:26:02 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1220282035.3.0.780937629508.issue3548@psf.upfronthosting.co.za>
Message-ID: <4727185d0809020126q60e37c3gaa35d6b538022440@mail.gmail.com>


Legoll Vincent <vincent.legoll at gmail.com> added the comment:

On Mon, Sep 1, 2008 at 5:13 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Vincent,
> GPL licenced code is incompatible with the inclusion into python.
> And if I am correct, you should sign a contributor agreement. Then the
> licence text is not necessary.

This is not a patch against python, this is a standalone script, just
implementing the same functionality as the original bug report in a
slightly different way...

But thanks for the input anyways.

If this functionality is really interesting people and agreed to be integrated
into upstream subprocess module, I can rework it the right way, or work
from the original patch from the bug report.

----------
nosy: +vlegoll

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

From report at bugs.python.org  Tue Sep  2 10:30:20 2008
From: report at bugs.python.org (Adi)
Date: Tue, 02 Sep 2008 08:30:20 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1220344220.02.0.0418803408238.issue1160@psf.upfronthosting.co.za>


Adi <adi at digitaltrowel.com> added the comment:

Is there any progress on this bug? I am currently considering
maintaining a branch of 2.5.2 which includes the patch suggested by effbot.

----------
nosy: +adi

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

From report at bugs.python.org  Tue Sep  2 11:43:27 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 09:43:27 +0000
Subject: [issue3352] Deficiencies in multiprocessing/threading API
In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za>
Message-ID: <1220348607.62.0.925835066354.issue3352@psf.upfronthosting.co.za>


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

Thanks!

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

From report at bugs.python.org  Tue Sep  2 12:15:45 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 10:15:45 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220350545.93.0.389152250151.issue3719@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Can you try this patch?

1. used "file -b" option to eliminate file path. Otherwide, re.split
won't work because file path will contain space like this. (I hope -b
option can be used anywhere "file" command exists)

a b/python.exe: MS-DOS executable PE  for MS Windows (console) Intel
80386 32-bit

2. used subprocess module instead of popen. subprocess is useful when
argument contains space or quote like this issue.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file11342/platform.patch

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

From report at bugs.python.org  Tue Sep  2 12:19:04 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 10:19:04 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220350744.08.0.252284781718.issue3719@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

[off topic]
I used cygwin to create this patch, but platform.architecture()[1]
becomes empty string because sys.executable in cygwin points to
directory. (at least before installing)

Python 2.6b3+ (trunk:66142M, Sep  2 2008, 17:09:46)
[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 sys
>>> sys.executable
'/home/WhiteRabbit/python-dev/trunk/python'

I workarounded this by inserting "target = './python.exe'" in
_syscmd_file, but sorry if this patch won't work.

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

From report at bugs.python.org  Tue Sep  2 12:29:16 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 10:29:16 +0000
Subject: [issue3748] platform.architecture() prints bogus message on windows
In-Reply-To: <1220269369.83.0.170599051752.issue3748@psf.upfronthosting.co.za>
Message-ID: <1220351356.07.0.123925883912.issue3748@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, should I backport this to release25-maint branch?
(If accepted, issue3719 as well)

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

From report at bugs.python.org  Tue Sep  2 12:31:03 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Sep 2008 10:31:03 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220351463.22.0.473449554393.issue3719@psf.upfronthosting.co.za>


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

Using subprocess is only possible conditionally, ie. if available.
Please note that the module is intended to be usable with multiple
Python versions and must at least support Python 2.1.

We could consider an updated patch for 2.7 and 3.1, but not for 2.6/3.0,
since it needs more testing.

I think for 2.6/3.0, adding the extra quotes is enough to get things
working.

Please open a new patch ticket for your patch and update it to work with
popen if subprocess is not available. The patch should also not remove
the lines:

-    if sys.platform in ('dos','win32','win16','os2'):
-        # XXX Others too ?
-        return default

from _syscmd_file().

I'll checkin the extra quotes.

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

From report at bugs.python.org  Tue Sep  2 12:31:43 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Sep 2008 10:31:43 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220351503.42.0.0335086372748.issue3719@psf.upfronthosting.co.za>


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

Updated the Python versions.

----------
versions: +Python 2.5, Python 2.6, Python 3.0 -Python 2.4

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

From report at bugs.python.org  Tue Sep  2 12:43:52 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 10:43:52 +0000
Subject: [issue3747] Fix caching in ABCMeta.__subclasscheck__
In-Reply-To: <1220263485.83.0.336107969335.issue3747@psf.upfronthosting.co.za>
Message-ID: <1220352232.47.0.926268196554.issue3747@psf.upfronthosting.co.za>


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

2.6 fixed in r66144, merged to 3.0 in r66147

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

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

From report at bugs.python.org  Tue Sep  2 12:55:59 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 10:55:59 +0000
Subject: [issue3719] platform.py: _syscmd_file() can't handle target path with
	space or special shell character
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220352959.67.0.00993210055241.issue3719@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, if python was installed into directory named
"foo ELF boo", python will say wrong architecture.

>>> import platform
>>> platform.architecture()
('32bit', 'ELF')

Is it not good to use "file -b" option?

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

From report at bugs.python.org  Tue Sep  2 13:06:21 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Sep 2008 11:06:21 +0000
Subject: =?utf-8?q?[issue3719]_platform.py:_=5Fsyscmd=5Ffile()_can't_handle_target_path_with=09space_or_special_shell_character?=
In-Reply-To: <1220352959.67.0.00993210055241.issue3719@psf.upfronthosting.co.za>
Message-ID: <48BD1E2A.3030204@egenix.com>


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

On 2008-09-02 12:55, Hirokazu Yamamoto wrote:
> Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:
> 
> Well, if python was installed into directory named
> "foo ELF boo", python will say wrong architecture.
> 
>>>> import platform
>>>> platform.architecture()
> ('32bit', 'ELF')
> 
> Is it not good to use "file -b" option?

Well, I'd say that install path is rather unlikely to occur in real
life ;-)

I'm not sure how wide-spread support for the -b option is, so we'd
have to check during the next release cycle.

----------
title: platform.py: _syscmd_file() can't handle target path with space or special shell character -> platform.py: _syscmd_file() can't handle target path with	space or special shell character

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

From report at bugs.python.org  Tue Sep  2 13:09:30 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Sep 2008 11:09:30 +0000
Subject: =?utf-8?q?[issue3719]_platform.py:_=5Fsyscmd=5Ffile()_can't_handle_target_path_with=09space_or_special_shell_character?=
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220353770.02.0.963724556752.issue3719@psf.upfronthosting.co.za>


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

Checked in as r66145 and r66146.

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

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

From report at bugs.python.org  Tue Sep  2 13:13:26 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 11:13:26 +0000
Subject: =?utf-8?q?[issue3719]_platform.py:_=5Fsyscmd=5Ffile()_can't_handle_target_path_with=09space_or_special_shell_character?=
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220354006.61.0.887749297375.issue3719@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

OK, I understand. And I must apologizes about previous
my patch.

  fileout = _architecture_split(output)[1:]

should not be deleted. It was should be changed to

  fileout = _architecture_split(output)

Thank you.

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

From report at bugs.python.org  Tue Sep  2 13:35:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 02 Sep 2008 11:35:56 +0000
Subject: [issue3733] Adding bin and Scripts folder into PATH
In-Reply-To: <1220048213.92.0.257328590649.issue3733@psf.upfronthosting.co.za>
Message-ID: <1220355356.64.0.31222517389.issue3733@psf.upfronthosting.co.za>


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

See the long discussion in issue3561.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Windows installer should add Python and Scripts directories to the PATH environment variable

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

From report at bugs.python.org  Tue Sep  2 14:14:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 12:14:08 +0000
Subject: [issue3757] threading.local doesn't support cyclic garbage collecting
In-Reply-To: <1220357648.44.0.102035652616.issue3757@psf.upfronthosting.co.za>
Message-ID: <1220357648.44.0.102035652616.issue3757@psf.upfronthosting.co.za>


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

tp_traverse and tp_clear on threading.local are defined, but the
Py_TPFLAGS_HAVE_GC flag is not set. As a result, cycles are not collected:

>>> import threading, weakref
>>> o = threading.local()
>>> class X(object): pass
... 
>>> x = X()
>>> x.o = o
>>> o.x = x
>>> wr = weakref.ref(x)
>>> del x, o
>>> import gc
>>> gc.collect()
0
>>> wr()
<__main__.X object at 0x9bb0dc4>

----------
components: Extension Modules, Library (Lib)
messages: 72332
nosy: pitrou
severity: normal
status: open
title: threading.local doesn't support cyclic garbage collecting
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Sep  2 14:14:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 12:14:42 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1220357682.6.0.61469353554.issue1868@psf.upfronthosting.co.za>


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

The patch is basically fine with me. While reviewing it I've found out
that threading.local doesn't have cyclic garbage collecting enabled.
I've opened a new issue for it in #3757.

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

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

From report at bugs.python.org  Tue Sep  2 14:36:36 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Sep 2008 12:36:36 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1220358996.04.0.0902093275014.issue3617@psf.upfronthosting.co.za>


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

Raising priority since this needs to be resolved prior to the final
release of Python 2.6/3.0.

Regarding finding the eula.txt in the VS2008 installation, there doesn't
appear to be a generic way. The eula.txt is stored in a folder named
after the installed version of VS2008. Finding the installation folder
is easy (use VS90COMNTOOLS env setting), but determining the product
name doesn't look as easy.

Perhaps there's some registry trick we could pull off ?!

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

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

From report at bugs.python.org  Tue Sep  2 14:55:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 02 Sep 2008 12:55:38 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1220360138.29.0.182615801808.issue1868@psf.upfronthosting.co.za>


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

With the patch, subclasses of threading.local seem to have an empty
__dict__:

import threading
class MyLocal(threading.local):
    pass

l = MyLocal()
l.x = 2
l.__dict__   # returns {}

Maybe __dict__ should be special-cased in local_getattro()?

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

From report at bugs.python.org  Tue Sep  2 15:21:04 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 02 Sep 2008 13:21:04 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1220360138.29.0.182615801808.issue1868@psf.upfronthosting.co.za>
Message-ID: <48BD3DBF.7050607@cheimes.de>


Christian Heimes <lists at cheimes.de> added the comment:

Amaury Forgeot d'Arc wrote:
> Maybe __dict__ should be special-cased in local_getattro()?

With the patch it's also no longer possible to get a list of attribute
names. +1 for special casing __dict__ in getattro and setattro.
setattr(local, "__dict__", egg) should raise an AttributeError.

Christian

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

From report at bugs.python.org  Tue Sep  2 15:34:09 2008
From: report at bugs.python.org (Ralph Corderoy)
Date: Tue, 02 Sep 2008 13:34:09 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>


New submission from Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:

A new target, "check", has been added to Makefile for 2.6.  It runs some
tests on the source code that are intended to check there's nothing
wrong before preparing a patch. 
http://svn.python.org/view/python/trunk/Makefile.pre.in?rev=61528&view=markup

Unfortunately, GNU coding standards have cemented in many people's minds
that "check" is the target for self-tests, e.g. "make clean all check
install".  http://www.gnu.org/prep/standards/standards.html#Standard-Targets

I realise Python doesn't fall under those coding standards, but none the
less it is confusing to people to re-use a standard target name for a
different use.  In the past, Python had no "check" target so people
spotted their mistake, investigated, and found the "test" target.

Please consider renaming this new "check" target, e.g. to "prepatch", to
avoid this confusion when 2.6 is released.  Perhaps a "check" target can
be added as a synonym for "test" at the same time?

----------
components: Build
messages: 72337
nosy: ralph.corderoy
severity: normal
status: open
title: "make check" suggest a testing target under GNU coding standards
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep  2 16:02:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 14:02:22 +0000
Subject: [issue3589] Misleading names for multiprocessing "convenience"
	functions
In-Reply-To: <1219066045.43.0.199498522059.issue3589@psf.upfronthosting.co.za>
Message-ID: <1220364142.05.0.985852039361.issue3589@psf.upfronthosting.co.za>


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

Not so much "too complicated" as "potentially touches a lot of code and
not something I want to fiddle with this close to release".

As I noted on python-dev, it's actually a change that can easily be
handled through the normal API deprecation process, so it can be
reconsidered at a later date.

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

From report at bugs.python.org  Tue Sep  2 16:17:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Sep 2008 14:17:23 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220365043.12.0.0918482704671.issue3758@psf.upfronthosting.co.za>


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

Brett, how about "patchcheck"?

----------
assignee:  -> brett.cannon
nosy: +benjamin.peterson, brett.cannon

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

From report at bugs.python.org  Tue Sep  2 16:25:30 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Tue, 02 Sep 2008 14:25:30 +0000
Subject: [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1220365530.66.0.47790934665.issue2975@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

Here is the equals sign fix as a separate patch file.

Added file: http://bugs.python.org/file11343/equalsInEnv.patch

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

From report at bugs.python.org  Tue Sep  2 16:28:58 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Tue, 02 Sep 2008 14:28:58 +0000
Subject: [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1220365738.84.0.793256796846.issue2975@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

Any hope for these two patches being applied?

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

From report at bugs.python.org  Tue Sep  2 16:37:24 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 14:37:24 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1220366244.77.0.426189892401.issue2486@psf.upfronthosting.co.za>


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

Looks like we'll be living with the slowdown for 3.0, so marking this as
a high priority item for 3.1.

(Given that the API doesn't change, I wonder if this could be included
in a 3.0.1 release?)

----------
priority:  -> high
versions: +Python 3.1 -Python 3.0

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

From report at bugs.python.org  Tue Sep  2 17:04:51 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 15:04:51 +0000
Subject: [issue3759] test_asyncore.py leaks handle
In-Reply-To: <1220367891.09.0.578636101762.issue3759@psf.upfronthosting.co.za>
Message-ID: <1220367891.09.0.578636101762.issue3759@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

asyncore.file_wrapper() dups passed handle, so original handle must be
closed.

----------
components: Tests
files: test_asyncore.patch
keywords: patch
messages: 72343
nosy: ocean-city
severity: normal
status: open
title: test_asyncore.py leaks handle
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11344/test_asyncore.patch

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

From report at bugs.python.org  Tue Sep  2 17:27:50 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 15:27:50 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220369270.0.0.00180039288204.issue2690@psf.upfronthosting.co.za>


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

This issue was missing a priority setting.

Alexander's range-sequence patch still applies cleanly to the Py3k
branch, and "make test" still runs correctly after applying it.

As Alexander notes above, range_contains does still need slightly better
handling of non-integer numbers - I suggest doing a numeric conversion
via PyNumber_Index(el) at the beginning of range_contains, and if that
conversion fails, do a conversion via PyNumber_Long(el) and immediately
return False if the result is not equal to el itself (i.e. only integer
values of non-integer types will be found in the range.

Since that explanation got kind of complicated, I've added a modified
patch that includes the above change, and adds a couple of additional
tests to ensure a non-integer floating point value won't be found in the
sequence.

----------
keywords: +needs review
priority:  -> release blocker
Added file: http://bugs.python.org/file11345/issue2690-range-sequence-ncoghlan.diff

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

From report at bugs.python.org  Tue Sep  2 17:38:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 15:38:24 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220369904.07.0.353850326405.issue2690@psf.upfronthosting.co.za>


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

It looks like your range_subscript() forgets to compute the length field...

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

From report at bugs.python.org  Tue Sep  2 17:47:30 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 15:47:30 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220370450.79.0.609746772649.issue2690@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file11345/issue2690-range-sequence-ncoghlan.diff

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

From report at bugs.python.org  Tue Sep  2 17:48:33 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 15:48:33 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220370513.06.0.194791773925.issue2690@psf.upfronthosting.co.za>


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

My initial patch had a few problems - I removed it and uploaded a
corrected version.

Added file: http://bugs.python.org/file11346/issue2690-range-sequence-ncoghlan.diff

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

From report at bugs.python.org  Tue Sep  2 17:50:22 2008
From: report at bugs.python.org (jfdp)
Date: Tue, 02 Sep 2008 15:50:22 +0000
Subject: =?utf-8?q?[issue3719]_platform.py:_=5Fsyscmd=5Ffile()_can't_handle_target_path_with=09space_or_special_shell_character?=
In-Reply-To: <1219970413.68.0.263157286627.issue3719@psf.upfronthosting.co.za>
Message-ID: <1220370622.73.0.294394859359.issue3719@psf.upfronthosting.co.za>


jfdp <joe.dipol at sun.com> added the comment:

To respond to a couple questions:

Adding the double quotes fixed the issue I had -- but I did very
limited testing.

The "-b" option is not support by 'file' on Solaris.

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

From report at bugs.python.org  Tue Sep  2 18:03:13 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 16:03:13 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220371393.32.0.139691924884.issue2690@psf.upfronthosting.co.za>


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

Good catch Antoine (I missed that in Alexander's patch) - working on
that now.

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

From report at bugs.python.org  Tue Sep  2 18:07:04 2008
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 02 Sep 2008 16:07:04 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220371624.52.0.26769705846.issue3720@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Maybe the file 'next-nevernull.patch' is not complete?  I don't see any
change in the definition of PyIter_Check().

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

From report at bugs.python.org  Tue Sep  2 18:10:30 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 02 Sep 2008 16:10:30 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1220371831.0.0.862434721434.issue2486@psf.upfronthosting.co.za>


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

Can not get into this now, but I'll be able to deal with this in some
weeks...

----------
assignee:  -> facundobatista

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

From report at bugs.python.org  Tue Sep  2 18:54:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 02 Sep 2008 16:54:39 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220374479.08.0.326296382068.issue3720@psf.upfronthosting.co.za>


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

Oops, sorry. I have too many files opened at the same time.
Here is an updated patch.

I removed all the "assert(PyIter_Check(it))", our evil iterator used to
make them fail anyway in debug mode; and in the case of a null function
pointer, the C stack gives the same information.

Added file: http://bugs.python.org/file11347/next-nevernull-2.patch

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

From report at bugs.python.org  Tue Sep  2 18:54:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 02 Sep 2008 16:54:45 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1220374485.02.0.278132957357.issue3720@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file11317/next-nevernull.patch

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

From report at bugs.python.org  Tue Sep  2 18:54:55 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 16:54:55 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220374495.81.0.990331713766.issue2690@psf.upfronthosting.co.za>


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

v2 of my updated patch attached to fix the issue Antoine noted.

Also gets rid of some tab-instead-of-spaces indenting issues in the
file, and avoids hardcoding PyRange_Type when creating new instances.

However, the patch still has issues, as can be seen with the new tests I
added to test_range to actually exercise some of the functionality
beyond the sys.maxsize limit.

Added file: http://bugs.python.org/file11348/issue2690-range-sequence-ncoghlan-v2.diff

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

From report at bugs.python.org  Tue Sep  2 19:16:18 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 02 Sep 2008 17:16:18 +0000
Subject: [issue3081] Py_(X)SETREF macros
In-Reply-To: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>
Message-ID: <1220375778.87.0.261079633152.issue3081@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Tue Sep  2 19:27:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 17:27:57 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220376477.61.0.599914288561.issue2690@psf.upfronthosting.co.za>


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

By the way, why is this release blocker? do we have performance numbers?

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

From report at bugs.python.org  Tue Sep  2 19:32:55 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 02 Sep 2008 17:32:55 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220376775.67.0.328964896571.issue2690@psf.upfronthosting.co.za>


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

I wonder if we shouldn't hold off on this. It's a substantial amount of
new code. I'd be fine with it going into 3.0.1 since it's pure
optimization (IIUC!). But right now we want burn-in, not new features.

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

From report at bugs.python.org  Tue Sep  2 19:52:37 2008
From: report at bugs.python.org (Iain MacKay)
Date: Tue, 02 Sep 2008 17:52:37 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1220377957.89.0.532906263133.issue1441530@psf.upfronthosting.co.za>


Iain MacKay <iain at computable-functions.com> added the comment:

Knowing that the large read provokes the problem enables one to write
this simple workaround by subclassing IMAP4 without patching the library:

maxRead = 1000000
class MySSL (imaplib.IMAP4_SSL):
  def read (self, n):
    #print "..Attempting to read %d bytes" % n
      if n <= maxRead:
        return imaplib.IMAP4_SSL.read (self, n)
      else:
        soFar = 0
        result = ""
        while soFar < n:
          thisFragmentSize = min(maxRead, n-soFar)
          #print "..Reading fragment size %s" % thisFragmentSize
          fragment =\
            imaplib.IMAP4_SSL.read (self, thisFragmentSize)
          result += fragment
          soFar += thisFragmentSize # only a few, so not a tragic o/head
          return result				

and this works just fine.

----------
nosy: +anglocelt
versions: +Python 2.5 -Python 2.4

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

From report at bugs.python.org  Tue Sep  2 19:57:43 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Sep 2008 17:57:43 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1220378263.81.0.0517684062628.issue2690@psf.upfronthosting.co.za>


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

Given the problems with it, I'm dropping this to normal priority and
punting to 3.1.

(the release blocker status was just temporary to ensure we got a
decision on it before rc1 - it previously didn't have a priority set)

----------
keywords:  -needs review
priority: release blocker -> normal
versions: +Python 3.1 -Python 3.0

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

From report at bugs.python.org  Tue Sep  2 20:00:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 18:00:24 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220378424.76.0.826577997452.issue3660@psf.upfronthosting.co.za>


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


----------
keywords: +needs review

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

From report at bugs.python.org  Tue Sep  2 20:15:48 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 02 Sep 2008 18:15:48 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1220379348.72.0.194328675879.issue3419@psf.upfronthosting.co.za>


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

Looks like Mark's patch was submitted as part of r66115 by Ben 
accidentally (as part of reverting r66114). I can confirm this patch 
resolves the incref issue as-is. I've run test_multiprocessing in a loop 
for about an hour now with no failures. 

Marking closed/fixed

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

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

From report at bugs.python.org  Tue Sep  2 20:26:58 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Sep 2008 18:26:58 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220365043.12.0.0918482704671.issue3758@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809021126t2b0b7151i2a8063159fbae42f@mail.gmail.com>


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

On Tue, Sep 2, 2008 at 7:17 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Brett, how about "patchcheck"?
>

Maybe. I will see if any inspiration comes to me in the near future.
Obviously there is no rush to get this into any specific RC.

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

From report at bugs.python.org  Tue Sep  2 20:29:25 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 02 Sep 2008 18:29:25 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220380165.23.0.51303119778.issue3729@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

There seems to be a pronouncement now
(http://mail.python.org/pipermail/python-3000/2008-September/014692.html),
so I'm attaching a patch which clips to sys.maxsize and includes
Amaury's suggestions.

Added file: http://bugs.python.org/file11349/len_check3.diff

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

From report at bugs.python.org  Tue Sep  2 20:29:43 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 02 Sep 2008 18:29:43 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220380183.06.0.682785316229.issue3729@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


Removed file: http://bugs.python.org/file11307/len_check.diff

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

From report at bugs.python.org  Tue Sep  2 20:29:46 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Tue, 02 Sep 2008 18:29:46 +0000
Subject: [issue3729] SystemError on calling len() if __len__() doesn't return
	an int
In-Reply-To: <1220021948.65.0.928639960663.issue3729@psf.upfronthosting.co.za>
Message-ID: <1220380186.84.0.246356116625.issue3729@psf.upfronthosting.co.za>


Changes by Hagen F?rstenau <hfuerstenau at gmx.net>:


Removed file: http://bugs.python.org/file11308/len_check2.diff

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

From report at bugs.python.org  Tue Sep  2 21:12:48 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 02 Sep 2008 19:12:48 +0000
Subject: [issue3419] multiprocessing module is racy
In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za>
Message-ID: <1220382768.91.0.451966341875.issue3419@psf.upfronthosting.co.za>


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

r66161 on py3k merges forward the fix for this

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

From report at bugs.python.org  Tue Sep  2 21:22:24 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Tue, 02 Sep 2008 19:22:24 +0000
Subject: [issue3760] PEP 3121 --- PyType_Copy is missing
In-Reply-To: <1220383344.44.0.399854586534.issue3760@psf.upfronthosting.co.za>
Message-ID: <1220383344.44.0.399854586534.issue3760@psf.upfronthosting.co.za>


New submission from Paul Pogonyshev <pogonyshev at gmx.net>:

PEP 3121 at python.org mentions PyType_Copy().  However, it doesn't seem
to be present in SVN version and there is no apparent replacement. 
Please clarify how types should be created for different module
instances --- if just sharing is fine, or should some copying (which
function?) be used.

----------
components: Interpreter Core
messages: 72362
nosy: _doublep
severity: normal
status: open
title: PEP 3121 --- PyType_Copy is missing
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Sep  2 21:38:20 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 02 Sep 2008 19:38:20 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1220384300.61.0.732033066144.issue1251@psf.upfronthosting.co.za>


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

Yes Janssen, I checked again and found it implemented in both trunk
(py26) and py3k. All the tests pass as well.

However, in one of my testcases for issue1424152, where I expected the 
timeout to happen for do_handshake(), it did not take effect. I shall
look for the reasons.

The following is the tail from the traceback.  

  File "/usr/local/lib/python2.6/httplib.py", line 1095, in connect
    self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
  File "/usr/local/lib/python2.6/ssl.py", line 316, in wrap_socket
    suppress_ragged_eofs=suppress_ragged_eofs)
  File "/usr/local/lib/python2.6/ssl.py", line 116, in __init__
    self.do_handshake()
  File "/usr/local/lib/python2.6/ssl.py", line 260, in do_handshake
    self._sslobj.do_handshake()
KeyboardInterrupt

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

From report at bugs.python.org  Tue Sep  2 21:56:47 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 19:56:47 +0000
Subject: [issue3759] test_asyncore.py leaks handle
In-Reply-To: <1220367891.09.0.578636101762.issue3759@psf.upfronthosting.co.za>
Message-ID: <1220385407.65.0.0466726951392.issue3759@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +easy, needs review

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

From report at bugs.python.org  Tue Sep  2 22:20:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 02 Sep 2008 20:20:45 +0000
Subject: [issue3759] test_asyncore.py leaks handle
In-Reply-To: <1220367891.09.0.578636101762.issue3759@psf.upfronthosting.co.za>
Message-ID: <1220386845.42.0.71254186787.issue3759@psf.upfronthosting.co.za>


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

Tested on Linux: each call to test.test_asyncore.test_main() opens two
file descriptors (shown in /proc/<pid>/fd). The patch corrects this.

----------
keywords:  -needs review
nosy: +amaury.forgeotdarc
resolution:  -> accepted

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

From report at bugs.python.org  Tue Sep  2 22:42:01 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 20:42:01 +0000
Subject: [issue3759] test_asyncore.py leaks handle
In-Reply-To: <1220367891.09.0.578636101762.issue3759@psf.upfronthosting.co.za>
Message-ID: <1220388121.92.0.0252683031415.issue3759@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66162(trunk), r66163(py3k)

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

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

From report at bugs.python.org  Tue Sep  2 22:59:48 2008
From: report at bugs.python.org (Chris Leow)
Date: Tue, 02 Sep 2008 20:59:48 +0000
Subject: [issue3761] urllib.request and urllib.response cannot handle HTTP1.1
	chunked encoding
In-Reply-To: <1220389188.67.0.216867570009.issue3761@psf.upfronthosting.co.za>
Message-ID: <1220389188.67.0.216867570009.issue3761@psf.upfronthosting.co.za>


New submission from Chris Leow <chrisleow343 at yahoo.co.uk>:

Hi, fairly new to Python, so not sure if this is something you want as a
behaviour or not:

urllib.response object when fetching an HTTP1.1 page does not
transparently handle "Transfer-Encoding": "chunked", and I think it should.

You can view source code for addinfourl, AbstractHTTPHandler and
HTTPHandler to verify this (sorry, I don't have line-numbers, I'm typing
this at home).

I would suggest extending addinfourl to "addinfourlchunked", for
example, to allow substitutes for fp.read(), readlines() and readline()
to be specified during the construction of addinfourl.

This threw me initially, and seems like quite a glareing omission for
newbies.

Cheers,

Chris

----------
components: Library (Lib)
messages: 72366
nosy: chrisleow
severity: normal
status: open
title: urllib.request and urllib.response cannot handle HTTP1.1 chunked encoding
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Sep  2 23:51:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Sep 2008 21:51:46 +0000
Subject: [issue3760] PEP 3121 --- PyType_Copy is missing
In-Reply-To: <1220383344.44.0.399854586534.issue3760@psf.upfronthosting.co.za>
Message-ID: <1220392306.04.0.969788572807.issue3760@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> loewis
nosy: +loewis
priority:  -> high

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

From report at bugs.python.org  Wed Sep  3 00:18:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Sep 2008 22:18:26 +0000
Subject: [issue3637] 2to3 refactoring
In-Reply-To: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>
Message-ID: <1220393906.93.0.713032722384.issue3637@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file11350/after_gps_review.patch

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

From report at bugs.python.org  Wed Sep  3 00:38:10 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Sep 2008 22:38:10 +0000
Subject: [issue3444] add warnings for intra-package imports
In-Reply-To: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za>
Message-ID: <1220395090.35.0.478813223378.issue3444@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Well, this would be nice, but it doesn't seem serious enough to block
the release.

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

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

From report at bugs.python.org  Wed Sep  3 00:45:10 2008
From: report at bugs.python.org (Matt Chisholm)
Date: Tue, 02 Sep 2008 22:45:10 +0000
Subject: [issue1638033] Add httponly to Cookie module
Message-ID: <1220395510.77.0.456809922662.issue1638033@psf.upfronthosting.co.za>


Matt Chisholm <matt-python at theory.org> added the comment:

Any progress on this? This patch is extremely straightforward (only
three lines of code), and should not break existing code. 

The HttpOnly extension to cookies is now supported by IE, Firefox 3.0,
and Opera. 

This article explains why HttpOnly is a good way to make cross-site
scripting attacks significantly more difficult:

http://www.codinghorror.com/blog/archives/001167.htmllop

I'd really like to see this patch applied to Cookie.py.

----------
nosy: +glyphobet

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

From report at bugs.python.org  Wed Sep  3 00:49:51 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 22:49:51 +0000
Subject: [issue1638033] Add httponly to Cookie module
Message-ID: <1220395791.87.0.973853371748.issue1638033@psf.upfronthosting.co.za>


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

Well, I'm sorry but this a feature request and must be delayed for
2.7/3.1, since 2.6/3.0 are now in the release candidate phase. :-(

(as for the patch, it would be nice if it added an unit test for the new
feature)

----------
nosy: +pitrou
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From report at bugs.python.org  Wed Sep  3 01:20:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 02 Sep 2008 23:20:45 +0000
Subject: [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1220397645.97.0.248985729196.issue2975@psf.upfronthosting.co.za>


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

Applied both patches (a bit differently for the equal sign) as r66171.

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

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

From report at bugs.python.org  Wed Sep  3 01:35:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 23:35:06 +0000
Subject: [issue3697] "Fatal Python error: Cannot recover from stack overflow"
	on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1220398506.39.0.037048373384.issue3697@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  3 01:38:50 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Tue, 02 Sep 2008 23:38:50 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220398730.91.0.545529283735.issue3756@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

Will do, although I'm slightly concerned that my "bytes" version of the 
function is about 50% slower than the "str" version. I can see why, I 
just can't think of a way to do it any faster. There's an inherent 
asymetry in bytes type that didn't exist before: b''.join(list(b'abc')) 
does not work. Of course, this does work: bytes(list(b'abc')), but the 
bytes constructor only accepts ints, not bytes. I'd like to see either 
the join method accept ints as well as bytes, or the bytes ctor accept 
bytes as well as ints. Or something.

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

From report at bugs.python.org  Wed Sep  3 01:58:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Sep 2008 23:58:02 +0000
Subject: [issue3637] 2to3 refactoring
In-Reply-To: <1219351576.1.0.980085138833.issue3637@psf.upfronthosting.co.za>
Message-ID: <1220399882.37.0.529875843961.issue3637@psf.upfronthosting.co.za>


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

Gregory P. Smith reviewed the change on Rietveld, and the patch was
applied in r66173.

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

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

From report at bugs.python.org  Wed Sep  3 02:02:38 2008
From: report at bugs.python.org (Scott Dial)
Date: Wed, 03 Sep 2008 00:02:38 +0000
Subject: [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1220400158.92.0.015614813283.issue2975@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

This patch shouldn't have been applied as it is. The definition of
"removeDuplicates" is both poorly-named, not exactly correct, and
redundant (as there is already a "normalize_and_reduce_paths") for
performing this fix on PATH. 

Jim, you acknowledged already that:

"""The normalize_and_reduce_paths() function needs to be performed on
INCLUDE and LIBPATH in addition to the exec path.  i.e.
os.environ['lib'] and os.environ['include']."""

So, I don't understand how that got missed. I've attached a patch that
removes the extra code.

Added file: http://bugs.python.org/file11351/msvc9compiler_path.diff

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

From report at bugs.python.org  Wed Sep  3 02:20:38 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Wed, 03 Sep 2008 00:20:38 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220401238.16.0.899527962862.issue3756@psf.upfronthosting.co.za>


Changes by Andrew McNamara <andrewm at object-craft.com.au>:


Added file: http://bugs.python.org/file11352/re_escape-patch

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

From report at bugs.python.org  Wed Sep  3 04:39:55 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Wed, 03 Sep 2008 02:39:55 +0000
Subject: [issue2975] VS8 include dirs grow without bound
In-Reply-To: <1211831796.1.0.811493312376.issue2975@psf.upfronthosting.co.za>
Message-ID: <1220409595.92.0.931611684622.issue2975@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

Yes, much better.  I should have read into the interior of the
discussion rather than just the edges...

Thanks!

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

From report at bugs.python.org  Wed Sep  3 07:59:58 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Sep 2008 05:59:58 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1220421598.0.0.425030163487.issue3645@psf.upfronthosting.co.za>


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

committed to trunk (2.6) in r66179.  This should be back ported to 
release25-maint and automagically merged into py3k.

can someone with OpenBSD confirm that this has indeed fixed the problem?  
if so i'll do the 25 backport and mark it as closed instead of pending.

----------
assignee:  -> gregory.p.smith
keywords: +easy
nosy: +gregory.p.smith
resolution:  -> accepted
status: open -> pending
versions:  -Python 2.6

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

From report at bugs.python.org  Wed Sep  3 08:00:14 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Sep 2008 06:00:14 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1220421614.9.0.661115070273.issue3645@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
keywords:  -needs review

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

From report at bugs.python.org  Wed Sep  3 09:04:23 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Sep 2008 07:04:23 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I created symbolic link to python.exe as dummy.exe on cygwin.
But I noticed platform.architecture() printed ('32bit', '')

$ ./dummy
Python 2.6b3+ (trunk:66166M, Sep  3 2008, 06:43:59)
[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 platform
>>> platform._follow_symlinks("dummy.exe")
'/home/WhiteRabbit/python-dev/trunk/dummy.exe/python.exe'
>>>

Is this _follow_symlinks's intended behavior? If no, I hope attached
patch will fix problem. Now platform.architecture() prints
('32bit', 'WindowsPE')

----------
messages: 72376
nosy: ocean-city
severity: normal
status: open
title: platform.architecture() fails if python is lanched via its symbolic link (cygwin)
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Sep  3 09:05:49 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Sep 2008 07:05:49 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220425549.94.0.0902845598243.issue3762@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

- But I noticed platform.architecture() printed ('32bit', '')
+ But I noticed platform.architecture() printed ('32bit', '')
when I lanched python via dummy.exe

----------
components: +Library (Lib)

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

From report at bugs.python.org  Wed Sep  3 11:15:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Sep 2008 09:15:46 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220433346.48.0.25194162228.issue3762@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This sliped out of my mind. :-(

[issue3719]
>Python versions and must at least support Python 2.1.

os.path.realpath is new feature in Python2.2, so probably this cannot be
used. I attached another patch platform_v2.patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file11353/platform_v2.patch

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

From report at bugs.python.org  Wed Sep  3 11:15:49 2008
From: report at bugs.python.org (Swaroop)
Date: Wed, 03 Sep 2008 09:15:49 +0000
Subject: [issue3763] Python 3.0 beta 2 : json and urllib not working together?
In-Reply-To: <1220433349.91.0.388298659355.issue3763@psf.upfronthosting.co.za>
Message-ID: <1220433349.91.0.388298659355.issue3763@psf.upfronthosting.co.za>


New submission from Swaroop <swaroopch at gmail.com>:

Hi,

Running the attached program in Python 3.0 beta 2 gives the following error:

  File "C:\Python30\lib\json\decoder.py", line 21, in linecol
    lineno = doc.count('\n', 0, pos) + 1
TypeError: expected an object with the buffer interface

I can't figure out if there's an error in the program itself, but I
suspect this isn't working as expected.

Please let me know if there's anything I can do to help (if this is a
bug indeed).

Regards,
Swaroop

----------
components: None
files: yahoo_search.py
messages: 72379
nosy: swaroopch
severity: normal
status: open
title: Python 3.0 beta 2 : json and urllib not working together?
versions: Python 3.0
Added file: http://bugs.python.org/file11354/yahoo_search.py

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

From report at bugs.python.org  Wed Sep  3 11:17:42 2008
From: report at bugs.python.org (Swaroop)
Date: Wed, 03 Sep 2008 09:17:42 +0000
Subject: [issue3763] Python 3.0 beta 2 : json and urllib not working together?
In-Reply-To: <1220433349.91.0.388298659355.issue3763@psf.upfronthosting.co.za>
Message-ID: <1220433462.06.0.0108727069139.issue3763@psf.upfronthosting.co.za>


Swaroop <swaroopch at gmail.com> added the comment:

Adding full traceback:

$ python yahoo_search.py
Traceback (most recent call last):
  File "yahoo_search.py", line 35, in <module>
    for result in search(query)['Result']:
  File "yahoo_search.py", line 28, in search
    result = json.load(urllib.request.urlopen(url))
  File "C:\Python30\lib\json\__init__.py", line 267, in load
    parse_constant=parse_constant, **kw)
  File "C:\Python30\lib\json\__init__.py", line 307, in loads
    return _default_decoder.decode(s)
  File "C:\Python30\lib\json\decoder.py", line 322, in decode
    raise ValueError(errmsg("Extra data", s, end, len(s)))
  File "C:\Python30\lib\json\decoder.py", line 30, in errmsg
    lineno, colno = linecol(doc, pos)
  File "C:\Python30\lib\json\decoder.py", line 21, in linecol
    lineno = doc.count('\n', 0, pos) + 1
TypeError: expected an object with the buffer interface

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

From report at bugs.python.org  Wed Sep  3 11:20:59 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Sep 2008 09:20:59 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220433659.23.0.396989683823.issue3762@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


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

From report at bugs.python.org  Wed Sep  3 11:21:02 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 03 Sep 2008 09:21:02 +0000
Subject: [issue3726] Allow ',
	<whitespace>' delimiters in logging.config.fileConfig()
In-Reply-To: <1220017483.8.0.409780209991.issue3726@psf.upfronthosting.co.za>
Message-ID: <1220433662.87.0.00420200831194.issue3726@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk (slightly modified version of patch).

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

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

From report at bugs.python.org  Wed Sep  3 11:21:45 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 03 Sep 2008 09:21:45 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220433705.62.0.528228681294.issue3762@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file11355/platform.patch

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

From report at bugs.python.org  Wed Sep  3 12:28:10 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Wed, 03 Sep 2008 10:28:10 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1220437690.76.0.371830111912.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

[sorry for the late reply, I have been on holidays]

Martin:
you are right that this memory is moved to swap and does not consume any
"real" memory; however we decided to work on this patch because we
observed on our application some performances degradation due to this
memory not being deallocated correctly.

Since then we have done some quite extensive tests (with the help of a
consultant at Sun): they have shown that this unnecessary swapping has a
noticeable impact on performances and at worst, when the system memory
is saturated, can completely put a server on its knees for several
minutes (we're talking of top of the line SunOS and AIX servers with
hundreds of GB of memory).

I will write a complete document explaining the tests and observations
that we did, but this memory issue was critical for us given the
degradation of performances it was generating on our production servers.

Concerning dlmalloc, you are right that it would be cleaner to improve
obmalloc so that it uses mmap when necessary, instead of adding another
layer with dlmalloc (even though that is what actually currently happens
on linux systems where dlmalloc is integrated in libc).

I will try to do that patch in coming weeks (obmalloc mostly allocates
some 256KB arenas so it should nearly always use mmap).

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

From report at bugs.python.org  Wed Sep  3 12:48:29 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 03 Sep 2008 10:48:29 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1220438909.21.0.889793776299.issue2562@psf.upfronthosting.co.za>


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

Removing Python 2.5 from the version list, since the patch may in some
cases (e.g. using a different encoding than UTF-8) cause problems with
existing setup.py files out there.

The patch is not compatible with Python 3.0 for obvious reasons, but
there shouldn't be any issue for Python 3.0 anyway.

Given that no one has volunteered to review the patch in addition to
Tarek and myself, I think we're good to go.

Tarek, if you're fine with this, please let me know and I'll check in
the patch (together with a note in NEWS).

----------
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Sep  3 12:58:05 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 03 Sep 2008 10:58:05 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1220439485.67.0.17995580084.issue2562@psf.upfronthosting.co.za>


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

Sure, sounds fine to me, thanks for the help on this issue

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

From report at bugs.python.org  Wed Sep  3 13:28:59 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 03 Sep 2008 11:28:59 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1220441339.89.0.828394617757.issue2562@psf.upfronthosting.co.za>


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

Checked in as r66181 on trunk.

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

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

From report at bugs.python.org  Wed Sep  3 15:26:31 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 03 Sep 2008 13:26:31 +0000
Subject: [issue3764] asyncore differences between 2.x and 3.x
In-Reply-To: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>
Message-ID: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

I don't know if this is intentional but I point it out anyway in case
this is wrong (as I think):

asyncore.py of Python 2.6 trunk on line 104 contains:

        if flags & select.POLLHUP:
            obj.handle_close()

...while the python 3.0 version is different:

        if flags & select.POLLHUP:
            obj.handle_close_event()

----------
components: Library (Lib)
messages: 72386
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson
severity: normal
status: open
title: asyncore differences between 2.x and 3.x
versions: Python 3.0

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

From report at bugs.python.org  Wed Sep  3 17:21:04 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 03 Sep 2008 15:21:04 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1220455264.86.0.0240697836313.issue600362@psf.upfronthosting.co.za>


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

Facundo, I have updated the patch against the trunk. Added the
PendingDeprecationWarning for py26 and DeprecationWarning for py3k. 
All tests pass ok.  Please verify and plan to apply this patch before rc1.

Added file: http://bugs.python.org/file11356/issue600362-py26-v3.diff

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

From report at bugs.python.org  Wed Sep  3 17:21:33 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 03 Sep 2008 15:21:33 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1220455293.31.0.725617927571.issue600362@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Added file: http://bugs.python.org/file11357/issue600362-py3k-v3.diff

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

From report at bugs.python.org  Wed Sep  3 17:21:44 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 03 Sep 2008 15:21:44 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1220455304.79.0.516388490205.issue600362@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file11116/issue600362-py26-v2.diff

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

From report at bugs.python.org  Wed Sep  3 17:21:52 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 03 Sep 2008 15:21:52 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1220455312.6.0.253620382016.issue600362@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file11117/issue600362-py3k-v2.diff

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

From report at bugs.python.org  Wed Sep  3 17:40:25 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 03 Sep 2008 15:40:25 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1220456425.03.0.318960155198.issue2200@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I've run into the same problem.

Attached patch (updated with Lev code) is almost the same except that it
doesn't attempt to return executable files without executable extension.

It also accounts that os2 executables can have arbitrary extensions
according to Perl manual.
http://www.perl.com/doc/manual/html/Porting/README.os2.html#Starting_OS_2_and_DOS_programs

----------
nosy: +techtonik
versions: +Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file11358/spawn.patch.txt

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

From report at bugs.python.org  Wed Sep  3 17:41:10 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 03 Sep 2008 15:41:10 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1220456470.17.0.319105631941.issue2200@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Removed file: http://bugs.python.org/file11358/spawn.patch.txt

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

From report at bugs.python.org  Wed Sep  3 17:41:20 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 03 Sep 2008 15:41:20 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1220456480.29.0.894033230006.issue2200@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file11359/spawn.patch.txt

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

From report at bugs.python.org  Wed Sep  3 18:08:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Sep 2008 16:08:00 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220458080.91.0.727690742719.issue3724@psf.upfronthosting.co.za>


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

I can't really see a compelling reason to make this change---it
seems like an unnecessary complication to add to what's currently
a simple function.  Someone who really needs the accuracy can
just use log10.  Perhaps a note in the documentation for log
suggesting this would be useful.

I guess this solution seems insufficiently general:  why 'fix'
log(x, 10) but not log(x, 2), for example?

OTOH, a two-argument log that was guaranteed correctly rounded
(or accurate to within 1ulp) for *all* bases would certainly
be of interest!  But that's a fairly major project...

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

From report at bugs.python.org  Wed Sep  3 18:09:37 2008
From: report at bugs.python.org (Christopher Nelson)
Date: Wed, 03 Sep 2008 16:09:37 +0000
Subject: [issue1159425] 2.4 crashes when try to exit app and mulitple threads
	active
Message-ID: <1220458177.94.0.400613165102.issue1159425@psf.upfronthosting.co.za>


Christopher Nelson <nadiasvertex at gmail.com> added the comment:

I also experience this on a regular basis.  I can't show you the code 
due to IP restrictions, but it happens almost 100% of the time in python 
2.4.4 on win2k8, and frequently in win2k3. 

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "C:\Program Files\Opsware\agent\lcpython15\lib\atexit.py", line 
24, in _r un_exitfuncs
    func(*targs, **kargs)
  File "C:\Program Files\Opsware\agent\lcpython15\lib\threading.py", 
line 638, i n __exitfunc
    self._Thread__delete()
  File "C:\Program Files\Opsware\agent\lcpython15\lib\threading.py", 
line 522, i n __delete
    del _active[_get_ident()]
KeyError: 2540
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Program Files\Opsware\agent\lcpython15\lib\atexit.py", line 
24, in _r un_exitfuncs
    func(*targs, **kargs)
  File "C:\Program Files\Opsware\agent\lcpython15\lib\threading.py", 
line 638, i n __exitfunc
    self._Thread__delete()
  File "C:\Program Files\Opsware\agent\lcpython15\lib\threading.py", 
line 522, i n __delete
    del _active[_get_ident()]
KeyError: 2540

----------
nosy: +nadiasvertex

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

From report at bugs.python.org  Wed Sep  3 18:18:23 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Sep 2008 16:18:23 +0000
Subject: [issue3682] test_math: math.log(-ninf) fails to raise exception on
	OpenBSD
In-Reply-To: <1219709028.38.0.6245780787.issue3682@psf.upfronthosting.co.za>
Message-ID: <1220458703.17.0.536919684212.issue3682@psf.upfronthosting.co.za>


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

It's possible that this patch would cause breakage on other systems: 
there's a reason that errno is currently ignored, which is that it can't
be trusted on all systems (notably Linux: on one Linux system I've used
of three different evaluations, all of log singularity type (log(0),
log1p(-1), atanh(1), ...), one gave errno=EDOM, one gave errno=ERANGE,
and one didn't set errno at all).

So I'm reluctant to mess with math_1, especially this close to a release.

An alternative solution would be to check special cases for log directly
within the mathmodule.c code, only passing positive nonspecial arguments
to the system log function.  This would have a much lower risk of
causing breakage on other systems.  Note that Solaris with Sun's
compiler also has some problems with log:  depending on compiler
options, etc., log(-1.0) can give -inf instead of nan.  So having Python
deal with log special cases directly seems like a good thing to do there
as well.

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

From report at bugs.python.org  Wed Sep  3 18:41:41 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 16:41:41 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1220460101.15.0.125778295901.issue3594@psf.upfronthosting.co.za>


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

I don't understand the whole decoding machinery in the tokenizer, but
the patch looks ok to me. (tested in debug mode under Linux and Windows)

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

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

From report at bugs.python.org  Wed Sep  3 18:45:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 16:45:21 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1220460321.2.0.966774842575.issue3696@psf.upfronthosting.co.za>


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

Amaury, as long as you fix the small quirk mentioned above (checking the
return value of the second call to mbstowcs()), I think this patch can
go in, since it does no harm on already working platforms.

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

From report at bugs.python.org  Wed Sep  3 18:47:57 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 03 Sep 2008 16:47:57 +0000
Subject: [issue3125] test_multiprocessing causes test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1220460477.54.0.101325509451.issue3125@psf.upfronthosting.co.za>


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

Just to confirm this issue was resolved enough to be lowered from a 
blocker - I ran py3k tests in a loop for about 2+ hours. The fix applied 
in r65883 works well enough that the current implementation does not need 
to change.

----------
priority: release blocker -> high
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From report at bugs.python.org  Wed Sep  3 18:54:08 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 03 Sep 2008 16:54:08 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220460848.82.0.00251452329349.issue3110@psf.upfronthosting.co.za>


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

Raising this to RB, we should not RC without the MP module properly 
compiling

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

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

From report at bugs.python.org  Wed Sep  3 18:55:37 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 03 Sep 2008 16:55:37 +0000
Subject: [issue3763] Python 3.0 beta 2 : json and urllib not working together?
In-Reply-To: <1220433349.91.0.388298659355.issue3763@psf.upfronthosting.co.za>
Message-ID: <1220460937.15.0.250530944461.issue3763@psf.upfronthosting.co.za>


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

On the code against the trunk, I am getting the following error:

Traceback (most recent call last):
  File "python3k_json.py", line 38, in <module>
    for result in search(query)['Result']:
  File "python3k_json.py", line 31, in search
    result = json.load(obj)
  File "/usr/local/lib/python3.0/json/__init__.py", line 267, in load
    parse_constant=parse_constant, **kw)
  File "/usr/local/lib/python3.0/json/__init__.py", line 307, in loads
    return _default_decoder.decode(s)
  File "/usr/local/lib/python3.0/json/decoder.py", line 319, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
TypeError: can't use a string pattern on a bytes-like object

Swaroop: What encoding would be the JSON File content? You can try by
passing the encoding argument to the load method. I tried latin1 and
ascii, did not help.

Few more things to note:
- The above TypeError was introduced by the fix of Issue2834.
- There are also bugs open in other modules (shutil, imaplib) where
problems with str<->bytes conversions are observed.

----------
components: +Library (Lib) -None
nosy: +orsenthil
type:  -> behavior

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

From report at bugs.python.org  Wed Sep  3 18:59:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 16:59:57 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1220461197.81.0.729060814529.issue3658@psf.upfronthosting.co.za>


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

If it's only to please pychecker, then I don't think we should make this
change. It's potential gratuitous breakage, especially if people
subclass those classes.

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

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

From report at bugs.python.org  Wed Sep  3 19:00:27 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Sep 2008 17:00:27 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220461227.71.0.791899534254.issue3724@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, thanks for the first review comments.  Am also disturbed by the
lack of generality and don't think it wise to introduce a discontinuity.
 Am rejecting this patch.  Leaving the bug report open in case other
solutions arise.

----------
nosy: +rhettinger
resolution:  -> rejected

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

From report at bugs.python.org  Wed Sep  3 19:06:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 17:06:53 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220461613.56.0.998080370388.issue3110@psf.upfronthosting.co.za>


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

I suggest committing a patch which falls back to _SEM_VALUE_MAX and see
how the Solaris buildbot reacts.

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

From report at bugs.python.org  Wed Sep  3 19:08:56 2008
From: report at bugs.python.org (Swaroop)
Date: Wed, 03 Sep 2008 17:08:56 +0000
Subject: [issue3763] Python 3.0 beta 2 : json and urllib not working together?
In-Reply-To: <1220433349.91.0.388298659355.issue3763@psf.upfronthosting.co.za>
Message-ID: <1220461736.87.0.495195185901.issue3763@psf.upfronthosting.co.za>


Swaroop <swaroop at swaroopch.com> added the comment:

Hi Senthil,

I am not aware of what encoding is used.

An example of the content is
http://search.yahooapis.com/WebSearchService/V1/webSearch?query=byte+of+python&appid=jl22psvV34HELWhdfUJbfDQzlJ2B57KFS_qs4I8D0Wz5U5_yCI1Awv8.lBSfPhwr&results=20&start=1&output=json

( If the above link does not work properly, please use http://is.gd/2bbI )

When viewing this, Firefox says it is UTF-8.

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

From report at bugs.python.org  Wed Sep  3 19:10:15 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 03 Sep 2008 17:10:15 +0000
Subject: [issue3752] test_bsddb broken
In-Reply-To: <1220281752.22.0.128006401133.issue3752@psf.upfronthosting.co.za>
Message-ID: <1220461815.47.0.240527698301.issue3752@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Solved in r66137 and r66138.

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

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

From report at bugs.python.org  Wed Sep  3 19:10:32 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 03 Sep 2008 17:10:32 +0000
Subject: [issue3752] test_bsddb broken
In-Reply-To: <1220281752.22.0.128006401133.issue3752@psf.upfronthosting.co.za>
Message-ID: <1220461832.8.0.52842701019.issue3752@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution: accepted -> fixed

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

From report at bugs.python.org  Wed Sep  3 19:43:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 03 Sep 2008 17:43:36 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1220463816.52.0.880550429238.issue3696@psf.upfronthosting.co.za>


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

Here is an updated patch:
- changed #ifndef into #ifdef. The "broken" case comes first now.
- check that the second call to mbstowcs does not fail.
- also, changed an assert, since strlen() does not always count the
exact number of chars.

I won't have SVN access for the next couple of days (behind a firewall...)
Antoine (or someone else), can you please check this in?

Added file: http://bugs.python.org/file11360/mbstowcs-2.patch

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

From report at bugs.python.org  Wed Sep  3 19:48:06 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 03 Sep 2008 17:48:06 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220464086.84.0.823921795407.issue3110@psf.upfronthosting.co.za>


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

Anyone mind reviewing the attached patch? This should resolve the solaris 
compile issue. I used skip's suggested code - I removed the #ifdef solaris 
at AP's suggestion.

----------
keywords: +patch
Added file: http://bugs.python.org/file11361/issue_3110.patch

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

From report at bugs.python.org  Wed Sep  3 19:51:29 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 03 Sep 2008 17:51:29 +0000
Subject: [issue3673] bsddb module leaks memory
In-Reply-To: <1219635742.08.0.574987175435.issue3673@psf.upfronthosting.co.za>
Message-ID: <1220464289.01.0.00124295455437.issue3673@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Excellent work, Neal. Committed as r66182 and r66183.

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

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

From report at bugs.python.org  Wed Sep  3 20:00:49 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 03 Sep 2008 18:00:49 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220464849.7.0.839593981886.issue3110@psf.upfronthosting.co.za>


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


----------
keywords: +needs review

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

From report at bugs.python.org  Wed Sep  3 20:04:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 18:04:45 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220465085.57.0.279222507846.issue3110@psf.upfronthosting.co.za>


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

I recompiled and tested multiprocessing both under Windows and Linux
with this patch, no problems detected. +1 for applying it.

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

From report at bugs.python.org  Wed Sep  3 20:08:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 03 Sep 2008 18:08:12 +0000
Subject: [issue3607] test_multiprocessing failure (Unserializable message)
In-Reply-To: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
Message-ID: <1220465292.09.0.438704537672.issue3607@psf.upfronthosting.co.za>


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

It seems that issue3125 follows the same problem;
one of them could be closed IMO.

Lowering priority as well.

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

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

From report at bugs.python.org  Wed Sep  3 20:20:04 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 03 Sep 2008 18:20:04 +0000
Subject: [issue3607] test_multiprocessing failure (Unserializable message)
In-Reply-To: <1219183680.84.0.240976772511.issue3607@psf.upfronthosting.co.za>
Message-ID: <1220466004.73.0.25636651454.issue3607@psf.upfronthosting.co.za>


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

Closing as dupe to issue3125

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Sep  3 20:20:12 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 03 Sep 2008 18:20:12 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1220466012.97.0.649089436625.issue3618@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Wed Sep  3 20:22:09 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 03 Sep 2008 18:22:09 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220466129.14.0.741411561315.issue3110@psf.upfronthosting.co.za>


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

I can confirm that Jesse's patch allows multiprocessing to compile on
Solaris 10.  Note, however, that there are other symbolic constants
defined which contain "SEM_VALUE_MAX", all with widely differing
underlying values:

    % find /usr/include -name '*.h' | xargs egrep SEM_VALUE_MAX
    /usr/include/sys/param.h:#define        _SEM_VALUE_MAX          INT_MAX
    /usr/include/sys/sysconfig.h:#define    _CONFIG_SEM_VALUE_MAX   21 
    /* max. value a semaphore may have */
    /usr/include/sys/unistd.h:#define       _SC_SEM_VALUE_MAX          
    37
    /usr/include/limits.h:#define   _POSIX_SEM_VALUE_MAX    32767

How do we know that _SEM_VALUE_MAX is the proper rvalue to use when
#define-ing SEM_VALUE_MAX?

Richard, as the author of the original processing module do you have
something to contribute to this discussion?  You've been completely
silent on this issue.

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

From report at bugs.python.org  Wed Sep  3 20:23:34 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 03 Sep 2008 18:23:34 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220466214.99.0.302722722904.issue3110@psf.upfronthosting.co.za>


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

Skip - Richard has been unavailable a good chunk of the summer. I don't 
know when he will be online again.

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

From report at bugs.python.org  Wed Sep  3 20:24:56 2008
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 03 Sep 2008 18:24:56 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1220466296.32.0.785847006004.issue3110@psf.upfronthosting.co.za>


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

I've committed the patch in r66184 on trunk, 66185 py3k. Skip raises a 
good point, therefore I'll leave this open but lower from a blocker.

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

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

From report at bugs.python.org  Wed Sep  3 20:28:31 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 03 Sep 2008 18:28:31 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1220466511.48.0.475405645366.issue3473@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Wed Sep  3 20:38:15 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 18:38:15 +0000
Subject: [issue3697] "Fatal Python error: Cannot recover from stack overflow"
	on Windows buildbots
In-Reply-To: <1219835160.32.0.648492582618.issue3697@psf.upfronthosting.co.za>
Message-ID: <1220467095.8.0.500981628896.issue3697@psf.upfronthosting.co.za>


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

Committed in r66186 after review by Amaury on IRC.

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

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

From report at bugs.python.org  Wed Sep  3 20:59:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 18:59:44 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1220468384.69.0.555932027632.issue3696@psf.upfronthosting.co.za>


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

Committed in r66187. Henry, could you confirm it fixes the problem on
your side?

----------
priority: release blocker -> critical
resolution:  -> accepted
status: open -> pending

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

From report at bugs.python.org  Wed Sep  3 21:00:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 19:00:55 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1220468455.29.0.938552584278.issue3626@psf.upfronthosting.co.za>


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

The mbstowcs problem should be fixed in r66187. What is the state of the
other problems? Is this issue still a release blocker?

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

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

From report at bugs.python.org  Wed Sep  3 21:53:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 19:53:26 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220471606.04.0.64903723075.issue3758@psf.upfronthosting.co.za>


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

Or how about ``make precommit``?

----------
priority:  -> low

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

From report at bugs.python.org  Wed Sep  3 22:00:09 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Wed, 03 Sep 2008 20:00:09 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1220472009.65.0.268032517598.issue3626@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

Thank you for the patch; that allows the build to finish.  The remaining
issues are now:

msg72029: printf("%ls",...) bug
msg72044: does not build with db4.7

Finally proceeding to the install, now I get another error:

mkdir ./Lib/plat-cygwin
cp ./Lib/plat-generic/regen ./Lib/plat-cygwin/regen
export PATH; PATH="`pwd`:$PATH"; \
	export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
	export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
	export EXE; EXE=".exe"; \
	cd ./Lib/plat-cygwin; ./regen
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)'
/usr/include/netinet/in.h
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
./regen: line 3:  4164 Segmentation fault      (core dumped) python$EXE
../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
make: *** [Lib/plat-cygwin] Error 139

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

From report at bugs.python.org  Wed Sep  3 22:55:16 2008
From: report at bugs.python.org (Christopher Li)
Date: Wed, 03 Sep 2008 20:55:16 +0000
Subject: [issue3765] [patch] allow mmap take file offset as argument
In-Reply-To: <1220475316.49.0.690011061298.issue3765@psf.upfronthosting.co.za>
Message-ID: <1220475316.49.0.690011061298.issue3765@psf.upfronthosting.co.za>


New submission from Christopher Li <python at chrisli.org>:

The os.mmap function does not take file offset as
requirement. As a result, if python want to mmap
a piece of the file data at the very end of the
file, it needs to mmap the every thing before that.

Without offset argument, it is hard to work with
large files.

I make a patch to add the offset arguments to mmap
function call a while back. I wish it get included
in the future version of python.

http://mail.python.org/pipermail/python-list/2005-May/324213.html


Thanks

----------
components: Library (Lib)
messages: 72416
nosy: chrisl
severity: normal
status: open
title: [patch] allow mmap take file offset as argument
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Wed Sep  3 23:19:31 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 21:19:31 +0000
Subject: [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1220476771.85.0.316856489143.issue2744@psf.upfronthosting.co.za>


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

So is this going to be a 3.1 issue or a 3.0 one? If it's the former then
it should not be a release blocker. But if is going to be for 3.0 then
the version list is wrong.

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

From report at bugs.python.org  Wed Sep  3 23:22:45 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 21:22:45 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220476965.51.0.216536214384.issue3758@psf.upfronthosting.co.za>


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

That suggests that it only need to run by committers. I find it useful,
just for the reindenting whenever I'm writing a patch.

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

From report at bugs.python.org  Wed Sep  3 23:23:00 2008
From: report at bugs.python.org (Simon Cross)
Date: Wed, 03 Sep 2008 21:23:00 +0000
Subject: [issue1923] meaningful whitespace can be lost in rfc822_escape
In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za>
Message-ID: <1220476980.07.0.84106219353.issue1923@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

Poking the issue.

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

From report at bugs.python.org  Wed Sep  3 23:26:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 21:26:20 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1220477180.33.0.0770631460186.issue3594@psf.upfronthosting.co.za>


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

The patch also looks pretty harmless to me. :)

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

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

From report at bugs.python.org  Wed Sep  3 23:29:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 21:29:28 +0000
Subject: [issue3764] asyncore differences between 2.x and 3.x
In-Reply-To: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>
Message-ID: <1220477368.84.0.373106487334.issue3764@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> josiahcarlson

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

From report at bugs.python.org  Wed Sep  3 23:38:03 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Sep 2008 21:38:03 +0000
Subject: [issue3763] Python 3.0 beta 2 : json and urllib not working together?
In-Reply-To: <1220433349.91.0.388298659355.issue3763@psf.upfronthosting.co.za>
Message-ID: <1220477883.88.0.346091089303.issue3763@psf.upfronthosting.co.za>


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

If you look at the headers of HTTP response, the encoding is utf-8. You
should also be able to get this information by calling the info() method
on the return value of urlopen().

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

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

From report at bugs.python.org  Wed Sep  3 23:42:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 21:42:41 +0000
Subject: [issue3590] sax.parser considers XML as text rather than bytes
In-Reply-To: <1219071975.28.0.899711064426.issue3590@psf.upfronthosting.co.za>
Message-ID: <1220478161.33.0.733667253612.issue3590@psf.upfronthosting.co.za>


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

This is a duplicate of #2501.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Sep  3 23:45:46 2008
From: report at bugs.python.org (Florian Mayer)
Date: Wed, 03 Sep 2008 21:45:46 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220478346.58.0.394747567413.issue3724@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

Uploaded small documentation patch warning the user of math.log(x, 10)
inaccuracy.

Added file: http://bugs.python.org/file11362/math_doc.patch

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

From report at bugs.python.org  Wed Sep  3 23:58:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Sep 2008 21:58:01 +0000
Subject: [issue3724] math.log(x, 10) gives different result than math.log10(x)
In-Reply-To: <1220013140.94.0.0541204512227.issue3724@psf.upfronthosting.co.za>
Message-ID: <1220479081.89.0.299096965103.issue3724@psf.upfronthosting.co.za>


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


----------
assignee: marketdickinson -> rhettinger

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

From report at bugs.python.org  Wed Sep  3 23:58:48 2008
From: report at bugs.python.org (Thorben Krueger)
Date: Wed, 03 Sep 2008 21:58:48 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>


New submission from Thorben Krueger <thkruege at uos.de>:

Under Linux 2.6.24-1-amd64 as well as 2.6.26 (x86-32), Python versions
2.5.2 and 2.4.4 (on both machines), there is a huge discrepancy between
socket read latencies, depending on "code context".

Some detail:

For a university project, I wrote a python client for a query-server. A
reference implementation existed in Perl, so the job was pretty straight
forward. However, for reasons unknown to me, the Python implementation
was by several orders of magnitude slower than the reference
implementation. To track down the issue, I wrote a dummy version of the
query-server in Python, where the problem persisted. I then stripped
down both client and server to the minimal functionality and still the
problem persisted. 
I wrote a demo inside a single file using socketpair() to post here, but
the issue was not reproducible.

Finally, I stripped down the original client/server to a postable level
and ran a profiler on a testcase.

Here is the gist of it:

Sending 500 packets @ 2 tokens each (500 very short lists) takes 40
seconds on average.

In detail:

14508 function calls in 39.980 CPU seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
     1500   39.834    0.027   39.834    0.027 {method 'recv' of
'_socket.socket' objects}
     1500    0.024    0.000   39.877    0.027 Client.py:16(read_int)
     1500    0.020    0.000    0.020    0.000 <string>:1(sendall)
     1500    0.018    0.000    0.048    0.000 Client.py:8(send_int)
      500    0.016    0.000   39.903    0.080 Client.py:19(read_int_list)
     1500    0.015    0.000    0.019    0.000 struct.py:77(unpack)
      500    0.010    0.000    0.060    0.000 Client.py:11(send_int_list)
     1500    0.010    0.000    0.010    0.000 struct.py:54(pack)
        1    0.009    0.009   39.980   39.980 dummytest.py:12(bench)
     1000    0.007    0.000    0.007    0.000 {method 'insert' of 'list'
objects}
     1001    0.006    0.000    0.006    0.000 {range}
      500    0.005    0.000   39.968    0.080 Client.py:28(spam)
     1500    0.005    0.000    0.005    0.000 {method 'unpack' of
'Struct' objects}
      501    0.002    0.000    0.002    0.000 {len}


Here is the same for 1 packet @ 50000 tokens (1 very long list), taking
below 10 seconds on average.

8.51872587204
         400018 function calls in 8.519 CPU seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    50001    2.980    0.000    2.980    0.000 {method 'recv' of
'_socket.socket' objects}
    50000    2.980    0.000    2.980    0.000 {method 'insert' of 'list'
objects}
    50001    0.993    0.000    0.993    0.000 <string>:1(sendall)
    50001    0.410    0.000    1.558    0.000 Client.py:8(send_int)
    50001    0.334    0.000    3.581    0.000 Client.py:16(read_int)
        1    0.247    0.247    6.809    6.809 Client.py:19(read_int_list)
    50001    0.191    0.000    0.266    0.000 struct.py:77(unpack)
    50001    0.154    0.000    0.154    0.000 struct.py:54(pack)
        1    0.146    0.146    1.703    1.703 Client.py:11(send_int_list)
    50001    0.075    0.000    0.075    0.000 {method 'unpack' of
'Struct' objects}

I don't get the reason for the huge speed discrepancy. I include all
source code files for reproducing the issue.

Notably, the original software (non stripped-down version) runs without
these issues using a OS X Python version. Details may follow, I don't
own a Mac but know people who do.

Also note that I can't get the server to shut down properly (the thread
does not terminate). You have to kill the process manually and wait for
the port to be freed by the kernel. Maybe this is easily fixable but at
least I don't know how.

The attached archive contains all source code plus README and the
socketpair() version.

----------
components: Library (Lib)
files: socket_bug.tar.bz2
messages: 72424
nosy: thorben
severity: normal
status: open
title: socket.socket.recv broken (unbearably slow)
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file11363/socket_bug.tar.bz2

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

From report at bugs.python.org  Thu Sep  4 00:32:11 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 03 Sep 2008 22:32:11 +0000
Subject: [issue3767] tkColorChooser may fail if no color is selected
In-Reply-To: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za>
Message-ID: <1220481131.49.0.0978802326192.issue3767@psf.upfronthosting.co.za>


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

Chooser._fixresult in the tkColorChooser module uses "if not result" to
check if user canceled the dialog, but nowadays Tk may return a cached
object that contains the result we are after, so, this object will not
simply evaluate to false and _fixresult will act like if the user didn't
cancel the dialog. 
The fix is simple, just get the real value of result in that check.

----------
components: Tkinter
files: str_result.diff
keywords: patch
messages: 72425
nosy: gpolo
severity: normal
status: open
title: tkColorChooser may fail if no color is selected
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11364/str_result.diff

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

From report at bugs.python.org  Thu Sep  4 00:36:02 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 22:36:02 +0000
Subject: [issue3768] Move test_py3kwarn over to new catch_warnings API
In-Reply-To: <1220481362.39.0.523563291415.issue3768@psf.upfronthosting.co.za>
Message-ID: <1220481362.39.0.523563291415.issue3768@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test_py3kwarn was using the old API presented by catch_warnings. The
attached patch fixes it to use the new one.

----------
components: Library (Lib)
files: fix_py3kwarn.diff
keywords: needs review, patch, patch
messages: 72426
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Move test_py3kwarn over to new catch_warnings API
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11365/fix_py3kwarn.diff

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

From report at bugs.python.org  Thu Sep  4 00:37:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 22:37:28 +0000
Subject: [issue3768] Move test_py3kwarn over to new catch_warnings API
In-Reply-To: <1220481362.39.0.523563291415.issue3768@psf.upfronthosting.co.za>
Message-ID: <1220481448.31.0.598081099762.issue3768@psf.upfronthosting.co.za>


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

Looks straightforward; go ahead.

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

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

From report at bugs.python.org  Thu Sep  4 00:46:16 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 03 Sep 2008 22:46:16 +0000
Subject: [issue1658] "RuntimeError: dictionary changed size during iteration"
	in Tkinter
In-Reply-To: <1198069697.21.0.802905521155.issue1658@psf.upfronthosting.co.za>
Message-ID: <1220481976.92.0.446638879712.issue1658@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Can someone review the patch and apply please ? It is sad to leave
tkinter like this in py3k. Clearly there are not much people using it
there, but it is something very simple to fix.

----------
keywords: +needs review

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

From report at bugs.python.org  Thu Sep  4 00:47:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 22:47:30 +0000
Subject: [issue3768] Move test_py3kwarn over to new catch_warnings API
In-Reply-To: <1220481362.39.0.523563291415.issue3768@psf.upfronthosting.co.za>
Message-ID: <1220482050.42.0.508067024765.issue3768@psf.upfronthosting.co.za>


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

Done in r66197 on the trunk with the Py3K block in r66198.

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

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

From report at bugs.python.org  Thu Sep  4 00:52:25 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 03 Sep 2008 22:52:25 +0000
Subject: [issue600362] relocate cgi.parse_qs() into urlparse
Message-ID: <1220482345.27.0.991618216275.issue600362@psf.upfronthosting.co.za>


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

Commited in r66196 and r66199, this went into 2.6/3.0 rc1!!

Thank you all for the effort!

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

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

From report at bugs.python.org  Thu Sep  4 01:06:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 23:06:32 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Attached is a patch that deprecates bsddb for removal in 3.0.

----------
components: Library (Lib)
files: deprecate_bsddb.diff
keywords: needs review, patch, patch
messages: 72431
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Deprecate bsddb for removal in 3.0
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11366/deprecate_bsddb.diff

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

From report at bugs.python.org  Thu Sep  4 01:12:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 23:12:56 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220483576.91.0.936222547331.issue3769@psf.upfronthosting.co.za>


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

I also think you need to deprecate the dbhash module.

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

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

From report at bugs.python.org  Thu Sep  4 01:20:55 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 03 Sep 2008 23:20:55 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220484055.04.0.310220074498.issue3769@psf.upfronthosting.co.za>


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

Remind me why we want to get rid of bsddb?

Skip

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Thu Sep  4 01:22:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 23:22:38 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220484055.04.0.310220074498.issue3769@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809031622j3b63a08h912686a839bd0ed@mail.gmail.com>


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

On Wed, Sep 3, 2008 at 6:20 PM, Skip Montanaro <report at bugs.python.org> wrote:
>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> Remind me why we want to get rid of bsddb?

The reasons are enumerated in PEP 3108.
>
> Skip
>
> ----------
> nosy: +skip.montanaro
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3769>
> _______________________________________
>

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

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

From report at bugs.python.org  Thu Sep  4 01:28:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Sep 2008 23:28:01 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220484481.35.0.299161554858.issue3769@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I thought someone stepped forward to maintain this package.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Sep  4 01:32:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 23:32:32 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220484752.61.0.214853794698.issue3769@psf.upfronthosting.co.za>


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

Also see this:
http://mail.python.org/pipermail/python-3000/2008-September/014712.html

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

From report at bugs.python.org  Thu Sep  4 01:39:44 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 23:39:44 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220485184.4.0.585185117694.issue3769@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file11366/deprecate_bsddb.diff

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

From report at bugs.python.org  Thu Sep  4 01:40:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 23:40:17 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220485217.59.0.300103537835.issue3769@psf.upfronthosting.co.za>


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

New patch to also deprecated dbhash.

Added file: http://bugs.python.org/file11367/deprecate_bsddb.diff

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

From report at bugs.python.org  Thu Sep  4 01:49:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Sep 2008 23:49:35 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220485775.81.0.720714205493.issue3769@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +barry

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

From report at bugs.python.org  Thu Sep  4 01:54:30 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Sep 2008 23:54:30 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220486070.46.0.125274333237.issue3769@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think this should be deferred to Py3.1. 

This decision was not widely discussed and I think it likely that some
users will be surprised and dismayed.  The release candidate seems to be
the wrong time to yank this out (in part because of the surprise factor)
and in part because I think the change silently affects shelve/anydbm
performance so that the impact may be significantly degraded but not
immediately apparent (test suites will still succeed).

We don't have to take this out.  So why do it hastily at the last minute
and without some discussion on comp.lang.python at least.

If it were any other release, we would have disciplined ourselves to
deprecate first and remove a generation or two later.

Also, the stated reason for removal may yet disappear if jcrea steps in
as promised and continues to make updates.

Also, the referenced note (
http://mail.python.org/pipermail/python-dev/2008-July/081379.html ) say
to "start end-of-lifing it" which I took to mean deprecate rather than
completely remove during a release candidate.

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

From report at bugs.python.org  Thu Sep  4 02:02:29 2008
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 04 Sep 2008 00:02:29 +0000
Subject: [issue3565] array documentation, method names not 3.0 compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1220486549.24.0.992008937343.issue3565@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

Can I just remind people that I have a documentation patch ready here
(and has been for about a month)?

Of course the doc+bytesmethods.patch may be debatable and probably too
late to go in 3.0. But you should be able to commit doc-only.patch with
no problems.

Current array documentation
(http://docs.python.org/dev/3.0/library/array.html) is clearly wrong in
Python 3.0 (even containing syntax errors).

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

From report at bugs.python.org  Thu Sep  4 02:07:10 2008
From: report at bugs.python.org (Clinton Roy)
Date: Thu, 04 Sep 2008 00:07:10 +0000
Subject: [issue3585] pkg-config support
In-Reply-To: <1219021409.35.0.10935334414.issue3585@psf.upfronthosting.co.za>
Message-ID: <1220486830.71.0.461856603255.issue3585@psf.upfronthosting.co.za>


Clinton Roy <clinton.roy at gmail.com> added the comment:

This version sets Libs.private for static compiles.

Any chance this will make it into the 2.6/3.0 release candidates ?

cheers,

Added file: http://bugs.python.org/file11368/pkgconfig.diff

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

From report at bugs.python.org  Thu Sep  4 02:12:44 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 00:12:44 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <D4C0145D0BCC4C00B9E9743D07D330C9@RaymondLaptop1>
Message-ID: <bbaeab100809031712y6bfc1e53md15f5c28d00f7ed3@mail.gmail.com>


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

On Wed, Sep 3, 2008 at 4:41 PM, Raymond Hettinger <python at rcn.com> wrote:
> I think this should be deferred to Py3.1.
> This decision was not widely discussed and I think it likely that some users
> will
> be surprised and dismayed.

Perhaps, but that could be said about almost any module that has been
removed through the stdlib reorg.

>  The release
> candidate seems to be the wrong time to
> yank this out (in part because of the surprise
> factor) and in part because I think the change
> silently affects shelve performance so that the
> impact may be significantly negative but not
> readily apparent.
>
> We don't have to take this out.

We don't have to remove anything that has gone through the stdlib
reorg, so that is not a solid argument.

>  So why do
> it hastily at the last minute and without some
> discussion on comp.lang.python at least.
>

It isn't being done "hastily"; this has been planned for a while.
People have just been too busy to get around to it. And we are not
changing any semantics or removing something from the language which
is what I view as what you don't change in an rc. So this might come
down to a different opinion of what one can do during an rc.

> If it were any other release, we would have
> disciplined ourselves to deprecate first and
> remove a generation or two later.
>

We are deprecating first in 2.6.

> Also, the reason for removal may yet disappear
> if jcrea steps in an continues to make updates.
>

OK, but none of his changes have received a code review, so if we are
going to go down the whole "disciplined" route about it being an rc
then we should back out all of Jesus' changes for both 2.6 and 3.0,
which puts us back to the same instability issues.

> Also, the referenced note (
> http://mail.python.org/pipermail/python-dev/2008-July/081379.html )
> say to "start end-of-lifing it" which I took to mean deprecate rather than
> remove during a release candidate.

Well, it was in the PEP before beta2 even went out the door.

-Brett

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

From report at bugs.python.org  Thu Sep  4 02:23:59 2008
From: report at bugs.python.org (Damien Miller)
Date: Thu, 04 Sep 2008 00:23:59 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>


New submission from Damien Miller <djmdjm at users.sourceforge.net>:

test_multiprocessing crashes on platforms that lack a working
sem_open(), despite it being turned off at compilation time by setting
HAVE_SEM_OPEN=0 in the Extension macros in setup.py

I think the multiprocessing module should disable the functionality
gracefully when it is missing from _multiprocessing.

Failure message:

test test_multiprocessing crashed -- <type 'exceptions.AttributeError'>:
'module' object has no attribute 'SemLock'
Traceback (most recent call last):
  File ".//Lib/test/regrtest.py", line 556, in runtest_inner
    indirect_test()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/test/test_multiprocessing.py",
line 1758, in test_main
    ProcessesMixin.pool = multiprocessing.Pool(4)
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/__init__.py",
line 226, in Pool
    return Pool(processes, initializer, initargs)
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/pool.py",
line 84, in __init__
    self._setup_queues()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/pool.py",
line 130, in _setup_queues
    from .queues import SimpleQueue
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/queues.py",
line 22, in <module>
    from multiprocessing.synchronize import Lock, BoundedSemaphore,
Semaphore, Condition
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/synchronize.py",
line 29, in <module>
    SEM_VALUE_MAX = _multiprocessing.SemLock.SEM_VALUE_MAX
AttributeError: 'module' object has no attribute 'SemLock'
1 test failed:
    test_multiprocessing

----------
components: Extension Modules
messages: 72442
nosy: djmdjm
severity: normal
status: open
title: test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Sep  4 02:47:19 2008
From: report at bugs.python.org (Damien Miller)
Date: Thu, 04 Sep 2008 00:47:19 +0000
Subject: [issue3771] test_httpservers intermittent failure
In-Reply-To: <1220489239.6.0.433848845577.issue3771@psf.upfronthosting.co.za>
Message-ID: <1220489239.6.0.433848845577.issue3771@psf.upfronthosting.co.za>


New submission from Damien Miller <djmdjm at users.sourceforge.net>:

On OpenBSD I'm seeing intermittent failures of test_httpservers with the
following error:

test_post (test.test_httpservers.CGIHTTPServerTestCase) ... ERROR

======================================================================
ERROR: test_post (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/test/test_httpservers.py",
line 326, in test_post
    res = self.request('/cgi-bin/file2.py', 'POST', params, headers)
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/test/test_httpservers.py",
line 64, in request
    return self.connection.getresponse()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/httplib.py",
line 949, in getresponse
    response.begin()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/httplib.py",
line 418, in begin
    self.msg = HTTPMessage(self.fp, 0)
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/mimetools.py",
line 24, in __init__
    rfc822.Message.__init__(self, fp, seekable)
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/rfc822.py",
line 108, in __init__
    self.readheaders()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/httplib.py",
line 274, in readheaders
    line = self.fp.readline()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/socket.py",
line 395, in readline
    data = recv(1)
error: [Errno 4] Interrupted system call

Rerunning the test by itself always passes; maybe a SIGCHLD is
interrupting the recv() call.

Anyway, EINTR is a recoverable error - the socket code should probably
retry the read.

----------
components: Extension Modules
messages: 72443
nosy: djmdjm
severity: normal
status: open
title: test_httpservers intermittent failure
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Sep  4 02:58:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 00:58:41 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1220489921.37.0.483321110581.issue3770@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

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

From report at bugs.python.org  Thu Sep  4 03:09:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:09:19 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1220490559.15.0.740126184372.issue2876@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:09:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:09:24 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1220490564.78.0.540086748985.issue3279@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:09:17 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Sep 2008 01:09:17 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220490557.25.0.967235651994.issue3769@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

>> I think this should be deferred to Py3.1.
>> This decision was not widely discussed and I think 
>> it likely that some users will be surprised and dismayed.

> Perhaps, but that could be said about almost any module 
> that has been removed through the stdlib reorg.

Many of those were trivial in comparison and many had good replacements
or were no longer relevant.  This is a bigger deal (almost on par with
removing Tkinter).

>> If it were any other release, we would have
>> disciplined ourselves to deprecate first and
>> remove a generation or two later.

> We are deprecating first in 2.6.

That, of course, isn't fair since 2.6 is going out the door at the same
time as 3.0.  Normally, we would go through more that one cycle between
the heads-up and taking the hit.  Life is already going to be
challenging for people using 2.6 as a stepping stone to 3.0.  Would hate
to stop some of them dead in the water.

> Well, it was in the PEP before beta2 even went out the door.

If you think everyone got fair warning, knows this is coming, has had a
chance to assess its impact, and has had a chance to comment on it, then
you're kidding yourself. 

I don't understand the rush to yank out a major component affecting a
commonly used module (shelve) without more due process, due diligence,
and a bit higher standard of care.  I don't think we're respecting our
users on this one.  What's wrong with deferring this to 3.1?

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

From report at bugs.python.org  Thu Sep  4 03:10:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:10:11 +0000
Subject: [issue2350] 'exceptions' import fixer
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1220490611.43.0.884916386708.issue2350@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:11:02 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:11:02 +0000
Subject: [issue1251] ssl module doesn't support non-blocking handshakes
In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>
Message-ID: <1220490662.21.0.162119913362.issue1251@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Thanks.  If you can identify a specific bug, I'll take a look at it.

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

From report at bugs.python.org  Thu Sep  4 03:11:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:11:32 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1220490692.14.0.538721443908.issue3642@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:12:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:12:11 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1220490731.65.0.209878460594.issue3723@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:12:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:12:34 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1220490754.9.0.138428723635.issue3659@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:13:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:13:27 +0000
Subject: [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1220490807.44.0.0506571052771.issue3628@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:14:26 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:14:26 +0000
Subject: [issue3597] Allow application developers to select ciphers,
	and default to strong in ssl lib
In-Reply-To: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>
Message-ID: <1220490866.6.0.0918567025246.issue3597@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I'm afraid you're ahead of me in knowledge here.  I've experimented with
the ciphers a bit, but there seem to be various compatibility issues.  I
finally decided to let the OpenSSL folks and various standard groups
worry about this; the designation of SSL 2, SSL 3, or TLS 1, is supposed
to select the appropriate cipher groups.

Now, as to making the default be different:  we discussed this on
python-dev a bit.  I think it might make sense to default to TLS 1, even
at the expense of compatibility, but we (the two or three of us actually
discussing it) finally decided to go with what the current Python
socket.ssl module used.

----------
nosy: +janssen

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

From report at bugs.python.org  Thu Sep  4 03:14:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:14:41 +0000
Subject: [issue2443] uninitialized access to va_list
In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za>
Message-ID: <1220490881.71.0.757380631047.issue2443@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:15:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:15:12 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1220490912.6.0.263580297963.issue3666@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:15:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:15:19 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1220490919.62.0.627395384704.issue3664@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:15:28 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:15:28 +0000
Subject: [issue3596] Provide a way to disable SSLv2 (or better yet,
	disable by default)
In-Reply-To: <1219115176.99.0.339604404005.issue3596@psf.upfronthosting.co.za>
Message-ID: <1220490928.2.0.712546542536.issue3596@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

We might consider this for 3.x.  We didn't want to do this for 2.6, to
maintain compatibility with the older socket.ssl module in Python.

----------
nosy: +janssen

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

From report at bugs.python.org  Thu Sep  4 03:16:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:16:12 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1220490972.8.0.269619130856.issue1868@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:16:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:16:29 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1220490989.82.0.793133373446.issue3618@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:16:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:16:47 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220491007.59.0.989531825517.issue3769@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:17:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:17:32 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1220491052.44.0.858405021871.issue3685@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:18:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:18:23 +0000
Subject: [issue3002] shutil.copyfile blocks indefinitely on named pipes
In-Reply-To: <1212075150.42.0.761610345558.issue3002@psf.upfronthosting.co.za>
Message-ID: <1220491103.29.0.884300143573.issue3002@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:19:06 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:19:06 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220491146.63.0.976429114691.issue3162@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Simon, Python 3.x now has recvfrom and recv_into, but not recvfrom_into.
 If you'd like to work up a patch for that, I'll add it to the next
release cycle.

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

From report at bugs.python.org  Thu Sep  4 03:19:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:19:20 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1220491160.01.0.556623105696.issue3626@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:20:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 01:20:10 +0000
Subject: [issue3705] py3k aborts if "-c" or "-m" is given a non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220491210.48.0.65055287471.issue3705@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:20:43 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:20:43 +0000
Subject: [issue1223] httplib does not handle ssl end of file properly
In-Reply-To: <1191199809.02.0.233978380017.issue1223@psf.upfronthosting.co.za>
Message-ID: <1220491243.13.0.222011365554.issue1223@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


----------
resolution: accepted -> fixed

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

From report at bugs.python.org  Thu Sep  4 03:27:34 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 01:27:34 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220491654.08.0.611679136892.issue3769@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

See http://mail.python.org/pipermail/python-dev/2008-July/081362.html

Guido states his opinion in no uncertain terms regarding pybsddb in
Python 3.0:

"+1. In my recollection maintaining bsddb has been nothing but trouble
right from the start when we were all sitting together at "Zope Corp
North" in a rented office in McLean... We can remove it from 3.0. We
can't really remove it from 2.6, but we can certainly start
end-of-lifing it in 2.6."

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

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

From report at bugs.python.org  Thu Sep  4 03:30:38 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 04 Sep 2008 01:30:38 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220489921.42.0.19696182917.issue3770@psf.upfronthosting.co.za>
Message-ID: <9D30D656-DDDE-4BB8-A270-28B018646A61@gmail.com>


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

Which platforms is this appearing on?

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

From report at bugs.python.org  Thu Sep  4 03:33:38 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:33:38 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220492018.08.0.910099216521.issue1291446@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I think I'm going to close this.  file.read(N) is not guaranteed to
return N bytes, it's guaranteed to return at most N bytes.

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

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

From report at bugs.python.org  Thu Sep  4 03:33:47 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:33:47 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220492027.49.0.846530509495.issue1291446@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep  4 03:36:08 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Sep 2008 01:36:08 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220492168.08.0.709186738367.issue3762@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +easy, needs review

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

From report at bugs.python.org  Thu Sep  4 03:36:22 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 01:36:22 +0000
Subject: [issue508944] socket-module SSL is broken
Message-ID: <1220492182.87.0.581379385812.issue508944@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


----------
resolution: later -> fixed

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

From report at bugs.python.org  Thu Sep  4 03:40:40 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 01:40:40 +0000
Subject: [issue2965] Update interface of weakref dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1220492440.92.0.190574228332.issue2965@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I will apply the patch to 3.0.

Please open a separate bug for the simplification (which is not an API
change).  As for returning iterators rather than views, it would be nice
to get that fixed before the final release, but I don't see that as
critical.  Please open a separate bug for that.

----------
nosy: +barry

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

From report at bugs.python.org  Thu Sep  4 03:43:02 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 01:43:02 +0000
Subject: [issue2965] Update interface of weakref dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1220492582.47.0.220604538588.issue2965@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

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

From report at bugs.python.org  Thu Sep  4 03:51:17 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 01:51:17 +0000
Subject: [issue2965] Update interface of weakref dictionaries
In-Reply-To: <1211708783.58.0.883984457478.issue2965@psf.upfronthosting.co.za>
Message-ID: <1220493077.67.0.553784502976.issue2965@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r66202

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

From report at bugs.python.org  Thu Sep  4 03:52:11 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 01:52:11 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1220493131.76.0.925995450509.issue2226@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

There's been no activity on this, but I don't believe it's serious
enough to block the release.

----------
nosy: +barry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 03:52:47 2008
From: report at bugs.python.org (Damien Miller)
Date: Thu, 04 Sep 2008 01:52:47 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <9D30D656-DDDE-4BB8-A270-28B018646A61@gmail.com>
Message-ID: <alpine.BSO.1.10.0809041133010.15327@fuyu.mindrot.org>


Damien Miller <djmdjm at users.sourceforge.net> added the comment:

On Thu, 4 Sep 2008, Jesse Noller wrote:

> 
> Jesse Noller <jnoller at gmail.com> added the comment:
> 
> Which platforms is this appearing on?

OpenBSD, with this section added to setup.py:

@@ -1269,6 +1268,14 @@ class PyBuildExt(build_ext):
                 )
             libraries = []

+        elif platform.startswith('openbsd'):
+            macros = dict(                  # OpenBSD
+                HAVE_SEM_OPEN=0,            # Not implemented
+                HAVE_SEM_TIMEDWAIT=0,
+                HAVE_FD_TRANSFER=1,
+                )
+            libraries = []
+
         else:                                   # Linux and other unices
             macros = dict(
                 HAVE_SEM_OPEN=1,

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

From report at bugs.python.org  Thu Sep  4 03:55:49 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 01:55:49 +0000
Subject: [issue2322] Clean up getargs.c and its formatting possibilities
In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
Message-ID: <1220493349.29.0.829205362127.issue2322@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Is there more information on this?  Where's the referenced article and
what exactly needs to get done?  Deferring this for rc1.

----------
nosy: +barry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 03:57:10 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 01:57:10 +0000
Subject: [issue3629] Py30b3 won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1220493430.92.0.517145906688.issue3629@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This bug will block rc2

----------
nosy: +barry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 04:02:54 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:02:54 +0000
Subject: [issue3661] sys.call_tracing segfaults
In-Reply-To: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
Message-ID: <1220493774.24.0.228000470281.issue3661@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This bug should be fixed for rc2, but it doesn't need to block rc1.

----------
nosy: +barry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 04:12:11 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:12:11 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1220494331.8.0.485832798994.issue1210@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This should be fixed but it's not a release blocker.

----------
nosy: +barry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 04:13:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 02:13:42 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220494422.47.0.760133457649.issue3756@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 04:15:17 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:15:17 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1220494517.23.0.304612387814.issue3623@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Deferring until rc2

----------
nosy: +barry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 04:20:52 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:20:52 +0000
Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1220494852.96.0.585700372686.issue2501@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Benjamin will commit this.

----------
assignee:  -> benjamin.peterson
nosy: +barry
resolution:  -> accepted

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

From report at bugs.python.org  Thu Sep  4 04:21:15 2008
From: report at bugs.python.org (Henry Precheur)
Date: Thu, 04 Sep 2008 02:21:15 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1220494875.92.0.620476759063.issue3696@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I am now able to finish the build and the interpreter seems to be
working. So it is all good :)

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

From report at bugs.python.org  Thu Sep  4 04:23:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 02:23:02 +0000
Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename
In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za>
Message-ID: <1220494982.54.0.495508636252.issue2501@psf.upfronthosting.co.za>


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

Applied in r66203.

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

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

From report at bugs.python.org  Thu Sep  4 04:23:11 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:23:11 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1220494991.78.0.114081370549.issue3617@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This should definitely block the final release, but not rc1.

----------
nosy: +barry
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Sep  4 04:23:57 2008
From: report at bugs.python.org (Henry Precheur)
Date: Thu, 04 Sep 2008 02:23:57 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1220495037.79.0.336590708494.issue3645@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I just compiled the latest version of trunk. The problem seems to be
fixed. And according to config.log & nm, readline.so is linked with the
right function.

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

From report at bugs.python.org  Thu Sep  4 04:27:54 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:27:54 +0000
Subject: [issue3667] Reloading an extension module always leaks
In-Reply-To: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>
Message-ID: <1220495274.79.0.366358754656.issue3667@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The patch looks good.  Benjamin will commit this.

----------
assignee: loewis -> benjamin.peterson
nosy: +barry, benjamin.peterson
resolution:  -> accepted

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

From report at bugs.python.org  Thu Sep  4 04:28:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 02:28:33 +0000
Subject: [issue3667] Reloading an extension module always leaks
In-Reply-To: <1219611300.04.0.860759707504.issue3667@psf.upfronthosting.co.za>
Message-ID: <1220495313.05.0.536012668287.issue3667@psf.upfronthosting.co.za>


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

Fixed in r66204.

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

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

From report at bugs.python.org  Thu Sep  4 04:43:45 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 04 Sep 2008 02:43:45 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220490557.25.0.967235651994.issue3769@psf.upfronthosting.co.za>
Message-ID: <18623.19290.526874.362918@montanaro-dyndns-org.local>


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

Is there going to be a dbm.* module which is supported across all the core
platforms: Windows, Mac & Unix?  I don't count dumbdbm as really all that
useful, especially given the caveats listed in the module docstring.

If not, could a dbm.sqlite module be written for 2.7 and 3.1 which can fill
that role?

Skip

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

From report at bugs.python.org  Thu Sep  4 04:49:29 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Sep 2008 02:49:29 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1220496569.33.0.921935274167.issue2226@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Recommend dealing with this in 3.1.
The __radd__ issue is non-trivial
and can't easily be dealt with at this point.

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

From report at bugs.python.org  Thu Sep  4 04:49:45 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:49:45 +0000
Subject: [issue2744] Fix test_cProfile
In-Reply-To: <1209770110.61.0.304892387875.issue2744@psf.upfronthosting.co.za>
Message-ID: <1220496585.62.0.745316207485.issue2744@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I guess since this hasn't been done by now, it's not going to get done
for 3.0, so I'm lowering the priority on it.

----------
nosy: +barry
priority: release blocker -> critical

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

From report at bugs.python.org  Thu Sep  4 04:50:56 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:50:56 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1220496656.09.0.393352513378.issue2226@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks Raymond.  Lowering the priority to critical and pushing this back
to 3.1.

----------
priority: deferred blocker -> critical
versions: +Python 3.1 -Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Sep  4 04:53:41 2008
From: report at bugs.python.org (Henry Precheur)
Date: Thu, 04 Sep 2008 02:53:41 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1220496821.22.0.951119316369.issue3685@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

Here is a better patch which use the workaround only if wcschr is broken.

I was able to build the python interpreter and to run regrtest.py with
it (some tests fail but it is very likely to be bugs in the modules)

Added file: http://bugs.python.org/file11369/fix_wcschr_generic.patch

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

From report at bugs.python.org  Thu Sep  4 04:54:13 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:54:13 +0000
Subject: [issue3629] Py30b3 won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1220496853.78.0.436252607123.issue3629@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

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

From report at bugs.python.org  Thu Sep  4 04:57:54 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 02:57:54 +0000
Subject: [issue2322] Clean up getargs.c and its formatting possibilities
In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
Message-ID: <1220497074.05.0.682980005127.issue2322@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Since I'm going to postpone rc1 anyway, might as well bump this back to
release blocker for now.

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

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

From report at bugs.python.org  Thu Sep  4 05:11:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 03:11:09 +0000
Subject: [issue2322] Clean up getargs.c and its formatting possibilities
In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
Message-ID: <1220497869.15.0.389776592047.issue2322@psf.upfronthosting.co.za>


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

This was an issue created at PyCon when I just went through every single
thing I could think of. It might not even be that relevant anymore.

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

From report at bugs.python.org  Thu Sep  4 05:19:51 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 03:19:51 +0000
Subject: [issue2322] Clean up getargs.c and its formatting possibilities
In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za>
Message-ID: <1220498391.26.0.611350959712.issue2322@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

As discussed with Brett on irc, closing this.

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

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

From report at bugs.python.org  Thu Sep  4 05:22:49 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Sep 2008 03:22:49 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220498569.63.0.218269912219.issue3769@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Since SQLite has a blob type and allows text keys, we should be able to
make a substitute that doesn't depend on bsddb.

Against, recommend holding-off on removal until 3.1 so we can bake in a
reasonable substitute (esp. for shelves where dumbdbm is a really bad
fallback).

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

From report at bugs.python.org  Thu Sep  4 05:35:43 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Thu, 04 Sep 2008 03:35:43 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1220499343.64.0.888312750254.issue3594@psf.upfronthosting.co.za>


Hye-Shik Chang <hyeshik at gmail.com> added the comment:

pitrou, that's because Python source code can't be correctly tokenized 
when it's encoded in few odd encodings like iso-2022 or shift-jis which 
utilizes \, (, ) and " as second byte of two-byte character sequence.

For example, '\x81\\' is HORIZONTAL BAR in shift-jis,

exec('print "\x81\\"')

fails. because of " is ignored by second byte of '\x81\\'.

----------
nosy: +hyeshik.chang

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

From report at bugs.python.org  Thu Sep  4 05:47:15 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 04 Sep 2008 03:47:15 +0000
Subject: [issue3772] logging module fails with non-ascii data
In-Reply-To: <1220500035.76.0.111711447652.issue3772@psf.upfronthosting.co.za>
Message-ID: <1220500035.76.0.111711447652.issue3772@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

It appears r66103 introduced a regression - file objects are treated as
having an encoding, so non-ascii data fails.  It was further complicated
by the fact that file objects in 2.6 have an 'encoding' attribute, but
by default it is None - so a 'hasattr' check for encoding doesn't work
the same.

The fix is quite trivial and I also added a new test to demonstrate the
error - but for the impatient, you can reproduce it via:

import logging
log = logging.getLogger("test")
log.addHandler(logging.FileHandler("log.out"))
log.warning("foo\x80")

In all earlier versions of Python, the bytes as specified are written. 
2.6 complains that 'None' is not a valid encoding and fails to write the
record.

----------
assignee: vsajip
components: Library (Lib)
keywords: patch
messages: 72478
nosy: mhammond, vsajip
priority: release blocker
severity: normal
status: open
title: logging module fails with non-ascii data
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Sep  4 05:49:08 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 04 Sep 2008 03:49:08 +0000
Subject: [issue3772] logging module fails with non-ascii data
In-Reply-To: <1220500035.76.0.111711447652.issue3772@psf.upfronthosting.co.za>
Message-ID: <1220500148.44.0.0692906010557.issue3772@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


Added file: http://bugs.python.org/file11370/logging_encoding.patch

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

From report at bugs.python.org  Thu Sep  4 06:58:22 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 04:58:22 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1220504302.34.0.124879161155.issue1210@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Take a look at the thread here:

http://mailman2.u.washington.edu/mailman/htdig/imap-protocol/2008-February/000811.html

I think the summary is, arbitrary bytes may occur in some places, but
they're likely to be UTF-8.  Otherwise, it's mainly ASCII, but purposely
left vague to see what convention developed.

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

From report at bugs.python.org  Thu Sep  4 07:04:58 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 05:04:58 +0000
Subject: [issue3594] PyTokenizer_FindEncoding() never succeeds
In-Reply-To: <1219108779.12.0.628146919019.issue3594@psf.upfronthosting.co.za>
Message-ID: <1220504698.51.0.141001352218.issue3594@psf.upfronthosting.co.za>


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

Committed in r66209.

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

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

From report at bugs.python.org  Thu Sep  4 07:05:15 2008
From: report at bugs.python.org (Jonathan Ellis)
Date: Thu, 04 Sep 2008 05:05:15 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220504715.29.0.225903431413.issue1291446@psf.upfronthosting.co.za>


Jonathan Ellis <ellisj at users.sourceforge.net> added the comment:

This is incorrect.  Perhaps you are thinking of a raw socket read; a 
_file-like-object_ read is supposed to return the amount of data 
requested, unless (a) the socket is in non-blocking mode, or (b) if EOF 
is reached first.  Normal socket.makefile observes this, but SSLObject 
does not.

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

From report at bugs.python.org  Thu Sep  4 07:07:11 2008
From: report at bugs.python.org (Jonathan Ellis)
Date: Thu, 04 Sep 2008 05:07:11 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220504831.85.0.222642849119.issue1291446@psf.upfronthosting.co.za>


Jonathan Ellis <ellisj at users.sourceforge.net> added the comment:

s/raw socket read/raw socket recv/

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

From report at bugs.python.org  Thu Sep  4 07:15:37 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 04 Sep 2008 05:15:37 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220505337.95.0.256166943185.issue3492@psf.upfronthosting.co.za>


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

this is a very simple patch and makes sense to me.  marking it a release 
blocker and asking about it on the mailing list.  if anyone disagrees 
with this one please speak up.

in general IO input functions elsewhere return bytes().  zlib should as 
well.  this fixes that.

----------
assignee:  -> gregory.p.smith
keywords: +easy, needs review
nosy: +gregory.p.smith
priority:  -> release blocker

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

From report at bugs.python.org  Thu Sep  4 07:24:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 05:24:15 +0000
Subject: [issue3773] Check for errors
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The patch adds two lines to call_find_module() to check for errors after
calling PyTokenizer_FindEncoding() since it returns NULL as a default
value so a call to PyErr_Occurred() is needed.

----------
components: Interpreter Core
files: check_findencoding_errors.diff
keywords: patch
messages: 72484
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Check for errors
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11371/check_findencoding_errors.diff

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

From report at bugs.python.org  Thu Sep  4 08:51:25 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 06:51:25 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220511085.22.0.460545889575.issue3773@psf.upfronthosting.co.za>


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


----------
title: Check for errors -> Check for errors when using PyTokenizer_FindEncoding()

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

From report at bugs.python.org  Thu Sep  4 08:51:42 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 06:51:42 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220511102.97.0.227564845258.issue3773@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  4 08:59:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 06:59:13 +0000
Subject: [issue3473] In function call, keyword arguments could follow *args
In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za>
Message-ID: <1220511553.58.0.920876413576.issue3473@psf.upfronthosting.co.za>


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

The compiler package was fixed some time ago with r65891

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

From report at bugs.python.org  Thu Sep  4 09:32:14 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 04 Sep 2008 07:32:14 +0000
Subject: [issue3772] logging module fails with non-ascii data
In-Reply-To: <1220500035.76.0.111711447652.issue3772@psf.upfronthosting.co.za>
Message-ID: <1220513534.56.0.246940533122.issue3772@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Changes checked into trunk.

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

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

From report at bugs.python.org  Thu Sep  4 09:32:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 07:32:37 +0000
Subject: [issue1658] "RuntimeError: dictionary changed size during iteration"
	in Tkinter
In-Reply-To: <1198069697.21.0.802905521155.issue1658@psf.upfronthosting.co.za>
Message-ID: <1220513557.95.0.994259404581.issue1658@psf.upfronthosting.co.za>


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

The patch is indeed simple.

A minor stylistic remark: instead of 
    for c in classes:
        del cnf[c[0]]
it would be clearer to write
    for k, v in classes:
        del cnf[v]
like the other loop does, 3 lines after.

Please apply.

----------
keywords:  -needs review
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Thu Sep  4 11:26:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 09:26:33 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220520393.07.0.417900411319.issue3762@psf.upfronthosting.co.za>


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

The problem shows up on other platforms as well.
The following comes from a standard Debian 64bit:

$ /usr/bin/python -c "import platform; print platform.architecture()"
('64bit', '')
$ /usr/bin/python2.4 -c "import platform; print platform.architecture()"
('64bit', 'ELF')

And the patch corrects this.

----------
keywords:  -needs review
nosy: +amaury.forgeotdarc
resolution:  -> accepted

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

From report at bugs.python.org  Thu Sep  4 11:39:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 09:39:51 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220521191.13.0.196764894316.issue3773@psf.upfronthosting.co.za>


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

In PyTokenizer_FindEncoding(), PyMem_MALLOC may return NULL.
Another patch attached.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file11372/check_findencoding_malloc.diff

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

From report at bugs.python.org  Thu Sep  4 11:45:10 2008
From: report at bugs.python.org (Chris Withers)
Date: Thu, 04 Sep 2008 09:45:10 +0000
Subject: [issue3722] print followed by exception eats print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1220521510.75.0.244566924627.issue3722@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Out of interest, where are the doctest docs you quoted? I missed that
bit and that disturbs me :-S

I'm not sure documenting a bug and trying to explain it away makes it
any less of a bug, nonetheless, lets leave this one open as a feature
request then ;-)

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

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

From report at bugs.python.org  Thu Sep  4 13:13:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 11:13:11 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220526791.11.0.559383486313.issue3492@psf.upfronthosting.co.za>


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

+1 for committing.

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

From report at bugs.python.org  Thu Sep  4 13:24:17 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 04 Sep 2008 11:24:17 +0000
Subject: [issue1658] "RuntimeError: dictionary changed size during iteration"
	in Tkinter
In-Reply-To: <1198069697.21.0.802905521155.issue1658@psf.upfronthosting.co.za>
Message-ID: <1220527457.91.0.270820804396.issue1658@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Committed r66215

I've applied this only in py3k since it doesn't affect python 2.6

----------
resolution: accepted -> fixed
status: open -> closed
versions:  -Python 2.6

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

From report at bugs.python.org  Thu Sep  4 13:25:14 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Sep 2008 11:25:14 +0000
Subject: [issue3762] platform.architecture() fails if python is lanched via
	its symbolic link (cygwin)
In-Reply-To: <1220425463.91.0.558268824215.issue3762@psf.upfronthosting.co.za>
Message-ID: <1220527514.86.0.173558901997.issue3762@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66213(trunk), r66214(release-maint25), r66216(py3k).

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

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

From report at bugs.python.org  Thu Sep  4 13:26:30 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Sep 2008 11:26:30 +0000
Subject: [issue3759] test_asyncore.py leaks handle
In-Reply-To: <1220367891.09.0.578636101762.issue3759@psf.upfronthosting.co.za>
Message-ID: <1220527590.46.0.36130668361.issue3759@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
resolution: accepted -> fixed

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

From report at bugs.python.org  Thu Sep  4 13:29:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 11:29:06 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220527746.5.0.273952244513.issue3492@psf.upfronthosting.co.za>


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

Two remarks:
1. Some functions in Modules/zipimport.c (get_data) will now receive
PyBytes, but zipimporter_get_source handle them as PyByteArray. Does
zipimport still work at all with this patch?

2. There are other places where PyString_FromString was (incorrectly
IMO) replaced with PyByteArray_FromString:
- Modules/_dbmmodule.c
- Modules/mmapmodule.c
- Modules/ossaudiodev.c
- Modules/zipimport.c (as noted above)
- PC/winreg.c
- Python/marshal.c

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

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

From report at bugs.python.org  Thu Sep  4 14:03:27 2008
From: report at bugs.python.org (Baptiste Carvello)
Date: Thu, 04 Sep 2008 12:03:27 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1220529807.24.0.817838616803.issue3187@psf.upfronthosting.co.za>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

If, as I understand, it is the application's job to call listdir with
bytes or unicode depending on the platform, it might be useful to have a
function in the os module telling whether the filesystem is bytes of
unicode-native. 

That way, the idiom for doing something to all files in a given
directory would read:

>>> directory="my_direcory"
... if not os.is_filesystem_unicode():
...     directory=directory.encode(sys.stdin.encoding)
... for name in os.listdir(directory):
...     f=open(name)
... # do something
...     f.close()

and it would work on all platforms, even if one of the filenames is not
in the locale's normal encoding.

If this idiom is correct, it could also be useful to include it in the
module documentation so that application authors know what they are
supposed to do.

----------
nosy: +zegreek

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

From report at bugs.python.org  Thu Sep  4 14:17:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 12:17:58 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1220530678.92.0.105608725596.issue3618@psf.upfronthosting.co.za>


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

We might as well bite the bullet and include a short, minimalist RLock
implementation in io.py (so as not to pull threading and all its
dependencies at startup). The C version of RLock will wait for 3.1.

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

From report at bugs.python.org  Thu Sep  4 14:30:23 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Thu, 04 Sep 2008 12:30:23 +0000
Subject: [issue877121] configure detects incorrect compiler optimization
Message-ID: <1220531423.43.0.766450885568.issue877121@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

This still happens with Python 2.6b3, 3.0b3 and 2.5.2 and Sun Studio 12
on Solaris Sparc.

Like mentioned in Issue1162001, the problem seems to be, that cc returns
0 if -OPT:Olimit=0 is used:

--($ ~)-- cc  -OPT:Olimit=0 test1.c; echo $?
cc: Warning: illegal option -OPT:Olimit=0
0

--($ ~)-- gcc  -OPT:Olimit=0 test1.c; echo $?
cc1: error: invalid option argument `-OPT:Olimit=0'
1

I ran this configure:

CXX=/opt/SUNWspro/bin/CC CC=/opt/SUNWspro/bin/cc ./configure
--prefix=$HOME/.software/python-2.6b3 --disable-ipv6 --enable-shared
--without-gcc --with-threads --with-doc-strings

The prefix was always different, of course :)

--($ ~)-- gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--($ ~)-- version # for cc
Machine hardware:   sun4u
OS version:         5.10
Processor type:     sparc
Hardware:           SUNW,Sun-Fire-480R

The following components are installed on your system:


Sun Studio 12
        Sun Studio 12 C Compiler
        Sun Studio 12 C++ Compiler
        Sun Studio 12 Tools.h++ 7.1
        Sun Studio 12 C++ Standard 64-bit Class Library
        Sun Studio 12 Garbage Collector 
        Sun Studio 12 Fortran 95 
        Sun Studio 12 Debugging Tools (including dbx)
        Sun Studio 12 IDE
        Sun Studio 12 Debugger GUI
        Sun Studio 12 Performance Analyzer (including collect, ...)
        Sun Studio 12 X-Designer 
        Sun Studio 12 VIM editor
        Sun Studio 12 XEmacs editor
        Sun Studio 12 Performance Library 
        Sun Studio 12 LockLint
        Sun Studio 12 Building Software (including dmake)
        Sun Studio 12 Documentation Set

version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
SunOS_sparc Patch 124867-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9
SunOS_sparc Patch 124863-01 2007/07/25
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95
8.3 SunOS_sparc Patch 127000-01 2007/07/18
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx
Debugger 7.6 SunOS_sparc Patch 124872-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun
Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun
Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19

----------
nosy: +mschmarck
versions: +Python 2.5 -Python 2.4

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

From report at bugs.python.org  Thu Sep  4 14:30:52 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Thu, 04 Sep 2008 12:30:52 +0000
Subject: [issue877121] configure detects incorrect compiler optimization
Message-ID: <1220531452.6.0.971011906406.issue877121@psf.upfronthosting.co.za>


Changes by Michael Schmarck <michael.schmarck at habmalnefrage.de>:


----------
versions: +Python 2.4, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Sep  4 14:36:26 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Thu, 04 Sep 2008 12:36:26 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220531786.42.0.656551152186.issue3756@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

On further testing, sometimes the str version is faster, sometimes the 
bytes version is faster. Never more than about 50% one way or the 
other, so probably not worth worrying about, although I still don't 
really like the implementation. Maybe it deserves a C implementation?

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

From report at bugs.python.org  Thu Sep  4 15:00:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 04 Sep 2008 13:00:45 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1220533245.0.0.074438689173.issue2305@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Closing this item; the 2.6 "What's New" is done, except for any small
fixes that get reported.

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

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

From report at bugs.python.org  Thu Sep  4 15:06:12 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 04 Sep 2008 13:06:12 +0000
Subject: [issue2305] Update What's new in 2.6
In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za>
Message-ID: <1220533572.39.0.962510893408.issue2305@psf.upfronthosting.co.za>


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

The parse_qs() and parse_qsl() relocation from module cgi to urlparse
needs an entry in the "What's new..." (alerting you through here,
because I commited this last night).

See issue 600362 for further info, or ask me directly, :)

----------
nosy: +facundobatista

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

From report at bugs.python.org  Thu Sep  4 15:19:31 2008
From: report at bugs.python.org (skomoroh)
Date: Thu, 04 Sep 2008 13:19:31 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>


New submission from skomoroh <skomoroh at gmail.com>:

When I create a menu item without command and them remove it, I have a
error:
  File "/usr/local/lib/python3.0/tkinter/__init__.py", line 2661, in delete
    if c in self._tclCommands:
TypeError: argument of type 'NoneType' is not iterable

----------
components: Tkinter
files: menu_bug.py
messages: 72501
nosy: skomoroh
severity: normal
status: open
title: tkinter Menu.delete bug
versions: Python 3.0
Added file: http://bugs.python.org/file11373/menu_bug.py

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

From report at bugs.python.org  Thu Sep  4 15:28:39 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Sep 2008 13:28:39 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1220534919.02.0.192305290647.issue3774@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I tried, and I confirmed released python2.5.2 runs fine. and
py3k, trunk, release25-maint fails. Probably something changed after
2.5.2 release.

----------
nosy: +ocean-city
versions: +Python 2.5, Python 2.6

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

From report at bugs.python.org  Thu Sep  4 15:36:03 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 04 Sep 2008 13:36:03 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <bbaeab100809031712y6bfc1e53md15f5c28d00f7ed3@mail.gmail.com>
Message-ID: <48BFE43D.5060904@jcea.es>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brett Cannon wrote:
>> Also, the reason for removal may yet disappear
>> if jcrea steps in an continues to make updates.
> 
> OK, but none of his changes have received a code review, so if we are
> going to go down the whole "disciplined" route about it being an rc
> then we should back out all of Jesus' changes for both 2.6 and 3.0,
> which puts us back to the same instability issues.

I was wondering if somebody could write a "TO DO" list of things need to
keep bsddb in the stdlib. Then I could work to trying to comply :).

Yes, we are all very busy guys, but still...

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSL/kPZlgi5GaxT1NAQLu4AP/VSHPYOCQgQYFJsdi2MWXBpyY7TyC5XgT
Ks2uilXru/hsKQcegn8G6z/53Bt0Uu+oXZSQaZ51V8VnwDXEqaZ+GnKK+S2ky9m0
yomgMlKIZZJsOVd6X4HbLtrVYVKX8wQ224X/yCkw27OLzLIE9IDbUzEjC3+/A7mD
9IJu3B6IaLA=
=ZA8p
-----END PGP SIGNATURE-----

----------
nosy: +jcea

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

From report at bugs.python.org  Thu Sep  4 15:38:38 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 04 Sep 2008 13:38:38 +0000
Subject: [issue3671] What's New in 2.6 - corrections
In-Reply-To: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>
Message-ID: <1220535518.66.0.169362012793.issue3671@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Many of the items are fixed in rev66217; thanks!  A few of them were
fixed in the revisions I did this past weekend.

Not fixed: 

* the links for apply() and map() in the PEP 371 section.  Georg, is
there a way to override where the methods link to, or at least prevent
them from being turned into links?

* the itertools section uses the -> to indicate the resulting stream of
values; this is why those examples aren't written in the
interpreter-prompt style.  So I'm not going to change the examples by
adding list().

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

From report at bugs.python.org  Thu Sep  4 15:46:58 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 13:46:58 +0000
Subject: [issue3775] Update RELNOTES file
In-Reply-To: <1220536018.76.0.0823799232176.issue3775@psf.upfronthosting.co.za>
Message-ID: <1220536018.76.0.0823799232176.issue3775@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

The RELNOTES file should contain all, but only, the issues relevant for
the 3.0 final release.

----------
assignee: barry
messages: 72505
nosy: barry
priority: deferred blocker
severity: normal
status: open
title: Update RELNOTES file
versions: Python 3.0

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

From report at bugs.python.org  Thu Sep  4 15:49:27 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 04 Sep 2008 13:49:27 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <D4C0145D0BCC4C00B9E9743D07D330C9@RaymondLaptop1>
Message-ID: <48BFE75B.1000502@gmail.com>


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

Raymond Hettinger wrote:
> I think this should be deferred to Py3.1.
> This decision was not widely discussed and I think it likely that some
> users will
> be surprised and dismayed.  The release
> candidate seems to be the wrong time to
> yank this out (in part because of the surprise
> factor) and in part because I think the change
> silently affects shelve performance so that the
> impact may be significantly negative but not
> readily apparent.

I don't use Python for database work myself, but something I am somewhat
disappointed to lose is the presence of a moderately complicated package
within the Python distribution itself which is making use of the various
2-to-3 migration tools to support both Python 2.x and 3.x with a single
mixed Python-and-C code base (along with automatic conversion via 2to3).

While that will still be visible to some degree due to the presence of
the 2.x version of the bsddb code in Python 2.6, I don't think it will
be quite the same as it would have been with the 3.x version also being
readily available as part of the standard 3.0 install.

Regardless, given that the removal of bsddb from the 3.0 branch is now a
done deal in svn, I suggest that all we can do is monitor how much
feedback we get indicating that the need to download bsddb as a separate
install is a significant hindrance to Py3k migrations. If the feedback
indicates it is necessary, restoring the module for 3.1 certainly isn't
an impossibility, but in the meantime there *are* real benefits to
decoupling the maintenance cycles (those wanting to get the most out of
Jesus's ongoing work in exposing more of the bsddb API are probably
going to want to be using the external pybsddb releases anyway rather
than waiting however many months it ends up being until we get to 2.7/3.1).

There's also a bit of a second shot at this for bsddb supporters, in
that some of the "omnibus" Python distribution providers like
ActiveState and Enthought may choose to include pybsddb once they start
releasing bundles for Python 3.0.

As far as the corporate scenarios go: if a corporate environment is *so*
screwed up as to simultaneously permit a migration from Python 2.x to
3.0 of an internal project that relies on bsddb, while at the same time
banning those performing the migration from installing the 3.0
compatible version of pybsddb, then they have much bigger problems than
which modules and packages we are choosing to include in the standard
library. In my experience, restrictive corporate environments are far
more likely to just disallow migrations to 3.0 altogether (and in many
cases, the decision makers disallowing such migrations probably won't be
wrong - the case for migrating an existing internal app to 3.0 is far,
far weaker than that for using 3.0 for new development).

Cheers,
Nick.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu Sep  4 16:14:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 14:14:27 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1220537667.68.0.0372429876921.issue3618@psf.upfronthosting.co.za>


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

Here is a patch. The RLock implementation is naive and as simple as
possible. It doesn't solve Haypo's case, probably because the tracing
func kicks in in the RLock code itself.

I don't want to make a decision on this alone, so someone please advise.

Added file: http://bugs.python.org/file11374/rlockio.patch

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

From report at bugs.python.org  Thu Sep  4 16:16:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 14:16:46 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1220537806.66.0.483109239271.issue3618@psf.upfronthosting.co.za>


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


----------
keywords: +needs review

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

From report at bugs.python.org  Thu Sep  4 16:18:48 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Sep 2008 14:18:48 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1220537928.82.0.0528804241601.issue3774@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've not tested this so heavily, but patch could be simple.
self._tclCommands could be None, so should check it.

----------
keywords: +easy, needs review, patch
Added file: http://bugs.python.org/file11375/menu_bag.patch

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

From report at bugs.python.org  Thu Sep  4 16:28:20 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 14:28:20 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220538500.48.0.473259235986.issue3756@psf.upfronthosting.co.za>


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

I don't think there are cases where re.escape is performance critical -
are there any?
By the way, it seems to me the simplest way to write re.escape() would
be to use a regexp to do the replacement. It might or might not be the
fastest.

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

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

From report at bugs.python.org  Thu Sep  4 17:30:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 15:30:04 +0000
Subject: [issue3618] possible deadlock in IO library (Lib/io.py)
In-Reply-To: <1219230050.91.0.189582586712.issue3618@psf.upfronthosting.co.za>
Message-ID: <1220542204.39.0.611428877578.issue3618@psf.upfronthosting.co.za>


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

(I have to add that the patch makes small reads about 60-80% slower)

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

From report at bugs.python.org  Thu Sep  4 17:34:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 15:34:35 +0000
Subject: [issue3696] Error parsing arguments on OpenBSD <= 4.4
In-Reply-To: <1219818572.87.0.301585519224.issue3696@psf.upfronthosting.co.za>
Message-ID: <1220542475.38.0.249885911358.issue3696@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  4 17:54:17 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 04 Sep 2008 15:54:17 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <48BFE75B.1000502@gmail.com>
Message-ID: <48C004A4.7030103@jcea.es>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Coghlan wrote:
> While that will still be visible to some degree due to the presence of
> the 2.x version of the bsddb code in Python 2.6, I don't think it will
> be quite the same as it would have been with the 3.x version also being
> readily available as part of the standard 3.0 install.

Since 2.6 intention seems to mark this module as deprecated, I guess 2.x
bsddb presence in stock python will finish in 2.7. Moreover, I'm working
just now improving 2.x/3.x conversion code in pybsddb. I think this code
will be available in bsddb 4.7.4, and it will not be integrated in
Python 2.6 (that will include 4.7.3.minor releases, if we keep the
criteria of "only stability and security fixes in 2.6.x").

If the idea is to keep bsddb alive in 2.x, I don't see the point of not
keeping the 3.0 version, because the issues used to justify the removal
persist: I'm the only maintainer, little code review, buildbot issues, etc.

(I would like a comprehensive list, to be able to improve those
deficiencies).

In fact, if we keep bsddb in 2.x, the pressure to keep it in 3.x will be
higher.

> Regardless, given that the removal of bsddb from the 3.0 branch is now a
> done deal in svn, I suggest that all we can do is monitor how much

Any version control system can revert that with a single command :).

All I can say is that current bsddb code (in my personal repository)
passes all tests in current compiled python3.0 binary, called with the
"-bb" parameter flag (the "-bb" flag was something I learned yesterday).

> but in the meantime there *are* real benefits to
> decoupling the maintenance cycles (those wanting to get the most out of
> Jesus's ongoing work in exposing more of the bsddb API are probably
> going to want to be using the external pybsddb releases anyway rather
> than waiting however many months it ends up being until we get to 2.7/3.1).

The cycles are actually decoupled since I toke over the bsddb
maintenance (I've released a new version per month). So the release
cycles are not an issue.

The main issue here is 3.0 support, that I worked over the last couple
of months. It is done now. It couldn't be done faster because I was
learning 3.0 internals on-the-fly (there are NO docs about C module
migration; my experience there could be valuable) and 3.0 was a moving
target (still is). For example, when I left to summer holiday bsddb
worked flawless in Python 3.0b2. It failed in 3.0b3 because threading
renames done in python 3.0.

So, Python 3.0 is not waiting for bsddb to be ready, because it already
is (since yesterday). And future Python releases won't suffer because we
won't have any other major architectural reengineering of Python in a
long long time (I hope!).

That is, future Python releases would take whatever bsddb is available
at that time. No wait. No dependent release cycles. With my current
release schema of "a release per month", I can track python evolution
with little effort. For example, Python 2.5 to 2.6 was pretty painless,
even with the "PyBytes_*" ugliness.

> As far as the corporate scenarios go: if a corporate environment is *so*
> screwed up as to simultaneously permit a migration from Python 2.x to
> 3.0 of an internal project that relies on bsddb, while at the same time
> banning those performing the migration from installing the 3.0
> compatible version of pybsddb, then they have much bigger problems than
> which modules and packages we are choosing to include in the standard
> library.

Agreed. I was thinking about bsddb removal in 2.7.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSMAEnplgi5GaxT1NAQIrKgP/YAp45HUSG8Q+M355LTVqlcLMLkycpooc
fflW0MlQ3zZV307VBUbGo9urkS6h1pYhYByivApylhVqj8D4x8OEmMZk0lX8cegG
LYSBzs/sBeyxWWva6r5D9/4DsgJe9ZHqaBLMpy6ipPNVtUbMS61VTNovb3wP+f72
EnSIf9k/glM=
=QxRo
-----END PGP SIGNATURE-----

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

From report at bugs.python.org  Thu Sep  4 19:26:54 2008
From: report at bugs.python.org (Kent Johnson)
Date: Thu, 04 Sep 2008 17:26:54 +0000
Subject: [issue3671] What's New in 2.6 - corrections
In-Reply-To: <1c2a2c590809040917k393a57a5n91bdb04aebe38df@mail.gmail.com>
Message-ID: <1c2a2c590809041026r72be62e5s27f9f34cea8af5e4@mail.gmail.com>


Kent Johnson <kent at kentsjohnson.com> added the comment:

For the itertools examples, perhaps you could remove the [ ] from the
result text so it doesn't look like a list. For example:
itertools.izip_longest([1,2,3], [1,2,3,4,5]) ->
 (1, 1), (2, 2), (3, 3), (None, 4), (None, 5)

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

From report at bugs.python.org  Thu Sep  4 19:46:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 17:46:00 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220550360.49.0.406565324874.issue3773@psf.upfronthosting.co.za>


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

If PyMem_MALLOC() returns NULL, shouldn't MemoryError be set?

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

From report at bugs.python.org  Thu Sep  4 20:09:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 18:09:46 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220551786.44.0.422375333023.issue3773@psf.upfronthosting.co.za>


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

Right, here is an updated patch

Added file: http://bugs.python.org/file11376/check_findencoding_malloc.diff

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

From report at bugs.python.org  Thu Sep  4 20:10:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 18:10:07 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220551807.82.0.519192670125.issue3773@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file11372/check_findencoding_malloc.diff

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

From report at bugs.python.org  Thu Sep  4 21:40:24 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 19:40:24 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220557224.73.0.20552362179.issue3773@psf.upfronthosting.co.za>


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

Your patch looks fine, Amaury.

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

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

From report at bugs.python.org  Thu Sep  4 22:03:22 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 04 Sep 2008 20:03:22 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220558602.61.0.858885949857.issue1291446@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

The way I read the documentation, file.read() (and that's what we're
talking about) is still not guaranteed to read all the bytes of the
file.  But, you're right, that is the accepted semantics.  So the
documentation should change, too.

However, the "read" method on an SSLSocket, which is not a file()
subclass, is *not* guaranteed to return N bytes, it's guaranteed to
return at most N bytes.  Call "makefile" on SSLSocket if you need a
file-like object.

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

From report at bugs.python.org  Thu Sep  4 22:11:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 20:11:20 +0000
Subject: [issue3776] deprecate bsddb/dbhash in 2.6 for removal in 3.0
In-Reply-To: <1220559079.97.0.262960509527.issue3776@psf.upfronthosting.co.za>
Message-ID: <1220559079.97.0.262960509527.issue3776@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

This patch deprecates bsddb and dbhash for removal in Python 3.0.

----------
components: Library (Lib)
files: deprecate_bsddb.diff
keywords: needs review, patch, patch
messages: 72517
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: deprecate bsddb/dbhash in 2.6 for removal in 3.0
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11377/deprecate_bsddb.diff

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

From report at bugs.python.org  Thu Sep  4 22:14:43 2008
From: report at bugs.python.org (Jonathan Ellis)
Date: Thu, 04 Sep 2008 20:14:43 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220559283.73.0.0765581663474.issue1291446@psf.upfronthosting.co.za>


Jonathan Ellis <ellisj at users.sourceforge.net> added the comment:

Here is the exact SSLObject.read documentation from 2.5 (although the 
bug was filed against 2.4, and 2.6 will be out soon, the docs are the 
same):

-----

read([n])

If n is provided, read n bytes from the SSL connection, otherwise read 
until EOF. The return value is a string of the bytes read.

-----

This is not ambiguous.  Similarly, help(file.read) is not ambiguous.  
(The "at most" part in the first line of file.read is later explained 
to apply to non-blocking reads.)

If you want to claim "well, it's not a file-like object" then (a) it 
shouldn't have file-like methods (socket-like send and recv are the 
obvious choices instead of write and read), (b) you need to fix your 
docs.  But since god knows how many programs are out there expecting 
the semantics explained by the existing docs, I think just fixing the 
bug in the code is better than defining away the problem.

(Obviously socket.makefile won't work on an object that doesn't 
implement a socket-like interface, so that's a non-option.)

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

From report at bugs.python.org  Thu Sep  4 22:49:17 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 04 Sep 2008 20:49:17 +0000
Subject: [issue3777] PyNumber_Long fails from Float
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

I am testing PySVN against python2.6b3.

I see a failure when PyNumber_Long is called with a Float.
It raises TypeError.

The same code works on 2.3, 2.4 and 2.5.

Looking with GDB I see:

(gdb) bt
#0  PyNumber_Long (o=0x1809384) at Objects/abstract.c:1735
#1  0x020f8e70 in Py::Long::Long (this=0xbfffefc8, ob=@0xbfffefc0) at
pysvn_client_cmd_list.cpp:739

1681            m = o->ob_type->tp_as_number;
1682            if (m && m->nb_long) { /* This should include subclasses
of long */
1683                    /* Classic classes always take this branch. */
1684                    PyObject *res = m->nb_long(o);
1685                    if (res && (!PyInt_Check(res) &&
!PyLong_Check(res))) {

res does not contain the value that nb_long(o) calculated.
and the if on 1685 is false so you get a type error.

I have compiled on Mac OS X 10.4 powerpc and fedora 8 x86.
Both fail in the exact same way.

If you need to reproduce you will need to build pysvn and
run a command that triggers the problem. I don't have a
smaller example.

----------
components: None
messages: 72519
nosy: barry-scott
severity: normal
status: open
title: PyNumber_Long fails from Float
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Sep  4 23:08:14 2008
From: report at bugs.python.org (donovaly)
Date: Thu, 04 Sep 2008 21:08:14 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>


New submission from donovaly <uwestoehr at web.de>:

- install Python 2.5.2 using the Windows installer
- now uninstall Python

Result: The uninstaller doesn't remove the registry folder
HKLM\SOFTWARE\Python
and all its subfolders.

----------
components: Installation
messages: 72520
nosy: donovaly
severity: normal
status: open
title: python uninstaller leave registry entries
versions: Python 2.5

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

From report at bugs.python.org  Thu Sep  4 23:11:06 2008
From: report at bugs.python.org (donovaly)
Date: Thu, 04 Sep 2008 21:11:06 +0000
Subject: [issue3779] log into bugs.python.org requires cookies
In-Reply-To: <1220562666.72.0.63652264802.issue3779@psf.upfronthosting.co.za>
Message-ID: <1220562666.72.0.63652264802.issue3779@psf.upfronthosting.co.za>


New submission from donovaly <uwestoehr at web.de>:

I tried to log into this issue tracker several times without success.
Now I found out by chance that I need to allow to set browser cookies to
be able to log in.
So please display a message that one needs to allows cookies to log in.

----------
messages: 72521
nosy: donovaly
severity: normal
status: open
title: log into bugs.python.org requires cookies

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

From report at bugs.python.org  Thu Sep  4 23:12:52 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 04 Sep 2008 21:12:52 +0000
Subject: [issue3776] deprecate bsddb/dbhash in 2.6 for removal in 3.0
In-Reply-To: <1220559079.97.0.262960509527.issue3776@psf.upfronthosting.co.za>
Message-ID: <1220562772.4.0.292069434794.issue3776@psf.upfronthosting.co.za>


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

Attached patch raises Py3k warnings rather than plain deprecation
warnings, so it looks good to me (some of the discussions on python-dev
gave the impression that may have been getting full deprecation
warnings, implying its potential removal in 2.7 as well).

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu Sep  4 23:13:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 21:13:02 +0000
Subject: [issue3779] log into bugs.python.org requires cookies
In-Reply-To: <1220562666.72.0.63652264802.issue3779@psf.upfronthosting.co.za>
Message-ID: <1220562782.4.0.846968735446.issue3779@psf.upfronthosting.co.za>


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

This should be reported to the meta tracker:
http://psf.upfronthosting.co.za/roundup/meta/.

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

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

From report at bugs.python.org  Thu Sep  4 23:29:05 2008
From: report at bugs.python.org (donovaly)
Date: Thu, 04 Sep 2008 21:29:05 +0000
Subject: [issue3779] log into bugs.python.org requires cookies
In-Reply-To: <1220562666.72.0.63652264802.issue3779@psf.upfronthosting.co.za>
Message-ID: <1220563745.84.0.322166799749.issue3779@psf.upfronthosting.co.za>


donovaly <uwestoehr at web.de> added the comment:

Closing the bug report is not correct. When my installation failed, I
need an info that cookies could cause the problem. This info has to be
given on your webpage, so it's your turn!

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

From report at bugs.python.org  Thu Sep  4 23:31:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 21:31:09 +0000
Subject: [issue3779] log into bugs.python.org requires cookies
In-Reply-To: <1220563745.84.0.322166799749.issue3779@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809041431s720e3004o84368f6896b08518@mail.gmail.com>


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

On Thu, Sep 4, 2008 at 4:29 PM, donovaly <report at bugs.python.org> wrote:
>
> donovaly <uwestoehr at web.de> added the comment:
>
> Closing the bug report is not correct. When my installation failed, I
> need an info that cookies could cause the problem. This info has to be
> given on your webpage, so it's your turn!

Please trust our knowledge of how to use the tracker! Your bug report
is about the tracker not Python, so it should be brought to the URL I
gave above.

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

From report at bugs.python.org  Thu Sep  4 23:32:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 21:32:57 +0000
Subject: [issue3160] Building a Win32 binary installer crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1220563977.23.0.614037743083.issue3160@psf.upfronthosting.co.za>


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

Fixed in r66223.

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

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

From report at bugs.python.org  Thu Sep  4 23:38:53 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 21:38:53 +0000
Subject: [issue3776] deprecate bsddb/dbhash in 2.6 for removal in 3.0
In-Reply-To: <1220559079.97.0.262960509527.issue3776@psf.upfronthosting.co.za>
Message-ID: <1220564333.99.0.787993748068.issue3776@psf.upfronthosting.co.za>


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

Sorry if that impression was given about 2.6 deprecation. The plan was
always just for 3.0 removal since removing in 2.6 really would not be
enough time to warn users.

I have assigned to myself to apply the patch when I have time (some time
tonight).

Thanks for the review, Nick!

----------
assignee:  -> brett.cannon

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

From report at bugs.python.org  Thu Sep  4 23:54:51 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 21:54:51 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220565291.47.0.156386503282.issue3758@psf.upfronthosting.co.za>


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

OK, I am going to go with ``make patchcheck`` since that is the script's
name and the command does nothing but execute the script.

I will wait until after rc1 to deal with this.

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

From report at bugs.python.org  Thu Sep  4 23:56:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 21:56:05 +0000
Subject: [issue3777] PyNumber_Long fails from Float
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220565365.34.0.487208414778.issue3777@psf.upfronthosting.co.za>


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

Note to others: PySvn uses the PyCXX classes. The call in question is
something similar to
   Py::Long( Py::Float( double( someValue ) ) )

Barry, what is the exact error message that you get?
What do you mean by "res does not contain the value that nb_long(o)
calculated" ?
And what is the exact content of the "o" variable at the time of the
failure? (you could look for example at o->ob_type->tp_name)

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

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

From report at bugs.python.org  Thu Sep  4 23:59:47 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Sep 2008 21:59:47 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

In Python 2.5 and earlier, the `warnings.warn_explicit` function could
be replaced in order to test what warnings were emitted by some code. 
This allowed unit tests for warnings to be written.  Since much of the
warnings module was re-implemented in C, replacing
`warnings.warn_explicit` no longer has any effect.  This, together with
the fact that there are no other public APIs for hooking into the
warning system with duplication suppression disabled means that there is
no reliable way to write unit tests for warnings.

This was previously discussed on python-dev, but no conclusion was
reached.  See
http://mail.python.org/pipermail/python-dev/2008-June/080635.html and
the follow-ups.

For Twisted, the consequence of this is roughly 79 failing unit tests in
Python 2.6b3 and no clear way to fix them, except to stop using the
standard library warnings module.

----------
components: Library (Lib)
messages: 72530
nosy: exarkun
severity: normal
status: open
title: No way to write unit tests for warnings
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Sep  5 00:08:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 04 Sep 2008 22:08:20 +0000
Subject: [issue1638033] Add httponly to Cookie module
Message-ID: <1220566100.06.0.692821591484.issue1638033@psf.upfronthosting.co.za>


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

To be honest, I don't see any harm in adding this now, especially since
rc1 hasn't been released yet.

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Fri Sep  5 00:08:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 22:08:30 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220566110.28.0.947650175558.issue3780@psf.upfronthosting.co.za>


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

Would the new catch_warnings [1] context manager help in this regard?

[1] http://docs.python.org/dev/library/warnings.html#warnings.catch_warnings

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

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

From report at bugs.python.org  Fri Sep  5 00:10:09 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Sep 2008 22:10:09 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

This example shows the behavior:

    from warnings import catch_warnings

    def test():
        with catch_warnings(True) as w:
            assert str(w.message) == "foo", "%r != %r" % (w.message, "foo")

    test()

This fails with an IndexError from the `w.message`.  That's a bit
surprising, and since this is mostly an API useful for testing, it'd be
much better if it had a well-defined, documented (ie, stable and likely
to continue working in the next release of Python) error mode.

----------
components: Library (Lib)
messages: 72533
nosy: exarkun
severity: normal
status: open
title: warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Sep  5 00:11:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 22:11:23 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220566283.68.0.980077763116.issue3781@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

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

From report at bugs.python.org  Fri Sep  5 00:13:48 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 04 Sep 2008 22:13:48 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220566428.28.0.0275338540854.issue3780@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Fri Sep  5 00:22:33 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 22:22:33 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809041522h2bc74ddfl2c920be5b308ccb5@mail.gmail.com>


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

On Thu, Sep 4, 2008 at 3:10 PM, Jean-Paul Calderone
<report at bugs.python.org> wrote:
>
> New submission from Jean-Paul Calderone <exarkun at divmod.com>:
>
> This example shows the behavior:
>
>    from warnings import catch_warnings
>
>    def test():
>        with catch_warnings(True) as w:
>            assert str(w.message) == "foo", "%r != %r" % (w.message, "foo")
>
>    test()
>
> This fails with an IndexError from the `w.message`.  That's a bit
> surprising, and since this is mostly an API useful for testing, it'd be
> much better if it had a well-defined, documented (ie, stable and likely
> to continue working in the next release of Python) error mode.
>

The question is what exception to raise when no warning has been
recorded. AttributeError goes with the idea that the attributes are
just not set since no warnings are there to set the attributes.
LookupError doesn't seem quite right. TypeError is definitely wrong
since it has nothing to do with the type of anything.

So unless someone comes up with a better suggestion I will change
__getattr__ on catch_warnings to raise AttributeError when IndexError
is raised because no warning is currently recorded.

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

From report at bugs.python.org  Fri Sep  5 00:30:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 22:30:58 +0000
Subject: [issue1638033] Add httponly to Cookie module
Message-ID: <1220567458.48.0.15829229367.issue1638033@psf.upfronthosting.co.za>


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

Well, if it's to be added then the patch should be updated to use reST.

----------
nosy: +benjamin.peterson
versions: +Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Sep  5 00:36:43 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 22:36:43 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220567803.84.0.868856417291.issue3780@psf.upfronthosting.co.za>


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

It sounds like you are trying to get around "once"/"default" rules to
see all warnings raised. Why can't you use catch_warnings() and do
``simplefilter("always")`` or use "error"? Otherwise you can force the
importing and use of the pure Python implementation of warnings if you
really want to continue to use your hacked version of warn_explicit (see
test_warnings on how to control whether the C implementation gets used
or not).

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Fri Sep  5 00:41:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 22:41:35 +0000
Subject: [issue3782] os.write accepts unicode strings
In-Reply-To: <1220568095.62.0.876870722017.issue3782@psf.upfronthosting.co.za>
Message-ID: <1220568095.62.0.876870722017.issue3782@psf.upfronthosting.co.za>


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

I'm a bit puzzled that both str and bytes are accepted by os.write() in
py3k:

>>> os.write(1, "foo\n")
foo
4
>>> os.write(1, b"foo\n")
foo
4

----------
components: Interpreter Core
messages: 72537
nosy: pitrou
priority: high
severity: normal
status: open
title: os.write accepts unicode strings
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Sep  5 00:43:49 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 04 Sep 2008 22:43:49 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1220568229.61.0.312845962344.issue3645@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

may issue 1204 is more general

----------
nosy: +rpetrov

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

From report at bugs.python.org  Fri Sep  5 00:43:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 22:43:50 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220568230.9.0.358861754381.issue3773@psf.upfronthosting.co.za>


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

I think this patch should be reverted. It causes a linking error because
pgen isn't linked to libpython; it doesn't find the _PyErr_NoMemory symbol.

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

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

From report at bugs.python.org  Fri Sep  5 00:47:07 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Sep 2008 22:47:07 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220568427.75.0.490051179145.issue3780@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I was aware of it, but I didn't realize adding an "always" filter would
make sure all warnings always got noticed.  I haven't tried changing
Twisted's use of the warnings module yet, but it looks like
`catch_warnings` will work here.

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

From report at bugs.python.org  Fri Sep  5 00:48:09 2008
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Thu, 04 Sep 2008 22:48:09 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220568489.46.0.142769200528.issue3780@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at divmod.com> added the comment:

Looks like we just misunderstood the way the warnings filter works, and
catch_warnings' interaction with it.  Thanks for the priority bump,
guido, and sorry for the false alarm!

----------
nosy: +glyph
status: open -> closed

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

From report at bugs.python.org  Fri Sep  5 00:48:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 22:48:16 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220568496.08.0.949494393049.issue3773@psf.upfronthosting.co.za>


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

pgen does not exist on Windows...

What if I simply remove the call to PyErr_NoMemory?
It is not strictly necessary: the function already returns NULL without
an exception set, for example when the file cannot be opened.

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

From report at bugs.python.org  Fri Sep  5 00:49:31 2008
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Thu, 04 Sep 2008 22:49:31 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220568571.15.0.725301639821.issue3780@psf.upfronthosting.co.za>


Changes by Glyph Lefkowitz <glyph at divmod.com>:


----------
resolution:  -> invalid

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

From report at bugs.python.org  Fri Sep  5 00:50:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 22:50:16 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220568496.08.0.949494393049.issue3773@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809041550g438199fal2cd528f46b60ffb5@mail.gmail.com>


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

On Thu, Sep 4, 2008 at 5:48 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> pgen does not exist on Windows...
>
> What if I simply remove the call to PyErr_NoMemory?
> It is not strictly necessary: the function already returns NULL without
> an exception set, for example when the file cannot be opened.

That sounds ok. I can't remember what the rest of the parse does when
there's no memory, though.

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

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

From report at bugs.python.org  Fri Sep  5 00:52:29 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Sep 2008 22:52:29 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220568749.2.0.018318616499.issue3781@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

The specific exception type isn't that important to me, as long as I can
rely on it being something in particular.

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

From report at bugs.python.org  Fri Sep  5 00:52:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 22:52:59 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220568779.43.0.82012600278.issue3773@psf.upfronthosting.co.za>


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

You could also surround the PyErr_NoMemory with #ifndef PGEN.

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

From report at bugs.python.org  Fri Sep  5 00:55:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 22:55:57 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220568957.65.0.348800629061.issue874900@psf.upfronthosting.co.za>


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

Ok, with this patch the test passes under py3k.

Apart from the trivial typo (_Thread__stopped -> _stopped), I had to
change print("...") to os.write(1, b"...\n") in the tests as otherwise
subprocess wouldn't receive any output from the third test (buffering
problem? I don't know really).

I also added the ident fix I had already suggested in _after_fork(). If
you put a print statement at this point you'll see the old and the new
value are not the same.

----------
keywords: +needs review
Added file: http://bugs.python.org/file11378/forkthread.patch

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

From report at bugs.python.org  Fri Sep  5 00:56:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 22:56:50 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220569010.62.0.301820956573.issue3781@psf.upfronthosting.co.za>


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

I won't be able to get to this until tonight, but assuming no one
objects, I will make it be an AttributeError and a release blocker so
that the API can be considered stable in rc1.

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

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

From report at bugs.python.org  Fri Sep  5 00:58:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 22:58:22 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220568489.46.0.142769200528.issue3780@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809041558p4f6afc0fxd87557b4d59feaf2@mail.gmail.com>


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

On Thu, Sep 4, 2008 at 3:48 PM, Glyph Lefkowitz <report at bugs.python.org> wrote:
>
> Glyph Lefkowitz <glyph at divmod.com> added the comment:
>
> Looks like we just misunderstood the way the warnings filter works, and
> catch_warnings' interaction with it.  Thanks for the priority bump,
> guido, and sorry for the false alarm!
>

If there is a doc problem, please suggest some better wording! I
tossed the text together the best I could but if it needs improvement
I welcome suggestions.

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

From report at bugs.python.org  Fri Sep  5 01:01:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 23:01:57 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220569317.61.0.0122416321408.issue874900@psf.upfronthosting.co.za>


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

I feel like that patch sort of avoids the problem by changing the test.
The test is hanging for some reason, so we should try to fix that, not
the test. :) I wonder if it has something to do with the various
deadlocks we are discovering in the io library.

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

From report at bugs.python.org  Fri Sep  5 01:08:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 23:08:19 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220569699.08.0.641698428915.issue874900@psf.upfronthosting.co.za>


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

Benjamin, if you don't change the test, the deadlock problem is still
solved, it's just that the third test fails because the subprocess
stdout is empty instead of containing the desired value. It is *not*
because the subprocess doesn't print anything (if you launch an
equivalent program on the command line, everything is printed), rather
it seems that subprocess doesn't get what is printed from the child
process of the subprocess.

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

From report at bugs.python.org  Fri Sep  5 01:09:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Sep 2008 23:09:54 +0000
Subject: [issue874900] threading module can deadlock after fork
In-Reply-To: <1220569699.08.0.641698428915.issue874900@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809041609h36c3fb92q7c97f630ef2bfa9c@mail.gmail.com>


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

On Thu, Sep 4, 2008 at 6:08 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Benjamin, if you don't change the test, the deadlock problem is still
> solved, it's just that the third test fails because the subprocess
> stdout is empty instead of containing the desired value. It is *not*
> because the subprocess doesn't print anything (if you launch an
> equivalent program on the command line, everything is printed), rather
> it seems that subprocess doesn't get what is printed from the child
> process of the subprocess.

Ah! My apologies for the giant misunderstanding.

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

From report at bugs.python.org  Fri Sep  5 01:16:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 23:16:00 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220570160.96.0.462516426092.issue874900@psf.upfronthosting.co.za>


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

Instead of os.write(), it is actually sufficient to sys.stdout.flush()
at the end of the subprocess. Patch attached.

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

From report at bugs.python.org  Fri Sep  5 01:17:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 23:17:40 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220570260.06.0.172407070645.issue874900@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file11379/forkthread2.patch

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

From report at bugs.python.org  Fri Sep  5 01:18:00 2008
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Thu, 04 Sep 2008 23:18:00 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220565587.27.0.0684560509319.issue3780@psf.upfronthosting.co.za>
Message-ID: <1220570280.68.0.537640694484.issue3780@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at divmod.com> added the comment:

The use of the term "filter" is pretty confusing.  I would normally say
it was just me, but a bunch of other Twisted hackers seemed to interpret
it the same way: a "filter" is something that has an opportunity to
remove something else.  For example, the python builtin function
"filter".  Experimentation with the filters list seems to confirm this
impression, since later filters do not have an opportunity to access the
warnings that earlier filters have removed.  The intuitive leap there is
to assume that inserting a filter at the head of the list won't do
anything different than inserting it at the tail, since a later filter
will remove it.

I can't think of an obvious recommendation to improve the text for the
filter system itself, because upon reading it in more depth, it's fairly
clear.  Maybe the heading could be changed to something more like
"intercepting warnings" or "controlling the way that warnings are
emitted"?  Something attention-grabbing that describes its purpose and
doesn't use the word "filter".  Even a sub-heading which simply
described how to use 'always'   filter to cause every warning to be
emitted would be helpful.

The biggest improvement to the documentation for "catch_warnings" would
be to put it in a section of its own, "How To Test Your Code Which Uses
Warnings", not as a footnote in "Available Classes".

(Also, as a minor note to be taken at your discretion: should
catch_warnings be named PEP 8 style as a class, since it is one?  I
don't really want to open that can of worms after reading the
interminable threading.Event thread, but it seemed worth saying as long
as was talking about this...)

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

From report at bugs.python.org  Fri Sep  5 01:24:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Sep 2008 23:24:34 +0000
Subject: [issue3773] Check for errors when using PyTokenizer_FindEncoding()
In-Reply-To: <1220505855.09.0.750309464395.issue3773@psf.upfronthosting.co.za>
Message-ID: <1220570674.89.0.117075146848.issue3773@psf.upfronthosting.co.za>


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

committed r66224 + r66225.

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

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

From report at bugs.python.org  Fri Sep  5 01:25:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 23:25:38 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220570738.9.0.950464912659.issue3781@psf.upfronthosting.co.za>


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

Why wouldn't w.message simply be None?

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

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

From report at bugs.python.org  Fri Sep  5 01:57:32 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 04 Sep 2008 23:57:32 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

Based on recent discussions about ridding Python of bsddb I decided to
see how hard it would be to implement a barebones dbm.sqlite module.
Turns out, not very hard.

No docs.  No test cases.  Caveat emptor.  But I think it can serve as
at least a proof of concept, maybe as the basis for a new module in
3.1.

----------
components: Library (Lib)
files: sqlite.py
keywords: patch
messages: 72556
nosy: skip.montanaro
severity: normal
status: open
title: dbm.sqlite proof of concept
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file11380/sqlite.py

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

From report at bugs.python.org  Fri Sep  5 02:01:38 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 00:01:38 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <18623.19290.526874.362918@montanaro-dyndns-org.local>
Message-ID: <18624.30425.279102.297960@montanaro-dyndns-org.local>


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

me> If not, could a dbm.sqlite module be written for 2.7 and 3.1 which
    me> can fill that role?

http://bugs.python.org/issue3783

S

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

From report at bugs.python.org  Fri Sep  5 02:04:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 00:04:01 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220573041.82.0.0678198770798.issue3660@psf.upfronthosting.co.za>


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

The patch for _pickle has been committed in r66227.

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

From report at bugs.python.org  Fri Sep  5 02:07:58 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Sep 2008 00:07:58 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220573277.94.0.109669332706.issue3492@psf.upfronthosting.co.za>


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

Correct, zipimport required fixing in order for this to work.  The newly
attached zlib-and-zipimport-gps01 patch.

review at http://codereview.appspot.com/4454

I haven't had a chance to look at the other modules Amaury mentioned but
on general principal I agree, they should return bytes.

Added file: http://bugs.python.org/file11381/zlib-and-zipimport-bytes-gps01.patch

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

From report at bugs.python.org  Fri Sep  5 02:44:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 00:44:57 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220575497.84.0.991790683243.issue3660@psf.upfronthosting.co.za>


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

Numbers for the current py3k branch (without encode-leak2.patch):

test_distutils leaked [141, 142] references, sum=283
test_docxmlrpc leaked [-7, -85] references, sum=-92
test_logging leaked [0, 219] references, sum=219
test_poplib leaked [0, 84] references, sum=84
test_sys leaked [0, 34] references, sum=34
test_unicode leaked [1, 1] references, sum=2
test_urllib2_localnet leaked [3, 3] references, sum=6
test_xmlrpc leaked [192, -190] references, sum=2

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

From report at bugs.python.org  Fri Sep  5 04:56:16 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Fri, 05 Sep 2008 02:56:16 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1220575497.84.0.991790683243.issue3660@psf.upfronthosting.co.za>
Message-ID: <ee2a432c0809041956o7c09089axf2b60a37beb4b1d7@mail.gmail.com>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

The only one that is probably an issue based on Antoine's info is:

test_unicode leaked [1, 1] references, sum=2

I've seen test_urllib2_localnet leak 3 before.  I don't know that it's
a real leak.  I'm pretty sure it is not a regression though.

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

From report at bugs.python.org  Fri Sep  5 05:39:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 03:39:47 +0000
Subject: [issue3780] No way to write unit tests for warnings
In-Reply-To: <1220570280.68.0.537640694484.issue3780@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809042039i19c96791k561c9fabecbc856a@mail.gmail.com>


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

On Thu, Sep 4, 2008 at 4:18 PM, Glyph Lefkowitz <report at bugs.python.org> wrote:
>
> Glyph Lefkowitz <glyph at divmod.com> added the comment:
>
> The use of the term "filter" is pretty confusing.  I would normally say
> it was just me, but a bunch of other Twisted hackers seemed to interpret
> it the same way: a "filter" is something that has an opportunity to
> remove something else.  For example, the python builtin function
> "filter".  Experimentation with the filters list seems to confirm this
> impression, since later filters do not have an opportunity to access the
> warnings that earlier filters have removed.  The intuitive leap there is
> to assume that inserting a filter at the head of the list won't do
> anything different than inserting it at the tail, since a later filter
> will remove it.
>

OK, so you were thinking of the filter list in a functional sense
where exceptions are passed down the chain to each filter rule instead
of a bunch of tests that stop checking once one of the rules applies.

> I can't think of an obvious recommendation to improve the text for the
> filter system itself, because upon reading it in more depth, it's fairly
> clear.  Maybe the heading could be changed to something more like
> "intercepting warnings" or "controlling the way that warnings are
> emitted"?  Something attention-grabbing that describes its purpose and
> doesn't use the word "filter".  Even a sub-heading which simply
> described how to use 'always'   filter to cause every warning to be
> emitted would be helpful.
>

OK.

> The biggest improvement to the documentation for "catch_warnings" would
> be to put it in a section of its own, "How To Test Your Code Which Uses
> Warnings", not as a footnote in "Available Classes".
>

Fair enough.

> (Also, as a minor note to be taken at your discretion: should
> catch_warnings be named PEP 8 style as a class, since it is one?  I
> don't really want to open that can of worms after reading the
> interminable threading.Event thread, but it seemed worth saying as long
> as was talking about this...)

It's partially historical since test.test_support.catch_warning() is a
context manager created from a generator. But it's also because I want
to have the option to change the context manager in the future if the
bootstrapping reasons that led to it being a class can go away. I
should probably change the section title to "Available Context
Managers" so people don't start making assumptions.

-Brett

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

From report at bugs.python.org  Fri Sep  5 05:59:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 03:59:15 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220587155.58.0.763040899303.issue3781@psf.upfronthosting.co.za>


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

There is no specific reason why it would be, although that is an option
as well. Part of the problem with None is that it is a legitimate
default value for some arguments to showwarning() so it doesn't
necessarily reflect that no exception was raised if you don't look at
key attributes.

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

From report at bugs.python.org  Fri Sep  5 06:12:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 04:12:00 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220587920.28.0.863516835295.issue3781@psf.upfronthosting.co.za>


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

The attached patch has WarningsRecorder raise AttributeError when there
is no recorded attribute and yet one tries to access warnings attributes.

And just so you know, JP, make sure to use keyword arguments when
calling catch_warnings() (in case you didn't notice the note in the
docs). In Py3K they are keyword-only.

----------
assignee: brett.cannon -> 
keywords: +needs review, patch
Added file: http://bugs.python.org/file11382/catch_warnings_atts.diff

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

From report at bugs.python.org  Fri Sep  5 06:44:29 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 04:44:29 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220589869.53.0.951827738534.issue3783@psf.upfronthosting.co.za>


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

Attaching corrected module.

Added file: http://bugs.python.org/file11383/sqlite.py

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

From report at bugs.python.org  Fri Sep  5 06:44:37 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 04:44:37 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220589877.48.0.123464757017.issue3783@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file11380/sqlite.py

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

From report at bugs.python.org  Fri Sep  5 06:45:21 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 04:45:21 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220589921.76.0.963175262024.issue3783@psf.upfronthosting.co.za>


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

Attaching test cases based on dumbdbm tests.

Added file: http://bugs.python.org/file11384/test_dbm_sqlite.py

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

From report at bugs.python.org  Fri Sep  5 06:54:42 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 04:54:42 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220590482.48.0.794356284995.issue3783@psf.upfronthosting.co.za>


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

Another slight revision to the module.

Added file: http://bugs.python.org/file11385/sqlite.py

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

From report at bugs.python.org  Fri Sep  5 06:54:47 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 04:54:47 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220590487.77.0.758283330573.issue3783@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file11383/sqlite.py

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

From report at bugs.python.org  Fri Sep  5 06:55:57 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 04:55:57 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220590557.97.0.405137502399.issue3783@psf.upfronthosting.co.za>


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

Trivial doc diffs against 3.0b3 doc.

Added file: http://bugs.python.org/file11386/dbm.diff

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

From report at bugs.python.org  Fri Sep  5 07:00:54 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 05:00:54 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220590854.4.0.698878968043.issue3783@psf.upfronthosting.co.za>


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

Another tweak - add values()

Added file: http://bugs.python.org/file11387/sqlite.py

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

From report at bugs.python.org  Fri Sep  5 07:02:13 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 05:02:13 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220590933.55.0.142392638629.issue3783@psf.upfronthosting.co.za>


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

Updated test cases

Added file: http://bugs.python.org/file11388/test_dbm_sqlite.py

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

From report at bugs.python.org  Fri Sep  5 07:02:20 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 05:02:20 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220590940.08.0.767054080479.issue3783@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file11384/test_dbm_sqlite.py

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

From report at bugs.python.org  Fri Sep  5 07:02:25 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 05:02:25 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220590945.46.0.965348926512.issue3783@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file11385/sqlite.py

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

From report at bugs.python.org  Fri Sep  5 07:50:49 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 05 Sep 2008 05:50:49 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220593849.41.0.891066067484.issue3492@psf.upfronthosting.co.za>


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

Does py3k list/barry have this bug in their radar for rc2 ?

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

From report at bugs.python.org  Fri Sep  5 07:56:37 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 05 Sep 2008 05:56:37 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220594197.29.0.534261472391.issue3492@psf.upfronthosting.co.za>


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

On Thu, Sep 4, 2008 at 4:59 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Two remarks:
> 1. Some functions in Modules/zipimport.c (get_data) will now receive
> PyBytes, but zipimporter_get_source handle them as PyByteArray. Does
> zipimport still work at all with this patch?
>
> 2. There are other places where PyString_FromString was (incorrectly
> IMO) replaced with PyByteArray_FromString:
> - Modules/_dbmmodule.c
> - Modules/mmapmodule.c
> - Modules/ossaudiodev.c
> - Modules/zipimport.c (as noted above)
> - PC/winreg.c
> - Python/marshal.c

Hmmm...but AFAIK zlib changes only affect zipimport directly. I wonder
whether these other instances have bugs reported and are being tracked
for the release.

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

From report at bugs.python.org  Fri Sep  5 09:05:28 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Fri, 05 Sep 2008 07:05:28 +0000
Subject: [issue3597] Allow application developers to select ciphers,
	and default to strong in ssl lib
In-Reply-To: <1219117091.2.0.876896713341.issue3597@psf.upfronthosting.co.za>
Message-ID: <1220598328.06.0.93967704392.issue3597@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

Yeah, compatibility can be a problem. The cipher list I used for
M2Crypto was recommended in the book Network Security with OpenSSL (I
think). Besides removing unsafe ciphers, it orders the remaining ciphers
from strongest to weakest, based on the hope/assumption/practice that
peers will hopefully select the first matching cipher. It is not
foolproof, though, so for truly compatible application you'd probably
need to try with different ciphers lists if you run into errors.
However, I have never run into a problem myself with that list, nor has
anyone reported any bugs against M2Crypto because of that.

Defaulting to TLSv1 should select a better cipher list than otherwise,
but I would be a bit concerned about that in turn being an even bigger
compatibility issue. I guess I could ask around.

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

From report at bugs.python.org  Fri Sep  5 09:11:57 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Fri, 05 Sep 2008 07:11:57 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1220598717.87.0.448512833707.issue1589@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

Could you clarify your comment regarding hostname check being false
security?

Just about all SSL texts I have read say you must do that, and that is
what your web browser and email client does to ensure it is talking to
the right host, for example. Without that check you are subject to a man
in the middle attack. Or is there some other check you perform that is
better?

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

From report at bugs.python.org  Fri Sep  5 09:41:51 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 07:41:51 +0000
Subject: [issue3784] Incorrect compiler options used for cc of Sun Studio 12
In-Reply-To: <1220600511.19.0.379971962657.issue3784@psf.upfronthosting.co.za>
Message-ID: <1220600511.19.0.379971962657.issue3784@psf.upfronthosting.co.za>


New submission from Michael Schmarck <michael.schmarck at habmalnefrage.de>:

While compiling Python 2.5.2, I stumbled upon this:

cc -G -R/export/home/webservd/.software/Python-2.5.2/lib
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v9.o
-L/export/home/webservd/.software/Python-2.5.2/lib -L/usr/local/lib
-lpython2.5 -o build/lib.solaris-2.10-sun4u-2.5/_ctypes.so -mimpure-text
cc: Warning: illegal option -mimpure-text


--($ ~/Source)-- CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25

--($ ~/Source)-- cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
usage: cc [ options] files.  Use 'cc -flags' for details

This is cc/CC from Sun Studio 12 on a Solaris 10 U5 Sparc system.

-mimpure-text is a gcc option.

----------
components: Installation
messages: 72575
nosy: mschmarck
severity: normal
status: open
title: Incorrect compiler options used for cc of Sun Studio 12
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Fri Sep  5 09:48:43 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 07:48:43 +0000
Subject: [issue3785] Can't build ctypes of Python 2.5.2 with Sun Studio 12
In-Reply-To: <1220600923.37.0.208591240416.issue3785@psf.upfronthosting.co.za>
Message-ID: <1220600923.37.0.208591240416.issue3785@psf.upfronthosting.co.za>


New submission from Michael Schmarck <michael.schmarck at habmalnefrage.de>:

Compilation of ctypes fails:


cc -G
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v9.o
-L/export/home/webservd/.software/Python-2.5.2/lib -L/usr/local/lib
-lpython2.5 -o build/lib.solaris-2.10-sun4u-2.5/_ctypes.so -mimpure-text
cc: Warning: illegal option -mimpure-text
*** WARNING: renaming "_ctypes" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-sun4u-2.5/_ctypes.so: symbol alloca: referenced
symbol not found
running build_scripts


To configure Python 2.5.2, I ran:

./configure --disable-ipv6 --enable-shared --without-gcc --with-threads
--with-doc-strings --prefix=$HOME/.software/Python-2.5.2

Versions:

--($ ~/Source/Python-2.5.2)-- CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25

--($ ~/Source/Python-2.5.2)-- cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
usage: cc [ options] files.  Use 'cc -flags' for details

--($ ~/Source/Python-2.5.2)-- /opt/SUNWspro/bin/version
Machine hardware:   sun4u
OS version:         5.10
Processor type:     sparc
Hardware:           SUNW,Sun-Fire-480R

The following components are installed on your system:


Sun Studio 12
        Sun Studio 12 C Compiler
        Sun Studio 12 C++ Compiler
        Sun Studio 12 Tools.h++ 7.1
        Sun Studio 12 C++ Standard 64-bit Class Library
        Sun Studio 12 Garbage Collector 
        Sun Studio 12 Fortran 95 
        Sun Studio 12 Debugging Tools (including dbx)
        Sun Studio 12 IDE
        Sun Studio 12 Debugger GUI
        Sun Studio 12 Performance Analyzer (including collect, ...)
        Sun Studio 12 X-Designer 
        Sun Studio 12 VIM editor
        Sun Studio 12 XEmacs editor
        Sun Studio 12 Performance Library 
        Sun Studio 12 LockLint
        Sun Studio 12 Building Software (including dmake)
        Sun Studio 12 Documentation Set

version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
SunOS_sparc Patch 124867-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9
SunOS_sparc Patch 124863-01 2007/07/25
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95
8.3 SunOS_sparc Patch 127000-01 2007/07/18
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx
Debugger 7.6 SunOS_sparc Patch 124872-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun
Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun
Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19





--($ ~/Source/Python-2.5.2)-- LC_ALL=C gmake
case $MAKEFLAGS in \
        *-s*) LD_LIBRARY_PATH=/export/home/webservd/Source/Python-2.5.2:
CC='cc' LDSHARED='cc -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q
build;; \
        *) LD_LIBRARY_PATH=/export/home/webservd/Source/Python-2.5.2:
CC='cc' LDSHARED='cc -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; \
        esac
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building '_ctypes' extension
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c -o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 2255: warning: statement not reached
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 2820: warning: assignment type mismatch:
        pointer to void "=" pointer to function(void) returning int
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 3382: warning: argument #1 is incompatible with prototype:
        prototype: pointer to function(void) returning int :
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/ctypes.h",
line 270
        argument : pointer to void
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 4780: warning: argument #1 is incompatible with prototype:
        prototype: pointer to void :
"/export/home/webservd/Source/Python-2.5.2/./Include/longobject.h", line 39
        argument : pointer to function(pointer to void, pointer to const
void, unsigned int) returning pointer to void
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 4781: warning: argument #1 is incompatible with prototype:
        prototype: pointer to void :
"/export/home/webservd/Source/Python-2.5.2/./Include/longobject.h", line 39
        argument : pointer to function(pointer to void, int, unsigned
int) returning pointer to void
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 4782: warning: argument #1 is incompatible with prototype:
        prototype: pointer to void :
"/export/home/webservd/Source/Python-2.5.2/./Include/longobject.h", line 39
        argument : pointer to function(pointer to const char, int)
returning pointer to struct _object {int ob_refcnt, pointer to struct
_typeobject {..} ob_type}
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 4783: warning: argument #1 is incompatible with prototype:
        prototype: pointer to void :
"/export/home/webservd/Source/Python-2.5.2/./Include/longobject.h", line 39
        argument : pointer to function(pointer to void, pointer to
struct _object {int ob_refcnt, pointer to struct _typeobject {..}
ob_type}, pointer to struct _object {int ob_refcnt, pointer to struct
_typeobject {..} ob_type}) returning pointer to struct _object {int
ob_refcnt, pointer to struct _typeobject {..} ob_type}
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.c",
line 4785: warning: argument #1 is incompatible with prototype:
        prototype: pointer to void :
"/export/home/webservd/Source/Python-2.5.2/./Include/longobject.h", line 39
        argument : pointer to function(pointer to const long, int)
returning pointer to struct _object {int ob_refcnt, pointer to struct
_typeobject {..} ob_type}
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callbacks.c -o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callbacks.o
cc: Warning: illegal option -OPT:Olimit=0
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c -o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c",
line 668: warning: argument #2 is incompatible with prototype:
        prototype: pointer to function(void) returning void :
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi.h", line 272
        argument : pointer to void
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c",
line 921: warning: implicit function declaration: alloca
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c",
line 975: warning: improper pointer/integer combination: op "="
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c",
line 1304: warning: argument #1 is incompatible with prototype:
        prototype: pointer to function(void) returning int :
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c",
line 905
        argument : pointer to void
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c",
line 1335: warning: argument #1 is incompatible with prototype:
        prototype: pointer to function(void) returning int :
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.c",
line 905
        argument : pointer to void
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/stgdict.c -o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/stgdict.o
cc: Warning: illegal option -OPT:Olimit=0
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/cfield.c -o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/cfield.o
cc: Warning: illegal option -OPT:Olimit=0
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/malloc_closure.c
-o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/malloc_closure.o
cc: Warning: illegal option -OPT:Olimit=0
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/prep_cif.c
-o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/prep_cif.o
cc: Warning: illegal option -OPT:Olimit=0
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
77: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
77: warning: attribute parameter "__QI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
78: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
78: warning: attribute parameter "__QI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
79: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
79: warning: attribute parameter "__HI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
80: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
80: warning: attribute parameter "__HI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
81: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
81: warning: attribute parameter "__SI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
82: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
82: warning: attribute parameter "__SI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
83: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
83: warning: attribute parameter "__DI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
84: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
84: warning: attribute parameter "__DI__" is undefined
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/ffi.c
-o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/ffi.o
cc: Warning: illegal option -OPT:Olimit=0
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
77: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
77: warning: attribute parameter "__QI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
78: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
78: warning: attribute parameter "__QI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
79: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
79: warning: attribute parameter "__HI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
80: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
80: warning: attribute parameter "__HI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
81: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
81: warning: attribute parameter "__SI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
82: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
82: warning: attribute parameter "__SI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
83: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
83: warning: attribute parameter "__DI__" is undefined
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
84: warning:  attribute "__mode__" is unknown, ignored
"build/temp.solaris-2.10-sun4u-2.5/libffi/include/ffi_common.h", line
84: warning: attribute parameter "__DI__" is undefined
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/ffi.c",
line 399: warning: argument #1 is incompatible with prototype:
        prototype: pointer to void :
"/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/ffi.c",
line 363
        argument : pointer to function(pointer to char, pointer to
struct  {pointer to struct  {..} cif, pointer to void rvalue, pointer to
pointer to void avalue}) returning void
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v8.S
-o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v8.o
cc: Warning: illegal option -OPT:Olimit=0
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.5.2/./Include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi/include
-Ibuild/temp.solaris-2.10-sun4u-2.5/libffi
-I/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src
-I/export/home/webservd/.software/Python-2.5.2/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.5.2/Include
-I/export/home/webservd/Source/Python-2.5.2 -c
/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v9.S
-o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v9.o
cc: Warning: illegal option -OPT:Olimit=0
cc -G
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4u-2.5/export/home/webservd/Source/Python-2.5.2/Modules/_ctypes/libffi/src/sparc/v9.o
-L/export/home/webservd/.software/Python-2.5.2/lib -L/usr/local/lib
-lpython2.5 -o build/lib.solaris-2.10-sun4u-2.5/_ctypes.so -mimpure-text
cc: Warning: illegal option -mimpure-text
*** WARNING: renaming "_ctypes" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-sun4u-2.5/_ctypes.so: symbol alloca: referenced
symbol not found
running build_scripts

----------
assignee: theller
components: ctypes
messages: 72576
nosy: mschmarck, theller
severity: normal
status: open
title: Can't build ctypes of Python 2.5.2 with Sun Studio 12
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Fri Sep  5 11:46:06 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 09:46:06 +0000
Subject: [issue3785] Can't build ctypes of Python 2.5.2 with Sun Studio 12
In-Reply-To: <1220600923.37.0.208591240416.issue3785@psf.upfronthosting.co.za>
Message-ID: <1220607966.39.0.0767817162331.issue3785@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

This does not happen when I use GCC to build Python.

--($ ~/Source/gccPy/Python-2.5.2)-- /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

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

From report at bugs.python.org  Fri Sep  5 11:50:59 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 09:50:59 +0000
Subject: [issue3785] Can't build ctypes of Python 2.5.2 with Sun Studio 12
In-Reply-To: <1220600923.37.0.208591240416.issue3785@psf.upfronthosting.co.za>
Message-ID: <1220608259.22.0.51395030542.issue3785@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

It works fine in 2.6b3, however (I only tested Sun Studio 12).

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

From report at bugs.python.org  Fri Sep  5 11:55:21 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 09:55:21 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>


New submission from Michael Schmarck <michael.schmarck at habmalnefrage.de>:

I'm trying to compile Python 2.6b3 using Sun Studio 12 on a Solaris 10
sparc system. It fails.

[...]
*** WARNING: renaming "_curses" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-sun4u-2.6/_curses.so: symbol wchgat: referenced
symbol not found
[...]
*** WARNING: renaming "_curses_panel" since importing it failed: No
module named _curses
[...]
"/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c",
line 253: undefined symbol: SEM_VALUE_MAX
[...]

--($ ~/Source/Python-2.6b3)-- /opt/SUNWspro/bin/version
Machine hardware:   sun4u
OS version:         5.10
Processor type:     sparc
Hardware:           SUNW,Sun-Fire-480R

The following components are installed on your system:


Sun Studio 12
        Sun Studio 12 C Compiler
        Sun Studio 12 C++ Compiler
        Sun Studio 12 Tools.h++ 7.1
        Sun Studio 12 C++ Standard 64-bit Class Library
        Sun Studio 12 Garbage Collector 
        Sun Studio 12 Fortran 95 
        Sun Studio 12 Debugging Tools (including dbx)
        Sun Studio 12 IDE
        Sun Studio 12 Debugger GUI
        Sun Studio 12 Performance Analyzer (including collect, ...)
        Sun Studio 12 X-Designer 
        Sun Studio 12 VIM editor
        Sun Studio 12 XEmacs editor
        Sun Studio 12 Performance Library 
        Sun Studio 12 LockLint
        Sun Studio 12 Building Software (including dmake)
        Sun Studio 12 Documentation Set

version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
SunOS_sparc Patch 124867-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9
SunOS_sparc Patch 124863-01 2007/07/25
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95
8.3 SunOS_sparc Patch 127000-01 2007/07/18
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx
Debugger 7.6 SunOS_sparc Patch 124872-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun
Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun
Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19


--($ ~/Source/Python-2.6b3)-- CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25

--($ ~/Source/Python-2.6b3)-- cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
usage: cc [ options] files.  Use 'cc -flags' for details


--($ ~/Source/Python-2.6b3)-- gmake
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building '_curses' extension
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.6b3/./Include
-I/export/home/webservd/.software/Python-2.6b3/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.6b3/Include
-I/export/home/webservd/Source/Python-2.6b3 -c
/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.c -o
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.c",
line 708: warning: implicit function declaration: mvwchgat
"/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.c",
line 712: warning: implicit function declaration: wchgat
cc -G
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_cursesmodule.o
-L/export/home/webservd/.software/Python-2.6b3/lib -L/usr/local/lib
-lcurses -ltermcap -lpython2.6 -o
build/lib.solaris-2.10-sun4u-2.6/_curses.so
*** WARNING: renaming "_curses" since importing it failed: ld.so.1:
python: fatal: relocation error: file
build/lib.solaris-2.10-sun4u-2.6/_curses.so: symbol wchgat: referenced
symbol not found
building '_curses_panel' extension
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -I.
-I/export/home/webservd/Source/Python-2.6b3/./Include
-I/export/home/webservd/.software/Python-2.6b3/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.6b3/Include
-I/export/home/webservd/Source/Python-2.6b3 -c
/export/home/webservd/Source/Python-2.6b3/Modules/_curses_panel.c -o
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_curses_panel.o
cc: Warning: illegal option -OPT:Olimit=0
cc -G
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_curses_panel.o
-L/export/home/webservd/.software/Python-2.6b3/lib -L/usr/local/lib
-lpanel -lcurses -ltermcap -lpython2.6 -o
build/lib.solaris-2.10-sun4u-2.6/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No
module named _curses
building '_multiprocessing' extension
cc -xcode=pic32 -OPT:Olimit=0 -DNDEBUG -O -DHAVE_SEM_OPEN=1
-DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing
-I. -I/export/home/webservd/Source/Python-2.6b3/./Include
-I/export/home/webservd/.software/Python-2.6b3/include -I. -IInclude
-I./Include -I/usr/local/include
-I/export/home/webservd/Source/Python-2.6b3/Include
-I/export/home/webservd/Source/Python-2.6b3 -c
/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c
-o
build/temp.solaris-2.10-sun4u-2.6/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c",
line 253: undefined symbol: SEM_VALUE_MAX
cc: acomp failed for
/export/home/webservd/Source/Python-2.6b3/Modules/_multiprocessing/multiprocessing.c

Failed to find the necessary bits to build these modules:
_bsddb             _hashlib           _sqlite3        
_ssl               _tkinter           bsddb185        
gdbm               linuxaudiodev      ossaudiodev     
readline                                              
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.


Failed to build these modules:
_curses            _curses_panel      _multiprocessing

running build_scripts

----------
components: Build
messages: 72579
nosy: mschmarck
severity: normal
status: open
title: _curses, _curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio 12
versions: Python 2.6

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

From report at bugs.python.org  Fri Sep  5 12:25:32 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Sep 2008 10:25:32 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220610332.43.0.313444731641.issue3492@psf.upfronthosting.co.za>


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

Patch looks good to me (I've only looked at the patch - not the other
possible misuses of PyByteArray_ that Amaury noted)

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Fri Sep  5 12:26:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 10:26:28 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1220610388.52.0.2806511131.issue3786@psf.upfronthosting.co.za>


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

As for the multiprocessing problem, it has been fixed recently on trunk.
Can you give it a try?

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

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

From report at bugs.python.org  Fri Sep  5 12:28:42 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Sep 2008 10:28:42 +0000
Subject: [issue3776] deprecate bsddb/dbhash in 2.6 for removal in 3.0
In-Reply-To: <1220559079.97.0.262960509527.issue3776@psf.upfronthosting.co.za>
Message-ID: <1220610522.65.0.182116316031.issue3776@psf.upfronthosting.co.za>


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

I was actually pretty sure the intention was to add Py3k warnings, but
the exact phrase being used in the python-dev thread was "deprecation
warnings" which made folks a little nervous.

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

From report at bugs.python.org  Fri Sep  5 12:32:15 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 10:32:15 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220610735.54.0.392287289253.issue3660@psf.upfronthosting.co.za>


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

FWIW, applying encode-leak2.patch removes the leak in test_unicode.

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

From report at bugs.python.org  Fri Sep  5 12:41:05 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 10:41:05 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1220611265.17.0.588195957353.issue3786@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

Yes, the multiprocessing problem has been fixed by the patch in Issue3110.

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

From report at bugs.python.org  Fri Sep  5 13:59:30 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 11:59:30 +0000
Subject: [issue3784] Incorrect compiler options used for cc of Sun Studio 12
In-Reply-To: <1220600511.19.0.379971962657.issue3784@psf.upfronthosting.co.za>
Message-ID: <1220615970.65.0.491409545075.issue3784@psf.upfronthosting.co.za>


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

Is it really a compile error or just a warning?

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

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

From report at bugs.python.org  Fri Sep  5 14:00:27 2008
From: report at bugs.python.org (Simon Cross)
Date: Fri, 05 Sep 2008 12:00:27 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220616027.23.0.108590492195.issue3162@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

I've attached a patch for trunk / 2.6 that adds recv_into and
recvfrom_into methods to ssl.SSLSocket and does a minor re-ordering of
the nasty lambdas in __init__. The recv_into method is a port of the one
from 3.0. The recvfrom_into method is a simple "fail if we have an SSL
object or pass down if we don't".

For the record, I'm against the lambdas in SSLSocket.__init__ and would
prefer the solution I suggested previously of putting a hasattr(...)
check into socket.socket (I can submit a patch if useful).

As is probably abundantly clear at the moment :), none of the SSLSocket
methods in questions have tests in test_ssl -- I will move on to trying
to add them next.

I'm also going to attach a patch for 3.0 which adds recvfrom_into (a
port of the 2.6 one).

----------
keywords: +patch
Added file: http://bugs.python.org/file11389/trunk-ssl-methods.patch

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

From report at bugs.python.org  Fri Sep  5 14:01:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 12:01:34 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220616094.31.0.0911774400842.issue3783@psf.upfronthosting.co.za>


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

It would be more efficient to base keys() on iterkeys() than the
reverse, IMO.
Other than that, why not open a branch or at least upload full-fledged
patch files? :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep  5 14:01:38 2008
From: report at bugs.python.org (Simon Cross)
Date: Fri, 05 Sep 2008 12:01:38 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220616098.28.0.661816055485.issue3162@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

Attach recvfrom_into method patch for 3.0.

Added file: http://bugs.python.org/file11390/3k-ssl-methods.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 15:08:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 13:08:34 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220620114.55.0.43308624926.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Antoine, it seem that with encode-leak2.patch, the error path after
PyErr_WarnEx() leaks the value of "v".

I rewrote the whole paragraph to make it more straightforward:
- the normal case is tested first
- all paths end with a "return", and no goto.
- no need to test that PyBytes_FromStringAndSize returns a PyBytes...

I find the code much easier to check in this form, but of course this is
a subjective POV.

Added file: http://bugs.python.org/file11391/encode-leak3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Sep  5 15:10:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 13:10:23 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1220620223.62.0.616934669299.issue1757072@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type:  -> feature request
versions: +Python 2.7, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Fri Sep  5 15:14:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 13:14:06 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1220620446.51.0.848694119027.issue3535@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Alan, do you have an opinion on this?

----------
nosy: +alanmcintyre
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Fri Sep  5 15:29:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 13:29:35 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220621375.41.0.218716952212.issue874900@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Just checked that the latest patch works on Windows as well.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Fri Sep  5 15:30:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 13:30:24 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1220620114.55.0.43308624926.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220621415.25003.0.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 05 septembre 2008 ? 13:08 +0000, Amaury Forgeot d'Arc a
?crit :
> Antoine, it seem that with encode-leak2.patch, the error path after
> PyErr_WarnEx() leaks the value of "v".

Hmm, you are right.

> I rewrote the whole paragraph to make it more straightforward:
> - the normal case is tested first
> - all paths end with a "return", and no goto.
> - no need to test that PyBytes_FromStringAndSize returns a PyBytes...

I'll take a look!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Sep  5 15:40:43 2008
From: report at bugs.python.org (Matteo Bertini)
Date: Fri, 05 Sep 2008 13:40:43 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1220622043.96.0.768342660792.issue1068268@psf.upfronthosting.co.za>


Matteo Bertini <matteob at naufraghi.net> added the comment:

I'd like to suggest to rise the priority of this bug.
Till this bus is around, no way using any module using subprocess.Popen 
form a PyQt app (and I suppose PyGtk and wxPython too).

----------
nosy: +naufraghi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Fri Sep  5 15:49:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 13:49:19 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220622559.45.0.86765331811.issue3660@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury, your patch is much clearer indeed and it fixes the leak.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Sep  5 16:39:38 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Sep 2008 14:39:38 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220616094.31.0.0911774400842.issue3783@psf.upfronthosting.co.za>
Message-ID: <18625.17570.198027.407439@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> It would be more efficient to base keys() on iterkeys() than the
    Antoine> reverse, IMO.

True.  I was just modifying the dumbdbm implementation.

    Antoine> Other than that, why not open a branch or at least upload
    Antoine> full-fledged patch files? :)

Well, I only intended to create the initial proof of concept, but then last
night I couldn't sleep so I cobbled the test module and docs from the
existing stuff ... ;-)

When I get a couple minutes free I'll try and condense it into a more
suitable form.  Probably not until the weekend though.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep  5 16:40:18 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Fri, 05 Sep 2008 14:40:18 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220625618.29.0.997982618803.issue3783@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep  5 16:43:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 14:43:23 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1220625803.84.0.858129678637.issue1068268@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Two remarks:
1 - The part of the patch around the call to select.select() is already
in trunk since r64756, almost in the same form. good.

2 - the patch seems to replace all calls to os.write, os.read and
os.waipid. But it is based on a very old version of subprocess, and
r38169 added a new call to os.waitpid. I don't know if it should be
replaced as well.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Fri Sep  5 16:51:58 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Fri, 05 Sep 2008 14:51:58 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220626318.63.0.0762984398489.issue3769@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This issue is closed but "rejected". Should it be marked as "accepted"
or "fixed"?.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3769>
_______________________________________

From report at bugs.python.org  Fri Sep  5 16:54:42 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Fri, 05 Sep 2008 14:54:42 +0000
Subject: [issue3776] deprecate bsddb/dbhash in 2.6 for removal in 3.0
In-Reply-To: <1220559079.97.0.262960509527.issue3776@psf.upfronthosting.co.za>
Message-ID: <1220626482.66.0.583578481116.issue3776@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3776>
_______________________________________

From report at bugs.python.org  Fri Sep  5 16:55:50 2008
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Sep 2008 14:55:50 +0000
Subject: [issue3721] invalid literal for int() with base 16: ''
In-Reply-To: <1219995326.44.0.411202937388.issue3721@psf.upfronthosting.co.za>
Message-ID: <1220626550.14.0.870656531237.issue3721@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The test fails for me on 2.5.1 (stock Mac OS 10.5.4) in the same way as
described in this bug.

In 2.6 (r66230) the test succeeds.

I recommend we close this.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3721>
_______________________________________

From report at bugs.python.org  Fri Sep  5 17:06:31 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Sep 2008 15:06:31 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220627191.12.0.857712349507.issue3769@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution: rejected -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3769>
_______________________________________

From report at bugs.python.org  Fri Sep  5 17:13:16 2008
From: report at bugs.python.org (Chris Lambacher)
Date: Fri, 05 Sep 2008 15:13:16 +0000
Subject: [issue3671] What's New in 2.6 - corrections
In-Reply-To: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>
Message-ID: <1220627596.69.0.391358710961.issue3671@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

In rev66217, the itertools example for "With two iterables, 2N-tuples
are returned." has a typo:
itertools(product([1,2], [3,4], repeat=2)
should be:
itertools.product([1,2], [3,4], repeat=2)

----------
nosy: +lambacck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3671>
_______________________________________

From report at bugs.python.org  Fri Sep  5 17:17:37 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 05 Sep 2008 15:17:37 +0000
Subject: [issue3671] What's New in 2.6 - corrections
In-Reply-To: <1219614797.59.0.814774740709.issue3671@psf.upfronthosting.co.za>
Message-ID: <1220627857.26.0.569096743444.issue3671@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

itertools(product typo fixed in rev. 66231.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3671>
_______________________________________

From report at bugs.python.org  Fri Sep  5 17:20:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 15:20:28 +0000
Subject: [issue3721] invalid literal for int() with base 16: ''
In-Reply-To: <1219995326.44.0.411202937388.issue3721@psf.upfronthosting.co.za>
Message-ID: <1220628028.51.0.737179998503.issue3721@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3721>
_______________________________________

From report at bugs.python.org  Fri Sep  5 17:27:51 2008
From: report at bugs.python.org (Simon Cross)
Date: Fri, 05 Sep 2008 15:27:51 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220628471.13.0.104301284786.issue3162@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

Tests for recv* and send* methods in 3.0 (2.6 tests coming shortly).

Added file: http://bugs.python.org/file11392/3k-ssl-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 17:50:48 2008
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Fri, 05 Sep 2008 15:50:48 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1220629848.25.0.146205967515.issue3417@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

I haven't managed to successfully complete the summer of code, due to
some personal problems, but I'm still working on 2to3 and on confidence
ranking for it.

There's a bzr branch with its current implementation at
http://isnomore.net/bzr/2to3 . I did an initial implementation of
confidence penalties on fix_dict for special contexts.

I'm still working on it (and on confidence ranking in general), but
please take a look and let me know what you think.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Fri Sep  5 18:06:05 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Fri, 05 Sep 2008 16:06:05 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220630765.36.0.0890847740262.issue3492@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Fri Sep  5 18:29:54 2008
From: report at bugs.python.org (Gregory Burd)
Date: Fri, 05 Sep 2008 16:29:54 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220632194.34.0.911187944849.issue3783@psf.upfronthosting.co.za>


Changes by Gregory Burd <greg.burd at oracle.com>:


----------
nosy: +gregburd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep  5 18:49:18 2008
From: report at bugs.python.org (Simon Cross)
Date: Fri, 05 Sep 2008 16:49:18 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220633358.81.0.854417615921.issue3162@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

Test for recv* and send* in 2.6.

The tests revealed some bugs so this patch fixes those and supercedes
trunk-ssl-methods.patch.

Of particular note is that recv_into called self.read(buf, nbytes) which
isn't supported in _ssl.c in 2.6. I've worked around it by creating a
temporary buffer in the Python code. This isn't great for large
messages, but the alternative is to modify _ssl.c itself (which I
suspect is unlikely to make it in to 2.6 at this stage).

Added file: http://bugs.python.org/file11393/trunk-ssl-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 18:58:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 16:58:58 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220633938.91.0.882686672848.issue3162@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> self.read(buf, nbytes)

Shouldn't this function be named readinto()?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:03:34 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Sep 2008 17:03:34 +0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1220634214.3.0.0281868368962.issue1040026@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I agree with Christian's most recent comment.

However without BDFL intervention I think its too late in the 2.6/3.0 
release cycle to rush this fix in.  It can wait for 2.6.1/3.0.1.

I won't have time to look at it for several days myself, but I'm 
assigning the bug to me so that it doesn't sit idle longer than it 
already has; feel free to steal it if someone else intends to fix it 
fast.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:05:04 2008
From: report at bugs.python.org (Simon Cross)
Date: Fri, 05 Sep 2008 17:05:04 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220634304.6.0.229656544605.issue3162@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

>> self.read(buf, nbytes)

> Shouldn't this function be named readinto()?

There is no readinto function (and I suspect one is unlikely to be added
now). In Py3k SSLSocket.read takes both len and buffer as optional
arguments.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:08:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 17:08:49 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220634529.0.0.826216502055.issue3162@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I asked this because I find the signature misleading:
   read(len)
or read(buffer, len)

io.py, for example, defines read(len) and read_into(buffer).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:09:57 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 05 Sep 2008 17:09:57 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220634597.6.0.779077694386.issue3162@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Simon, thanks, this patch looks good to me (2.6 only, right?).  I'll try
it out and report back.  If it looks good, I'll commit it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:15:19 2008
From: report at bugs.python.org (Simon Cross)
Date: Fri, 05 Sep 2008 17:15:19 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220634919.27.0.682908717335.issue3162@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

@Bill Janssen:

There are currently two patch sets which I think should be applied. For
2.6 it's just trunk-ssl-tests.patch. For 3.0 it's 3k-ssl-methods.patch
and 3k-ssl-tests.patch.

@Amaury Forgeot d'Arc

I agree it's not great nomenclature but that's a whole separate can of
worms and not one I want to open in this bug (and in any case, it has
practically zero hope of making it into 2.6/3.0 at this point).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:20:14 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 05 Sep 2008 17:20:14 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220635214.11.0.457868333401.issue1291446@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Ah, sorry.  I was looking at the 2.6 documentation, not the 2.5
documentation.  In 2.6 (which is what the new SSL code is for),
documentation of socket.ssl has been removed entirely, along with the
text that you cite, although the functionality from 2.5 socket.ssl is
still provided for backwards compatibility.  In 2.6, the ssl.SSLSocket
type is a subclass of socket.socket, so you call "makefile" on it to get
a file-like object for reading and writing.

If you'd like to submit a patch for 2.5 and 2.6, I think this is
backwards-compatible enough to qualify as a fix, not a feature enhancement.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1291446>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:24:31 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 05 Sep 2008 17:24:31 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220635471.97.0.108072183782.issue3162@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Re: nomenclature

I think this is partly a design bug on my part, supporting the old
pre-2.6 "read" and "write" methods on the SSL context.  Users should
really call "makefile" to get something they can "read" and "write";
those methods should, in 2.6, only be internal, and not exposed outside
the class.  Of course, that would complicate the socket.ssl
compatibility code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:38:42 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 05 Sep 2008 17:38:42 +0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1220636322.62.0.240558016892.issue1040026@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Yes, please move this to 3.0.1 / 2.6.1.  The hard part appears to be
making sure that it compiles *and* is correct on all conceivable
platforms...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_______________________________________

From report at bugs.python.org  Fri Sep  5 19:43:06 2008
From: report at bugs.python.org (Jonathan Ellis)
Date: Fri, 05 Sep 2008 17:43:06 +0000
Subject: [issue1291446] SSLObject breaks read semantics
Message-ID: <1220636586.39.0.174991474987.issue1291446@psf.upfronthosting.co.za>


Jonathan Ellis <ellisj at users.sourceforge.net> added the comment:

Ah, great.  I was wondering why you kept talking about SSLSocket 
instead of SSLObject.  "New API in 2.6" is good enough for me.  Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1291446>
_______________________________________

From report at bugs.python.org  Fri Sep  5 20:11:11 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 05 Sep 2008 18:11:11 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1220638271.75.0.863865039424.issue3623@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

issue3763 mentions about the similar problem with json library.
The traceback posted illustrates the issue (c) mentioned here:

  File "C:\Python30\lib\json\decoder.py", line 30, in errmsg
    lineno, colno = linecol(doc, pos)
  File "C:\Python30\lib\json\decoder.py", line 21, in linecol
    lineno = doc.count('\n', 0, pos) + 1
TypeError: expected an object with the buffer interface

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Fri Sep  5 20:19:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 18:19:36 +0000
Subject: [issue3769] Deprecate bsddb for removal in 3.0
In-Reply-To: <1220483192.38.0.643616546213.issue3769@psf.upfronthosting.co.za>
Message-ID: <1220638776.35.0.322723024376.issue3769@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I accidentally filed this twice, and the code review is on the other
issue, so setting the superceder and closing (although the patch has not
been applied yet).

----------
resolution: fixed -> duplicate
superseder:  -> deprecate bsddb/dbhash in 2.6 for removal in 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3769>
_______________________________________

From report at bugs.python.org  Fri Sep  5 20:35:21 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 18:35:21 +0000
Subject: [issue3776] deprecate bsddb/dbhash in 2.6 for removal in 3.0
In-Reply-To: <1220559079.97.0.262960509527.issue3776@psf.upfronthosting.co.za>
Message-ID: <1220639721.5.0.197257843039.issue3776@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Trunk done with r66232 and blocked on 3.0 with r66233.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3776>
_______________________________________

From report at bugs.python.org  Fri Sep  5 20:36:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 18:36:56 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220639816.0.0.410445945747.issue3758@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The attached patch renames the target to patchcheck.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11394/rename_check.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3758>
_______________________________________

From report at bugs.python.org  Fri Sep  5 20:48:25 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 05 Sep 2008 18:48:25 +0000
Subject: [issue3785] Can't build ctypes of Python 2.5.2 with Sun Studio 12
In-Reply-To: <1220600923.37.0.208591240416.issue3785@psf.upfronthosting.co.za>
Message-ID: <1220640505.97.0.702861777329.issue3785@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The libffi library in Python 2.5 is too old and won't be upgraded to a
newer version.

I see several possibilities for you:

- Use Python 2.6 (if you can live with the beta or wait for the release)

- Use Python 2.5, compile with GCC

- Use Python 2.5, and build/install the ctypes version from Python SVN
trunk as add-on module, it is available here:
http://svn.python.org/projects/ctypes/branches/ctypes-1.1/

Closing as wont fix, sorry.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3785>
_______________________________________

From report at bugs.python.org  Fri Sep  5 20:52:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 05 Sep 2008 18:52:00 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

A long time ago I added the PyInstanceMethod_Type in r59469. It's a
wrapper that turns every function including PyCFunctions into a bindable
function.

class Example:
    id = instancemethod(id)

Example().id()

Without instancemethod the builtin function is not called with 'self' as
first argument.

The code is in the core for a long time but it has neither been used and
unit tested nor was it exposed yet. The feature was requested by the
Pyrex and Cython developers. The feature should either be removed or
exposed somehow. 

I know it's very late in the release cycle but I feel uncomfortable with
code that has no tests. If you don't want to expose it to the user but
only to C extension writers I'll come up with another plan. For example
I could add the type to the testcapi module and test it there.

----------
assignee: barry
components: Interpreter Core
files: instancemethod_public.patch
keywords: needs review, patch, patch
messages: 72619
nosy: barry, christian.heimes, gvanrossum
priority: release blocker
severity: normal
status: open
title: Make PyInstanceMethod_Type available or remove it
versions: Python 3.1
Added file: http://bugs.python.org/file11395/instancemethod_public.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Fri Sep  5 21:28:39 2008
From: report at bugs.python.org (Matt Chisholm)
Date: Fri, 05 Sep 2008 19:28:39 +0000
Subject: [issue1638033] Add httponly to Cookie module
Message-ID: <1220642919.57.0.539873121508.issue1638033@psf.upfronthosting.co.za>


Matt Chisholm <matt-python at theory.org> added the comment:

I have updated the diff to use reST for the docs.  I removed the link to
MSDN from the reST docs because it is broken and I could not find the
article that it was intended to point to.  I also slightly re-worded the
paragraph describing httponly.  

I did not add any tests for the new feature as Antoine Pitrou requested,
because the test for Cookie only tests SimpleCookie. It does not test
expires, max-age, secure, or any of the other cookie attributes that
Cookie.py sets. Testing httponly (or any of the other cookie attributes)
would require rewriting most of the test.

Added file: http://bugs.python.org/file11396/HttpOnlyCookies.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1638033>
_______________________________________

From report at bugs.python.org  Fri Sep  5 21:30:22 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Sep 2008 19:30:22 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1220643022.73.0.878907422921.issue3787@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

It's really to late to add any new features, so adding tests to testcapi
seems like the right thing to do.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Fri Sep  5 21:41:47 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 05 Sep 2008 19:41:47 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1220643707.11.0.261743451049.issue3787@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Here is a new patch as discussed on IRC. It adds the type to the
_testcapi module and the tests to test_capi.

Added file: http://bugs.python.org/file11397/instancemethod_capi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Fri Sep  5 21:56:16 2008
From: report at bugs.python.org (djc)
Date: Fri, 05 Sep 2008 19:56:16 +0000
Subject: [issue648658] xmlrpc can't do proxied HTTP
Message-ID: <1220644576.9.0.476426958797.issue648658@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

Would this be solved by issue1424152?

----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue648658>
_______________________________________

From report at bugs.python.org  Fri Sep  5 22:36:29 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 20:36:29 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1220646989.79.0.596840231904.issue3574@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have attached a new version of the patch with the changes to test_imp
removed as issue 3594 fixed the need for the change. I have also
directly uploaded test_pep3120.py since it is flagged as binary and thus
cannot be diffed by svn.

Added file: http://bugs.python.org/file11398/fix_latin.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Fri Sep  5 22:36:41 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 20:36:41 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1220647001.61.0.926751954032.issue3574@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file11130/fix_latin.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Fri Sep  5 22:37:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 20:37:07 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1220647027.88.0.413093039504.issue3574@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Added file: http://bugs.python.org/file11399/test_pep3120.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Fri Sep  5 22:37:13 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 20:37:13 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1220647033.61.0.440881289424.issue3574@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file11131/pep3120_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Fri Sep  5 22:45:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 20:45:48 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220647548.49.0.795187455243.issue3758@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Patch looks fine to me.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3758>
_______________________________________

From report at bugs.python.org  Fri Sep  5 22:59:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 20:59:49 +0000
Subject: [issue1638033] Add httponly to Cookie module
Message-ID: <1220648389.65.0.998739672027.issue1638033@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patch looks good to me and I will apply it soon if there are not
objections.

Rewriting of Cookie's tests should probably be another issue.

----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1638033>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:00:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 21:00:20 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220648420.93.0.937251647457.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

encode-leak3.patch applied in r66234.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:07:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 21:07:04 +0000
Subject: [issue3788] test_cookie isn't comprehensive
In-Reply-To: <1220648824.87.0.764661238377.issue3788@psf.upfronthosting.co.za>
Message-ID: <1220648824.87.0.764661238377.issue3788@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

At the moment, test_cookie only tests SimpleCookie and not completely.
It should test Morsel attributes and bad input better.

----------
components: Library (Lib), Tests
keywords: easy
messages: 72628
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_cookie isn't comprehensive
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3788>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:20:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 21:20:53 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1220649653.54.0.596546310651.issue3279@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

IMO, it's unacceptable to be running Python code before the stdio
streams are set up. I believe that moving the site initialization after
the setting up the streams isn't as big a problem because the dynlibs
are on sys.path before site is run when python is installed. See
#586680. I will write to Python-dev.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:25:29 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Fri, 05 Sep 2008 21:25:29 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1220649929.5.0.313053423914.issue3535@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Your patch seems like a better way to detect whether a file is written
as Zip64, and it seems to be able to properly handle extracting a >2GB
file from a >2GB archive, so I'd vote to include it.  

I tested it with r66233, using a file made from the output of large.c,
zipped with the built-in archiver on OS X 10.4.11.  All regression tests
pass, including test_zipfile64, on both Linux and OS X.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:34:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 21:34:57 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1220649929.5.0.313053423914.issue3535@psf.upfronthosting.co.za>
Message-ID: <1220650490.13393.5.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Alan, do you have commit access? Otherwise the patch needs approval from
another core developer.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:40:49 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Fri, 05 Sep 2008 21:40:49 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1220650849.39.0.0741673719023.issue3535@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

No, I don't have commit access at the moment.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:47:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 21:47:48 +0000
Subject: [issue3660] reference leaks in 3.0
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220651268.59.0.657590998841.issue3660@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Current status:

test_distutils leaked [141, 142] references, sum=283
test_logging leaked [0, -219] references, sum=-219
test_smtplib leaked [0, 87] references, sum=87

The distutils leak should be investigated, but the overall situation is
rather good now. The other, transient, leaks might be due to some thread
being cleaned up too late or something.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:53:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 21:53:24 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1220651604.07.0.730111552873.issue3535@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Fri Sep  5 23:59:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 21:59:16 +0000
Subject: [issue3660] reference leaks in test_distutils
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220651956.01.0.756822515301.issue3660@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

test_distutils is also leaking the the trunk:

test_distutils leaked [144, 144, 144, 144] references, sum=576

----------
nosy: +benjamin.peterson
title: reference leaks in 3.0 -> reference leaks in test_distutils
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:13:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 22:13:29 +0000
Subject: [issue3601] test_unicode.test_raiseMemError fails in UCS4
In-Reply-To: <1219160525.52.0.218582324378.issue3601@psf.upfronthosting.co.za>
Message-ID: <1220652809.17.0.851869474004.issue3601@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r66235, r66236.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3601>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:14:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 22:14:52 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1220652892.18.0.961296641268.issue3279@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a patch that builds _bytesio and _stringio right into the binary.
I think Windows build files will need to be updated, though.

----------
keywords: +needs review
Added file: http://bugs.python.org/file11400/make_modules_builtin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:19:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 22:19:45 +0000
Subject: [issue3660] reference leaks in test_distutils
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220653185.68.0.152296612886.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

test_distutils will be difficult; the leak is around the "import xx" in
Lib/distutils/tests/test_build_ext.py.

And Python/import.c says:
/* To prevent initializing an extension module more than once, we keep a
static dictionary 'extensions' keyed [...] by filename (for dynamically
loaded modules). A copy of the module's dictionary is stored [...] 
*/

This dictionary keeps growing with random filenames in the temp
directory. I can't see a way to clean it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:29:40 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 22:29:40 +0000
Subject: [issue3660] reference leaks in test_distutils
In-Reply-To: <1220653185.68.0.152296612886.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220653777.13393.6.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> test_distutils will be difficult; the leak is around the "import xx" in
> Lib/distutils/tests/test_build_ext.py.
> 
> And Python/import.c says:
> /* To prevent initializing an extension module more than once, we keep a
> static dictionary 'extensions' keyed [...] by filename (for dynamically
> loaded modules). A copy of the module's dictionary is stored [...] 
> */
> 
> This dictionary keeps growing with random filenames in the temp
> directory. I can't see a way to clean it.

If it's just that (one leaked string per each extension module import),
I think we can live with it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:34:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 22:34:00 +0000
Subject: [issue3660] reference leaks in test_distutils
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220654040.86.0.809464231247.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's not only the name, but a copy of the whole module dict just after
import (that's why reload(sys) takes you back the
sys.setdefaultencoding() function).

Actually I found a (hackish) way to clean the 'extension' dict, but this
is not enough: the static variables in xxmodule.c cannot be cleared.
Shall we exclude this test from the leak hunter?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:35:26 2008
From: report at bugs.python.org (David Decotigny)
Date: Fri, 05 Sep 2008 22:35:26 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>


New submission from David Decotigny <com.d2 at free.fr>:

With the attached script, then demo() called with for example
datasize=40*1024*1024 and timeout=1 will deadlock: the program never
terminates.

The bug appears on Linux (RHEL4) / intel x86 with "multiprocessing"
coming with python 2.6b3 and I think it can be easily reproduced on
other Unices. It also appears with python 2.5 and the standalone
processing package 0.52
(https://developer.berlios.de/bugs/?func=detailbug&bug_id=14453&group_id=9001).

After a quick investigation, it seems to be a deadlock between waitpid
in the parent process, and a pipe::send in the "_feed" thread of the
child process. Indeed, the problem seems to be that "_feed" is still
sending data (the data is laaarge) to the pipe while the parent process
already called waitpid (because of the "short" timeout): the pipe fills
up because no consumer is eating the data (consumer already in waitpid)
and hence the "_feed" thread in the child blocks forever. Since the
child process does a _feed.join() before exiting (after function f), it
never exits. And hence the waitpid in the parent process never returns
because the child never exits.

This doesn't happen anymore if I use timeout=None or a larger timeout
(eg. 10 seconds). Because in both cases, waitpid is called /after/ the
"_feed" thread in the child process could send all of its data through
the pipe.

----------
components: Library (Lib)
files: c.py
messages: 72640
nosy: DavidDecotigny
severity: normal
status: open
title: multiprocessing deadlocks when sending large data through Queue with timeout
versions: Python 2.6
Added file: http://bugs.python.org/file11401/c.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:35:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 22:35:53 +0000
Subject: [issue3660] reference leaks in test_distutils
In-Reply-To: <1220654040.86.0.809464231247.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220654151.13393.7.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It's not only the name, but a copy of the whole module dict just after
> import (that's why reload(sys) takes you back the
> sys.setdefaultencoding() function).

Ow.

> Actually I found a (hackish) way to clean the 'extension' dict, but this
> is not enough: the static variables in xxmodule.c cannot be cleared.
> Shall we exclude this test from the leak hunter?

I'd prefer not. If we hide this leak, we'll end up forgetting about its
existence.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:36:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 22:36:18 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220654178.42.0.655572114529.issue3789@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:44:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 22:44:38 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1220654678.36.0.264335060158.issue3279@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Windows build files will need to be updated
Nothing to do here: they are already built-in, linked into Python30.dll,
and listed in PC/config.c

But shouldn't the two extension modules be removed from setup.py?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:47:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 22:47:44 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1220654864.74.0.181252426487.issue3279@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Yes, indeed.

Added file: http://bugs.python.org/file11402/make_modules_builtin2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Sat Sep  6 00:48:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 22:48:11 +0000
Subject: [issue3660] reference leaks in test_distutils
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1220654891.66.0.609166408671.issue3660@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With the new module structure in 3.0, it should be possible to add a
cleanup function. It would be a good exercise; I don't know of any
module defining such a function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3660>
_______________________________________

From report at bugs.python.org  Sat Sep  6 01:01:49 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Sep 2008 23:01:49 +0000
Subject: [issue3758] "make check" suggest a testing target under GNU coding
	standards
In-Reply-To: <1220362449.51.0.882466438238.issue3758@psf.upfronthosting.co.za>
Message-ID: <1220655709.07.0.908816541986.issue3758@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

On the trunk with r66237 and 3.0 with r66238.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3758>
_______________________________________

From report at bugs.python.org  Sat Sep  6 01:12:22 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 05 Sep 2008 23:12:22 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1220656342.8.0.886925256598.issue3787@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The issue is no longer a release blocker for the first rc1. Barry has
decided against adding instancemethod. However the new tests should be
added until the final roles out.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Sat Sep  6 01:17:21 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 05 Sep 2008 23:17:21 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1220656641.48.0.910721587728.issue3279@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Look good to me, and python-dev accepted the patch. So, go ahead and
commit it.

----------
assignee:  -> benjamin.peterson
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Sat Sep  6 01:21:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 23:21:11 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1220656871.4.0.093837191853.issue3787@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Usually, when you expose things under _tescapi for testing you test it
with related concepts.. I'm not sure what the correct place for this one
is, though. (maybe test_class?) Anyway, you could also nest
InstanceMethod and testfunction inside the test function its self to
avoide pollution.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Sat Sep  6 01:21:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 05 Sep 2008 23:21:23 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1220656883.16.0.158969485084.issue3535@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I also agree with the patch. This seems the correct way to detect the
Zip64 format.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Sat Sep  6 01:27:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 23:27:32 +0000
Subject: [issue3279] import of site.py fails on startup
In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za>
Message-ID: <1220657252.69.0.307354223541.issue3279@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66239.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3279>
_______________________________________

From report at bugs.python.org  Sat Sep  6 01:43:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Sep 2008 23:43:34 +0000
Subject: [issue3535] zipfile has problem reading zip files over 2GB
In-Reply-To: <1218360448.56.0.0890131265061.issue3535@psf.upfronthosting.co.za>
Message-ID: <1220658214.3.0.755587173853.issue3535@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r66240, r66241. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3535>
_______________________________________

From report at bugs.python.org  Sat Sep  6 02:16:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 00:16:31 +0000
Subject: [issue3790] in zlib decompressor objects,
	unused_data and unconsumed_tail must be immutable
In-Reply-To: <1220660191.68.0.82924423128.issue3790@psf.upfronthosting.co.za>
Message-ID: <1220660191.68.0.82924423128.issue3790@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Currently (in py3k), the attributes "unused_data" and "unconsumed_tail"
on zlib decompressor objects are bytearrays. This can wreak havoc in the
read() method of ZipInfo objects, because one of those bytearrays is
assigned to the internal "rawbuffer" and then extended using "+="...
leading to wrong results (right now I can only reproduce it on a 3.5 GB
zip file, sorry :-( ).

Here is a patch.

----------
components: Extension Modules
files: zlib_unconsumed_tail.patch
keywords: needs review, patch, patch
messages: 72652
nosy: pitrou
priority: critical
severity: normal
status: open
title: in zlib decompressor objects, unused_data and unconsumed_tail must be immutable
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11403/zlib_unconsumed_tail.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3790>
_______________________________________

From report at bugs.python.org  Sat Sep  6 02:19:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 00:19:37 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220660377.63.0.894379318361.issue3492@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We must definitely clean up other uses of bytearray in the extension
modules - see #3790 for an example.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Sat Sep  6 02:32:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 00:32:25 +0000
Subject: [issue3791] bsddb not completely removed
In-Reply-To: <1220661145.94.0.113291838613.issue3791@psf.upfronthosting.co.za>
Message-ID: <1220661145.94.0.113291838613.issue3791@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Some remnants of the defunct bsddb module, on windows:
- _bsddb44.lib is still compiled (but never used anywhere)
- _bsddb.py is still referenced by the msi installer

This is a release blocker: the installer won't work.

----------
components: Windows
files: remove-bsddb.patch
keywords: needs review, patch, patch
messages: 72654
nosy: amaury.forgeotdarc
priority: release blocker
severity: normal
status: open
title: bsddb not completely removed
versions: Python 3.0
Added file: http://bugs.python.org/file11404/remove-bsddb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3791>
_______________________________________

From report at bugs.python.org  Sat Sep  6 02:38:35 2008
From: report at bugs.python.org (David Decotigny)
Date: Sat, 06 Sep 2008 00:38:35 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220661515.49.0.155212431803.issue3789@psf.upfronthosting.co.za>


David Decotigny <com.d2 at free.fr> added the comment:

A quick fix in the user code, when we are sure we don't need the child
process if a timeout happens, is to call worker.terminate() in an except
Empty clause.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 02:51:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 00:51:02 +0000
Subject: [issue3791] bsddb not completely removed
In-Reply-To: <1220661145.94.0.113291838613.issue3791@psf.upfronthosting.co.za>
Message-ID: <1220662262.31.0.634457478103.issue3791@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There are many other places with bsddb. I tried to list all the files here:

Doc\library\collections.rst
Doc\library\dbm.rst
Doc\library\shelve.rst
Doc\reference\datamodel.rst
Lib\pydoc_topics.py
Lib\shelve.py
Lib\test\regrtest.py
Makefile.pre.in
Misc\developers.txt
Misc\RPM\python-3.0.spec
Misc\valgrind-python.supp
Modules\Setup.dist
PC\VS8.0\pyproject.vsprops
PCbuild\pyproject.vsprops
PCbuild\readme.txt
PCbuild\vs9to8.py
Tools\scripts\db2pickle.py
Tools\scripts\pickle2db.py


And some files that don't seem well maintained anyway:
PC\os2emx\README.os2emx
PC\os2vacpp\makefile
PC\os2vacpp\makefile.omk
PC\VC6\readme.txt
PC\VS7.1\python.build
PC\VS7.1\python.iss
PC\VS7.1\python20.wse
PC\VS7.1\readme.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3791>
_______________________________________

From report at bugs.python.org  Sat Sep  6 03:10:45 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 06 Sep 2008 01:10:45 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220663445.3.0.288342754588.issue3789@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

See http://docs.python.org/dev/library/multiprocessing.html#multiprocessing-
programming

Specifically:
Joining processes that use queues

Bear in mind that a process that has put items in a queue will wait 
before terminating until all the buffered items are fed by the ?feeder? 
thread to the underlying pipe. (The child process can call the 
Queue.cancel_join() method of the queue to avoid this behaviour.)

This means that whenever you use a queue you need to make sure that all 
items which have been put on the queue will eventually be removed before 
the process is joined. Otherwise you cannot be sure that processes which 
have put items on the queue will terminate. Remember also that non-
daemonic processes will be automatically be joined.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 03:16:25 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 06 Sep 2008 01:16:25 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220663785.72.0.150113888463.issue3789@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

In a later release, I'd like to massage this in such a way that you do not 
have to wait for a child queue to be drained prior to calling join.

One way to work around this David, is to call Queue.cancel_join_thread():

def f(datasize, q):
    q.cancel_join_thread()
    q.put(range(datasize))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 03:20:34 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 06 Sep 2008 01:20:34 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220664034.17.0.701842955873.issue3789@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 03:45:25 2008
From: report at bugs.python.org (David Decotigny)
Date: Sat, 06 Sep 2008 01:45:25 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220665525.74.0.467681868703.issue3789@psf.upfronthosting.co.za>


David Decotigny <com.d2 at free.fr> added the comment:

Thank you Jesse. When I read this passage, I thought naively that a
timeout raised in a get() would not be harmful: that somehow the whole
get() request would be aborted. But now I realize that it would make
things rather complicated and dangerous: the data would get dropped, and
will never be recovered by subsequent get().
So thank you for the hint, and leave the things as they are, it's better.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 03:55:38 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 06 Sep 2008 01:55:38 +0000
Subject: [issue3789] multiprocessing deadlocks when sending large data through
	Queue with timeout
In-Reply-To: <1220654126.75.0.335381648399.issue3789@psf.upfronthosting.co.za>
Message-ID: <1220666138.51.0.328489617867.issue3789@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

No problem David, you're the 4th person to ask me about this in the past 2 
months :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3789>
_______________________________________

From report at bugs.python.org  Sat Sep  6 04:55:26 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 06 Sep 2008 02:55:26 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220669726.6.0.793634468107.issue3783@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

OK, I made a sandbox project out of it:

svn+ssh://pythondev at svn.python.org/sandbox/trunk/dbm_sqlite

Hack away!

----------
assignee:  -> skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sat Sep  6 04:55:31 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 06 Sep 2008 02:55:31 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220669731.86.0.729680195817.issue3783@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Removed file: http://bugs.python.org/file11386/dbm.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sat Sep  6 04:55:35 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 06 Sep 2008 02:55:35 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220669735.19.0.532092925383.issue3783@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Removed file: http://bugs.python.org/file11387/sqlite.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sat Sep  6 04:55:38 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 06 Sep 2008 02:55:38 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220669738.4.0.0397037283147.issue3783@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Removed file: http://bugs.python.org/file11388/test_dbm_sqlite.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sat Sep  6 06:08:40 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 06 Sep 2008 04:08:40 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1220674120.45.0.6833924963.issue3640@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Sat Sep  6 06:53:06 2008
From: report at bugs.python.org (Steve Smith)
Date: Sat, 06 Sep 2008 04:53:06 +0000
Subject: [issue3792] Module variable overridden in child processes with
	multiprocessing
In-Reply-To: <1220676786.79.0.371553586642.issue3792@psf.upfronthosting.co.za>
Message-ID: <1220676786.79.0.371553586642.issue3792@psf.upfronthosting.co.za>


New submission from Steve Smith <tarkasteve at gmail.com>:

The process variable 'p' is leaking into sub-processes when using the
multiprocessing modules.  The following code demonstrates the problem:

    import sys
    from multiprocessing import Process

    p = 'Correct'

    def test():
        print "Got 'p' of", p

    if __name__ == '__main__':
        if len(sys.argv) == 2 and sys.argv[1] == '-m':
            p = Process(target=test)
            p.start()
            p.join()
        else:
            test()

Running this in SP and MP mode shows the leakage:

    ssmith$ /opt/python-svn/bin/python mpbug.py 
    Got 'p' of Correct
    ssmith$ /opt/python-svn/bin/python mpbug.py -m
    Got 'p' of <Process(Process-1, started)>

This occurs in both 2.6b3 and trunk.

----------
components: Library (Lib)
messages: 72662
nosy: TarkaSteve
severity: normal
status: open
title: Module variable overridden in child processes with multiprocessing
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3792>
_______________________________________

From report at bugs.python.org  Sat Sep  6 12:43:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 10:43:07 +0000
Subject: [issue3792] Module variable overridden in child processes with
	multiprocessing
In-Reply-To: <1220676786.79.0.371553586642.issue3792@psf.upfronthosting.co.za>
Message-ID: <1220697787.1.0.796366498077.issue3792@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What do you mean, "overriden"? The behaviour looks totally normal to me.
You change the value of "p" before the subprocess is started, so the
subprocess inherits the new value, not the old one.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3792>
_______________________________________

From report at bugs.python.org  Sat Sep  6 14:28:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Sep 2008 12:28:46 +0000
Subject: [issue3792] Module variable overridden in child processes with
	multiprocessing
In-Reply-To: <1220676786.79.0.371553586642.issue3792@psf.upfronthosting.co.za>
Message-ID: <1220704126.48.0.0676176860355.issue3792@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I agree; this is the expected behavior. Perhaps you don't understand how
globals work in Python?

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3792>
_______________________________________

From report at bugs.python.org  Sat Sep  6 14:46:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 12:46:38 +0000
Subject: [issue3792] Module variable overridden in child processes with
	multiprocessing
In-Reply-To: <1220676786.79.0.371553586642.issue3792@psf.upfronthosting.co.za>
Message-ID: <1220705198.61.0.98551526827.issue3792@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, I get the OP's expected result on windows:

C:\dev\python\trunk>PCbuild\python_d t.py
Got 'p' of Correct
C:\dev\python\trunk>PCbuild\python_d t.py -m
Got 'p' of Correct

This is easy to explain: on Unix, the forked process has a copy of the
memory and reads the last value in the module. 
But on Windows, the freshly spawned process imports the module, and get
the initial value (since it does not enter the "__main__" block).

This is documented:
http://docs.python.org/dev/library/multiprocessing.html#windows , under
"Global Variables".

By the way, the Windows way may have some advantages for some uses.
Could the same method (start a new interpreter, import modules, copy
needed objects), be made available on Unix?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3792>
_______________________________________

From report at bugs.python.org  Sat Sep  6 15:04:26 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 06 Sep 2008 13:04:26 +0000
Subject: [issue3040] optparse documentation: variable arguments example
	doesn't work as listed
In-Reply-To: <1212635679.53.0.642286486593.issue3040@psf.upfronthosting.co.za>
Message-ID: <1220706266.49.0.642744884418.issue3040@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Fixed in rev. 66250 of trunk; thanks!

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3040>
_______________________________________

From report at bugs.python.org  Sat Sep  6 15:09:48 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 06 Sep 2008 13:09:48 +0000
Subject: [issue3604] broken link in curses module docs
In-Reply-To: <1219175178.82.0.559397561246.issue3604@psf.upfronthosting.co.za>
Message-ID: <1220706588.21.0.0893332467226.issue3604@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

This is fixed in the Python 2.6 documentation, where the HOWTOs 
have been incorporated and the link is therefore automatic.  Thanks for 
your report!

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3604>
_______________________________________

From report at bugs.python.org  Sat Sep  6 15:36:33 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 06 Sep 2008 13:36:33 +0000
Subject: [issue3793] Small RST fix in datamodel.rst
In-Reply-To: <1220708193.69.0.306345187593.issue3793@psf.upfronthosting.co.za>
Message-ID: <1220708193.69.0.306345187593.issue3793@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

A missing blank line under the heading for __bool__ in datamodel.rst (in
Python 3.0 docs) causes the following line to appear in the output HTML.

".. index:: single: __len__() (mapping object method)"

Visible here:
http://docs.python.org/dev/3.0/reference/datamodel.html#object.__bool__

Fixed in attached patch by adding a blank line.

Commit log:
Added blank line to avoid RST source leaking into HTML output.

----------
assignee: georg.brandl
components: Documentation
files: patch
messages: 72668
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: Small RST fix in datamodel.rst
versions: Python 3.0
Added file: http://bugs.python.org/file11405/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3793>
_______________________________________

From report at bugs.python.org  Sat Sep  6 15:54:31 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 06 Sep 2008 13:54:31 +0000
Subject: [issue3794] __div__ still documented in Python 3
In-Reply-To: <1220709271.27.0.757768420161.issue3794@psf.upfronthosting.co.za>
Message-ID: <1220709271.27.0.757768420161.issue3794@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

The "special method names" section of the Python 3.0 documentation still
mentions the __div__ method. I believe this method has been totally
removed in Python 3 in favour of __truediv__. (Perhaps I am mistaken,
but 'int' object has no attribute '__div__', so I assume this is correct).

Note here:
http://docs.python.org/dev/3.0/reference/datamodel.html#object.__div__

__div__ is still documented. Most of the __div__/__truediv__ section
describes the issues distinguishing the two. Now that __div__ is gone,
surely there is no need for this section, and __truediv__ can just be
pushed up above with all the other operators?

Attached a patch doing that. Also deleted __rdiv__ and __idiv__ from the
following sections. (And one minor extra fix: added ``//`` to the list
of operators in reflected methods, since it was missing - note this
required a reflow of text, which is why the diff shows the whole
paragraph changing).

Change log:

Doc/reference/datamodel.rst: Removed section under "emulating numeric
types" about difference between __div__ and __truediv__, since __div__
has been removed from the language. Also deleted __rdiv__ and __idiv__
from the following sections, also removed.

----------
assignee: georg.brandl
components: Documentation
files: datamodel.patch
keywords: patch
messages: 72669
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: __div__ still documented in Python 3
versions: Python 3.0
Added file: http://bugs.python.org/file11406/datamodel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3794>
_______________________________________

From report at bugs.python.org  Sat Sep  6 16:13:03 2008
From: report at bugs.python.org (Steve Smith)
Date: Sat, 06 Sep 2008 14:13:03 +0000
Subject: [issue3792] Module variable overridden in child processes with
	multiprocessing
In-Reply-To: <1220676786.79.0.371553586642.issue3792@psf.upfronthosting.co.za>
Message-ID: <1220710383.63.0.175691691703.issue3792@psf.upfronthosting.co.za>


Steve Smith <tarkasteve at gmail.com> added the comment:

Ugh, sorry.  Stupidity on the reporter's part.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3792>
_______________________________________

From report at bugs.python.org  Sat Sep  6 17:45:51 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 06 Sep 2008 15:45:51 +0000
Subject: [issue3777] PyNumber_Long fails from Float
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220715951.11.0.502777165188.issue3777@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

You are right that its the Py::Long( Py::Float( double( x ) ) )
that is triggering this problem.

Here is the gdb from the powerpc build that shows the
info you asked for and show res being corrupt.

I'm going to try and build a smaller version of this
problem using a minimal PyCXX module.

>>> import pysvn;pysvn.Client().ls('pysvn/__init__.py')

Breakpoint 1, bp () at pysvn_client_cmd_list.cpp:33
33      }
(gdb) c
Continuing.
Current language:  auto; currently c++

Breakpoint 2, pysvn_client::cmd_ls (this=0x1114830, a_args=@0xbffff118,
a_kws=@0xbffff120) at pysvn_client_cmd_list.cpp:138
138             Py::Long l_tmp( f_tmp );
(gdb) b PyNumber_Long
Breakpoint 5 at 0x213cfc: file Objects/abstract.c, line 1673.
(gdb) c
Continuing.

Breakpoint 5, PyNumber_Long (o=0x1809384) at Objects/abstract.c:1673
1673            if (trunc_name == NULL) {
(gdb) p o
$25 = (PyObject *) 0x1809384
Current language:  auto; currently c
(gdb) p *o
$26 = {
  ob_refcnt = 1, 
  ob_type = 0x35723c
}
(gdb) p *o->ob_type
$27 = {
  ob_refcnt = 4, 
  ob_type = 0x35f0bc, 
  ob_size = 0, 
  tp_name = 0x339d98 "float", 
  tp_basicsize = 16, 
  tp_itemsize = 0, 
  tp_dealloc = 0x23de30 <float_dealloc>, 
  tp_print = 0x23fa90 <float_print>, 
  tp_getattr = 0, 
  tp_setattr = 0, 
  tp_compare = 0, 
  tp_repr = 0x23fa50 <float_repr>, 
  tp_as_number = 0x357ab4, 
  tp_as_sequence = 0x0, 
  tp_as_mapping = 0x0, 
  tp_hash = 0x23e570 <float_hash>, 
  tp_call = 0, 
  tp_str = 0x23fa10 <float_str>, 
  tp_getattro = 0x263800 <PyObject_GenericGetAttr>, 
  tp_setattro = 0, 
  tp_as_buffer = 0x0, 
  tp_flags = 394747, 
  tp_doc = 0x357a4c "float(x) -> floating point number\n\nConvert a
string or number to a floating point number, if possible.", 
  tp_traverse = 0, 
  tp_clear = 0, 
  tp_richcompare = 0x23e000 <float_richcompare>, 
  tp_weaklistoffset = 0, 
  tp_iter = 0, 
  tp_iternext = 0, 
  tp_methods = 0x35733c, 
  tp_members = 0x0, 
  tp_getset = 0x357300, 
  tp_base = 0x0, 
  tp_dict = 0x0, 
  tp_descr_get = 0, 
  tp_descr_set = 0, 
  tp_dictoffset = 0, 
  tp_init = 0, 
  tp_alloc = 0, 
  tp_new = 0x241a10 <float_new>, 
  tp_free = 0, 
  tp_is_gc = 0, 
  tp_bases = 0x0, 
  tp_mro = 0x0, 
  tp_cache = 0x0, 
  tp_subclasses = 0x0, 
  tp_weaklist = 0x0, 
  tp_del = 0, 
  tp_version_tag = 0
}
(gdb) n
1679            if (o == NULL)
(gdb) 
1681            m = o->ob_type->tp_as_number;
(gdb) 
1682            if (m && m->nb_long) { /* This should include subclasses
of long */
(gdb) p *m
$28 = {
  nb_add = 0x242980 <float_add>, 
  nb_subtract = 0x242c40 <float_sub>, 
  nb_multiply = 0x242f00 <float_mul>, 
  nb_divide = 0x2431c0 <float_classic_div>, 
  nb_remainder = 0x243510 <float_rem>, 
  nb_divmod = 0x243830 <float_divmod>, 
  nb_power = 0x243bf0 <float_pow>, 
  nb_negative = 0x241d70 <float_neg>, 
  nb_positive = 0x241b60 <float_float>, 
  nb_absolute = 0x241e70 <float_abs>, 
  nb_nonzero = 0x23e580 <float_nonzero>, 
  nb_invert = 0, 
  nb_lshift = 0, 
  nb_rshift = 0, 
  nb_and = 0, 
  nb_xor = 0, 
  nb_or = 0, 
  nb_coerce = 0x241f70 <float_coerce>, 
  nb_int = 0x23e6e0 <float_trunc>, 
  nb_long = 0x23e6e0 <float_trunc>, 
  nb_float = 0x241b60 <float_float>, 
  nb_oct = 0, 
  nb_hex = 0, 
  nb_inplace_add = 0, 
  nb_inplace_subtract = 0, 
  nb_inplace_multiply = 0, 
  nb_inplace_divide = 0, 
  nb_inplace_remainder = 0, 
  nb_inplace_power = 0, 
  nb_inplace_lshift = 0, 
  nb_inplace_rshift = 0, 
  nb_inplace_and = 0, 
  nb_inplace_xor = 0, 
  nb_inplace_or = 0, 
  nb_floor_divide = 0x243b60 <float_floor_div>, 
  nb_true_divide = 0x244340 <float_div>, 
  nb_inplace_floor_divide = 0, 
  nb_inplace_true_divide = 0, 
  nb_index = 0
}
(gdb) n

Breakpoint 3, PyNumber_Long (o=0x1809384) at Objects/abstract.c:1684
1684                    PyObject *res = m->nb_long(o);
(gdb) s
float_trunc (v=0x1809384) at Objects/floatobject.c:1084
1084            double x = PyFloat_AsDouble(v);
(gdb) p o
$29 = (PyObject *) 0x1809384
(gdb) p v
$30 = (PyObject *) 0x1809384
(gdb) n
1087            (void)modf(x, &wholepart);
(gdb) p x
$31 = 0
(gdb) n
1100            if (LONG_MIN < wholepart && wholepart < LONG_MAX) {
(gdb) p wholepart
$32 = 4555
(gdb) n
1102                    return PyInt_FromLong(aslong);
(gdb) p asLong
No symbol "asLong" in current context.
(gdb) p aslong
No symbol "aslong" in current context.
(gdb) n
1105    }
(gdb) n
PyNumber_Long (o=0x1809384) at Objects/abstract.c:1685
1685                    if (res && (!PyInt_Check(res) &&
!PyLong_Check(res))) {
(gdb) p res
$33 = (PyObject *) 0x383cf0
(gdb) p *res
$34 = {
  ob_refcnt = 1362084, 
  ob_type = 0x140
}
(gdb) n

Breakpoint 4, PyNumber_Long (o=0x1809384) at Objects/abstract.c:1735
1735    }
(gdb)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Sat Sep  6 19:03:18 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 06 Sep 2008 17:03:18 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220720598.5.0.49425088757.issue3781@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I hate to make API suggestions this late in the process, but this is the
first
time I've looked at this.  I think the basic problem is that the context
manager API is a bit weird.  What I don't like is the fact that
__getattr__()
indexes the last item in the WarningsRecorder.  I don't know the history
here,
but why wouldn't this be a better API?

    with catch_warnings(True) as w:
        assert len(w) > 0, 'No caught warnings'
        assert str(w[-1].message) == 'foo', 'blah blah'

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Sep  6 19:24:24 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 06 Sep 2008 17:24:24 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1220721864.46.0.0935074643135.issue3657@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Neal, can you verify that this is still a problem now that bsddb has
been removed?  The tests, run in the order of the last comment, succeed
for me in both 2.6 and 3.0, debug build or not, on both my single
processor Ubuntu box and dual core Mac.

----------
nosy: +barry
priority: release blocker -> deferred blocker
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Sat Sep  6 19:43:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Sep 2008 17:43:02 +0000
Subject: [issue3794] __div__ still documented in Python 3
In-Reply-To: <1220709271.27.0.757768420161.issue3794@psf.upfronthosting.co.za>
Message-ID: <1220722982.54.0.55134168284.issue3794@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r66260.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3794>
_______________________________________

From report at bugs.python.org  Sat Sep  6 19:43:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Sep 2008 17:43:13 +0000
Subject: [issue3793] Small RST fix in datamodel.rst
In-Reply-To: <1220708193.69.0.306345187593.issue3793@psf.upfronthosting.co.za>
Message-ID: <1220722993.43.0.201556735877.issue3793@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r66260.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3793>
_______________________________________

From report at bugs.python.org  Sat Sep  6 19:44:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Sep 2008 17:44:02 +0000
Subject: [issue3794] __div__ still documented in Python 3
In-Reply-To: <1220709271.27.0.757768420161.issue3794@psf.upfronthosting.co.za>
Message-ID: <1220723042.76.0.574612051602.issue3794@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Uh, I meant r66261. Thanks for the patch!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3794>
_______________________________________

From report at bugs.python.org  Sat Sep  6 19:44:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 17:44:31 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220723071.26.0.438630994856.issue3783@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/issue3783>
_______________________________________

From report at bugs.python.org  Sat Sep  6 19:48:42 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 17:48:42 +0000
Subject: [issue3790] in zlib decompressor objects,
	unused_data and unconsumed_tail must be immutable
In-Reply-To: <1220660191.68.0.82924423128.issue3790@psf.upfronthosting.co.za>
Message-ID: <1220723322.14.0.798668337232.issue3790@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3790>
_______________________________________

From report at bugs.python.org  Sat Sep  6 20:06:08 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Sep 2008 18:06:08 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220724368.55.0.655562881209.issue3783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I would like to see something like this go into 3.0 so that shelves
don't become useless for Windows users.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sat Sep  6 20:24:22 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 06 Sep 2008 18:24:22 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220725462.58.0.570006838265.issue3781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The use of __getattr__ is a historical artifact. Originally there was no
way to record multiple warnings as the object returned by
catch_warnings() represented only a single instance of a warning. But
then the ability to record multiple warnings was added. To not break
existing code (I am guessing), the setting of attributes on the
WarningsRecorder was added. To tawdry life of catch_warnings(). =)

While having the attributes of the last warning directly accessible is
handy, I am in no way married to the idea. Actually, if we run with the
list analogy we can just ditch WarningsRecorder and return a list itself
that is directly appended to through a version of showwarning() that is
a closure instead. That cuts out code and everyone knows how to work
with lists as sequential recording of events.

OK, I'm sold. =) I will work on this today or tomorrow and get the patch
done and ready to go no later than Sunday evening for review.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Sep  6 20:26:20 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 06 Sep 2008 18:26:20 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220725580.45.0.406773189103.issue3781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

And I forgot to mention that subclassing list is a new thing I tossed in
when I moved the code and tweaked the API so that's another reason that
using list's abilities was not pervasive.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Sep  6 20:31:38 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 06 Sep 2008 18:31:38 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220725898.57.0.37480439904.issue3781@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Sounds good.  This needs to go into 2.6 and 3.0.  And while you're add
it, can you add catch_warnings to the __all__?

----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Sep  6 20:36:05 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 06 Sep 2008 18:36:05 +0000
Subject: [issue3777] PyNumber_Long fails from Float
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220726165.24.0.703570814555.issue3777@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

O.k. I know what is going on.

Here is the description from abstracts.h for PyNumber_Long:

     PyAPI_FUNC(PyObject *) PyNumber_Long(PyObject *o);

       /*
	 Returns the o converted to a long integer object on success,
	 or NULL on failure.  This is the equivalent of the Python
	 expression: long(o).

       */

Its says that I can expect a long integer. However PyNumber_long
can return an int or a long.

PyCXX checks for a long, but an int is not a long and I raise
a type error.

This is a contract break on the Python API.

The change that causes this break is in floatobject.c
>From 2.5.2 code:

static PyNumberMethods float_as_number = {
...
	float_int, 	/*nb_int*/
	float_long, 	/*nb_long*/

>From 2.6b3 code:

static PyNumberMethods float_as_number = {
...
	float_trunc, 	/*nb_int*/
	float_trunc, 	/*nb_long*/

float_trunc returns either an int or a long.
Which is not what is required for the API.

Here is the same bug at the pure python level.

 $ python2.6
Python 2.6b3 (r26b3:65922, Aug 25 2008, 15:44:46) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> long(4)
4L
>>> long(4.3)
4
>>> long("6")
6L
>>> type(long(4.3))
<type 'int'>
>>> 

Barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Sat Sep  6 20:41:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Sep 2008 18:41:36 +0000
Subject: [issue3705] py3k aborts if "-c" or "-m" is given a non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220726496.64.0.642597694702.issue3705@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Hmm. I suppose anything is better than segfaulting. I think the patch is
fine for now, though.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Sat Sep  6 21:28:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Sep 2008 19:28:33 +0000
Subject: [issue1638033] Add httponly to Cookie module
Message-ID: <1220729313.95.0.36474116937.issue1638033@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Applied in r66262.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1638033>
_______________________________________

From report at bugs.python.org  Sat Sep  6 21:38:15 2008
From: report at bugs.python.org (Bjarke Walling)
Date: Sat, 06 Sep 2008 19:38:15 +0000
Subject: [issue3795] wsgiref.simple_server fails to run demo_app
In-Reply-To: <1220729895.68.0.892573521462.issue3795@psf.upfronthosting.co.za>
Message-ID: <1220729895.68.0.892573521462.issue3795@psf.upfronthosting.co.za>


New submission from Bjarke Walling <bwp at bwp.dk>:

To reproduce the error start Python 3.0 and enter the usual WSGI "hello
world" application:

>>> from wsgiref.simple_server import make_server, demo_app
>>> httpd = make_server('', 8000, demo_app)
>>> httpd.serve_forever()

Open a browser and point it at http://location:8000/. On each HTTP
request an exception will be thrown:

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 55779)
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/socketserver.py", line 281, in
_handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/lib/python3.0/socketserver.py", line 307, in
process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python3.0/socketserver.py", line 320, in
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python3.0/socketserver.py", line 614, in __init__
    self.handle()
  File "/usr/local/lib/python3.0/wsgiref/simple_server.py", line 136, in
handle
    self.rfile, self.wfile, self.get_stderr(), self.get_environ()
  File "/usr/local/lib/python3.0/wsgiref/simple_server.py", line 115, in
get_environ
    k,v = h.split(':',1)
ValueError: need more than 1 value to unpack
----------------------------------------

Expected result: The nice demo page containing WSGI environment
variables is displayed in the browser.

----------
components: Library (Lib)
messages: 72684
nosy: Walling
severity: normal
status: open
title: wsgiref.simple_server fails to run demo_app
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3795>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:11:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 20:11:43 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220731903.83.0.425187774359.issue3777@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You are right: long(4.2) used to return a long.

This was changed by the introduction of the float_trunc() function,
which is now used for float.__trunc__, float.__int__ and float.__long__.

OTOH, long() has always been allowed to return an int. Checked with
python2.2:
>>> class C:
...   def __long__(self): return 4
...
>>> type(long(C()))
<type 'int'>

I suggest that:
- your code should be more tolerant, specially when calling API
functions from the "Abstract Objects Layer", accept both longs and ints.
- Concerning long(float()), the new behavior breaks existing code, and
should be reverted. I will try to come with a patch.

----------
priority:  -> release blocker
title: PyNumber_Long fails from Float -> long(4.2) now returns an int

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:15:06 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 20:15:06 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220732106.5.0.0332974638074.issue3492@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in r66266 along with #3790.

leaving this open and assigned to me while i investigate the other uses
of ByteArray in the Modules/ directory.

IMHO, its fine if we fix any remaining bytearray uses up for rc2.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:15:27 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 20:15:27 +0000
Subject: [issue3790] in zlib decompressor objects,
	unused_data and unconsumed_tail must be immutable
In-Reply-To: <1220660191.68.0.82924423128.issue3790@psf.upfronthosting.co.za>
Message-ID: <1220732127.58.0.503822403448.issue3790@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in r66266 along with #3492.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3790>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:15:51 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 20:15:51 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220732151.99.0.761700430318.issue3492@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:28:28 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 06 Sep 2008 20:28:28 +0000
Subject: [issue3669] sqlite3.Connection.iterdump docs pythonicity
In-Reply-To: <1219612748.54.0.0398165047003.issue3669@psf.upfronthosting.co.za>
Message-ID: <1220732908.4.0.277053663215.issue3669@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Applied in rev. 66268; thanks!

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3669>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:31:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 20:31:21 +0000
Subject: [issue3796] some tests are not run in test_float
In-Reply-To: <1220733080.87.0.13440485067.issue3796@psf.upfronthosting.co.za>
Message-ID: <1220733080.87.0.13440485067.issue3796@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

r62680 moved some tests from test_builtin to test_float,
but the list of classes to run was not updated.
Some minor updated were needed to let these tests pass.

----------
files: test_float.patch
keywords: needs review, patch, patch
messages: 72689
nosy: amaury.forgeotdarc
severity: normal
status: open
title: some tests are not run in test_float
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11407/test_float.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3796>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:35:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Sep 2008 20:35:03 +0000
Subject: [issue3796] some tests are not run in test_float
In-Reply-To: <1220733080.87.0.13440485067.issue3796@psf.upfronthosting.co.za>
Message-ID: <1220733303.8.0.962569356597.issue3796@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Go ahead and commit.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3796>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:46:13 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 20:46:13 +0000
Subject: [issue3797] mmap,
	dbm and ossaudiodev return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

As noted in issue #3492 the following py3k modules still erroneously
return bytearray objects instead of bytes objects from their read functions:

mmap
dbm
ossaudiodev

Attached is a trivial patch to fix those.

----------
assignee: gregory.p.smith
components: Extension Modules
files: mmap-dbm-oss_bytes.patch
keywords: easy, needs review, patch, patch
messages: 72691
nosy: gregory.p.smith
priority: deferred blocker
severity: normal
status: open
title: mmap, dbm and ossaudiodev return bytearray instead of bytes
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11408/mmap-dbm-oss_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:47:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 20:47:48 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220734068.81.0.764111177835.issue3705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r66269.

----------
priority: deferred blocker -> high
title: py3k aborts if "-c" or "-m" is given a non-ascii value -> py3k fails under Windows if "-c" or "-m" is given a non-ascii value
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:50:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 20:50:09 +0000
Subject: [issue3797] mmap, dbm, ossaudiodev,
	marshal & winreg return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220734209.79.0.553596500463.issue3797@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

attached a patch for PC/winreg.c and Python/marshal.c.

----------
title: mmap, dbm and ossaudiodev return bytearray instead of bytes -> mmap, dbm, ossaudiodev, marshal & winreg return bytearray instead of bytes
Added file: http://bugs.python.org/file11409/marshal-winreg_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 22:50:25 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 20:50:25 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220734225.52.0.00521578242325.issue3492@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

issue #3797 has been opened to track the other files mentioned.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:05:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 21:05:03 +0000
Subject: [issue3796] some tests are not run in test_float
In-Reply-To: <1220733080.87.0.13440485067.issue3796@psf.upfronthosting.co.za>
Message-ID: <1220735103.54.0.167589478202.issue3796@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r66270 and r66271.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3796>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:11:47 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 06 Sep 2008 21:11:47 +0000
Subject: [issue1674032] Make threading.Event().wait(timeout=3) return isSet
Message-ID: <1220735507.02.0.733507505279.issue1674032@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
components:  -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674032>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:14:30 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 06 Sep 2008 21:14:30 +0000
Subject: [issue3797] mmap, dbm, ossaudiodev,
	marshal & winreg return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220735670.49.0.918412858364.issue3797@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Hello. I confirmed test_winreg.py passed after applied
marshal-winreg_bytes.patch.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:17:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 21:17:00 +0000
Subject: [issue1674032] Make threading.Event().wait(timeout=3) return isSet
Message-ID: <1220735820.35.0.709010681074.issue1674032@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree this would be a worthwhile addition too. Unfortunately given the
current schedule this will probably have to wait for 2.7/3.1.

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674032>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:18:49 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 21:18:49 +0000
Subject: [issue3797] mmap, dbm, ossaudiodev,
	marshal & winreg return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220735929.51.0.8181741108.issue3797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Tests pass here as well, under Windows and Linux.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:19:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 21:19:12 +0000
Subject: [issue3797] mmap, dbm, ossaudiodev,
	marshal & winreg return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220735952.5.0.0450241517056.issue3797@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- PyBytes_Resize takes a PyObject**, you should pass &rv. Didn't you get
a compiler warning?

- Here is an additional test for the winreg module, your patch is needed
for it to pass.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:20:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 21:20:42 +0000
Subject: [issue3797] mmap, dbm, ossaudiodev,
	marshal & winreg return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220736042.94.0.934081224877.issue3797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As for ossaudiodev:

-    PyByteArray_Resize(rv, count);
+    _PyBytes_Resize(rv, count);

I think this should be _PyBytes_Resize(&rv, count) instead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:21:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 21:21:19 +0000
Subject: [issue3797] mmap, dbm, ossaudiodev,
	marshal & winreg return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220736079.13.0.80064778669.issue3797@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury beat me to the punch :-o

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:22:50 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 21:22:50 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220736170.75.0.122410578168.issue3777@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a patch that restores the float->long conversion. The function
was simply copied from 2.5.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11410/float_long.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:26:43 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 06 Sep 2008 21:26:43 +0000
Subject: [issue1317] smtplib.SMTP docs
In-Reply-To: <1193167470.47.0.372860933497.issue1317@psf.upfronthosting.co.za>
Message-ID: <1220736403.72.0.802113398538.issue1317@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Documentation added in rev. 66272.

----------
assignee:  -> akuchling
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1317>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:33:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 21:33:43 +0000
Subject: [issue3795] wsgiref.simple_server fails to run demo_app
In-Reply-To: <1220729895.68.0.892573521462.issue3795@psf.upfronthosting.co.za>
Message-ID: <1220736823.23.0.242318689457.issue3795@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This seems to be a duplicate of #3348.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3795>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:34:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 21:34:23 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1220736863.35.0.652162703048.issue3348@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also reported in #3795.
PJE, are you willing to work on this some day?

----------
nosy: +Walling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:35:20 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 21:35:20 +0000
Subject: [issue3797] mmap, dbm, ossaudiodev,
	marshal & winreg return bytearray instead of bytes
In-Reply-To: <1220733973.88.0.0354187973694.issue3797@psf.upfronthosting.co.za>
Message-ID: <1220736920.82.0.460341925655.issue3797@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

heh indeed it should be &rv.  i made the patch on a mac and hadn't run
it on my linux host before opening the issue.

fixed locally and given all of the reviews across all relevant
platforms.. committing.  py3k r66273.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3797>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:42:28 2008
From: report at bugs.python.org (David Naylor)
Date: Sat, 06 Sep 2008 21:42:28 +0000
Subject: [issue2320] Race condition in subprocess using stdin
In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za>
Message-ID: <1220737348.98.0.51284686394.issue2320@psf.upfronthosting.co.za>


David Naylor <naylor.b.david at gmail.com> added the comment:

I'm currently developing a script that makes extensive use of threads 
and Popen, with threads being created dynamically and each thread 
creating a large number of Popen processes.  

If I limit the thread count to 2 (main + worker) then the problem 
appears to disappear (or is just intermittent) however if I run with 
more than 2 threads or from within winpdb then the dead lock occurres 
rather consistently (and in the case of winpdb, always)

According to winpdb the script hangs on line 1086 of subprocess.py 
(from 2.5.2), strangely all remaining worker threads hand at this 
point:
    # Wait for exec to fail or succeed; possibly raising exception
==> data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
    os.close(errpipe_read)
    if data != "":
        os.waitpid(self.pid, 0)
        child_exception = pickle.loads(data)
        raise child_exception

I tried the suggestion of adding close_fds=True or using a global lock 
but the script still hangs under winpdb.  A solution that did appear 
to work was having both a global lock and adding close_fds=True to the 
call list.  

Running the script under pdb or cProfile appears to fix the problem as 
well...

NOTE: winpdb appears to bring out the worst case scenario and reliably 
reproduces the problem.

This is running on FreeBSD 8-Current amd64 (from early August) with 2 
cores.

----------
nosy: +DragonSA

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2320>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:51:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 21:51:02 +0000
Subject: [issue3798] SystemExit incorrectly displays unicode message
In-Reply-To: <1220737862.32.0.22799945135.issue3798@psf.upfronthosting.co.za>
Message-ID: <1220737862.32.0.22799945135.issue3798@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

When SystemExit is raised with a string argument, it is printed as UTF-8
to the (libc) stderr, and does not use the terminal's encoding.

handle_system_exit() should use PyFile_WriteString() instead of
PyObject_Print().

----------
messages: 72708
nosy: amaury.forgeotdarc
severity: normal
status: open
title: SystemExit incorrectly displays unicode message
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3798>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:51:33 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 21:51:33 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1220737893.34.0.979049548389.issue1068268@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

its too late in the release process for subprocess internals being EINTR
safe to make it into 2.6 but it is reasonable for 2.6.1.

----------
priority: low -> normal
type:  -> behavior
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:56:42 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 21:56:42 +0000
Subject: [issue3645] readline module Crashs on OpenBSD/amd64
In-Reply-To: <1219383669.6.0.427882345707.issue3645@psf.upfronthosting.co.za>
Message-ID: <1220738202.58.0.446322743491.issue3645@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

true, issue 1204 is more general.  i'll leave this in but it can be
removed once the better general fix is in with 1204.  i won't backport
this one.

----------
keywords: +64bit
status: pending -> closed
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3645>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:59:32 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 06 Sep 2008 21:59:32 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

Consider these two timeit commands:

py3k% python3.0 -m timeit -s 'import dbm.ndbm as db' -s 'f = 
db.open("/tmp/trash.db", "c")' 'for i in range(1000): f[str(i)] = str(i)'
100 loops, best of 3: 5.51 msec per loop
py3k% python3.0 -m timeit -s 'import dbm.dumb as db' -s 'f = 
db.open("/tmp/trash.db", "c")' 'for i in range(1000): f[str(i)] = str(i)'
Traceback (most recent call last):
  File "/Users/skip/local/lib/python3.0/timeit.py", line 297, in main
    x = t.timeit(number)
  File "/Users/skip/local/lib/python3.0/timeit.py", line 193, in timeit
    timing = self.inner(it, self.timer)
  File "<timeit-src>", line 7, in inner
    for i in range(1000): f[str(i)] = str(i)
  File "/Users/skip/local/lib/python3.0/dbm/dumb.py", line 165, in 
__setitem__
    raise TypeError("keys must be bytes")
TypeError: keys must be bytes

Seems to me they should either both succeed or both fail.  What are keys
and values supposed to be for these modules?

Marking it as high priority.  When 3.0 is released all these modules
should probably agree.

----------
messages: 72711
nosy: skip.montanaro
priority: high
severity: normal
status: open
title: Byte/string inconsistencies between different dbm modules
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Sat Sep  6 23:59:38 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 21:59:38 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220738378.17.0.698012693083.issue1204@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

when committing this one, the platform specific openbsd/amd64 fix I
committed for this in issue 3645 should probably be verified as unneeded
and undone.

marking as release blocker as we should make sure this autoconf update
goes in before the 2.6/3.0 release.  compiling for 64bit with readline
should work out of the box withing requiring patches on the most common
OSes.

I'm verifying rpetrov's patch in my centos4 VM now...

----------
assignee: akuchling -> gregory.p.smith
nosy: +gregory.p.smith
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:14:29 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Sat, 06 Sep 2008 22:14:29 +0000
Subject: [issue3348] Cannot start wsgiref simple server in Py3k
In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za>
Message-ID: <1220739269.91.0.646813849458.issue3348@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Not any time soon; I don't currently use Py3K and can't even vouch for
the correctness of the posted patch within Py3K.  (i.e., what really
happened to the message class?)  Sorry; all I can really do here is
clarify WSGI-related questions.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3348>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:20:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 22:20:19 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220739619.97.0.520706379238.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This patch corrects the "-m" case on windows: the path has to be
decoded/recoded using the filesystem encoding, and not the default utf-8.
Review is needed, of course.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file11411/find_module_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:20:58 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 06 Sep 2008 22:20:58 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220725898.57.0.37480439904.issue3781@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809061520o5e170ae2pb5b3092c382595e2@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sat, Sep 6, 2008 at 11:31 AM, Barry A. Warsaw <report at bugs.python.org> wrote:
>
> Barry A. Warsaw <barry at python.org> added the comment:
>
> Sounds good.  This needs to go into 2.6 and 3.0.

Oh, definitely.

>  And while you're add
> it, can you add catch_warnings to the __all__?
>

Yep. And I will also change the __init__() so that it properly forces
keyword-only arguments in 2.6 like 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:27:04 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 22:27:04 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220740024.76.0.223576581551.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

forkthread2.patch looks good to me.  to be consistent shouldn't we also
apply that fix to 2.6?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:34:14 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 22:34:14 +0000
Subject: [issue874900] threading module can deadlock after fork
In-Reply-To: <1220740024.76.0.223576581551.issue874900@psf.upfronthosting.co.za>
Message-ID: <1220740446.5581.0.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 06 septembre 2008 ? 22:27 +0000, Gregory P. Smith a ?crit :
> Gregory P. Smith <greg at krypto.org> added the comment:
> 
> forkthread2.patch looks good to me.  to be consistent shouldn't we also
> apply that fix to 2.6?

Only the ident-resetting part needs to be backported, the rest is
py3k-specific (especially _stopped vs. _Thread__stopped :-)).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:43:08 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 06 Sep 2008 22:43:08 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220740988.99.0.389180907278.issue3777@psf.upfronthosting.co.za>


Barry Alan Scott <barry-scott at users.sourceforge.net> added the comment:

My concern and yours is that this is not backwards
compatible. I would hate to see "random" failures
of extensions written using PyCXX because of this.

I'm tempted to says that I'll keep PyCXX 5.x as is for
Python 2.x and leave all the changes in semantics
for PyCXX 6.0 that will support Python 3.0.
And in Python 3.0 this problem does not exist
by design.

I don't think you example proves anything.
Python does not check at the pure python level at all.

>>> class X:
...     def __long__( self ):
...             return "Hello"
... 
>>> long( X() )
'Hello'
>>> 

You get all you deserve if you define __long__ and break its
API.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:43:17 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Sat, 06 Sep 2008 22:43:17 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220740997.47.0.760604671085.issue3783@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Here's an alternate version with most of bsddb's interface intact.

----------
nosy: +josiahcarlson
Added file: http://bugs.python.org/file11412/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sun Sep  7 00:50:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 22:50:46 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1220739619.97.0.520706379238.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220741442.5581.2.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good and works under Linux.
One small nit, you could just as well use "NN(ssi)" for the
Py_BuildValue and remove Py_DECREF(fob), so as to be more consistent.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Sun Sep  7 01:04:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 23:04:58 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220742298.95.0.148886870132.issue874900@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r66274, r66275. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Sep  7 02:00:05 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 07 Sep 2008 00:00:05 +0000
Subject: [issue2420] Faq 4.28 -- Trailing comas
In-Reply-To: <1205916647.4.0.701365283019.issue2420@psf.upfronthosting.co.za>
Message-ID: <1220745605.43.0.630766323754.issue2420@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I've edited the suggested text and added it to the FAQ
in rev. 11722.  Thanks for your contribution!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2420>
_______________________________________

From report at bugs.python.org  Sun Sep  7 02:27:52 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 00:27:52 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220747272.58.0.8960474174.issue1204@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I've attached an updated patch.  Not much changed other than the better
diff -u format, a couple grammar errors in comments and inclusion of the
new autoconf generated configure script.

It works fine for me on ubuntu hardy 32bit, CentOS 5.x x86_64, MacOS X
10.5 32-bit and 64-bit.

Could someone confirm on a platform where linking with 64bit readline
was broken before that this fixes it.  I added Henry Precheur to the
nosy list as he should be able to confirm on OpenBSD/amd64.

Lowering this to deferred blocker as it need not hold up -rc1 so long as
we get it in before -rc2.

----------
keywords: +needs review
nosy: +henry.precheur
priority: release blocker -> deferred blocker
versions: +Python 3.0
Added file: http://bugs.python.org/file11413/configure-readline-libs-64bit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 02:38:12 2008
From: report at bugs.python.org (Senthil)
Date: Sun, 07 Sep 2008 00:38:12 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1220747892.34.0.673954176079.issue3704@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

The patch and tests look fine to me, Gregory. I verified it against the
trunk. Should not we have it for py3k as well?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Sun Sep  7 02:54:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 00:54:47 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220748887.04.0.518138103811.issue3783@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

sq_dict review:

have sqlite quote/escape self._mtn before using it with a python %s
substitution.  or pass it into the sql query function as a positional ?
parameter like you do for keys and values.  (avoid sql injection)

raise a TypeError rather than a ValueError when you don't like the key
or value type.

also, to test the type, isinstance(val, str) is better than using type(val).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sun Sep  7 02:57:25 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 00:57:25 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1220749045.69.0.396947729136.issue3704@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

yep it applies to all releases.  anyways, it won't make 2.6/3.0 but it
can be put into 2.5.3/2.6.1/3.0.1.

----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Sun Sep  7 03:04:18 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 01:04:18 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1220749458.93.0.374127302911.issue874900@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I backported the last bit from r66275 to release25-maint in r66279.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Sun Sep  7 03:36:13 2008
From: report at bugs.python.org (Henry Precheur)
Date: Sun, 07 Sep 2008 01:36:13 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220751373.76.0.889607407851.issue1204@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

According to config.log the readline functions are correctly detected. I
tested the patch with Python 2.5 & 2.6 and both work with the test I
posted on issue 3645.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 05:34:23 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Sun, 07 Sep 2008 03:34:23 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1220758463.44.0.775831399012.issue3783@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I tried passing the db name as a parameter with '?', it doesn't always 
work.  Also, there shouldn't be any SQL injection issues here unless 
someone designed their system wrong (if a third party is allowed to pass 
the name of a db table into the open/create function, then they can do 
much worse than mangle or hide data in a sqlite database).

With regards to isinstance being better than type; it's only better if 
you want to support subclasses.  When writing the module, I had no 
interest in supporting subclasses (though supporting both str and buffer 
in 2.x, and bytes and memoryview in 3.x seems reasonable).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Sun Sep  7 05:54:34 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Sun, 07 Sep 2008 03:54:34 +0000
Subject: [issue3764] asyncore differences between 2.x and 3.x
In-Reply-To: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>
Message-ID: <1220759674.66.0.907322226516.issue3764@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed in 66281.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3764>
_______________________________________

From report at bugs.python.org  Sun Sep  7 06:29:19 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 04:29:19 +0000
Subject: [issue3764] asyncore differences between 2.x and 3.x
In-Reply-To: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>
Message-ID: <1220761759.4.0.711580567659.issue3764@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

please undo this, this broke asyncore in trunk.  handle_close_event 
doesn't exist in 2.6.

----------
nosy: +gregory.p.smith
priority:  -> release blocker
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3764>
_______________________________________

From report at bugs.python.org  Sun Sep  7 06:30:32 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 04:30:32 +0000
Subject: [issue3764] asyncore differences between 2.x and 3.x
In-Reply-To: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>
Message-ID: <1220761832.32.0.827016288081.issue3764@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +easy
type:  -> behavior
versions: +Python 2.6 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3764>
_______________________________________

From report at bugs.python.org  Sun Sep  7 06:44:24 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Sun, 07 Sep 2008 04:44:24 +0000
Subject: [issue3764] asyncore differences between 2.x and 3.x
In-Reply-To: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>
Message-ID: <1220762664.31.0.399088838865.issue3764@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I reverted the change I made to 2.6, see 66282.

The handle_close_event() method also doesn't exist in 3.0, which is why 
it (and the reference) were removed in revision 64883.  Giampaolo needs 
to update his Python 3.0 checkout.

Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3764>
_______________________________________

From report at bugs.python.org  Sun Sep  7 07:18:16 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 05:18:16 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220764696.93.0.843425026664.issue1204@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r66283 (followed by rerunning autoconf to generate a new
configure script in r66284).

----------
keywords:  -needs review
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 08:44:42 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 06:44:42 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220769882.12.0.729883885186.issue1204@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

merged into py3k branch in r66285.

backported to release25-maint in r66288 and r66289.

----------
resolution:  -> accepted
status: open -> closed
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 09:46:32 2008
From: report at bugs.python.org (skomoroh)
Date: Sun, 07 Sep 2008 07:46:32 +0000
Subject: [issue3800] Fix for formatter.py
In-Reply-To: <1220773592.58.0.798930732664.issue3800@psf.upfronthosting.co.za>
Message-ID: <1220773592.58.0.798930732664.issue3800@psf.upfronthosting.co.za>


New submission from skomoroh <skomoroh at gmail.com>:

Code:
import formatter
w = formatter.DumbWriter()
f = formatter.AbstractFormatter(w)
f.push_margin('dd')
f.pop_margin()

Result:
Traceback (most recent call last):
  File "formatter_test.py", line 7, in <module>
    f.push_margin('dd')
  File "/usr/local/lib/python3.0/formatter.py", line 261, in push_margin
    self.writer.new_margin(margin, len(fstack))
TypeError: object of type 'filter' has no len()

I've attached the trivial patch for fix it.

----------
components: Library (Lib)
files: formatter.patch
keywords: patch
messages: 72735
nosy: skomoroh
severity: normal
status: open
title: Fix for formatter.py
versions: Python 3.0
Added file: http://bugs.python.org/file11414/formatter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3800>
_______________________________________

From report at bugs.python.org  Sun Sep  7 12:50:56 2008
From: report at bugs.python.org (Graham Higgins)
Date: Sun, 07 Sep 2008 10:50:56 +0000
Subject: [issue3746] Sphinx producing duplicate id attributes,
	HTML fails validation.
In-Reply-To: <1220263337.27.0.506394651597.issue3746@psf.upfronthosting.co.za>
Message-ID: <1220784656.31.0.820696373328.issue3746@psf.upfronthosting.co.za>


Graham Higgins <gjh-python at bel-epa.com> added the comment:

Now confirmed. To reproduce, run sphinx-quickstart with project name 
"Test", accepting all defaults. Execute "make html", examine 
.build/html/index.html to find:

<div class="section" id="welcome-to-test-s-documentation">
<h1 id="welcome-to-test-s-documentation">

Added file: http://bugs.python.org/file11415/index.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3746>
_______________________________________

From report at bugs.python.org  Sun Sep  7 13:29:47 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 07 Sep 2008 11:29:47 +0000
Subject: [issue3764] asyncore differences between 2.x and 3.x
In-Reply-To: <1220448391.23.0.861310246092.issue3764@psf.upfronthosting.co.za>
Message-ID: <1220786987.05.0.981723804487.issue3764@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Sorry, my fault.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3764>
_______________________________________

From report at bugs.python.org  Sun Sep  7 15:24:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Sep 2008 13:24:49 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220793889.08.0.98237542827.issue3777@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Jeffery, you made this change in r59671. Can you comment?

----------
nosy: +benjamin.peterson, jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Sun Sep  7 17:03:11 2008
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sun, 07 Sep 2008 15:03:11 +0000
Subject: [issue3417] make the fix_dict fixer smarter
In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za>
Message-ID: <1220799791.7.0.0145798920898.issue3417@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

(I've just realized it's not working properly for fix_dict; I'm fixing
it and will drop a note here when it is)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3417>
_______________________________________

From report at bugs.python.org  Sun Sep  7 17:29:31 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 07 Sep 2008 15:29:31 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1220801371.14.0.129402024124.issue3799@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Making this into a release blocker just so someone will look at it.
Needs to be decided & fixed by rc2 at the very latest.

----------
nosy: +gvanrossum
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Sun Sep  7 18:16:03 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 07 Sep 2008 16:16:03 +0000
Subject: =?utf-8?q?[issue3680]_Cycles_with_some_iterator_are=09leaking.?=
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <48C3FE40.1010109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This is my first excursion into cyclic garbage collector
> implementations, so please review carefully.

If you don't implement a tp_clear function, you should leave
a comment why not. I think it's ok, since the underlying
containers will get cleared, thus breaking the cycle.

> Also, I am not sure about
> tp_traverse for the deque type. Must the block member also be considered
> or is the deque member sufficient?

It is fine as-is. The iterator doesn't own the reference to the block
objects, and traversing the deque will also traverse all contained
objects.

> Finally, do you consider this a show stopper?

Not me. As-is, this bug doesn't cause crashes, and can be worked-around
in applications (by explicitly breaking the cycle).

----------
nosy: +loewis
title: Cycles with some iterator are leaking. -> Cycles with some iterator are	leaking.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________

From report at bugs.python.org  Sun Sep  7 18:45:03 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 07 Sep 2008 16:45:03 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1220805903.19.0.40828029175.issue3690@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm not sure this is a bug. sys.getsizeof doesn't take padding in the
malloc implementation into account, either, so a long object that
accounts to 22 bytes (such as the number 1) uses at least 24 bytes,
also. In any case, I also think this doesn't matter much either way.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Sun Sep  7 19:03:22 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 07 Sep 2008 17:03:22 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1220807002.27.0.926333549106.issue3799@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Extra data point.  I tried

  f["1"] = "a"

and

  f[b"1"] = "a"

with dbm.{gnu,ndbm,dumb,sqlite}.  All worked with bytes.  A except
dbm.dumb worked with strings.  (dbm.sqlite is my little proof-of-concept
module currently in the sandbox.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Sun Sep  7 19:28:28 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 07 Sep 2008 17:28:28 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220808508.42.0.187640842502.issue1204@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I realize too late that in my patch line "if test $py_cv_lib_readline =
!yes; then" is not correct. :(
It has to be "if test $py_cv_lib_readline = no; then", i.e. s/!yes/no/'.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 19:33:11 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 07 Sep 2008 17:33:11 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1220808791.42.0.966916457508.issue3799@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

How hard would it be to fix dbm.dumb to accept strings as well?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Sun Sep  7 20:39:34 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 18:39:34 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220812774.7.0.780972601261.issue1204@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

eek.  not quite fixed then :)

i'll retest and take care of it.

----------
resolution: accepted -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 21:20:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 19:20:09 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220815209.2.0.908993302807.issue1204@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r66295/r66296.

merging and backporting now...

----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 21:26:46 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 07 Sep 2008 19:26:46 +0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1220815606.17.0.681605976275.issue1204@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

merged to py3k r66297 + r66298

backported to release25-maint r66299 + r66300.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
_______________________________________

From report at bugs.python.org  Sun Sep  7 21:28:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 07 Sep 2008 19:28:35 +0000
Subject: [issue3760] PEP 3121 --- PyType_Copy is missing
In-Reply-To: <1220383344.44.0.399854586534.issue3760@psf.upfronthosting.co.za>
Message-ID: <1220815715.73.0.472406288146.issue3760@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The intention is that different interpreters have distinct, separate
instances of the type objects. This is desirable in case of class
variables, and standard for Python-defined types. Clearly, 3.0 won't
provide that separation for many of the builtin types (and never may);
for out-of-core types, it is really the choice of the module designer.

I forgot to implement PyType_Copy; it is meant to create a new type
object which is a field-by-field copy. It's now too late to add it to
3.0; extension authors requiring it now should include it's source code
(which is currently not even written - contributions are welcome).

Reconsidering it: what should it do to the base types? 
 a) just incref tp_base and clone tp_bases, 
 b) offer an optional parameter to specify an alternative base object, 
 c) offer an optional parameter to specify an alternative bases tuple.

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3760>
_______________________________________

From report at bugs.python.org  Sun Sep  7 21:45:13 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 07 Sep 2008 19:45:13 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1220437690.76.0.371830111912.issue3526@psf.upfronthosting.co.za>
Message-ID: <48C42F47.4070005@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I will try to do that patch in coming weeks (obmalloc mostly allocates
> some 256KB arenas so it should nearly always use mmap).

Exactly so. If you can, please also consider supporting Windows, in the
same way.

Anything in obmalloc that is not arena space should continue to come
from malloc, I believe.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Sun Sep  7 22:16:41 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Sep 2008 20:16:41 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220818601.61.0.168399213056.issue3781@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sun Sep  7 22:18:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 07 Sep 2008 20:18:12 +0000
Subject: [issue3784] Incorrect compiler options used for cc of Sun Studio 12
In-Reply-To: <1220600511.19.0.379971962657.issue3784@psf.upfronthosting.co.za>
Message-ID: <1220818692.95.0.942608217647.issue3784@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Also, can you please attach your config.log?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3784>
_______________________________________

From report at bugs.python.org  Sun Sep  7 22:23:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 07 Sep 2008 20:23:09 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1220818989.25.0.774554280332.issue3786@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think this is a bug in Python? It sounds like a bug in the
operating system to me.

(actually, it's two bugs - please use separate bug reports in the future:
one is that Solaris doesn't implement wchgat, and the other one that it
doesn't provide SEM_VALUE_MAX. Neither is a fatal bug, though, since
it's just some extension modules that thus fail to build)

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Sun Sep  7 22:31:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 07 Sep 2008 20:31:01 +0000
Subject: [issue3791] bsddb not completely removed
In-Reply-To: <1220661145.94.0.113291838613.issue3791@psf.upfronthosting.co.za>
Message-ID: <1220819461.95.0.0368782221296.issue3791@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine to me, please apply.

----------
assignee:  -> amaury.forgeotdarc
keywords:  -needs review
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3791>
_______________________________________

From report at bugs.python.org  Sun Sep  7 23:29:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Sep 2008 21:29:17 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220822957.31.0.994306911459.issue3781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The new patch ditches the WarningsRecorder class and just returns a list
that is directly mutated. I also removed all uses of
test.test_support.catch_warning() and moved them over. Docs have been
thoroughly updated to give example usage. And lastly, I fixed bsddb to
use catch_warnings() where it was blindly resetting the warnings filter.
It still sets a filter at the top of the module, but I didn't want to
have to search for all potential places where catch_warnings() would
have been needed.

Added file: http://bugs.python.org/file11416/clean_up_catch_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sun Sep  7 23:29:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Sep 2008 21:29:26 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220822966.04.0.93114999948.issue3781@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file11382/catch_warnings_atts.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Mon Sep  8 00:06:28 2008
From: report at bugs.python.org (Kevin M. Turner)
Date: Sun, 07 Sep 2008 22:06:28 +0000
Subject: [issue3801] cgi.parse_qsl does not return list
In-Reply-To: <1220825188.21.0.705754581726.issue3801@psf.upfronthosting.co.za>
Message-ID: <1220825188.21.0.705754581726.issue3801@psf.upfronthosting.co.za>


New submission from Kevin M. Turner <acapnotic at users.sourceforge.net>:

This is a regression from 2.5 that causes our test suite to fail in 2.6.

Looks like a cut-and-paste bug.  Patch attached.

----------
components: Library (Lib)
files: cgi_parse_qsl.diff
keywords: patch
messages: 72755
nosy: acapnotic
severity: normal
status: open
title: cgi.parse_qsl does not return list
versions: Python 2.6
Added file: http://bugs.python.org/file11417/cgi_parse_qsl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3801>
_______________________________________

From report at bugs.python.org  Mon Sep  8 02:24:29 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 08 Sep 2008 00:24:29 +0000
Subject: [issue3801] cgi.parse_qsl does not return list
In-Reply-To: <1220825188.21.0.705754581726.issue3801@psf.upfronthosting.co.za>
Message-ID: <1220833469.53.0.0779913258045.issue3801@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Dumb error, it was even only in 2.6, 3.0 was ok.

Thanks for noticing it, I fixed it and added tests for both versions.

Thank you again!!

----------
nosy: +facundobatista
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3801>
_______________________________________

From report at bugs.python.org  Mon Sep  8 02:26:16 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 08 Sep 2008 00:26:16 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1220833576.66.0.821569313311.issue3799@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I'm not sure.  I've never done anything with the io module.  Simply
eliminating the bytes checks and letting it try to write the string
yields:

  File "/Users/skip/local/lib/python3.0/dbm/dumb.py", line 170, in 
__setitem__
    self._addkey(key, self._addval(val))
  File "/Users/skip/local/lib/python3.0/dbm/dumb.py", line 138, in 
_addval
    f.write(val)
  File "/Users/skip/local/lib/python3.0/io.py", line 1224, in write
    return BufferedWriter.write(self, b)
  File "/Users/skip/local/lib/python3.0/io.py", line 1034, in write
    raise TypeError("can't write str to binary stream")

I suppose you'd have to check if val is an instance of str and if so,
encode it as utf-8.  I notice in the existing code that it's doing
some key decoding assuming latin-1.  That would be an incompatibility,
but I think assuming latin-1 is wrong.

That said, I've attached a patch which passes all current unit tests.

Skip

----------
keywords: +patch
Added file: http://bugs.python.org/file11418/dumb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Mon Sep  8 02:52:07 2008
From: report at bugs.python.org (Tim Peters)
Date: Mon, 08 Sep 2008 00:52:07 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1220835127.56.0.0764264373645.issue3526@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

> Anything in obmalloc that is not arena space should continue to come
> from malloc, I believe.

Sorry, but I don't understand why arena space should be different.  If a
platform's libc implementers think mmap should be used to obtain 256KB
chunks (i.e., arenas), then surely they implement the platform malloc to
defer to mmap in such cases.  If they don't but "should", then bugging
the platform vendor to improve the system malloc in this respect is the
best idea (then all apps on the platform benefit, and Python stays simpler).

OTOH, if for some compelling reason it's believed Python knows better
than platform vendors, then obmalloc should be uglied-up on all paths to
make the enlightened choice.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Mon Sep  8 03:35:57 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Mon, 08 Sep 2008 01:35:57 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220837757.81.0.520135181652.issue3756@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

I don't think it's possible to say whether it's preformance critical - 
I can certainly image use cases such as parser generators where its 
speed could be noticed.

I tried building a version using regular expressions, but I couldn't do 
any better than 5x slower than the existing implementations, and the 
resulting code was less readable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3756>
_______________________________________

From report at bugs.python.org  Mon Sep  8 04:12:55 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Mon, 08 Sep 2008 02:12:55 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1220839975.05.0.692473113254.issue3756@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

I meant "I can certainly imagine use cases..."

In case it's not clear, I think the implementation in the patch is 
"good enough" (unless someone can suggest any obvious optimisations).

If someone can prove that re.escape() performance is causing problems 
for other modules in the standard lib (email, ctypes, warnings, 
fnmatch, _strptime use it, among others), then we might consider a C 
implementation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3756>
_______________________________________

From report at bugs.python.org  Mon Sep  8 05:21:23 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 08 Sep 2008 03:21:23 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1220835127.56.0.0764264373645.issue3526@psf.upfronthosting.co.za>
Message-ID: <48C49A30.9000800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> OTOH, if for some compelling reason it's believed Python knows better
> than platform vendors, then obmalloc should be uglied-up on all paths to
> make the enlightened choice.

I'm proposing that obmalloc is changed to know better than system malloc
on systems supporting anonymous mmap, and Windows, and that the call

   malloc(ARENA_SIZE)

is replaced by mmap. This has the advantage of doing better than system
malloc on Solaris, plus it also might guarantee that arenas will be
POOL_SIZE aligned.

OTOH, the calls

  realloc(arenas, nbytes)
  malloc(nbytes)

should continue to go to system malloc, because they are typically
not multiples of the system page size.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Mon Sep  8 05:26:35 2008
From: report at bugs.python.org (Tim Peters)
Date: Mon, 08 Sep 2008 03:26:35 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1220844395.89.0.229703317276.issue3526@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

I have to admit that if Python /didn't/ know better than platform libc
implementers in some cases, there would be no point to having obmalloc
at all :-(

What you (Martin) suggest is reasonable enough.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Mon Sep  8 06:59:58 2008
From: report at bugs.python.org (Marcus CM)
Date: Mon, 08 Sep 2008 04:59:58 +0000
Subject: [issue3802] smtpd.py __getaddr insufficient handling
In-Reply-To: <1220849998.55.0.777734204126.issue3802@psf.upfronthosting.co.za>
Message-ID: <1220849998.55.0.777734204126.issue3802@psf.upfronthosting.co.za>


New submission from Marcus CM <marcus at internetnowasp.net>:

The __getaddr does not handle certain valid MAIL FROM well :

For eg,

<marcus at internetnow.com.my> SIZE=7777 AUTH=<>

would result in a mismatch of bracket handling.


Suggested fix is :-

def __getaddr(self, keyword, arg):
        address = None
        keylen = len(keyword)
        if arg[:keylen].upper() == keyword:
            address = arg[keylen:].strip()
            if not address:
                pass
            
            # Marcus fix :
            i  = address.count("<")
            ii = address.count(">")            
            if i != ii :
                address = None
                return address
            
            # Marcus remark : bug if : <abc at ap.com.my> SIZE=6092 AUTH=<>
            elif address[0] == '<' and address[-1] == '>' and address !
= '<>':
                # Addresses can be in the form <person at dom.com> but 
watch out
                # for null address, e.g. <>
                                
                if address.count("<") == 1 :
                    address = address[1:-1]
                    
        return address

----------
messages: 72763
nosy: marcus at internetnowasp.net
severity: normal
status: open
title: smtpd.py __getaddr insufficient handling
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3802>
_______________________________________

From report at bugs.python.org  Mon Sep  8 07:43:23 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 08 Sep 2008 05:43:23 +0000
Subject: [issue3492] Zlib compress/decompress functions returning bytearray
In-Reply-To: <1217672159.34.0.803781605821.issue3492@psf.upfronthosting.co.za>
Message-ID: <1220852603.27.0.731834186228.issue3492@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Hi Gregory,

      Let me know if I can help out some way in testing the #3797
patches on various platforms.

Regards,

--Anand

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3492>
_______________________________________

From report at bugs.python.org  Mon Sep  8 08:42:08 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Mon, 08 Sep 2008 06:42:08 +0000
Subject: [issue3784] Incorrect compiler options used for cc of Sun Studio 12
In-Reply-To: <1220600511.19.0.379971962657.issue3784@psf.upfronthosting.co.za>
Message-ID: <1220856128.4.0.782464728304.issue3784@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

It's a warning.

Added file: http://bugs.python.org/file11419/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3784>
_______________________________________

From report at bugs.python.org  Mon Sep  8 08:44:34 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Mon, 08 Sep 2008 06:44:34 +0000
Subject: [issue3784] Incorrect compiler options used for cc of Sun Studio 12
In-Reply-To: <1220600511.19.0.379971962657.issue3784@psf.upfronthosting.co.za>
Message-ID: <1220856274.18.0.0857646362299.issue3784@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

Attaching a log of the complete build process of Python 2.5.2.

Added file: http://bugs.python.org/file11420/build-Python-2.5.2.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3784>
_______________________________________

From report at bugs.python.org  Mon Sep  8 08:49:30 2008
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 08 Sep 2008 06:49:30 +0000
Subject: [issue3803] Comparison operators - New rules undocumented in Python
	3.0
In-Reply-To: <1220856570.81.0.704917897963.issue3803@psf.upfronthosting.co.za>
Message-ID: <1220856570.81.0.704917897963.issue3803@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

I've noticed that in Python 3.0, the <, >, <= and >= operators now raise
a TypeError when comparing objects of different types, rather than
ordering them "consistently but arbitrarily". The documentation doesn't
yet reflect this behaviour.

The current documentation says:
"(This unusual definition of comparison was used to simplify the
definition of operations like sorting and the in and not in operators.
In the future, the comparison rules for objects of different types are
likely to change.)"

I assume this is the change it's warning us about.

Hence I propose this patch to reference/expressions.rst, which removes
the above quoted paragraph and describes the new TypeError-raising
behaviour. My text is as follows:

"The objects need not have the same type. If both are numbers, they are
converted to a common type. Otherwise, the == and != operators always
consider objects of different types to be unequal, while the <, >, >=
and <= operators raise a TypeError when comparing objects of different
types."

----------
assignee: georg.brandl
components: Documentation
files: expressions.patch
keywords: patch
messages: 72767
nosy: georg.brandl, mgiuca
severity: normal
status: open
title: Comparison operators - New rules undocumented in Python 3.0
versions: Python 3.0
Added file: http://bugs.python.org/file11421/expressions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3803>
_______________________________________

From report at bugs.python.org  Mon Sep  8 08:49:38 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Mon, 08 Sep 2008 06:49:38 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1220856578.78.0.869721501879.issue3786@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

I filed that as a bug against Python 2.6, because in 2.5.2, the curses
modules could be built just fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Mon Sep  8 09:09:56 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 08 Sep 2008 07:09:56 +0000
Subject: [issue3784] Incorrect compiler options used for cc of Sun Studio 12
In-Reply-To: <1220600511.19.0.379971962657.issue3784@psf.upfronthosting.co.za>
Message-ID: <1220857796.59.0.917724709608.issue3784@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, now I see the problem. This is ctypes-specific, and ctypes requires
gcc on Solaris. Closing as "won't fix".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3784>
_______________________________________

From report at bugs.python.org  Mon Sep  8 09:11:19 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 08 Sep 2008 07:11:19 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220856578.78.0.869721501879.issue3786@psf.upfronthosting.co.za>
Message-ID: <48C4D014.3080504@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I filed that as a bug against Python 2.6, because in 2.5.2, the curses
> modules could be built just fine.

So would you like to work on a patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Mon Sep  8 11:00:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Sep 2008 09:00:01 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220864401.69.0.831091946021.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Updated patch.

Added file: http://bugs.python.org/file11422/find_module_unicode_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Mon Sep  8 11:39:33 2008
From: report at bugs.python.org (Pernici Mario)
Date: Mon, 08 Sep 2008 09:39:33 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1220866773.86.0.909854931309.issue3451@psf.upfronthosting.co.za>


Pernici Mario <pernici at users.sourceforge.net> added the comment:

I have translated in C the algorithm for long division by
Burnikel and Ziegler (BZ), using the Python version fast_div.py
and the suggestions by Mark.

Here is a benchmark for divmod(p. q), p = 7**np, q = 5**nq
digits = q_digits = p_digits/2; the time taken by Python division
is normalized to 1
tests on Debian, BZ with Python-2.6b3
        Pentium 1.60GHz    Athlon XP 2600+     Athlon 64 3800+
digits  BZ      fast_div   BZ      fast_div    BZ      fast_div
500     1.01    1.27       1.00    1.18        1.00    1.21
700     0.88    1.22       0.76    1.08        0.81    1.14
1000    0.82    1.17       0.72    1.04        0.76    1.10
2000    0.66    0.85       0.55    0.73        0.59    0.78
4000    0.51    0.62       0.43    0.52        0.45    0.56
10000   0.32    0.38       0.31    0.37        0.33    0.39
20000   0.24    0.25       0.23    0.25        0.25    0.27
100000  0.14    0.14       0.11    0.11        0.12    0.12

BZ starts being faster than Python division around 2000 bits, apart
from two cases:
 for q with less than 4000 bits and p much smaller than q**2
 x_divrem is faster than divmod_pos;
 for p very much larger than q**2 x_divrem becomes
 again faster.
I put a bound in long_divrem to fall back to x_divrem in those cases,
based on tests on my laptop Pentium 1.60GHz.

The treatment of exceptions is very rudimentary;
I use a simple macro STUB_EXC to return NULL,
but without releasing memory.
Help for doing this properly is welcome.

Please find attached the diff to the longobject.c file in Python-2.6b3 .

Mario

----------
nosy: +pernici
Added file: http://bugs.python.org/file11423/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Mon Sep  8 13:38:00 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 08 Sep 2008 11:38:00 +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: <1220873880.75.0.946259273675.issue2016@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
_______________________________________

From report at bugs.python.org  Mon Sep  8 14:24:53 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Sep 2008 12:24:53 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220876693.0.0.602725023498.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

./python -c "print('?')"
does not work on my Linux machine with latest py3k (r66303), certainly
because my terminal uses a latin-1 encoding: wcstombs will convert the
argument back to the terminal encoding, whereas PyRun_SimpleString
expects a UTF-8 string.

I join another patch, which propagates the wchar_t as far as possible,
and encodes it as utf-8; with test.

This also corrects the Windows case.

Added file: http://bugs.python.org/file11424/command_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Mon Sep  8 14:58:00 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 08 Sep 2008 12:58:00 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219934469.45.0.0810562153441.issue3714@psf.upfronthosting.co.za>
Message-ID: <20080908125725.GC12999@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

I verified the patch against the trunk. It works fine and solves the issue.
But, I have a minor concern over 'ascii' as the default encoding, which you
have chosen.

For e.g, when I ran python3.0 nntplib.py (It would run tests, as the module
does not have an explicit test), I got the following error due to encoding.
(tests read comp.lang.python)

UnicodeDecodeError: 'ascii' codec can't decode byte 0x93 in position 29:
ordinal not in range(128)

Setting the encoding to 'latin1', it passed.

Would 'latin1' be a better default encoding? Or should we leave it as 'ascii'.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Mon Sep  8 15:15:06 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Sep 2008 13:15:06 +0000
Subject: [issue3782] os.write accepts unicode strings
In-Reply-To: <1220568095.62.0.876870722017.issue3782@psf.upfronthosting.co.za>
Message-ID: <1220879706.46.0.631606307659.issue3782@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

posix_write() uses s* 

s* (string, Unicode, or any buffer compatible object) [Py_buffer *]
http://docs.python.org/dev/3.0/c-api/arg.html

IMHO os.write should not accept unicode and convert it to default
encoding. The low level os functions are all about bytes.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3782>
_______________________________________

From report at bugs.python.org  Mon Sep  8 15:27:14 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Mon, 08 Sep 2008 13:27:14 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1220880434.4.0.740565186703.issue3714@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Actually RFC-977 said all characters must be in ASCII, but RFC-3977
changed default character set to UTF-8. So I think UTF-8 must be default
encoding, not Latin-1. Moreover Latin-1 can silently hide a real
encoding, for example:

>>> u'\u0422\u0435\u0441\u0442'.encode("koi8-r").decode("latin1")
u'\xf4\xc5\xd3\xd4'

Additionally in the future it would be a good idea to look in the
article headers for article body encoding.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Mon Sep  8 15:28:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Sep 2008 13:28:55 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1220880535.23.0.728696470355.issue3714@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Setting the default encoding as "ascii" is very conservative until we
know the encoding actually used by the server.

Are you sure that comp.lang.python uses latin-1? RFC3977, which
re-defines the NNTP protocol, prefers utf-8 for the character set.

Is there a way to know the character set used by a server?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Mon Sep  8 15:36:11 2008
From: report at bugs.python.org (Senthil)
Date: Mon, 08 Sep 2008 13:36:11 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1220880535.23.0.728696470355.issue3714@psf.upfronthosting.co.za>
Message-ID: <20080908133558.GA17701@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

When the default encoding 'ascii' failed, I tried, 'utf-8', even that failed to
retrieve the message headers from comp.lang.python. 
'latin1' succeeded. That was reason for my suggestion, considering 'latin1' to
be superset of 'ascii'. 

But, yes checking the encoding at the server and using that would be a good
idea. The for the default, we could follow whatever RFC3977 recommends.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Mon Sep  8 15:41:56 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Mon, 08 Sep 2008 13:41:56 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1220881316.75.0.552701301923.issue3714@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

If I understand it correctly there is no "character set used by server"
because every article can be in different encoding. RFC-3977 say:

"""
The character set of article bodies SHOULD be indicated in the
article headers, and this SHOULD be done in accordance with MIME.
"""

But it's not always true, for example fido7.* groups known to use
"KOI-8R" encoding but I didn't find any relevant headers.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Mon Sep  8 15:54:51 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Mon, 08 Sep 2008 13:54:51 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <1220882091.47.0.52683137259.issue3714@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

RFC-3977 say the following about headers:

- The names of headers (e.g., "From" or "Subject") MUST be in
  US-ASCII.

- Header values SHOULD use US-ASCII or an encoding based on it, such
  as RFC 2047 [RFC2047], until such time as another approach has
  been standardised.  At present, 8-bit encodings (including UTF-8)
  SHOULD NOT be used because they are likely to cause
  interoperability problems.

But in practice for now there is no way to reliable find a header's
encoding.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Mon Sep  8 18:38:12 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 08 Sep 2008 16:38:12 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220891892.69.0.710478305621.issue3162@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I've applied Simon's patch to the 2.6 trunk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Mon Sep  8 18:45:51 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 08 Sep 2008 16:45:51 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220892351.39.0.158995548012.issue3162@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

And for the 3K branch.  Thanks!

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Mon Sep  8 19:11:06 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 08 Sep 2008 17:11:06 +0000
Subject: [issue3782] os.write accepts unicode strings
In-Reply-To: <1220568095.62.0.876870722017.issue3782@psf.upfronthosting.co.za>
Message-ID: <1220893866.14.0.860077823613.issue3782@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Agreed.  But we need to tread carefully -- fixing this might break other
stuff that has silently relied on it.  Better try it ASAP.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3782>
_______________________________________

From report at bugs.python.org  Mon Sep  8 19:26:33 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 08 Sep 2008 17:26:33 +0000
Subject: [issue516762] have a way to search backwards for re
Message-ID: <1220894793.64.0.879077989089.issue516762@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Does this request still stand? I'm working on the re module at the moment.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue516762>
_______________________________________

From report at bugs.python.org  Mon Sep  8 20:16:43 2008
From: report at bugs.python.org (Toby Donaldson)
Date: Mon, 08 Sep 2008 18:16:43 +0000
Subject: [issue3679] pressing HOME key in IDLE editor ends IDLE
In-Reply-To: <1219696636.82.0.798556102821.issue3679@psf.upfronthosting.co.za>
Message-ID: <1220897803.66.0.888457555035.issue3679@psf.upfronthosting.co.za>


Toby Donaldson <tjdonaldson at gmail.com> added the comment:

The problem seems to have disappeared in the 3.0b3 Windows installer
version --- the Home key seems to work as it should.

(However, to get IDLE to run at all in 3.03b, I had to apply the fix
listed here: http://bugs.python.org/issue3628)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3679>
_______________________________________

From report at bugs.python.org  Mon Sep  8 21:08:04 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 19:08:04 +0000
Subject: [issue3804] Test for issue2222 (r65745)
In-Reply-To: <1220900884.92.0.14463681622.issue3804@psf.upfronthosting.co.za>
Message-ID: <1220900884.92.0.14463681622.issue3804@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

This test is for issue2222. (I didn't know sys.getrefcount)
This test doesn't cover the case like os.rename(str, int), but it might
be better than no tests.

----------
components: Tests
files: test_for_issue2222.patch
keywords: needs review, patch
messages: 72786
nosy: ocean-city
severity: normal
status: open
title: Test for issue2222 (r65745)
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11425/test_for_issue2222.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3804>
_______________________________________

From report at bugs.python.org  Mon Sep  8 21:36:48 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Sep 2008 19:36:48 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Modules/_ssl.c in the py3k branch:

PySSL_SSLread():

 calls parsetuple expecting "|Oi" as arguments.

However the logic below to interpret and use the arguments is very
convoluted.  it'd be better to reorder these as "|iO" to match the api
in Lib/ssl.py.  Or even better to just get rid of the "O" all together
(currently used to pass in a bytearray buffer to write into instead of
allocating its own).

also:

it returns either a bytes or a long depending on the order and type of
arguments given.  yuck.

----------
assignee: janssen
components: Extension Modules
messages: 72787
nosy: gregory.p.smith, janssen
priority: high
severity: normal
status: open
title: sslobj.read py3k takes odd arguments
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Mon Sep  8 22:53:00 2008
From: report at bugs.python.org (Simon Cross)
Date: Mon, 08 Sep 2008 20:53:00 +0000
Subject: [issue3162] ssl.SSLSocket implements methods that are overriden by
	socket.socket.__init__ and methods with incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1220907180.63.0.80943208666.issue3162@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

And thanks for looking at them and applying! :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3162>
_______________________________________

From report at bugs.python.org  Mon Sep  8 23:10:10 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 08 Sep 2008 21:10:10 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220908210.49.0.0131782253687.issue3805@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

There was a reason to do it that way.  Now if I can only remember what
it was...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Mon Sep  8 23:11:12 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 08 Sep 2008 21:11:12 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220908272.29.0.756182707125.issue3805@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


----------
priority: high -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Mon Sep  8 23:45:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 21:45:04 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1220910304.87.0.167273354149.issue2562@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Does this need to be merged into py3k? If so, can someone who handled
this bug do it. I met a few test failures in my attempt...

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Mon Sep  8 23:46:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 21:46:38 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1220910398.91.0.524692906082.issue3708@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Gregory, could you merge this into py3k, please?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Mon Sep  8 23:51:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 21:51:36 +0000
Subject: [issue3804] Test for issue2222 (r65745)
In-Reply-To: <1220900884.92.0.14463681622.issue3804@psf.upfronthosting.co.za>
Message-ID: <1220910696.73.0.712703184719.issue3804@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think you should put test_rename in FileTests. Then we can write real
tests for os.rename sometimes else.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3804>
_______________________________________

From report at bugs.python.org  Mon Sep  8 23:59:55 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Sep 2008 21:59:55 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220911195.22.0.0796770781338.issue3805@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i only had a brief look when i was going through code looking for
potentially incorrect uses of PyByteArray_*.

I've got a patch that i believe cleans it up a little but its sitting on
a machine i don't have remote access to at the moment.  i'll attach it
when i get a chance.

Looking at Lib/ssl.py it appears that recv_into needs this functionality.

I'd still suggest changing the order to be "|iO" to simplify the code a
little.  The PyLong_Check(buf) could go away.  I do not see any calls to
_sslobj.read() within Lib.ssl.py that only pass in a buffer without
passing in a length.

When no bytearray is passed in, the code internally uses a temporary
bytearray object which is later freed after being copied into a bytes
object.  I think it would be better to just use
PyBytes_FromStringAndSize(0, len) and replace the "if (!buf_passed)"
conversion data copy with a _PyBytes_Resize?  The latter will only
realloc and copy if needed.

regardless, thanks for lowering the priority.  looking over the code
again I believe whats there is functionally correct even if a bit odd
looking.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:06:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 22:06:29 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1220911589.02.0.136606184501.issue3708@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Apparently this isn't an issue in py3k, so no worries! :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:12:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 22:12:42 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220911962.24.0.468099971845.issue3781@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patch mostly looks good. However, all the w[-1] logic looks rather
verbose to me since its main use case in testing will be making sure
*one* warning happened. Returning a list adds the extra step of checking
the length and then indexing it for the warning validation. I'm not
completely suggesting that you bring back the smart list, but maybe an
option on catch_warning to just yield the WarningMessage on __enter__.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:21:01 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 22:21:01 +0000
Subject: [issue3804] Test for issue2222 (r65745)
In-Reply-To: <1220900884.92.0.14463681622.issue3804@psf.upfronthosting.co.za>
Message-ID: <1220912461.7.0.0310502695625.issue3804@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

OK, this is revised patch.

Added file: http://bugs.python.org/file11426/test_for_issue2222.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3804>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:22:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 22:22:42 +0000
Subject: [issue3804] Test for issue2222 (r65745)
In-Reply-To: <1220900884.92.0.14463681622.issue3804@psf.upfronthosting.co.za>
Message-ID: <1220912562.41.0.49849035728.issue3804@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I think the patch is fine. (Please don't merge it yet, though. I'm
working on a merge now.)

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3804>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:23:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 22:23:12 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220912592.82.0.262590512752.issue3777@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

In the meantime, Amaury, you patch is good.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:24:35 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Sep 2008 22:24:35 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1220912675.96.0.812216982114.issue1868@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

i won't have time to work on this for several days but i will happily
review updated patches if anyone could contribute fixes for the __dict__
issues described in the most recent comments.

feel free to steal the issue from me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:31:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 22:31:28 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220913088.56.0.433722990874.issue3705@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think the patch good; go ahead.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:35:54 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 22:35:54 +0000
Subject: [issue3806] LockTests in test_imp should be skipped when thread is
	not available
In-Reply-To: <1220913354.36.0.779804691108.issue3806@psf.upfronthosting.co.za>
Message-ID: <1220913354.36.0.779804691108.issue3806@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

LockTests is meaningfull only when thread is available, so this patch
removes it from tests when thread is unavailable. This patch is for trunk.

----------
components: Tests
files: test_imp.patch
keywords: patch
messages: 72801
nosy: ocean-city
severity: normal
status: open
title: LockTests in test_imp should be skipped when thread is not available
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11427/test_imp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3806>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:38:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 22:38:00 +0000
Subject: [issue3806] LockTests in test_imp should be skipped when thread is
	not available
In-Reply-To: <1220913354.36.0.779804691108.issue3806@psf.upfronthosting.co.za>
Message-ID: <1220913480.97.0.712645786247.issue3806@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Why not just append LockTests to the tests after instead of deleting it
from the list?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3806>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:54:34 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 22:54:34 +0000
Subject: [issue3806] LockTests in test_imp should be skipped when thread is
	not available
In-Reply-To: <1220913354.36.0.779804691108.issue3806@psf.upfronthosting.co.za>
Message-ID: <1220914474.28.0.219926512173.issue3806@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Like attached new patch? There was no strong meaning. :-)
del tests[0] can can preserve order of tests, but it's not so important,
is it.

Added file: http://bugs.python.org/file11428/test_imp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3806>
_______________________________________

From report at bugs.python.org  Tue Sep  9 00:55:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 22:55:43 +0000
Subject: [issue3806] LockTests in test_imp should be skipped when thread is
	not available
In-Reply-To: <1220913354.36.0.779804691108.issue3806@psf.upfronthosting.co.za>
Message-ID: <1220914543.55.0.180345790996.issue3806@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Looks good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3806>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:17:34 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Sep 2008 23:17:34 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220911962.24.0.468099971845.issue3781@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809081617y64090161q82c24fbdb4eb3193@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Sep 8, 2008 at 3:12 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> The patch mostly looks good. However, all the w[-1] logic looks rather
> verbose to me since its main use case in testing will be making sure
> *one* warning happened. Returning a list adds the extra step of checking
> the length and then indexing it for the warning validation. I'm not
> completely suggesting that you bring back the smart list, but maybe an
> option on catch_warning to just yield the WarningMessage on __enter__.
>

Well, the real question is whether most users will use this for
testing, or for temporarily suppressing warnings. The stdlib is not a
normal use-case in this regard since we have to be so careful with
giving deprecations.

I honest don't fine the [-1] indexing that bad and I had to add all of
them. =) Makes it explicit you are assuming there is at least one
warnings (and probably only one) and you should check that there was
not an extra one.

I will wait to see if Barry has anything to say on the matter since he
pushed for the change.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:28:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Sep 2008 23:28:21 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1220916501.22.0.409243551402.issue3632@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can anyone review my new patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:42:39 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 23:42:39 +0000
Subject: [issue3804] Test for issue2222 (r65745)
In-Reply-To: <1220900884.92.0.14463681622.issue3804@psf.upfronthosting.co.za>
Message-ID: <1220917359.4.0.0427044145812.issue3804@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66316(trunk), r66318(release25-maint), r66320(py3k)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3804>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:43:38 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Sep 2008 23:43:38 +0000
Subject: [issue3606] 2to3: commands varible replaced by subprocess
In-Reply-To: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>
Message-ID: <1220917418.74.0.51223263463.issue3606@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, no problem. So you can close this (invalid) issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3606>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:45:47 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Sep 2008 23:45:47 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220917547.08.0.39609499943.issue3634@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug and the fix are trivials. Can anyone review my patch?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:54:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 23:54:50 +0000
Subject: [issue3606] 2to3: commands varible replaced by subprocess
In-Reply-To: <1219183541.38.0.933947202959.issue3606@psf.upfronthosting.co.za>
Message-ID: <1220918090.25.0.614604743705.issue3606@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3606>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:55:17 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 23:55:17 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I'm not sure how to fix this, (or even should fix this) when configure
--without-threads, error message is not pretty. This happens at trunk,
but probably same thing would happen at py3k.


gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25-i686-2.6/home/
WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/multiprocessing.o
build/te
mp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_multiproces
sing/socket_connection.o
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/pyth
on-dev/trunk/Modules/_multiprocessing/semaphore.o -L/usr/local/lib -L.
-lpython2
.6 -o build/lib.cygwin-1.5.25-i686-2.6/_multiprocessing.dll
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_mul
tiprocessing/semaphore.o: In function `semlock_acquire':
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:330:
und
efined reference to `_PyThread_get_thread_ident'
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:283:
und
efined reference to `_PyThread_get_thread_ident'
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_mul
tiprocessing/semaphore.o: In function `semlock_release':
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:339:
und
efined reference to `_PyThread_get_thread_ident'
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_mul
tiprocessing/semaphore.o: In function `semlock_ismine':
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:491:
und
efined reference to `_PyThread_get_thread_ident'
collect2: ld returned 1 exit status

----------
components: Build
messages: 72810
nosy: ocean-city
severity: normal
status: open
title: _multiprocessing build fails when configure --without-threads
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Tue Sep  9 01:58:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 08 Sep 2008 23:58:15 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220918295.51.0.258764838005.issue3634@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The patch looks absolutely fine to me. (I think I have to have another
core developer look at it too, though.)

----------
assignee:  -> benjamin.peterson
keywords: +needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 02:17:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Sep 2008 00:17:43 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220919463.24.0.268061893133.issue3634@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Adding a simple unit test would be nice.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 02:50:01 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Sep 2008 00:50:01 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220921401.19.0.405582983222.issue3781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Covered by r66321 in the trunk. Now I just need to merge into 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 03:17:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 01:17:55 +0000
Subject: [issue3808] test_cgi is giving deprecation warnings
In-Reply-To: <1220923075.22.0.836380316706.issue3808@psf.upfronthosting.co.za>
Message-ID: <1220923075.22.0.836380316706.issue3808@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

test_cgi
/temp/python/py3k/Lib/cgi.py:166: DeprecationWarning: cgi.parse_qs is
deprecated, use urllib.parse.parse_qs instead
  DeprecationWarning)
/temp/python/py3k/Lib/cgi.py:172: DeprecationWarning: cgi.parse_qsl is
deprecated, use urllib.parse.parse_qs instead
  DeprecationWarning)

----------
assignee: facundobatista
components: Tests
messages: 72814
nosy: benjamin.peterson, facundobatista
priority: normal
severity: normal
status: open
title: test_cgi is giving deprecation warnings
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3808>
_______________________________________

From report at bugs.python.org  Tue Sep  9 03:35:28 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 09 Sep 2008 01:35:28 +0000
Subject: [issue3808] test_cgi is giving deprecation warnings
In-Reply-To: <1220923075.22.0.836380316706.issue3808@psf.upfronthosting.co.za>
Message-ID: <1220924128.82.0.114849552861.issue3808@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

My fault, I'm exercising functions that have to raise a deprecation
warning... should I remove these tests?

Thank you!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3808>
_______________________________________

From report at bugs.python.org  Tue Sep  9 03:36:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 01:36:41 +0000
Subject: [issue3808] test_cgi is giving deprecation warnings
In-Reply-To: <1220923075.22.0.836380316706.issue3808@psf.upfronthosting.co.za>
Message-ID: <1220924201.06.0.184857461752.issue3808@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

No, just surround the tests in the warnings.catch_warning context
manager and filter out the DeprecationWarnings.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3808>
_______________________________________

From report at bugs.python.org  Tue Sep  9 03:52:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Sep 2008 01:52:50 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220925170.69.0.393946466582.issue3781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r66322 has the fix in 3.0.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 03:56:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Sep 2008 01:56:07 +0000
Subject: [issue3809] test_logging leaving a 'test.blah' file behind
In-Reply-To: <1220925367.02.0.0825641930975.issue3809@psf.upfronthosting.co.za>
Message-ID: <1220925367.02.0.0825641930975.issue3809@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test_logging is leaving behind a file named 'test.blah' after every run.

----------
assignee: vsajip
components: Tests
messages: 72818
nosy: brett.cannon, vsajip
priority: deferred blocker
severity: normal
status: open
title: test_logging leaving a 'test.blah' file behind
type: resource usage
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3809>
_______________________________________

From report at bugs.python.org  Tue Sep  9 04:44:18 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 09 Sep 2008 02:44:18 +0000
Subject: [issue3808] test_cgi is giving deprecation warnings
In-Reply-To: <1220923075.22.0.836380316706.issue3808@psf.upfronthosting.co.za>
Message-ID: <1220928258.44.0.498802902385.issue3808@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Fixed in r66326. Thank you!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3808>
_______________________________________

From report at bugs.python.org  Tue Sep  9 07:21:17 2008
From: report at bugs.python.org (Per Cederqvist)
Date: Tue, 09 Sep 2008 05:21:17 +0000
Subject: [issue3810] os.chdir() et al: is the path str or bytes?
In-Reply-To: <1220937677.05.0.675791850215.issue3810@psf.upfronthosting.co.za>
Message-ID: <1220937677.05.0.675791850215.issue3810@psf.upfronthosting.co.za>


New submission from Per Cederqvist <ceder at lysator.liu.se>:

The documentation at
http://docs.python.org/dev/3.0/library/os.html#os.chdir doesn't specify
if the path argument to os.chdir() should be a str or a bytes, or if
maybe both are acceptable.  This is true for most of the
file-manipulating functions in the os module.

os.listdir() talks about Unicode objects.  It should probably talk about
bytes and str instead.

----------
assignee: georg.brandl
components: Documentation
messages: 72820
nosy: ceder, georg.brandl
severity: normal
status: open
title: os.chdir() et al: is the path str or bytes?
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3810>
_______________________________________

From report at bugs.python.org  Tue Sep  9 07:37:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 05:37:54 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

This is a patch to update the Unicode database. It's mostly the imported
data, but there were two code changes:
- 5.1 changes the "mirrored" property for a character (U+0F3A), and the
delta-to-3.2 code did not support that. I added a field into
hange_record to support that kind of change.
- 5.1 also added a character (U+1d79) whose upper-case version is far
off (U+A77D), triggering a complaint that the delta can't be represented
in 16 bits. I fixed that adding a flag into the ctype record indicating
that deltas aren't used for that record.

Fredrik, can you please review these changes?

----------
assignee: effbot
files: ucd51.diff.bz2
keywords: needs review
messages: 72821
nosy: effbot, loewis
severity: normal
status: open
title: Update Unicode database to 5.1.0
versions: Python 2.6
Added file: http://bugs.python.org/file11429/ucd51.diff.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Tue Sep  9 07:39:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 05:39:54 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1220938794.44.0.645999750902.issue3811@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +patch -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Tue Sep  9 07:39:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 05:39:59 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1220938799.71.0.562484555692.issue3811@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Tue Sep  9 08:47:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 06:47:03 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1220942823.32.0.616112636839.issue3632@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is fine.
I don't know if it can make the 2.6 release, but it is very simple, and
affect only a function used in debugger macros.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Tue Sep  9 08:56:39 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 06:56:39 +0000
Subject: [issue3812] py3k build fails if configure --without-threads
In-Reply-To: <1220943399.18.0.51803892566.issue3812@psf.upfronthosting.co.za>
Message-ID: <1220943399.18.0.51803892566.issue3812@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. I failed to build py3k on cygwin (configure --without-threads).
It's because io.py imports _dummy_thread, and it imports traceback, and
it tries to import c-module itertools which is not built yet.

Attached file is workaround patch.

/////////////////////////////

Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/home/WhiteRabbit/python-dev/py3k/Lib/io.py", line 64, in <module>
    from _thread import allocate_lock as Lock
ImportError: No module named _thread

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/WhiteRabbit/python-dev/py3k/Lib/io.py", line 66, in <module>
    from _dummy_thread import allocate_lock as Lock
  File "/home/WhiteRabbit/python-dev/py3k/Lib/_dummy_thread.py", line
19, in <mo
dule>
    import traceback as _traceback
  File "/home/WhiteRabbit/python-dev/py3k/Lib/traceback.py", line 6, in
<module>

    import itertools
ImportError: No module named itertools
Aborted (core dumped)

----------
components: Build
files: py3k_workaround.patch
keywords: patch
messages: 72823
nosy: ocean-city
severity: normal
status: open
title: py3k build fails if configure --without-threads
versions: Python 3.0
Added file: http://bugs.python.org/file11430/py3k_workaround.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3812>
_______________________________________

From report at bugs.python.org  Tue Sep  9 08:57:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 06:57:00 +0000
Subject: [issue3791] bsddb not completely removed
In-Reply-To: <1220661145.94.0.113291838613.issue3791@psf.upfronthosting.co.za>
Message-ID: <1220943420.67.0.675551972204.issue3791@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed patch as r66330.
Lower priority, but let the item open: more "bsddb" should be removed.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3791>
_______________________________________

From report at bugs.python.org  Tue Sep  9 09:00:17 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 07:00:17 +0000
Subject: [issue3812] py3k build fails if configure --without-threads
In-Reply-To: <1220943399.18.0.51803892566.issue3812@psf.upfronthosting.co.za>
Message-ID: <1220943617.65.0.23818090463.issue3812@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file11430/py3k_workaround.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3812>
_______________________________________

From report at bugs.python.org  Tue Sep  9 09:01:14 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 07:01:14 +0000
Subject: [issue3812] py3k build fails if configure --without-threads
In-Reply-To: <1220943399.18.0.51803892566.issue3812@psf.upfronthosting.co.za>
Message-ID: <1220943674.1.0.414182319898.issue3812@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I removed workaround patch. It was not simply working.:-(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3812>
_______________________________________

From report at bugs.python.org  Tue Sep  9 09:07:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 07:07:13 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220944033.85.0.799043271126.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied both patches as r66331.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Tue Sep  9 09:34:06 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 07:34:06 +0000
Subject: [issue3806] LockTests in test_imp should be skipped when thread is
	not available
In-Reply-To: <1220913354.36.0.779804691108.issue3806@psf.upfronthosting.co.za>
Message-ID: <1220945646.05.0.371207257235.issue3806@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks. Fixed in r66319(trunk) and r66334(py3k).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3806>
_______________________________________

From report at bugs.python.org  Tue Sep  9 09:34:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 07:34:21 +0000
Subject: [issue3806] LockTests in test_imp should be skipped when thread is
	not available
In-Reply-To: <1220913354.36.0.779804691108.issue3806@psf.upfronthosting.co.za>
Message-ID: <1220945661.45.0.83274898091.issue3806@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/issue3806>
_______________________________________

From report at bugs.python.org  Tue Sep  9 09:37:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 07:37:17 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1220945837.36.0.0224640387213.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Unfortunately, my patch does not work: see the compile warnings in "main.c":
http://www.python.org/dev/buildbot/3.0/x86%20osx.5%203.0/builds/344/step-compile/0

I reverted the change, and will try something else...

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Tue Sep  9 09:39:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 07:39:25 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220945965.51.0.985082050206.issue3777@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied as r66332

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Tue Sep  9 10:17:47 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Sep 2008 08:17:47 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220948267.81.0.0565450517546.issue3634@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Add a test to check to regression.

Added file: http://bugs.python.org/file11431/weakref_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 10:38:51 2008
From: report at bugs.python.org (Marbod Mueller)
Date: Tue, 09 Sep 2008 08:38:51 +0000
Subject: [issue1516] make _ctypes work with non-gcc compilers
In-Reply-To: <1196297579.57.0.775741892495.issue1516@psf.upfronthosting.co.za>
Message-ID: <1220949532.0.0.573414626503.issue1516@psf.upfronthosting.co.za>


Changes by Marbod Mueller <Marbod.Mueller at softwareag.com>:


----------
nosy: +mmueller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1516>
_______________________________________

From report at bugs.python.org  Tue Sep  9 10:39:05 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 08:39:05 +0000
Subject: [issue3813] cannot lanch python.exe via symbolic link if
	HAVE_BROKEN_MBSTOWCS
In-Reply-To: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>
Message-ID: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

On cygwin, py3k aborts if lanches it via symbolic link.

//////////// message beg /////////////////////////

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
Aborted (core dumped)

//////////// message end  /////////////////////////

This is because mbstowcs() on cygwin is broken, so _Py_wreadlink() in
Modules/getpath.c is also broken. I'll attach two patches to fix this. I
don't know which is better.

----------
components: Interpreter Core
files: py3k_getpath_v1.patch
keywords: patch
messages: 72831
nosy: ocean-city
severity: normal
status: open
title: cannot lanch python.exe via symbolic link if HAVE_BROKEN_MBSTOWCS
versions: Python 3.0
Added file: http://bugs.python.org/file11432/py3k_getpath_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3813>
_______________________________________

From report at bugs.python.org  Tue Sep  9 10:42:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 08:42:33 +0000
Subject: [issue3813] cannot lanch python.exe via symbolic link if
	HAVE_BROKEN_MBSTOWCS
In-Reply-To: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>
Message-ID: <1220949753.74.0.239912452358.issue3813@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file11433/py3k_getpath_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3813>
_______________________________________

From report at bugs.python.org  Tue Sep  9 10:55:07 2008
From: report at bugs.python.org (Marbod Mueller)
Date: Tue, 09 Sep 2008 08:55:07 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1220950507.81.0.915332654288.issue1544339@psf.upfronthosting.co.za>


Changes by Marbod Mueller <Marbod.Mueller at softwareag.com>:


----------
nosy: +mmueller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Tue Sep  9 11:05:26 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 09:05:26 +0000
Subject: [issue516762] have a way to search backwards for re
Message-ID: <1220951126.56.0.92001264583.issue516762@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Why not? I needed such a feature some time ago.
But if possible, it should be a keyword argument:
re.search(..., backwards=True)
similar to list.sort(reverse=True)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue516762>
_______________________________________

From report at bugs.python.org  Tue Sep  9 11:20:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 09:20:56 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220952056.79.0.414232478031.issue3634@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think the test should check that TypeError is actually raised:
  self.assertRaises(TypeError, r.__init__, 0, 0, 0, 0, 0)
It's even shorter than the try/except block...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 11:37:02 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 09 Sep 2008 09:37:02 +0000
Subject: =?utf-8?q?[issue2562]_Cannot_use_non-ascii_letters_in_disutils_if_setuptools_is=09used.?=
In-Reply-To: <1220910304.87.0.167273354149.issue2562@psf.upfronthosting.co.za>
Message-ID: <48C643BB.7060802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-09-08 23:45, Benjamin Peterson wrote:
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
> 
> Does this need to be merged into py3k? If so, can someone who handled
> this bug do it. I met a few test failures in my attempt...

As mentioned in the ticket discussion, this does not need to
be forward patched to 3.0.

----------
title: Cannot use non-ascii letters in disutils if setuptools is used. -> Cannot use non-ascii letters in disutils if setuptools is	used.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
_______________________________________

From report at bugs.python.org  Tue Sep  9 11:44:12 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Sep 2008 09:44:12 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220953452.86.0.781404663585.issue3634@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file11434/weakref_test-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 11:44:16 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Sep 2008 09:44:16 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220953456.62.0.201446037522.issue3634@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11431/weakref_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 11:45:04 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Sep 2008 09:45:04 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220953504.21.0.850781113127.issue3634@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

amaury: oh yes, i forget to use assertRaise(). A new patch is 
attached.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 12:08:37 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Tue, 09 Sep 2008 10:08:37 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1220954917.33.0.147544485867.issue3786@psf.upfronthosting.co.za>


Michael Schmarck <michael.schmarck at habmalnefrage.de> added the comment:

Yes, I would _like_ to do that, but I fear that I lack the necessary
skills...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Tue Sep  9 12:25:19 2008
From: report at bugs.python.org (Douche)
Date: Tue, 09 Sep 2008 10:25:19 +0000
Subject: [issue3814] Add VCS support
In-Reply-To: <1220955919.51.0.983874938632.issue3814@psf.upfronthosting.co.za>
Message-ID: <1220955919.51.0.983874938632.issue3814@psf.upfronthosting.co.za>


New submission from Douche <sdouche at gmail.com>:

This is a basic try (4h) to extract specific SVN code out of the core
and add entry points for:
- filters (.svn, .hg, ...)
- find files in repos
- get revision's number

Thoughts:
- if repos have 2 VCS entries (.svn and .hg for example), the first
valid entry point is used. 
- walk_revctrl function needs more love. I keep the philosophy of
iterator but is it the good way ?

Notes:
- vcs_svn.py & vcs_hg.py are only for demo. The natural place are into
Setuptools plugins.
- filters must return a list.
- revisions must return a int or None (not 0).

Critics welcome.

----------
components: Distutils
files: setuptools-sd-20080908.patch
keywords: patch
messages: 72837
nosy: sdouche
severity: normal
status: open
title: Add VCS support
type: feature request
versions: 3rd party
Added file: http://bugs.python.org/file11435/setuptools-sd-20080908.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3814>
_______________________________________

From report at bugs.python.org  Tue Sep  9 12:38:10 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 10:38:10 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220956690.22.0.626835845341.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reopening this because I disagree with the fix - I would prefer to see
catch_warnings() reverted back to the API and implementation* it used
prior to the test_support->warnings migration.

That version had perfectly clear semantics when no warning was issued:
w.message (and all of the other warning attributes) were None. If the
implementation of WarningsRecorder hadn't been changed then this bug
would have never arisen.

The attributes of the last warning are cached on the recorder because by
*far* the most common intended use case that makes use of the warnings
recorder is to test operations that are expected to raise a single
warning. The list of warnings is retained solely for special cases where
one operation raises multiple warnings (e.g. see the py3k warnings tests
for __hash__ inheritance).

*aside from the use of @contextmanager, obviously

----------
nosy: +ncoghlan
resolution: accepted -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 12:40:47 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 10:40:47 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220956847.27.0.266045892162.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As far as the use cases go, it was moved out of test.test_support to
warnings SOLELY due to the requests from the twisted folks for
assistance in testing their generation of warnings. The fact that it is
also useful for suppressing warnings in general without affecting the
global state of the warnings module (aside from thread safety issues) is
just a bonus.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:04:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 11:04:55 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1220958295.5.0.565083322007.issue3807@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'm not sure if I'm doing right thing, but this patch works on cygwin at
least.

----------
keywords: +patch
Added file: http://bugs.python.org/file11436/skip_multiprocessing_without_threads.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:14:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 11:14:37 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220958877.81.0.610481479642.issue3805@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The same function has two distinct behaviours:
- If you pass a number, it return a bytes object.
- If you pass a buffer, it returns a number!
Different arguments and different return types: they should have
different names IMO.

io.py proposes read(n) and readinto(buf) for this distinction, and I
fail to see a reason why PySSL_SSLread need to be different:

- readinto(buf, count=-1) could be similar to the actual PySSL_SSLread.
the "count" defaults to len(buf).
- read(count) could be implemented in C or python (or not at all), it is
equivalent to:
    def read(self, count=1024):
        buf = bytearray(count)
        nb = self.readinto(buf)
        return bytes(buf[:nb])

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:20:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 11:20:24 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220959224.93.0.672151693481.issue3634@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Both patches look fine to me.
They could be backported to 2.5 as well.

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:28:37 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 09 Sep 2008 11:28:37 +0000
Subject: [issue3815] Python 3.0b3 - Idle doesn't start on win XPh
In-Reply-To: <1220959717.64.0.398340627049.issue3815@psf.upfronthosting.co.za>
Message-ID: <1220959717.64.0.398340627049.issue3815@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

Using Python 3.0b3 on windows XPH SP2 (installed form python-3.0b3.msi) 
Idle can't be started.
Using a windows shortcut, only an error-promt is shown "Subprocess 
Startup Error: IDLE's subprocess dien't make connection. Either IDLE 
can't start a subprocess or personal firewall is blocking the 
connection."
I'm aware of the warning about firewalls in IDLE, but the previous 3.0 
betas didn't have that issue with the same settings of the windows 
firewall.

After directly calling:
C:\Python30\python.exe C:\Python30\Lib\idlelib\idle.py

The same error is thrown, but previously another exception is writen to 
the console:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python30\lib\idlelib\run.py", line 76, in main
    sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'

Regards,
   vbr

----------
components: IDLE
messages: 72843
nosy: vbr
severity: normal
status: open
title: Python 3.0b3 - Idle doesn't start on win XPh
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3815>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:28:44 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Sep 2008 11:28:44 +0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1220959724.91.0.758070377164.issue2145@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You can close this issue. It's not really a bug, it's a feature :-) 
find_library() only finds library and not programs. libdistorm64.so is 
compiled as a program, not a library.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:29:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Sep 2008 11:29:11 +0000
Subject: [issue3814] Add VCS support
In-Reply-To: <1220955919.51.0.983874938632.issue3814@psf.upfronthosting.co.za>
Message-ID: <1220959751.51.0.260248084361.issue3814@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This isn't the right place to post setuptools patches, as setuptools is
not part of the standard Python distribution. There is a setuptools bug
tracker at http://bugs.python.org/setuptools/

You can probably also use the distutils-sig mailing-list for announcing
your patch (which is used for setuptools discussions):
http://mail.python.org/mailman/listinfo/distutils-sig/

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3814>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:30:09 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Sep 2008 11:30:09 +0000
Subject: [issue1297193] Search is to long with regex like ^(.+|dontmatch)*$
Message-ID: <1220959809.95.0.819465156588.issue1297193@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's not a bug, it's a feature. I wrote a library 
(http://hachoir.org/wiki/hachoir-regex) to "optimize" regex, so you 
can close this issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1297193>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:30:29 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 09 Sep 2008 11:30:29 +0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1220959829.44.0.406366286176.issue2145@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Cool.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
_______________________________________

From report at bugs.python.org  Tue Sep  9 13:35:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Sep 2008 11:35:36 +0000
Subject: [issue1297193] Search is to long with regex like ^(.+|dontmatch)*$
Message-ID: <1220960136.51.0.866358245816.issue1297193@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fair enough :)

----------
nosy: +pitrou
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1297193>
_______________________________________

From report at bugs.python.org  Tue Sep  9 14:02:55 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Sep 2008 12:02:55 +0000
Subject: [issue1755388] Problem with socket.gethostbyaddr() and
	KeyboardInterrupt
Message-ID: <1220961775.74.0.663147084498.issue1755388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using gdb, I dig the problem:
 * when CTRL+c is pressed, signal_handler (sig_num=2) 
at ./Modules/signalmodule.c:175 is called
 * signal_handler() stores the signal has a "pending call"
 * Linux kernel interrupts its name resolution (it looks like it's the 
read() syscall?) and return the error ETIMEDOUT (110)
 * back to socket_gethostbyaddr(): result=110, h=NULL
 * gethost_common() set an error using set_herror(1)
 * socket_gethostbyaddr() return NULL

Later, Py_MakePendingCalls() will call signal_default_int_handler() 
which raises the KeyboardInterrupt.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755388>
_______________________________________

From report at bugs.python.org  Tue Sep  9 14:13:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 09 Sep 2008 12:13:14 +0000
Subject: [issue3816] __newobj__ pickle feature is not documented
In-Reply-To: <1220962394.03.0.479554047795.issue3816@psf.upfronthosting.co.za>
Message-ID: <1220962394.03.0.479554047795.issue3816@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The pickle system has an undocumented but very useful feature. When the
first element of the tuple returned by __reduce__ is a function named
__newobj__, a special obcode is generated. __newobj__ doesn't need to be
registered as safe for unpickling, too.

>From pickle.py:

            # use the more efficient NEWOBJ opcode, while still
            # allowing protocol 0 and 1 to work normally.  For this to
            # work, the function returned by __reduce__ should be
            # called __newobj__, and its first argument should be a
            # new-style class.  The implementation for __newobj__
            # should be as follows, although pickle has no way to
            # verify this:
            #
            # def __newobj__(cls, *args):
            #     return cls.__new__(cls, *args)
            #
            # Protocols 0 and 1 will pickle a reference to __newobj__,
            # while protocol 2 (and above) will pickle a reference to
            # cls, the remaining args tuple, and the NEWOBJ code,
            # which calls cls.__new__(cls, *args) at unpickling time
            # (see load_newobj below).  If __reduce__ returns a
            # three-tuple, the state from the third tuple item will be
            # pickled regardless of the protocol, calling __setstate__
            # at unpickling time (see load_build below).
            #
            # Note that no standard __newobj__ implementation exists;
            # you have to provide your own.  This is to enforce
            # compatibility with Python 2.2 (pickles written using
            # protocol 0 or 1 in Python 2.3 should be unpicklable by
            # Python 2.2).

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 72850
nosy: christian.heimes, georg.brandl
priority: low
severity: normal
status: open
title: __newobj__ pickle feature is not documented
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3816>
_______________________________________

From report at bugs.python.org  Tue Sep  9 14:20:44 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 12:20:44 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220962844.97.0.865609986432.issue3781@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

With a name like catch_warnings() in the warnings module, it will
definitely get used in production code to suppress warnings.  If its
intended to be used only by tests, then it belongs somewhere else.  If
not test_support then maybe unittest.  If it were moved then I wouldn't
care about the bug that all other warnings caught are inaccessible.

You'd still have to fix the w.messages attribute to be None if there
were no warnings raised.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 14:29:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 12:29:37 +0000
Subject: [issue3813] cannot lanch python.exe via symbolic link if
	HAVE_BROKEN_MBSTOWCS
In-Reply-To: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>
Message-ID: <1220963377.52.0.298132665624.issue3813@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

http://man.he.net/man3/readlink says: "Conforming applications should
not assume that the returned contents of the symbolic link are
null-terminated"

cygwin is not broken, but very (too much?) conforming in this case ;-)

I think your second patch is the correct one, just keep the "return
(int)r1;" because the return value is stored in a "linklen" variable.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3813>
_______________________________________

From report at bugs.python.org  Tue Sep  9 14:38:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 12:38:35 +0000
Subject: [issue3813] cannot lanch python.exe via symbolic link if
	HAVE_BROKEN_MBSTOWCS
In-Reply-To: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>
Message-ID: <1220963915.5.0.0975474409081.issue3813@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +needs review
priority:  -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3813>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:11:24 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:11:24 +0000
Subject: [issue3629] Python won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1220965884.96.0.686532417447.issue3629@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
title: Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2 -> Python won't compile a regex that compiles with 2.5.2 and 30b2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:11:44 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:11:44 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1220965904.99.0.747614341436.issue3187@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:12:01 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:12:01 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1220965921.31.0.311834133341.issue3574@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:12:15 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:12:15 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1220965935.29.0.688464909049.issue3799@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:12:41 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 13:12:41 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220965961.37.0.869815222283.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It turns out the warnings.catch_warnings version has re-entrancy issues
due to the fact that it can't use @contextmanager:

Python 2.6b3+ (trunk:66143M, Sep  2 2008, 20:04:43)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> orig_filters = warnings.filters
>>> cw = warnings.catch_warnings()
>>> with cw:
...   warnings.filters = []
...   with cw:
...     pass
...
>>> warnings.filters is orig_filters
False
>>> warnings.filters
[]
>>> orig_filters
[('ignore', None, <type 'exceptions.PendingDeprecationWarning'>, None,
0), ('ignore', None, <type 'exceptions.ImportWarning'>, None, 0),
('ignore', None, <type 'exceptions.BytesWarning'>, None, 0)]

I propose that we just revert to the test.test_support.catch_warnings
implementation that was used in the beta releases, and leave the
question of whether to expose this ability somewhere other than our own
regression test support module for 2.7/3.1. That version worked, and the
attempt to move it at the last minute has caused nothing but trouble.

So on trunk we would revert the following checkins:
r66135 (relocate to warnings and change API)
r66321 (change API again in attempt to fix bugs in r66135)

And on the py3k branch we would revert:
r66139 (merge r66135)
r66322* (merge r66322)

*This commit actually appears to have missed the changes to
test.test_support that were in r66321 - test.support was not modified by
the r66322 checkin (which strikes me as all the more reason to revert
all of these changes and go back to the beta implementation)

----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:13:03 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:13:03 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1220965983.45.0.0193192448064.issue2876@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:14:07 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:14:07 +0000
Subject: [issue2350] 'exceptions' import fixer
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1220966047.79.0.0819061764461.issue2350@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:14:18 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:14:18 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1220966058.05.0.249050322246.issue3642@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:14:28 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:14:28 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1220966068.25.0.330796890113.issue3617@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:14:43 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:14:43 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1220966083.05.0.828149292206.issue1868@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:14:36 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:14:36 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1220966076.92.0.969218765269.issue3657@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:14:51 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Sep 2008 13:14:51 +0000
Subject: [issue3809] test_logging leaving a 'test.blah' file behind
In-Reply-To: <1220925367.02.0.0825641930975.issue3809@psf.upfronthosting.co.za>
Message-ID: <1220966091.01.0.54411388574.issue3809@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3809>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:26:37 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 13:26:37 +0000
Subject: [issue3813] cannot lanch python.exe via symbolic link if
	HAVE_BROKEN_MBSTOWCS
In-Reply-To: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>
Message-ID: <1220966797.75.0.427662406188.issue3813@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Oh, I misunderstood the reason...
readlink() can return non-null-terminated string, so mbstowcs may
convert illegual memory area. I've attached py3k_getpath_v3.patch.

Added file: http://bugs.python.org/file11437/py3k_getpath_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3813>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:33:18 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 13:33:18 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220967198.98.0.63035200544.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I also have to comment on the "makes the API simpler to use" note in the
checkin message. No, no it doesn't. See all those "warning[-1]" calls in
the current unit tests? They're all unhelpful, because if a warning
doesn't get raised, you're going to get an IndexError instead of an
Assertion error (i.e. exactly the problem complained about in the
original message in this thread).

Losing the attributes from the WarningRecorder means that you have to
check if you got a warning first before you can check if you got the
*right* warning. With the cached attributes, you can just check for the
right warning, and only worry about the *number* of warnings in cases
where that is likely to matter (usually because you expect multiple
warnings from one operation).

These are all *solvable* problems, but I don't think right before a
release candidate is the time to be fiddling with it - so let's revert
back to providing this feature only through the regression test suite
and deal with moving it into a more "official" part of the standard
library in a later release after this version has had a chance to bake
for a while (the twisted folks can always try to import it from our test
suite, and copy our implementation as a fallback if the test suite isn't
available for some reason).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:39:00 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 13:39:00 +0000
Subject: [issue3812] py3k build fails if configure --without-threads
In-Reply-To: <1220943399.18.0.51803892566.issue3812@psf.upfronthosting.co.za>
Message-ID: <1220967540.96.0.0874739181062.issue3812@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Simple workaround is to remove itertools from traceback module and write
equivalent code to itertools.chain.

I'm not sure it is acceptable put such limitation to standard library.
(That is, traceback is used from build process, so should not use C-module)

Added file: http://bugs.python.org/file11438/py3k_remove_itertools_from_traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3812>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:39:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 13:39:34 +0000
Subject: [issue3813] cannot lanch python.exe via symbolic link if
	HAVE_BROKEN_MBSTOWCS
In-Reply-To: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>
Message-ID: <1220967574.83.0.072158307021.issue3813@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Your patch is OK for me. Please apply!

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3813>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:43:55 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Sep 2008 13:43:55 +0000
Subject: [issue3809] test_logging leaving a 'test.blah' file behind
In-Reply-To: <1220925367.02.0.0825641930975.issue3809@psf.upfronthosting.co.za>
Message-ID: <1220967835.82.0.625000064988.issue3809@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk - revision 66337.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3809>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:57:25 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 09 Sep 2008 13:57:25 +0000
Subject: [issue3817] ftplib: ABOR does not consider 225 response code
In-Reply-To: <1220968645.43.0.419983108509.issue3817@psf.upfronthosting.co.za>
Message-ID: <1220968645.43.0.419983108509.issue3817@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

RFC-959 at chapter 5.4 includes 225 as a possible response to an ABOR
command.
225 should be sent by server when a client issues an ABOR command and
there's no data transfer to abort.
The patch in attachment includes 225 code in the list of positive ABOR
response codes.


[1] http://www.ietf.org/rfc/rfc0959.txt

----------
files: ftplib.patch
keywords: patch
messages: 72859
nosy: giampaolo.rodola
severity: normal
status: open
title: ftplib: ABOR does not consider 225 response code
Added file: http://bugs.python.org/file11439/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3817>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:57:42 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 09 Sep 2008 13:57:42 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220968662.05.0.152415524666.issue3777@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Just a quick nit, but it seems to me that since 2.6 still actually
distinguishes between longs and ints that the two error messages in
PyLong_FromFloat should mention "long" instead of "integer".

Skip

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:58:15 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 09 Sep 2008 13:58:15 +0000
Subject: [issue3818] ftplib.FTP.abort() should consider "225" a positive
	response code to ABOR
In-Reply-To: <1220968695.13.0.61969231566.issue3818@psf.upfronthosting.co.za>
Message-ID: <1220968695.13.0.61969231566.issue3818@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

RFC-959 at chapter 5.4 includes 225 as a possible response to an ABOR
command.
225 should be sent by server when a client issues an ABOR command and
there's no data transfer to abort.
The patch in attachment includes 225 code in the list of positive ABOR
response codes.


[1] http://www.ietf.org/rfc/rfc0959.txt

----------
files: ftplib.patch
keywords: patch
messages: 72861
nosy: giampaolo.rodola
severity: normal
status: open
title: ftplib.FTP.abort() should consider "225" a positive response code to ABOR
Added file: http://bugs.python.org/file11440/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3818>
_______________________________________

From report at bugs.python.org  Tue Sep  9 15:59:08 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 13:59:08 +0000
Subject: [issue3813] cannot lanch python.exe via symbolic link if
	HAVE_BROKEN_MBSTOWCS
In-Reply-To: <1220949545.4.0.793432672425.issue3813@psf.upfronthosting.co.za>
Message-ID: <1220968748.98.0.633317946396.issue3813@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66338(py3k).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3813>
_______________________________________

From report at bugs.python.org  Tue Sep  9 16:10:30 2008
From: report at bugs.python.org (Jason Tishler)
Date: Tue, 09 Sep 2008 14:10:30 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1220969430.14.0.724383240149.issue1706863@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

The Cygwin build is having the same problem:

http://cygwin.com/ml/cygwin/2008-09/msg00145.html

In this case, the sqlite3 libraries are installed (in /usr/lib), but 
their suffixes do not match the expected values.

Does anyone know the best way to make setup.py and/or distutils search 
for .dll.a instead of .dll?

----------
nosy: +jlt63

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Tue Sep  9 16:21:09 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 14:21:09 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220970069.75.0.231251748382.issue3781@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 16:37:58 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 09 Sep 2008 14:37:58 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220971078.17.0.310996717572.issue3781@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Exposing a list seems like a great low-level API to me.  There are no
[-1]s in the Twisted codebase as a result of using this API because we
have a higher-level API built on top of it.  Having this low-level API
that doesn't try to make a specific application more convenient (at the
cost of ambiguity) means anyone can write a better high-level API on top
of it that makes a specific use-case convenient.

For Twisted, we actually would have very little difficulty coming up
with our own version of catch_warnings without copying the
implementation from the test_support module.  What we are *really*
interested in is a public API.  Copying the implementation from
test_support doesn't give us that.

I understand the concern with introducing changes like this into CPython
so close to a release.  I just want it to be clear that without a public
API for this feature, the issue isn't resolved for Twisted. That may not
have been clear by just looking at this ticket, but see also issue3780
which I filed before filing this one which was also marked as a release
blocker and which was resolved only because of the existence of
`warnings.catch_warnings` (therefore removing the public API would mean
re-opening that ticket).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 16:53:21 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 14:53:21 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220972001.05.0.834079710074.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In working on the reversion patch, I just noticed that r66321 also
incorrectly removed a whole pile of w.reset() calls.

When using a single catch_warning() context to test two or more
operations which may raise the same warning, you *must* call w.reset()
between each operation, or the later operations can fail to raise
warnings, but the test will still pass because the most recent warning
is still one which was correctly raised by an earlier operation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 16:54:36 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 14:54:36 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220972076.86.0.987237343153.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

test.test_support *is* a public API (it's even documented).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 16:58:47 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 09 Sep 2008 14:58:47 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220972327.04.0.656140552045.issue3781@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

There was a discussion on python-dev about using things from the `test`
package from code outside the `test` package:

http://mail.python.org/pipermail/python-dev/2008-August/081860.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:02:12 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 15:02:12 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220972532.86.0.698009553369.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I will put together two patches: one that reverts all the way back to
what we had in the betas, and another which just reverts the Python test
suite changes in the most recent checkin (instead modifying
test_support.catch_warning to use the modified warnings.catch_warnings),
then fixes the context manager in the warnings module (adding tests for
both bugs)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:11:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 15:11:02 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220561357.57.0.619578409655.issue3777@psf.upfronthosting.co.za>
Message-ID: <1220973062.65.0.851931162817.issue3777@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I suppose you meant PyLong_FromDouble()? I think the messages talk about
abstract numbers, not a specific python type: "infinity/NaN cannot be
converted to an integral value".

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:12:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Sep 2008 15:12:12 +0000
Subject: [issue3812] py3k build fails if configure --without-threads
In-Reply-To: <1220943399.18.0.51803892566.issue3812@psf.upfronthosting.co.za>
Message-ID: <1220973132.48.0.765496951584.issue3812@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Agreed. I suggest that you add a comment like
"itertools.chain is in an extension module and may be unavailable"
just above.
Otherwise, someday one will find that this code should use a function
from the stdlib, and revert your change...

Please apply it.

----------
nosy: +amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3812>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:12:44 2008
From: report at bugs.python.org (Kyle McFarland)
Date: Tue, 09 Sep 2008 15:12:44 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>


New submission from Kyle McFarland <TFKyle at Gmail.com>:

when you request a url that requests Basic authentication info
HTTPBasicAuthHandler adds the Authorization header to the request as a
normal (not unredirected) header, then if the server returns a 301 or
302 redirect HTTPRedirectHandler will send a request to the redirected
address keeping the normal headers including the Authorization header
HTTPBasicAuthHandler added, I'll attach the code I used to test this.

GET from libwww-perl seems to do this but most browsers don't seem to 
by default and although I can't find much in the RFCs about how
redirecting is supposed to work wrt. auth headers (feel free to point
out sections if I'm blind) I think it breaks
ftp://ftp.isi.edu/in-notes/rfc2617.txt somewhat (section 1.1, 
"""
The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized, the
same credentials MAY be reused for all other requests within that
protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a single protection
space cannot extend outside the scope of its server.
""") since redirects can point to arbitrary urls off of the server.

as in bug #1480067 just adding the header as an unredirected header
would stop the header being sent across redirects if that's indeed the
proper behaviour.

----------
components: Library (Lib)
files: test.py
messages: 72871
nosy: TFKyle
severity: normal
status: open
title: urllib2 sends Basic auth across redirects
Added file: http://bugs.python.org/file11441/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3819>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:16:57 2008
From: report at bugs.python.org (Kyle McFarland)
Date: Tue, 09 Sep 2008 15:16:57 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <1220973417.83.0.110254616203.issue3819@psf.upfronthosting.co.za>


Changes by Kyle McFarland <TFKyle at Gmail.com>:


Added file: http://bugs.python.org/file11442/untest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3819>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:19:29 2008
From: report at bugs.python.org (Kyle McFarland)
Date: Tue, 09 Sep 2008 15:19:29 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <1220973569.61.0.0310130184797.issue3819@psf.upfronthosting.co.za>


Changes by Kyle McFarland <TFKyle at Gmail.com>:


Added file: http://bugs.python.org/file11443/bug3819.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3819>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:29:39 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 15:29:39 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220974179.78.0.213098143987.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fully reverting the relocation also required reverting r66197 (a belated
checkin of test_py3kwarn for the r66135 changes).

There was also a change to test_warnings that had to be reverted (it
appeared to have been mistakenly checked in as part of the checkin that
added the bsddb Py3k warnings).

Running tests now for the full reversion patch. The major objection to
that approach (aside from the issue with external testing of warnings)
is the problem that actually lead to catch_warnings() being relocated in
the first place: suppressing spurious Py3k warnings in modules like cgi.py.

So as much as I was pushing that option earlier, it looks like it isn't
going to be viable.

It's past 1 am here, so I'll be working on the other (cleaner) patch
tomorrow evening.

The intended end result of that other patch:

A warnings.catch_warnings() implementation with the current interface
(i.e. return a list on entry if record=True, None otherwise) that is
intended either to suppress warnings, or to serve as a building block
for better warning testing tools. The patch will also fix the
re-entrancy problem by adding explicit self._entered state guards.

A test_support.catch_warning() implementation which is tailored towards
the needs of the Python regression test suite (probably the
list-with-attributes interface provided by the previous incarnation of
warnings.catch_warning, but with __getattr__ adjusted to return None
when there is no warning caught).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:40:51 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 15:40:51 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220974851.54.0.138025403766.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reversion patch attached - it does indeed recreate some nasty
dependencies from the main areas of the standard library on to the
regression test suite. That's enough to kill the idea of a complete
reversion as far as I'm concerned - I'll get the proper fix done this
evening.

(That's 18-20 hours from the time of this post, for anyone trying to
figure out timezones)

Added file: http://bugs.python.org/file11444/issue3781_revert_to_beta_implementation_26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:45:27 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 09 Sep 2008 15:45:27 +0000
Subject: [issue3777] long(4.2) now returns an int
In-Reply-To: <1220973062.65.0.851931162817.issue3777@psf.upfronthosting.co.za>
Message-ID: <18630.39430.255341.391116@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Amaury> I suppose you meant PyLong_FromDouble()? 

Yes, sorry.

    Amaury> I think the messages talk about abstract numbers, not a specific
    Amaury> python type: "infinity/NaN cannot be converted to an integral
    Amaury> value".

Well, 2.5 called it "long".

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3777>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:54:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 15:54:17 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1220975657.46.0.891112848646.issue3617@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think this needs to be resolved before 2.6, not without a
pronouncement from a lawyer advising the PSF. Layman's analyses of legal
issues are void.

Thus lowering the priority.

----------
nosy: +loewis
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Tue Sep  9 17:59:07 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Tue, 09 Sep 2008 15:59:07 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1220975947.53.0.156358949337.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is a new patch so that pymalloc can be combined with dlmalloc.

I first added the --with-pymalloc-mmap option to configure.in which
ensures that pymalloc arenas are allocated through mmap when possible.

However I found this was not enough: PyObject_Malloc uses arenas only
when handling objects smaller than 256 bytes. For bigger objects, it
directly rely on the system malloc. There are also some big buffers
which can be directly allocated through PyMem_MALLOC.

This patch can be activated by compiling Python with:
--with-pymalloc --with-pymalloc-mmap --with-dlmalloc

The behavior is then like that:
* PyObject_MALLOC will allocate arenas with mmap

* when allocating an object smaller than 256 bytes with 
PyObject_MALLOC, it will be stored in an arena (like before)

* when allocating an object bigger than 256 bytes with PyObject_MALLOC,
it will be allocated by dlmalloc (if it is smaller than 256KB it will go
in a dlmalloc pool, otherwise it will be mmaped)

* allocation through PyMem_MALLOC is handled by dlmalloc

I think it is a good compromise:
On systems like Linux, where the system malloc is already clever enough,
compiling with only --with-pymalloc should behave like before. On
systems like SunOS and AIX, this patch ensures that Python can benefit
of the speed of pymalloc for small objects, while ensuring that most of
the memory allocated can be correctly released at the system level.

Added file: http://bugs.python.org/file11445/patch_dlmalloc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Sep  9 18:00:54 2008
From: report at bugs.python.org (Tim Pietzcker)
Date: Tue, 09 Sep 2008 16:00:54 +0000
Subject: [issue3820] Python 3.0b3 doesn't start on German Win XP SP3/SP2
In-Reply-To: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>
Message-ID: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>


New submission from Tim Pietzcker <tim.pietzcker at web.de>:

I have experienced the exact same thing on two different PCs, one
running WinXP (German, 32bit Intel) SP2, one running SP3: When starting
the Python command line or when trying to run a Python script, I
immediately get the (Windows) error message that python.exe couldn't be
started because it is misconfigured, and I should install it again
(which doesn't help). Uninstalling and going back to 3.0b2 works. The
MD5 checksum of the installer is correct. I'm wondering, though, why the
file size has dropped from 13 to 11 MB.

----------
components: Windows
messages: 72877
nosy: pietzcker
severity: normal
status: open
title: Python 3.0b3 doesn't start on German Win XP SP3/SP2
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3820>
_______________________________________

From report at bugs.python.org  Tue Sep  9 18:01:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 16:01:49 +0000
Subject: [issue1840] Tools/i18n/msgfmt.py fixes for Python 3.0
In-Reply-To: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za>
Message-ID: <1220976109.03.0.342992596929.issue1840@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing it as fixed then.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1840>
_______________________________________

From report at bugs.python.org  Tue Sep  9 18:07:13 2008
From: report at bugs.python.org (Juan Javier)
Date: Tue, 09 Sep 2008 16:07:13 +0000
Subject: [issue3821] trace module bug when using --missing
In-Reply-To: <1220976433.09.0.355914664139.issue3821@psf.upfronthosting.co.za>
Message-ID: <1220976433.09.0.355914664139.issue3821@psf.upfronthosting.co.za>


New submission from Juan Javier <jjdominguezm at yahoo.com>:

I get the following exception:

$ /opt/python3.0b2/bin/python3.0 -m trace -c -m run.py
Traceback (most recent call last):
  File "/opt/python3.0b2/lib/python3.0/runpy.py", line 121, in
_run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/opt/python3.0b2/lib/python3.0/runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 809, in <module>
    main()
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 806, in main
    results.write_results(missing, summary=summary, coverdir=coverdir)
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 303, in write_results
    lnotab = find_executable_linenos(filename)
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 428, in
find_executable_linenos
    return find_lines(code, strs)
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 392, in find_lines
    linenos.update(find_lines(c, strs))
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 386, in find_lines
    linenos = find_lines_from_code(code, strs)
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 370, in
find_lines_from_code
    line_increments = [ord(c) for c in code.co_lnotab[1::2]]
  File "/opt/python3.0b2/lib/python3.0/trace.py", line 370, in <listcomp>
    line_increments = [ord(c) for c in code.co_lnotab[1::2]]
TypeError: ord() expected string of length 1, but int found

I think that line 370 of trace.py should say:

line_increments = [int(c) for c in code.co_lnotab[1::2]]

instead of:

line_increments = [ord(c) for c in code.co_lnotab[1::2]]

----------
components: Library (Lib)
messages: 72879
nosy: jjdominguezm
severity: normal
status: open
title: trace module bug when using --missing
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3821>
_______________________________________

From report at bugs.python.org  Tue Sep  9 18:13:24 2008
From: report at bugs.python.org (Toby Donaldson)
Date: Tue, 09 Sep 2008 16:13:24 +0000
Subject: [issue3822] zfill doc string uses inconsistent variable names
In-Reply-To: <1220976804.14.0.81278850769.issue3822@psf.upfronthosting.co.za>
Message-ID: <1220976804.14.0.81278850769.issue3822@psf.upfronthosting.co.za>


New submission from Toby Donaldson <tjdonaldson at gmail.com>:

The doc string for zfill use the variable name "x" when it should
probably be using the variable name "S".

>>> print(''.zfill.__doc__)
S.zfill(width) -> str

Pad a numeric string x with zeros on the left, to fill a field
of the specified width. The string x is never truncated.

----------
assignee: georg.brandl
components: Documentation
messages: 72880
nosy: georg.brandl, tjd
severity: normal
status: open
title: zfill doc string uses inconsistent variable names
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3822>
_______________________________________

From report at bugs.python.org  Tue Sep  9 18:19:22 2008
From: report at bugs.python.org (Toby Donaldson)
Date: Tue, 09 Sep 2008 16:19:22 +0000
Subject: [issue3815] Python 3.0b3 - Idle doesn't start on win XPh
In-Reply-To: <1220959717.64.0.398340627049.issue3815@psf.upfronthosting.co.za>
Message-ID: <1220977162.9.0.00915714618654.issue3815@psf.upfronthosting.co.za>


Toby Donaldson <tjdonaldson at gmail.com> added the comment:

I also had problems running IDLE, and the fix listed here solved it for
me: http://bugs.python.org/issue3628

----------
nosy: +tjd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3815>
_______________________________________

From report at bugs.python.org  Tue Sep  9 18:31:35 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 09 Sep 2008 16:31:35 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1220975657.46.0.891112848646.issue3617@psf.upfronthosting.co.za>
Message-ID: <48C6A4E4.2040007@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-09-09 17:54, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> I don't think this needs to be resolved before 2.6, not without a
> pronouncement from a lawyer advising the PSF. Layman's analyses of legal
> issues are void.
> 
> Thus lowering the priority.

That's an interesting argument :-) What makes you think that a
layman's judgment over a layman's analysis is not void as well ?

Rather than arguing about the necessity of including the license
of a 3rd party file that we intend to include in a wide-spread
software release, wouldn't it be easier to just add the file
and be done with it, like I suggested at the very beginning of
this discussion ?

----------
title: Add MS EULA to the list of third-party licenses in the Windows installer -> Add MS EULA to the list of third-party licenses in the	Windows installer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Tue Sep  9 18:51:38 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 09 Sep 2008 16:51:38 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220958877.81.0.610481479642.issue3805@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0809090951u331d6bb1l7207525ad9eb1b46@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Please, guys, let's not deep-end on this.  It's an admittedly eccentric but
working and purely internal interface.  There are actual release-blockers
that need to be addressed.

On Tue, Sep 9, 2008 at 4:14 AM, Amaury Forgeot d'Arc <report at bugs.python.org
> wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> The same function has two distinct behaviours:
> - If you pass a number, it return a bytes object.
> - If you pass a buffer, it returns a number!
> Different arguments and different return types: they should have
> different names IMO.
>
> io.py proposes read(n) and readinto(buf) for this distinction, and I
> fail to see a reason why PySSL_SSLread need to be different:
>
> - readinto(buf, count=-1) could be similar to the actual PySSL_SSLread.
> the "count" defaults to len(buf).
> - read(count) could be implemented in C or python (or not at all), it is
> equivalent to:
>    def read(self, count=1024):
>        buf = bytearray(count)
>        nb = self.readinto(buf)
>        return bytes(buf[:nb])
>
> ----------
> nosy: +amaury.forgeotdarc
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3805>
> _______________________________________
>

Added file: http://bugs.python.org/file11446/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080909/3e7f0973/attachment.txt>

From report at bugs.python.org  Tue Sep  9 19:02:32 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 09 Sep 2008 17:02:32 +0000
Subject: [issue3714] nntplib module broken by str to unicode conversion
In-Reply-To: <1219932621.55.0.439111476187.issue3714@psf.upfronthosting.co.za>
Message-ID: <20080909170222.GB3400@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

So, in effect, if we settle for ASCII as the default encoding, then the
attached patch is good enough. Someone should check this in. 
Should it go in py3k, release? Because, without this patch(which is again
simple), nntplib is almost unusable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3714>
_______________________________________

From report at bugs.python.org  Tue Sep  9 19:13:38 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 09 Sep 2008 17:13:38 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220980418.01.0.452024611569.issue3805@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


Removed file: http://bugs.python.org/file11446/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Tue Sep  9 19:14:31 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 09 Sep 2008 17:14:31 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220980471.6.0.500032988362.issue3805@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

But I should say...  Greg, I do appreciate the review and the comments.
 I was waiting for the bytes work in 3K to settle down before looking at
that code again.  When I do, I'll take your comments to heart.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Tue Sep  9 19:20:40 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 09 Sep 2008 17:20:40 +0000
Subject: [issue3805] sslobj.read py3k takes odd arguments
In-Reply-To: <1220902607.94.0.0236135682272.issue3805@psf.upfronthosting.co.za>
Message-ID: <1220980840.73.0.651812831316.issue3805@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

yep, agreed.  leave this for later.  my bad for opening it with high 
priority in the first place.  low is correct. :)

i was just trying to write down comments on odd code that i came across 
before i forgot about it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3805>
_______________________________________

From report at bugs.python.org  Tue Sep  9 19:43:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 17:43:08 +0000
Subject: [issue3815] Python 3.0b3 - Idle doesn't start on win XPh
In-Reply-To: <1220959717.64.0.398340627049.issue3815@psf.upfronthosting.co.za>
Message-ID: <1220982188.29.0.012664204629.issue3815@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing as a duplicate of issue3628

----------
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE does not run with Py30b3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3815>
_______________________________________

From report at bugs.python.org  Tue Sep  9 19:44:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 17:44:34 +0000
Subject: [issue3820] Python 3.0b3 doesn't start on German Win XP SP3/SP2
In-Reply-To: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>
Message-ID: <1220982274.96.0.958596317118.issue3820@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Did you install it for all users, or just for yourself?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3820>
_______________________________________

From report at bugs.python.org  Tue Sep  9 19:47:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 17:47:06 +0000
Subject: [issue3820] Python 3.0b3 doesn't start on German Win XP SP3/SP2
In-Reply-To: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>
Message-ID: <1220982426.04.0.497369557147.issue3820@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, it seems that this installer is lacking the MS CRT. This should be
fixed in the release candidate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3820>
_______________________________________

From report at bugs.python.org  Tue Sep  9 19:55:36 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 17:55:36 +0000
Subject: [issue3812] py3k build fails if configure --without-threads
In-Reply-To: <1220943399.18.0.51803892566.issue3812@psf.upfronthosting.co.za>
Message-ID: <1220982936.48.0.21154353715.issue3812@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66340(py3k).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3812>
_______________________________________

From report at bugs.python.org  Tue Sep  9 20:25:19 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Tue, 09 Sep 2008 18:25:19 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with unprivileged
	servers, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>


New submission from Forest Wilkinson <forest at users.sourceforge.net>:

SSLSocket() and ssl.wrap_socket() accept private keys only as paths to
their location on the file system.  This means that a server can only
support SSL if it has read access to its private key file at the time
when client connections arrive, which is a problem for servers that bind
to their socket and drop privileges as soon as they start up.

In other words, the new ssl module's API prevents its use in servers
that follow best practices that are prevalent in the unix world.

If SSLSocket() and ssl.wrap_socket() were updated to accept private keys
as strings (or open file-like objects or some such), the problem would
go away.  Moreover, it would allow a program to keep private keys cached
in memory, which might slightly improve performance over reading them
from the file system on every new connection.

----------
components: Library (Lib)
messages: 72891
nosy: forest
severity: normal
status: open
title: ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement
type: security
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Tue Sep  9 20:26:52 2008
From: report at bugs.python.org (Tim Pietzcker)
Date: Tue, 09 Sep 2008 18:26:52 +0000
Subject: [issue3820] Python 3.0b3 doesn't start on German Win XP SP3/SP2
In-Reply-To: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>
Message-ID: <1220984812.19.0.0518790295035.issue3820@psf.upfronthosting.co.za>


Tim Pietzcker <tim.pietzcker at web.de> added the comment:

OK, thanks. I have set it to install for all users, if that's still
relevant. Is there a way to manually install the MS CRT (which version),
so I can use b3 until rc1 comes out?

Thanks,
Tim

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3820>
_______________________________________

From report at bugs.python.org  Tue Sep  9 20:29:06 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 09 Sep 2008 18:29:06 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <20080909182855.GD3400@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

1) The section you refer to is 1.2 of RFC2617, which specifies the details on
Access Authentication in General and not specific to url redirects. So, I don't
think we should take it as a referece.

2) Under the section - 3.3 Digest Operation, the Authentication cases under
redirection is provided like this. (search for keyword 'redirect')

"""
The client will retry the request, at which time the server might respond with a 301/302 redirection, pointing to the URI on the second server. The client will follow the redirection, and pass an Authorization header , including the <opaque> data...
"""

This basically states that Authorization header should be passed on the
redirects in Digest authentication case and (should we assume in Basic
Authentication case also?) If yes, then urllib2 is actually doing the same
thing.  Do you have a practical scenario where this has resulted in failure/
security loophole?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3819>
_______________________________________

From report at bugs.python.org  Tue Sep  9 20:48:42 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Tue, 09 Sep 2008 18:48:42 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1220986122.1.0.174786058816.issue3823@psf.upfronthosting.co.za>


Changes by Forest Wilkinson <forest at users.sourceforge.net>:


----------
title: ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement -> ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:04:33 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 09 Sep 2008 19:04:33 +0000
Subject: [issue3817] ftplib: ABOR does not consider 225 response code
In-Reply-To: <1220968645.43.0.419983108509.issue3817@psf.upfronthosting.co.za>
Message-ID: <1220987073.11.0.878694982604.issue3817@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Giampaolo, should we close this one as duplicate of 3818 (that you
created one minute later)?

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3817>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:10:21 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 09 Sep 2008 19:10:21 +0000
Subject: [issue3815] Python 3.0b3 - Idle doesn't start on win XPh
In-Reply-To: <1220959717.64.0.398340627049.issue3815@psf.upfronthosting.co.za>
Message-ID: <1220987421.98.0.627196694465.issue3815@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Sorry for the noise, somehow my search in the bug tracker didn't show 
this report; after fixing the mentioned line in run.py everything works 
ok.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3815>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:17:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 19:17:41 +0000
Subject: [issue3376] Use Python 3 lexer for 3.0 docs
In-Reply-To: <1216403458.56.0.508505661401.issue3376@psf.upfronthosting.co.za>
Message-ID: <1220987861.87.0.231154673503.issue3376@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed in r66344.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3376>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:26:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 19:26:21 +0000
Subject: [issue3822] zfill doc string uses inconsistent variable names
In-Reply-To: <1220976804.14.0.81278850769.issue3822@psf.upfronthosting.co.za>
Message-ID: <1220988381.99.0.683204379676.issue3822@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66347.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3822>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:27:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Sep 2008 19:27:52 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220988472.27.0.421448210685.issue3781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I can understand the amount of time it might take to revert this;
merging was horrendous and stuff was partially combined into single
patches as to get a review done for all related changes instead of doing
more atomic commits if a review was not required.

And it took me days to make the transition and related changes, so
undoing is obviously not easy. Sorry about that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:32:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 19:32:10 +0000
Subject: [issue3800] Fix for formatter.py
In-Reply-To: <1220773592.58.0.798930732664.issue3800@psf.upfronthosting.co.za>
Message-ID: <1220988730.64.0.138510124731.issue3800@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66348.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3800>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:32:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 19:32:19 +0000
Subject: [issue3803] Comparison operators - New rules undocumented in Python
	3.0
In-Reply-To: <1220856570.81.0.704917897963.issue3803@psf.upfronthosting.co.za>
Message-ID: <1220988739.85.0.342999172766.issue3803@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66349.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3803>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:39:42 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Sep 2008 19:39:42 +0000
Subject: [issue3809] test_logging leaving a 'test.blah' file behind
In-Reply-To: <1220967835.82.0.625000064988.issue3809@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809091239k1382b243k8da5b4f120b09db1@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Tue, Sep 9, 2008 at 6:43 AM, Vinay Sajip <report at bugs.python.org> wrote:
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> Fix checked into trunk - revision 66337.
>

Did anyone do a code review for this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3809>
_______________________________________

From report at bugs.python.org  Tue Sep  9 21:43:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 19:43:12 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1220989392.77.0.216681123388.issue3743@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It was a (lame attempt at a) joke... sorry :D

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:13:00 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 20:13:00 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1220991180.09.0.753091446684.issue1717@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Bumping priority even further. This shouldn't make it past rc.

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:23:59 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Tue, 09 Sep 2008 20:23:59 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1220991839.66.0.47113887438.issue3823@psf.upfronthosting.co.za>


Changes by Forest Wilkinson <forest at users.sourceforge.net>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:28:38 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 20:28:38 +0000
Subject: [issue3472] Updates to "Macintosh Library Modules" Section 1.1
In-Reply-To: <1217446944.11.0.813308740394.issue3472@psf.upfronthosting.co.za>
Message-ID: <1220992118.96.0.445457577278.issue3472@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Done in r66350. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3472>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:29:18 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Tue, 09 Sep 2008 20:29:18 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1220992158.36.0.762505038152.issue3823@psf.upfronthosting.co.za>


Forest Wilkinson <forest at users.sourceforge.net> added the comment:

This problem also exists in the add-on ssl module for python < 2.6:
http://pypi.python.org/pypi/ssl/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:32:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 20:32:57 +0000
Subject: [issue3818] ftplib.FTP.abort() should consider "225" a positive
	response code to ABOR
In-Reply-To: <1220968695.13.0.61969231566.issue3818@psf.upfronthosting.co.za>
Message-ID: <1220992377.45.0.343992938452.issue3818@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> ftplib: ABOR does not consider 225 response code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3818>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:36:34 2008
From: report at bugs.python.org (Anthony Lenton)
Date: Tue, 09 Sep 2008 20:36:34 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1220992594.03.0.263629251733.issue1441530@psf.upfronthosting.co.za>


Anthony Lenton <antoniolenton at gmail.com> added the comment:

I confirm that the bug occurs with Python 2.5.1 on Windows XP.  Also,
anglocelt's fix worked fine for me.

----------
nosy: +elachuni

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:42:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 20:42:11 +0000
Subject: [issue3318] Documentation: timeit: "lower bound" should read "upper
	bound"
In-Reply-To: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za>
Message-ID: <1220992931.31.0.275267255012.issue3318@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sadly, this is not mathematics. Else, I'd concur that the designation
"lower bound" should be accurate with respect to a certain set.

I fail to see what is missing in the explanation "the lowest value is a
lower bound *in a typical case*". It allows for lower execution times.

Also, your suggested wording "the lowest value is an upper bound" is
certainly not more accurate, if not an oxymoron in itself. I repeat,
what you usually want when timing code snippets is the execution time
under realistic conditions, because you'd have a hard time defining what
"the fastest machine" is.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3318>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:42:09 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 20:42:09 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed test_tarfile on py3k fails like this.

======================================================================
ERROR: test_directory_size (__main__.WriteTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_tarfile.py", line 598, in test_directory_size
    tarinfo = tar.gettarinfo(path)
  File "/home/WhiteRabbit/python-dev/py3k/Lib/tarfile.py", line 1869, in
gettari
nfo
    tarinfo.gname = grp.getgrgid(tarinfo.gid)[0]
UnicodeDecodeError: 'utf8' codec can't decode byte 0x82 in position 0:
unexpecte
d code byte

======================================

And I noticed PyUnicode_FromString supposes input as UTF-8, but actually
member of struct grp is MBCS or CP932 on cygwin.

After patched following workaround, test passed. I don't know how to fix
this... Does python have system encoding or something?
(I experienced similar error on test_grp and test_pwd)

Index: Modules/grpmodule.c
===================================================================
--- Modules/grpmodule.c	(revision 66345)
+++ Modules/grpmodule.c	(working copy)
@@ -32,6 +32,8 @@
 static int initialized;
 static PyTypeObject StructGrpType;
 
+#define PyUnicode_FromString(s) PyUnicode_DecodeMBCS(s, strlen(s),
"strict")
+
 static PyObject *
 mkgrent(struct group *p)
 {
@@ -83,6 +85,8 @@
     return v;
 }
 
+#undef PyUnicode_FromString
+
 static PyObject *
 grp_getgrgid(PyObject *self, PyObject *pyo_id)
 {

----------
messages: 72907
nosy: ocean-city
severity: normal
status: open
title: test_tarfile fails on cygwin (unicode decode error)
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:56:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 20:56:34 +0000
Subject: [issue3634] invalid result value of _weakref.__init__()
In-Reply-To: <1219339501.95.0.782408070152.issue3634@psf.upfronthosting.co.za>
Message-ID: <1220993794.08.0.256631406613.issue3634@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66352.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3634>
_______________________________________

From report at bugs.python.org  Tue Sep  9 22:57:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 20:57:06 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1220993826.87.0.489946771071.issue3823@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:07:53 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 09 Sep 2008 21:07:53 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>


New submission from Matthew Barnett <python at mrabarnett.plus.com>:

This is a major reworking of the re module in Python 2.5.2.

Added atomic groups.
Added possessive quantifiers.
Lookbehinds can now be variable length.
Typically x2 faster.

More changes to follow.

----------
components: Regular Expressions
files: regex_2.5.2.diff
keywords: patch
messages: 72910
nosy: mrabarnett
severity: normal
status: open
title: Major reworking of Python 2.5.2 re module
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11447/regex_2.5.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:09:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 21:09:48 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <48C6A4E4.2040007@egenix.com>
Message-ID: <48C6E618.2050603@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Rather than arguing about the necessity of including the license
> of a 3rd party file that we intend to include in a wide-spread
> software release, wouldn't it be easier to just add the file
> and be done with it, like I suggested at the very beginning of
> this discussion ?

It's certainly easier to defer the decision than to take action,
especially when we don't *need* to take action (Python works fine
whether or not the file is included). There are so many more important
things to do.

OTOH, contributions are welcome.

----------
title: Add MS EULA to the list of third-party licenses in the	Windows installer -> Add MS EULA to the list of third-party licenses in the Windows installer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:12:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 21:12:49 +0000
Subject: [issue3820] Python 3.0b3 doesn't start on German Win XP SP3/SP2
In-Reply-To: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>
Message-ID: <1220994769.0.0.973231383132.issue3820@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

There is a stand-alone installer for it, but I don't have the time to
google for it right now (it was announced in earlier alpha releases,
when the CRT wasn't included - it has "redistributable" in its name).
Notice that this installer is not uninstallable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3820>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:13:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 21:13:37 +0000
Subject: [issue3820] Python 3.0b3 doesn't start on German Win XP SP3/SP2
In-Reply-To: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>
Message-ID: <1220994817.38.0.64969814057.issue3820@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Alternatively, you can install 2.6 first.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3820>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:16:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 21:16:09 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1220994969.36.0.182959750765.issue3825@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Very interesting! Have you seen #3626? Another thing to note is that
this will have to wait for 2.7 before it could potentially be integrated
into the trunk.

----------
nosy: +benjamin.peterson
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:16:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Sep 2008 21:16:35 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1220994995.59.0.421648013673.issue3825@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi,

This looks impressive. You should really work from the current SVN
trunk, not from the 2.5 sources, as there were some additions to the re
module (mainly, a bytecode verifier contributed by Google).

Also, if it can be split into several functionally independent patches,
it will certainly help reviewing and (perhaps) integrating.

Last remark: we are currently in the last phases of the release process
for 2.6 and 3.0, so your work will probably not get a lot of attention
in the next few weeks. Don't be discouraged though!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:21:12 2008
From: report at bugs.python.org (romkyns)
Date: Tue, 09 Sep 2008 21:21:12 +0000
Subject: [issue3826] Self-reference in BaseHTTPRequestHandler descendants
	causes stuck connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>


New submission from romkyns <ws.python at starkov.name>:

See example code attached. A very basic http server responds with an XML
document to any GET request. I think what happens is that the connection
remains open at the end of the request, leading the browser to believe
there's more data to come (and hence not displaying anything).

What's curious is that commenting out the single line "self.dummy =
self" fixes the problem. Also, the problem occurs in 3.0b2 but not in 2.5.2.

To reproduce:

1. Run the example code on 3.0b2
2. Navigate to http://localhost:8123/
   The browser shows "Transferring data" or something similar, until it
times out.
3. Comment out the line "self.dummy = self"
4. Navigate to http://localhost:8123/
   This time it loads instantly.

Repeat with 2.5.2 - both variants work.

I don't know much at all about python internals, but it seems that 1) a
circular reference prevents the request handler from being GC'd and 2)
http.server relies on the request being GC'd to finalise the connection.

----------
components: Library (Lib)
files: breakage.py
messages: 72917
nosy: romkyns
severity: normal
status: open
title: Self-reference in BaseHTTPRequestHandler descendants causes stuck connections
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11448/breakage.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:21:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 21:21:38 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1220995298.21.0.806512250901.issue3824@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think you should use the locale's encoding to process the data, ie.
either mbstowcs, then Unicode from wchar_t, or decode with the
nl_langinfo(CODESET) encoding. You might have to set the locale before
this can work (which isn't thread-safe), so it might be tricky to implement.

Python already does nl_langinfo at startup, but then restores the
locale. It should probably save the default locale's codeset somewhere,
as C code requires it in many places.

There is also a "system" encoding, but that is UTF-8 independent of the
system.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:21:42 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 21:21:42 +0000
Subject: [issue2859] sphinx and virtualenv
In-Reply-To: <1210831952.05.0.738382267541.issue2859@psf.upfronthosting.co.za>
Message-ID: <1220995302.41.0.818133399221.issue2859@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is a known issue with Jinja, and will hopefully be fixed in its
next release.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2859>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:26:08 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 09 Sep 2008 21:26:08 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1220995568.79.0.461649830678.issue3825@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This sounds really neat.  but as Anotine said it'll be several weeks 
before any of us can give this serious attention.  Definitely update to 
trunk and base your work off of that.

quick comments:

Your _sre.c diff appears to remove and replace the entire file.  I don't 
think thats actually what you did.  Chances are that diff is a result of 
changed newline f lea.  Can you please make sure your file uses the 
previous line ending style so that the diff is more managable.

Also, please include unit test updates to validate all new functionality 
in Lib/test/test_re.py.

thanks for your efforts!  -gps

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:27:22 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 09 Sep 2008 21:27:22 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1220995642.1.0.130751099101.issue3825@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

weird typo:  s/f lea/formats/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Tue Sep  9 23:49:13 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 09 Sep 2008 21:49:13 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <48C6E618.2050603@v.loewis.de>
Message-ID: <48C6EF54.1060300@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-09-09 23:09, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> Rather than arguing about the necessity of including the license
>> of a 3rd party file that we intend to include in a wide-spread
>> software release, wouldn't it be easier to just add the file
>> and be done with it, like I suggested at the very beginning of
>> this discussion ?
> 
> It's certainly easier to defer the decision than to take action,
> especially when we don't *need* to take action (Python works fine
> whether or not the file is included). 

We've had the same issue with the OpenSSL license and the other
3rd party packages which come with the Python Windows installer.

Do you really think that simply ignoring the fact that we are
violating copyrights "because Python works without them" is the
right way to move forward, esp. considering that the PSF itself
is all about protecting copyrights ?

> There are so many more important things to do.

True.

> OTOH, contributions are welcome.

I'd love to, but haven't found a way to determine the path to the
eula.txt file in a reliable way.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:00:46 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Sep 2008 22:00:46 +0000
Subject: [issue3809] test_logging leaving a 'test.blah' file behind
In-Reply-To: <1220925367.02.0.0825641930975.issue3809@psf.upfronthosting.co.za>
Message-ID: <1220997646.65.0.264984432023.issue3809@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Sorry, no - whoops. It was a minor test data change which introduced the
problem...I didn't think it was worth wasting anyone's time (I ran
regrtest, which passed, before checkin) but if you tell me that *all*
changes need to be reviewed, I'll make sure this gets done. I had
thought that only changes of a certain size/complexity needed review...

Is it OK to assign my changes to you for review?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3809>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:01:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 22:01:05 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1220997665.82.0.837767640671.issue1717@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Guido's patch breaks these tests:

test_descr test_hash test_long test_richcmp test_set

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:07:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Sep 2008 22:07:45 +0000
Subject: [issue3746] Sphinx producing duplicate id attributes,
	HTML fails validation.
In-Reply-To: <1220263337.27.0.506394651597.issue3746@psf.upfronthosting.co.za>
Message-ID: <1220998065.23.0.485726237332.issue3746@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the report! This was due to a docutils 0.4/0.5
incompatibility, which should now be fixed in r66355.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3746>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:13:39 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Sep 2008 22:13:39 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1220998419.01.0.404839265269.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No worries - the only reason I suggested full reversion at all is
because I had temporarily forgotten why the relocation had become so
necessary (i.e. we needed the feature ourselves in the main part of the
standard library to avoid emitting spurious warnings).

J.P.'s suggestion (basic functionality in warnings, with each group of
users providing their own convenience API tailored to their own use
cases) makes an awful lot of sense, which is why it is the model I am
going to adopt.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:15:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 09 Sep 2008 22:15:01 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <48C6EF54.1060300@egenix.com>
Message-ID: <48C6F560.4020201@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> We've had the same issue with the OpenSSL license and the other
> 3rd party packages which come with the Python Windows installer.

No, the issue was completely different. Those licenses literally
say "include a copy of the license text" (e.g. for OpenSSL
"Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions [...]")

That's a requirement that I can understand. For the MS EULA,
I don't understand what it says, and I don't know whether
including it will make compliance with the license better or
worse. I need a lawyer to tell me what to do comply with the
license, then I can decide whether I like to do that, and the
lawyer can also tell me what the consequences might be if I
did something different.

> Do you really think that simply ignoring the fact that we are
> violating copyrights

I don't believe we are violating copyrights by not including the
license (and I don't believe you when you say we do). I would
believe a lawyer telling me so (although according to my experience
with lawyers, the lawyer may not actually say that, but only tell
me what to do).

> I'd love to, but haven't found a way to determine the path to the
> eula.txt file in a reliable way.

So I propose to defer this until a) we have a reliable confirmation
that it is the right thing to do, and b) there is also a proposal
for an implementation strategy. Blocking the release for this
issue is really counter-productive.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:16:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 22:16:16 +0000
Subject: [issue2619] Document PEP 3118
In-Reply-To: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>
Message-ID: <1220998576.89.0.232561343867.issue2619@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I documented the memoryview object in r66357. If you're really nice to
me, maybe I'll do the C-API, too. :)

----------
priority: critical -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2619>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:18:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 22:18:42 +0000
Subject: [issue3827] memoryview.size is redundant
In-Reply-To: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>
Message-ID: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

memoryview.size will always be the same as len(view), so one or the
other should go. (probably .size)

----------
components: Interpreter Core
messages: 72929
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: memoryview.size is redundant
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3827>
_______________________________________

From report at bugs.python.org  Wed Sep 10 00:22:22 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 09 Sep 2008 22:22:22 +0000
Subject: [issue3617] Add MS EULA to the list of third-party licenses in the
	Windows installer
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1220998942.36.0.5754596259.issue3617@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Here's a patch that adds the MS EULA to the MSI installer.

I couldn't test this, since I don't have a Python build environment on
Windows, but it should be more or less working.

----------
keywords: +patch
Added file: http://bugs.python.org/file11449/msi-msvs-eula.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Sep 10 01:01:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 23:01:18 +0000
Subject: [issue3827] memoryview.size is redundant
In-Reply-To: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>
Message-ID: <1221001278.09.0.983071224483.issue3827@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11450/remove_size_attr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3827>
_______________________________________

From report at bugs.python.org  Wed Sep 10 01:11:44 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 09 Sep 2008 23:11:44 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <48C6F560.4020201@v.loewis.de>
Message-ID: <48C702AC.6080802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-09-10 00:15, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> We've had the same issue with the OpenSSL license and the other
>> 3rd party packages which come with the Python Windows installer.
> 
> No, the issue was completely different. Those licenses literally
> say "include a copy of the license text" (e.g. for OpenSSL
> "Redistributions in binary form must reproduce the above copyright
>  notice, this list of conditions [...]")
> 
> That's a requirement that I can understand. For the MS EULA,
> I don't understand what it says, and I don't know whether
> including it will make compliance with the license better or
> worse. I need a lawyer to tell me what to do comply with the
> license, then I can decide whether I like to do that, and the
> lawyer can also tell me what the consequences might be if I
> did something different.
>
>> Do you really think that simply ignoring the fact that we are
>> violating copyrights
> 
> I don't believe we are violating copyrights by not including the
> license (and I don't believe you when you say we do). I would
> believe a lawyer telling me so (although according to my experience
> with lawyers, the lawyer may not actually say that, but only tell
> me what to do).

This part sparked the original discussion:

"""
For any Distributable Code you distribute, you must ...
require distributors and external end users to agree to terms
that protect it at least as much as this agreement;
"""

The PSF license doesn't provide the same level of protection
as the MS EULA, so the only way to maintain the protection is
to either add special terms that fulfill this requirement to the
license covering the DLLs, or to simply include the MS EULA and
tell the user that the DLLs are covered by that license.

I proposed to do the latter, since it's the easiest way
to avoid any issues.

>> I'd love to, but haven't found a way to determine the path to the
>> eula.txt file in a reliable way.
> 
> So I propose to defer this until a) we have a reliable confirmation
> that it is the right thing to do, and b) there is also a proposal
> for an implementation strategy. Blocking the release for this
> issue is really counter-productive.

It's not ideal, but if all it takes is including the EULA
(and the PSF lawyer should be able to get back to us on this
within the time frame of the release schedule), then it's easy to
resolve.

----------
title: Add MS EULA to the list of third-party licenses in the Windows installer -> Add MS EULA to the list of third-party licenses in the	Windows installer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Sep 10 01:46:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Sep 2008 23:46:57 +0000
Subject: [issue3827] memoryview.size is redundant
In-Reply-To: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>
Message-ID: <1221004017.25.0.322377647184.issue3827@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +teoliphant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3827>
_______________________________________

From report at bugs.python.org  Wed Sep 10 01:47:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Sep 2008 23:47:45 +0000
Subject: [issue3827] memoryview.size is redundant
In-Reply-To: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>
Message-ID: <1221004065.42.0.419033496982.issue3827@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is ok to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3827>
_______________________________________

From report at bugs.python.org  Wed Sep 10 02:06:45 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 10 Sep 2008 00:06:45 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221005205.35.0.690769537348.issue3825@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


Removed file: http://bugs.python.org/file11447/regex_2.5.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Wed Sep 10 02:11:06 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 10 Sep 2008 00:11:06 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221005466.41.0.44299621409.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Corrected the diff file. I worked from Python 2.5.2 because that's what
I'm currently using. I'll work from the trunk in future.

Added file: http://bugs.python.org/file11451/regex_2.5.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Wed Sep 10 02:41:32 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 10 Sep 2008 00:41:32 +0000
Subject: [issue3817] ftplib: ABOR does not consider 225 response code
In-Reply-To: <1220968645.43.0.419983108509.issue3817@psf.upfronthosting.co.za>
Message-ID: <1221007292.27.0.832589221003.issue3817@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

No, Georg Brandl already closed that one.
Sorry for the duplicate, it was accidental.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3817>
_______________________________________

From report at bugs.python.org  Wed Sep 10 03:32:12 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 10 Sep 2008 01:32:12 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221010332.32.0.627802275109.issue3823@psf.upfronthosting.co.za>


Changes by Bill Janssen <bill.janssen at gmail.com>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 04:21:50 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 10 Sep 2008 02:21:50 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1221013310.02.0.679125955551.issue1589@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Sorry to be so brief there -- I was off on vacation.

Verifying hostnames is a prescription that someone (well, OK, Eric
Rescorla, who knows what he's talking about) put in the https IETF RFC
(which, by the way, is only an informational RFC, not standards-track).
 It's a good idea if you're a customer trying to talk to Wells-Fargo,
say, over an https connection, but isn't suitable for all https traffic.
 I support putting it in the httplib Https class by default, but there
should be a way to override it, as there is with the Java APIs for https
connections.  (Take a look at javax.net.ssl.HostnameVerifier; one of the
more popular Java classes at PARC is a version of this that verifies any
hostname).

So what's wrong with it?  There are two problems.  The first is that
certificates for services are all about the hostname, and that's just
wrong.  You should verify the specific service, not just the hostname. 
    So a client that really cares about what they are talking to should
have the certificate for that service, and verify that it is the service
it's talking to, and ignore the hostname in the URL.

But the larger problem is that hostnames are a DNS construct for humans,
and not really well supported on computers, or by the services that run
on those computers.  Most computers have only the haziest notion of what
their hostname is, and many have lots of different hostnames (my laptop
has at least five hostnames that I know of, all meaning the same
computer, but with five different PARC IP addresses).  So the services
running on that computer aren't real clear about their hostnames,
either.  If I run a service on that computer that I secure with SSL, so
that packets going over my WiFi are encrypted, which hostname should
that service declare itself to be in the certificate?  And the services
on that computer keep running, even when it switches its IP address (and
thus its set of hostnames).  So doing hostname matching provokes lots of
false negatives, especially when it's not needed.  I think it by and
large isn't a good idea, though I support having it (in an overrideable
form) for the client-side https class in httplib.

This is all exacerbated by the fact that HTTP isn't what it was when
Eric wrote that RFC eight years ago.  The growth of Web 2.0 and
"RESTful" services means that lots of new things are using https in a
much less formal way, more to get encrypted packets than to verify
endpoints.  So false negatives caused by mindless hostname verification
cause real damage.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Sep 10 04:34:18 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 02:34:18 +0000
Subject: [issue3809] test_logging leaving a 'test.blah' file behind
In-Reply-To: <1220997646.65.0.264984432023.issue3809@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809091933p4e3bd282u6a812c0158e8af98@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Tue, Sep 9, 2008 at 3:00 PM, Vinay Sajip <report at bugs.python.org> wrote:
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> Sorry, no - whoops. It was a minor test data change which introduced the
> problem...I didn't think it was worth wasting anyone's time (I ran
> regrtest, which passed, before checkin) but if you tell me that *all*
> changes need to be reviewed,

All changes are supposed to happen with the thinking that something
like this wouldn't slip through.

> I'll make sure this gets done.

Well, I am not going to make you revert it, just make sure that future
patches you want in during the rc phase get reviewed.

> I had
> thought that only changes of a certain size/complexity needed review...
>
> Is it OK to assign my changes to you for review?

I don't necessarily have the time, so don't assign to me. Setting
"needs review" and making it a release blocker should be enough to get
someone to look it over.

-Brett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3809>
_______________________________________

From report at bugs.python.org  Wed Sep 10 04:35:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 02:35:50 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220998419.01.0.404839265269.issue3781@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809091935m5bb0c5c6v292cf71903f11086@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Tue, Sep 9, 2008 at 3:13 PM, Nick Coghlan <report at bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> No worries - the only reason I suggested full reversion at all is
> because I had temporarily forgotten why the relocation had become so
> necessary (i.e. we needed the feature ourselves in the main part of the
> standard library to avoid emitting spurious warnings).
>
> J.P.'s suggestion (basic functionality in warnings, with each group of
> users providing their own convenience API tailored to their own use
> cases) makes an awful lot of sense, which is why it is the model I am
> going to adopt.
>

Adopt how? As in just provide a context manager that copies and
restores the filter? That might be enough and then let test.support
have a subclass or another context manager that plugs in the whole
showwarning() implementation. Then everyone should be happy.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Wed Sep 10 04:39:54 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 02:39:54 +0000
Subject: [issue3827] memoryview.size is redundant
In-Reply-To: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>
Message-ID: <1221014394.93.0.71958438724.issue3827@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Since this is a 3.0 thing I am dropping it down to a deferred blocker.

----------
nosy: +brett.cannon
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3827>
_______________________________________

From report at bugs.python.org  Wed Sep 10 04:41:01 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 02:41:01 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1221014461.11.0.736378858507.issue1717@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Since we are making 3.0 issues deferred blockers dropping the priority.

----------
nosy: +brett.cannon
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Wed Sep 10 06:22:40 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Sep 2008 04:22:40 +0000
Subject: [issue3629] Python won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1221020560.03.0.123410029711.issue3629@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Figured it out.  Does anyone want to review?

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11452/fix3629.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Wed Sep 10 06:51:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 04:51:43 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221022303.82.0.0958400717169.issue3811@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Guido, would you like to review?

----------
assignee: effbot -> gvanrossum
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Wed Sep 10 07:41:13 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 05:41:13 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1221025273.91.0.759297548774.issue3642@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Going with what Martin suggested, the attached patch reverts what
Christian did and adds an #ifdef sizeof(uint) <= sizeof(uint) around the
PY_SIZE_MAX check. Someone should obviously test on an AMD64 machine (I
have a Core 2 Mac, but I don't know what flags I would need to pass to
trigger the warning on my machine).

----------
assignee:  -> loewis
keywords: +patch
Added file: http://bugs.python.org/file11453/issue3642.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Wed Sep 10 07:53:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 05:53:42 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1221026022.39.0.943200306068.issue3642@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It doesn't work that way - you can't use sizeof() in the preprocessor.
Instead, the pyconfig.h constants should be used. I'll try to look into
this later today.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Wed Sep 10 08:32:29 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 06:32:29 +0000
Subject: [issue3629] Python won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1221028349.59.0.718368447549.issue3629@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch seems okay and passes regrtest, although I have to admit I am not
intimately familiar with sre or the new validator.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Wed Sep 10 09:01:55 2008
From: report at bugs.python.org (Tim Pietzcker)
Date: Wed, 10 Sep 2008 07:01:55 +0000
Subject: [issue3820] Python 3.0b3 doesn't start on German Win XP SP3/SP2
In-Reply-To: <1220976054.63.0.127579855963.issue3820@psf.upfronthosting.co.za>
Message-ID: <1221030115.87.0.791340464625.issue3820@psf.upfronthosting.co.za>


Tim Pietzcker <tim.pietzcker at web.de> added the comment:

Thanks a lot, now it works! The download link is 

http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf

in case someone else needs it.

Best regards,
Tim

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3820>
_______________________________________

From report at bugs.python.org  Wed Sep 10 09:05:49 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 10 Sep 2008 07:05:49 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1221030349.36.0.998826229268.issue3807@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +needs review
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Wed Sep 10 09:06:14 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Wed, 10 Sep 2008 07:06:14 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221030374.65.0.532414494397.issue3811@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

The patch looks fine to me (assuming that I didn't miss something 
critical hidden among the large table diffs).

(I'd probably named the "NODELTA" flag after what it is rather than what 
it isn't, but I cannot think of a short replacement right now, so let's 
leave it as it is.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Wed Sep 10 09:26:02 2008
From: report at bugs.python.org (Thorben Krueger)
Date: Wed, 10 Sep 2008 07:26:02 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1221031562.14.0.495802396879.issue3766@psf.upfronthosting.co.za>


Thorben Krueger <thkruege at uos.de> added the comment:

As promised, here is the profiler output for a Mac (thanks Stefan). The
problem does NOT occur here, which should help greatly in tracking down
the cause in the socket library. Anyone into this?

$ python runme.py
500 packets @ 2 tokens each (500 very short lists)
0.0814669132233
        14508 function calls in 0.082 CPU seconds

  Ordered by: internal time

  ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    1500    0.048    0.000    0.048    0.000 {method 'recv' of
'_socket.socket' objects}
    1500    0.015    0.000    0.015    0.000 <string>:1(sendall)
    1500    0.003    0.000    0.021    0.000 Client.py:8(send_int)
    1500    0.003    0.000    0.053    0.000 Client.py:16(read_int)
     500    0.003    0.000    0.057    0.000 Client.py:19(read_int_list)
    1500    0.002    0.000    0.002    0.000 struct.py:77(unpack)
    1500    0.002    0.000    0.002    0.000 struct.py:54(pack)
     500    0.001    0.000    0.022    0.000 Client.py:11(send_int_list)
       1    0.001    0.001    0.082    0.082 runme.py:12(bench)
    1000    0.001    0.000    0.001    0.000 {method 'insert' of 'list'
objects}
    1001    0.001    0.000    0.001    0.000 {range}
     500    0.001    0.000    0.080    0.000 Client.py:28(spam)
    1500    0.000    0.000    0.000    0.000 {method 'unpack' of
'Struct' objects}
     501    0.000    0.000    0.000    0.000 {len}


1 packet @ 50000 tokens (1 very long list)
5.20953297615
        400018 function calls in 5.210 CPU seconds

  Ordered by: internal time

  ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   50001    2.267    0.000    2.267    0.000 <string>:1(sendall)
   50001    1.263    0.000    1.263    0.000 {method 'recv' of
'_socket.socket' objects}
   50000    1.112    0.000    1.112    0.000 {method 'insert' of 'list'
objects}
   50001    0.137    0.000    1.490    0.000 Client.py:16(read_int)
   50001    0.134    0.000    2.478    0.000 Client.py:8(send_int)
       1    0.082    0.082    2.685    2.685 Client.py:19(read_int_list)
   50001    0.077    0.000    0.077    0.000 struct.py:54(pack)
   50001    0.073    0.000    0.089    0.000 struct.py:77(unpack)
       1    0.044    0.044    2.522    2.522 Client.py:11(send_int_list)
   50001    0.016    0.000    0.016    0.000 {method 'unpack' of
'Struct' objects}

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Wed Sep 10 10:15:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 08:15:16 +0000
Subject: [issue3629] Python won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1221034516.22.0.568639775067.issue3629@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I came to the same conclusion: the 'skip' value is relative to the
previous code, so it is necessary to adjust the target position.
The patch is OK for me.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Wed Sep 10 10:20:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 08:20:08 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1221034808.56.0.462669107007.issue3743@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Jumping to "release blocker", since it causes a buildbot to fail.
Review needed.

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Wed Sep 10 11:34:28 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 10 Sep 2008 09:34:28 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221039268.13.0.247940132815.issue3811@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Reviewed the patch: looks fine to me. 

One nit: the unicodedata module doc-string must be updated to 5.1.0 as
well. Ditto for the documentation.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Wed Sep 10 11:36:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 09:36:37 +0000
Subject: [issue3821] trace module bug when using --missing
In-Reply-To: <1220976433.09.0.355914664139.issue3821@psf.upfronthosting.co.za>
Message-ID: <1221039397.61.0.947167815075.issue3821@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This can be further simplified:
   line_increments = code.co_lnotab[1::2]

Assigning to myself, I will try to add unit tests as well. the trace
module is not tested at all...

----------
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3821>
_______________________________________

From report at bugs.python.org  Wed Sep 10 12:06:11 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 10 Sep 2008 10:06:11 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221041171.07.0.842647380311.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Not quite that basic for the warnings.catch_warnings() part. I plan to
leave the current warnings.catch_warnings() alone (aside from adding
some re-entrancy checks), and add back a
test.test_support.check_warnings() that uses a WarningsRecorder object
to simplify the specific use cases in the Python regression test suite
(i.e. at least adding back the easy attribute access, and possibly other
things if there are other common features of the way we use it in the
tests).

The patch will make it clearer (working on that now).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Wed Sep 10 12:10:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 10:10:29 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221041429.37.0.430149765859.issue3825@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The correct link is #2636.
Is it the same work?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Wed Sep 10 13:28:22 2008
From: report at bugs.python.org (Christian Kassab)
Date: Wed, 10 Sep 2008 11:28:22 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1221046102.87.0.86218073769.issue1424152@psf.upfronthosting.co.za>


Christian Kassab <chris.kassab at gmail.com> added the comment:

Python 2.4.3 also doesn't support ssl and a proxy to be used at the same
time in CentOS 5.1. This file addresses the issues. It has been tested
by using YUM to access a repository through a proxy using ssl client
certificates. YUM itself needed to be patched to allow for client certs
to be used... that change is on its way upstream.

Thanks to all the other guys here for supplying the first patches!

----------
nosy: +ckassab
versions: +Python 2.4
Added file: http://bugs.python.org/file11454/issue1424152-py24.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Wed Sep 10 13:34:20 2008
From: report at bugs.python.org (Simon Cross)
Date: Wed, 10 Sep 2008 11:34:20 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221046460.28.0.660798014976.issue3823@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

I've dug around in the code a bit and the keyfile, certfile and ca_certs
filename arguments to SSLSocket.__init__ are passed down into
newPySSLObject in _ssl.c and from there directly to SSL_CTX_* function
from OpenSSL so making these arguments allow file-like objects is going
to be non-trivial.

The options I see are:

* Write the file-like objects out to named temporary files and pass
those through to OpenSSL (seems like a nasty hack and prone to all sorts
of problems).

* Change the which OpenSSL functions are used to setup the certificate
(I definitely don't think this could go into 2.6 or 3.0 at this stage;
also see analysis of current OpenSSL usage below for more difficulties)

* Add an SSL CTX wrapper object and allow that to be passed down to
newPySSLObject instead of the filenames. Then the CTX object could be
created before dropping privileges (I think this is probably also too
big a change to be considered for 2.6 or 3.0 at this point, but it's
what looks best to me at the moment).

The current situation in _ssl.c:

* keyfile is loaded using SSL_CTX_use_PrivateKey_file(...) which loads
the first certificate from keyfile into ctx. We could replace this with
SSL_CTX_use_PrivateKey(SSL_CTX *ctx, EVP_PKEY *pkey) but we'd have to
load the key ourselves and make sure to follow what OpenSSL does to
maintain compatibility.

* certfile is loaded with SSL_CTX_use_certificate_chain_file(...) which
reads in all the certificates from certfile into ctx. We could read the
certificates in ourselves and them load them one by one using
SSL_CTX_use_certificate(...) and then SSL_CTX_add_extra_chain_cert(...).

* ca_certs is loaded using SSL_CTX_load_verify_locations(...). As fasr
as I can see there is no convenient replacement function for this in
OpenSSL. SSL_CTX_set_client_CA_list(...) will load a list of certificate
names but doesn't load the certificates themselves (so verification
won't be done with them) and SSL_CTX_add_client_CA(...) has the same
issue.      

One could use SSL_CTX_set_cert_store(...) to register callbacks (and
then presumably one can do whatever one wants and can get around the
ca_certs issue) but the man page for SSL_CTX_set_cert_store has the
rather disheartening "Currently no detailed documentation on how to use
the X509_STORE object is available."

All this comes with the proviso that I just started digging into the
OpenSSL manpages today so I'm a long way from being an expert. :)

I can probably find time to create a patch with tests once we have a
clear direction to go in.

@Forest: If you have an details on how non-Python servers go about
loading certificates and then dropping privileges using OpenSSL, that
would be extremely useful.

----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 13:37:52 2008
From: report at bugs.python.org (Mike Statkus)
Date: Wed, 10 Sep 2008 11:37:52 +0000
Subject: [issue1606092] csv module broken for unicode
Message-ID: <1221046672.16.0.359573864052.issue1606092@psf.upfronthosting.co.za>


Mike Statkus <mstatkus at yandex.ru> added the comment:

Example of UnicodeWriter.writerow(self,row) presented in Python 2.5
Manual at section 9.1.5 (Examples on CSV module of standard library)
does not correctly process rows containing not only strings, but also
int type values, raising an attribute error. 
1st line of code in UnicodeWriter.writerow:
self.writer.writerow([s.encode("utf-8") for s in row])
tries to call .encode() method for s, that might be an int, not a
string. A simple workaround is:
self.writer.writerow([unicode(s).encode("utf-8") for s in row])

----------
nosy: +mstatkus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1606092>
_______________________________________

From report at bugs.python.org  Wed Sep 10 14:22:50 2008
From: report at bugs.python.org (Travis N. Vaught)
Date: Wed, 10 Sep 2008 12:22:50 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221049370.25.0.239991773174.issue3617@psf.upfronthosting.co.za>


Changes by Travis N. Vaught <travis at enthought.com>:


----------
nosy: +tvaught

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Wed Sep 10 14:45:07 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 10 Sep 2008 12:45:07 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1221050707.34.0.00331069639343.issue3824@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, probably I saw illusion... If uses cp932 codec, still
test_tarfile.py reports error. :-(

======================================================================
ERROR: test_tar_size (__main__.WriteTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_tarfile.py", line 570, in test_tar_size
    tar.add(path)
  File "/home/WhiteRabbit/python-dev/py3k/Lib/tarfile.py", line 1953, in add
    self.addfile(tarinfo, f)
  File "/home/WhiteRabbit/python-dev/py3k/Lib/tarfile.py", line 1976, in
addfile

    buf = tarinfo.tobuf(self.format, self.encoding, self.errors)
  File "/home/WhiteRabbit/python-dev/py3k/Lib/tarfile.py", line 987, in
tobuf
    return self.create_gnu_header(info, encoding, errors)
  File "/home/WhiteRabbit/python-dev/py3k/Lib/tarfile.py", line 1018, in
create_
gnu_header
    return buf + self._create_header(info, GNU_FORMAT, encoding, errors)
  File "/home/WhiteRabbit/python-dev/py3k/Lib/tarfile.py", line 1107, in
_create
_header
    stn(info.get("gname", "root"), 32, encoding, errors),
  File "/home/WhiteRabbit/python-dev/py3k/Lib/tarfile.py", line 177, in stn
    s = s.encode(encoding, errors)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-3: ordin
al not in range(128)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Wed Sep 10 14:45:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 12:45:32 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1221050732.35.0.270706544022.issue3807@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is not easy to read, but if it can be summarized to:

    if sysconfig.get_config_var('WITH_THREAD'):
        <build the _multiprocessing extension>
    else:
        missing.append('_multiprocessing')

then this makes sense - it seems that the multiprocessing module is
completely unusable if python cannot use threads. Even at the python
level, it uses "import threading" in many places.

This need another review, though. Raising issue to ReleaseBlocker.

----------
nosy: +amaury.forgeotdarc
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Wed Sep 10 14:57:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 12:57:13 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1221051433.26.0.0477246113851.issue3824@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is PyUnicode_DecodeMBCS available on cygwin?
I get compilation errors when I try your patch.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Wed Sep 10 15:11:31 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 10 Sep 2008 13:11:31 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1221052291.39.0.511042913501.issue3824@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Yes, when I did it last night, I thought I could compile it and saw OK
on test_tarfile.py, but probably I dreamed. :-(

#define PyUnicode_FromString(s) PyUnicode_Decode(s, strlen(s), "cp932",
"strict")

or following patch should work.

----------
keywords: +patch
Added file: http://bugs.python.org/file11455/experimental_mbcstowcs_codec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Wed Sep 10 16:08:31 2008
From: report at bugs.python.org (Andreas Kloeckner)
Date: Wed, 10 Sep 2008 14:08:31 +0000
Subject: [issue3828] Bound methods compare 'successfully' with ints
In-Reply-To: <1221055711.08.0.163905874333.issue3828@psf.upfronthosting.co.za>
Message-ID: <1221055711.08.0.163905874333.issue3828@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

Check out this transcript:
8< -----------------------------------------------------------------------
Python 2.5.2 (r252:60911, Aug  8 2008, 09:22:44) 
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
...   def b(self):
...     pass
... 
>>> a = A()
>>> a.b < 0
False
>>> 
8< -----------------------------------------------------------------------

I would argue that the 'successful' comparison of a bound method with an
int is undesirable. This especially bad when you're refactoring a class
property into a class method and the property used to get used in
comparisons.
Instead of the expected exceptions, you get weird behavior.

----------
components: Interpreter Core
messages: 72961
nosy: inducer
severity: normal
status: open
title: Bound methods compare 'successfully' with ints
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3828>
_______________________________________

From report at bugs.python.org  Wed Sep 10 16:12:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 14:12:27 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221055947.6.0.334635302748.issue3811@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now committed the change as r66362 (including the missing
documentation updates), and ported it to 3.0 as r66363 (where I had to
change the flag value and regenerate the data, as the flag 0x100 was
already taken).

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Wed Sep 10 16:13:29 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Sep 2008 14:13:29 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1221056009.63.0.345620336287.issue3799@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think this isn't quite right.

Ideally a fix should maintain several important properties:

(1) Be able to read databases written by Python 2.x.

(1a) Write databases readable by Python 2.x.

(2) Use the same mapping between str and bytes as the other *dbm
libraries have.

(2a) Return the same value for keys() as the other *dbm libraries
(except for order).

I think (2) means that we should use UTF-8 to convert str keys to bytes,
but (1) means we should use Latin-1 to convert keys to str *upon writing
the index*.  This will also satisfy (1a).  The keys maintained
internally should be kept in bytes to satsfy (2a).

PS. I noticed the dbm module still returns bytearrays for keys and
values. Is there a bug open to change those to bytes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Wed Sep 10 16:28:07 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Sep 2008 14:28:07 +0000
Subject: [issue3629] Python won't compile a regex that compiles with 2.5.2 and
	30b2
In-Reply-To: <1219308121.8.0.569099168761.issue3629@psf.upfronthosting.co.za>
Message-ID: <1221056887.35.0.0238106334655.issue3629@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Submitted as r66364.

I'll merge into 3.0 as well (it's  clean merge).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3629>
_______________________________________

From report at bugs.python.org  Wed Sep 10 16:52:31 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 10 Sep 2008 14:52:31 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221058351.15.0.729379450908.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

This is different work from a different author than #2636. I've
submitted what I've done so far in case my computer gets hit by a bus.
:-) I still have more work to do on it, so I'm not concerned that it
might not get any attention for a while.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Wed Sep 10 17:20:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 15:20:15 +0000
Subject: [issue3828] Bound methods compare 'successfully' with ints
In-Reply-To: <1221055711.08.0.163905874333.issue3828@psf.upfronthosting.co.za>
Message-ID: <1221060015.51.0.0977144629494.issue3828@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You are right. And thanks to the time machine, python 3.0 already forbid
such comparisons:

>>> a.b < 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: method() < int()

The behaviour cannot change for the 2.x series, though - it would break
backward compatibility. python2.6 however has a "-3" option that prints
a warning in this case:

>>> a.b < 0
__main__:1: DeprecationWarning: comparing unequal types not supported in 3.x

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3828>
_______________________________________

From report at bugs.python.org  Wed Sep 10 17:20:46 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 10 Sep 2008 15:20:46 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221060046.17.0.727410188982.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Cleanup patch now attached. Details of changes:

- warnings.catch_warnings() now has reentry guards (and associated
tests) to prevent silent errors when misused

- added back a test_support.check_warnings() convenience wrapper
(deliberately changing the name to be different from the context manager
in the warnings module). This wrapper is no longer configurable - it is
now used solely for tests that want to record normal warnings and check
the results.

- restored the w.reset() calls that went away in the previous checkin

- unit tests that want to test a different module, or don't want
warnings recorded now consistently use warnings.catch_warnings() directly

- cleanups up to the respective documentation

- cleanups to test_py3kwarn so it is better behaved when other tests are
run before it (the lack of reinitialisation of extension modules still
causes problems though)

- tested with "./python -3 -m test.regrtest -uall -x test_ossaudiodev"
(exclusion is needed because test_ossaudiodev hasn't worked properly on
my machine in a very long time - the audio file playback runs overtime
and I've never found the time to figure out why)

Just needs a review and then should be good to go.

----------
keywords: +needs review -patch
Added file: http://bugs.python.org/file11456/issue3781_catch_warnings_cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Wed Sep 10 17:44:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 15:44:01 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1221061441.53.0.398758585411.issue3642@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is my attempt for a patch (obmalloc.diff). Please review.

----------
keywords: +needs review
Added file: http://bugs.python.org/file11457/obmalloc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Wed Sep 10 17:51:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 15:51:17 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1221061877.98.0.278143493933.issue3743@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please apply.

----------
assignee:  -> amaury.forgeotdarc
keywords:  -needs review
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Wed Sep 10 17:59:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 15:59:17 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1221062357.63.0.0371897154902.issue2876@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still don't see why this is a release blocker. Adding a 2to3 fixer
certainly isn't a release blocker - if the fixer isn't available, users
would need to manually fix the code.

Adding a Py3k warning shouldn't be a release blocker, either - I think
such warnings could get added in 2.6.1 also (as they are only issued if
you invoke Python with -3).

Tentatively lowering the priority to normal.

----------
nosy: +loewis
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Wed Sep 10 18:03:57 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 16:03:57 +0000
Subject: [issue2350] 'exceptions' import fixer
In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za>
Message-ID: <1221062637.02.0.11472342726.issue2350@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Given that this is now a request for a fixer, and not a request for a
deprecation warning, I don't see why this is considered a release
blocker. Lowering the priority to normal. Even if the fixer isn't added
to the 2to3 copy shipped with 2.6.0, I think 2to3 improvements can well
be incorporated into 2.6.1 (including additional fixers).

----------
nosy: +loewis
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2350>
_______________________________________

From report at bugs.python.org  Wed Sep 10 18:10:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 16:10:38 +0000
Subject: [issue3807] _multiprocessing build fails when configure
	--without-threads
In-Reply-To: <1220918117.44.0.469611073223.issue3807@psf.upfronthosting.co.za>
Message-ID: <1221063038.4.0.73211766894.issue3807@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why is this a release blocker? If you configure without threads, you get
a few ugly compiler messages, but Python still builds exactly the same
way as without this patch, right?

So if the patch doesn't make it into 2.6, it can still be applied in
2.6.1 (as it is a clear bugfix).

Tentatively lowering priority to normal.

As for reviewing it: indeed, it looks overly complicated (perhaps it
would look nicer in Rietveld). As a last-minute change, I would prefer
something that looks more along the lines of Amaury's fragment (i.e.
trying to avoid changes to the indentation level).

----------
nosy: +loewis
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3807>
_______________________________________

From report at bugs.python.org  Wed Sep 10 18:17:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 16:17:31 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1221063451.09.0.0187412283262.issue1868@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If Christian's analysis is right, and memory is released except for the
last thread, I don't think this qualifies as a release blocker.

Also (unless I misinterpret the issue), it seems that we have made many
releases already which had this bug, so it's unclear why it should block
the next release.

Tentatively lowering the priority to high.

----------
nosy: +loewis
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Wed Sep 10 18:18:10 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Sep 2008 16:18:10 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221063490.18.0.247357511565.issue3811@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file11458/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Wed Sep 10 18:11:58 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Sep 2008 16:11:58 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1221055947.6.0.334635302748.issue3811@psf.upfronthosting.co.za>
Message-ID: <ca471dc20809100911u9c99bbbu4f98e6cd56da33c8@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

2008/9/10 Martin v. L?wis <report at bugs.python.org>:
> I have now committed the change as r66362 (including the missing
> documentation updates), and ported it to 3.0 as r66363 (where I had to
> change the flag value and regenerate the data, as the flag 0x100 was
> already taken).

That's unfortunate -- perhaps the 2.6 flag and data can be brought in line,
to make future merges easier?

Added file: http://bugs.python.org/file11458/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080910/93d06ef5/attachment.txt>

From report at bugs.python.org  Wed Sep 10 18:33:04 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Sabl=C3=A9?=)
Date: Wed, 10 Sep 2008 16:33:04 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1221064384.3.0.611887379831.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

My previous patch has a small problem as I believed dlmalloc was always
returning a non-NULL value, even when asking for 0 bytes.

It turns out not to be the case, so here is a new patch
(patch_dlmalloc3.diff) which must be applied after the previous one
(patch_dlmalloc2.diff) to correct this problem.

Added file: http://bugs.python.org/file11459/patch_dlmalloc3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Wed Sep 10 18:47:19 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 10 Sep 2008 16:47:19 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221065239.35.0.578340373249.issue3823@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Thanks, Simon.

I remember digging through all this last year, and finally deciding
to keep things simple and use the strategy the current codebase uses.

It almost sounds like we'd need to create Key and Certificate objects
in the _ssl module, which could be used to load up all the keys and/or
certificates the server uses, before it changes UID (and presumbably
loses access to the files the data is kept in).  I was resisting
going down that path; there's a lot of complexity there I want to avoid.
But much of the mechanism of a Certificate object is already there;
perhaps adding an opaque Key object wouldn't be too bad.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 18:54:32 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 10 Sep 2008 16:54:32 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221065672.52.0.948787625248.issue3823@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Both M2Crypto and pyOpenSSL expose certificate and key objects and have
seen lots of real-world use.  Following their lead would be sensible.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 19:44:48 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 10 Sep 2008 17:44:48 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: <1220321981.61.0.172632147.issue3756@psf.upfronthosting.co.za>
Message-ID: <1221068688.96.0.502604419475.issue3756@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Looks fine, except I used frozenset for the _alphanum* variables and
reverted to double quotes like the rest of the file.  Submitted as r66366.

----------
assignee:  -> gvanrossum
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3756>
_______________________________________

From report at bugs.python.org  Wed Sep 10 20:09:23 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 10 Sep 2008 18:09:23 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <ca471dc20809100911u9c99bbbu4f98e6cd56da33c8@mail.gmail.com>
Message-ID: <48C80D51.1090309@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> That's unfortunate -- perhaps the 2.6 flag and data can be brought in
> line, to make future merges easier?

I thought of that, however, merging the databases themselves would still
not be possible: the 3.0 database has the flags set in many records,
which causes merge conflicts (as the 2.x database has different flag
values). So regenerating the database is necessary, anyway.

In future changes, it might be useful to have new flags with the same
values, so that such patches can be merged without conflicts in the
generator.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Wed Sep 10 20:12:00 2008
From: report at bugs.python.org (romkyns)
Date: Wed, 10 Sep 2008 18:12:00 +0000
Subject: [issue3826] Self-reference in BaseHTTPRequestHandler descendants
	causes stuck connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1221070320.24.0.00463128476259.issue3826@psf.upfronthosting.co.za>


romkyns <ws.python at starkov.name> added the comment:

My initial description doesn't state the actual observable problem very
clearly: the problem is that the browser gets stuck instead of
displaying the page, writing something along the lines of "Transferring
data from localhost". After many seconds it times out. Aborting the
request in Firefox causes the page to be displayed.

Also forgot to mention that it's possible to work around this by
explicitly removing all circular references after the base class'
__init__ method - so for the attached example a work-around is
"self.dummy = None" as the last line of the __init__ method.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Wed Sep 10 22:33:00 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 10 Sep 2008 20:33:00 +0000
Subject: [issue3829] Tuple comparison masking exception
In-Reply-To: <1221078780.65.0.750398332014.issue3829@psf.upfronthosting.co.za>
Message-ID: <1221078780.65.0.750398332014.issue3829@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. <fdrake at acm.org>:

There's a strange condition where cmp() of tuples of unorderable values
returns -1 even though using the unorderable values raises an exception.

If I have these two unorderable values, cmp() raises an expected exception:

  >>> s0 = frozenset(['testing 0'])
  >>> s1 = frozenset(['testing 1'])
  >>> cmp(s0, s1)
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  TypeError: cannot compare sets using cmp()

Comparing tuples of the values returns -1:

  >>> cmp((s0,), (s1,))
  -1

Py3k does raise a TypeError, but the message is indecipherable:

  >>> cmp((s0,), (s1,))
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unorderable types: 'tuple' != 'tuple'

(The Py3k message for the set comparison is the same as for Python 2.)

I believe that this is an error; the exception from the underlying item
comparison should be propagated.

----------
components: Interpreter Core
messages: 72981
nosy: fdrake
severity: normal
status: open
title: Tuple comparison masking exception
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3829>
_______________________________________

From report at bugs.python.org  Wed Sep 10 22:36:58 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 10 Sep 2008 20:36:58 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221079018.36.0.449130665999.issue3823@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Sure -- but the point of the SSL module was to do something
small and compatible with the existing socket.ssl module; I really don't
want to get into a full-fledged Python interface to OpenSSL.  Perhaps
incremental progress would be OK...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 22:47:17 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 10 Sep 2008 20:47:17 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221079637.48.0.302164344492.issue3823@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I'm just suggesting that if the ssl module *is* going to gain
certificate and key objects, looking at existing APIs and perhaps
emulating them, to the extent that they provide functionality which the
ssl module is also going to provide, is a good idea.  Perhaps we could
actually get the various APIs to begin to converge (where they overlap)
instead of producing further divergence.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 23:07:46 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 10 Sep 2008 21:07:46 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1221080866.61.0.216484166243.issue1868@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Agreed, this is fine for a bugfix point release.

I was initially concerned about the Modules/threadmodule.c struct 
localobject changing but that is private and used only by code within 
threadmodule.c so its not part of an API anything else could depend on.  
Changing it for 2.6.1/2.5.3/3.0.1 should be fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Wed Sep 10 23:08:11 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 10 Sep 2008 21:08:11 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221080891.69.0.0638379149055.issue3823@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

You can load a private key from a string by creating a memory BIO and
using PEM_read_bio_PrivateKey or d2i_PrivateKey_bio.

This is how pyOpenSSL implements its load_privatekey API.  You can see
the code here:

http://bazaar.launchpad.net/~exarkun/pyopenssl/trunk/annotate/70?file_id=crypto.c-20080219014912-qyb7kjf196jhzlyv-128

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 23:31:02 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 10 Sep 2008 21:31:02 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221082262.41.0.6350108068.issue3811@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

#66363 breaks test_unicode and test_format on 3.0.

----------
nosy: +ajaksu2
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Wed Sep 10 23:02:38 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Wed, 10 Sep 2008 21:02:38 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1221080558.69.0.108075646854.issue3823@psf.upfronthosting.co.za>


Forest Wilkinson <forest at users.sourceforge.net> added the comment:

Simon:  I wish I could offer guidance here, but I'm afraid that I too am
reading some of these openssl man pages for the first time.

I agree that writing to a temporary file would be bad.

Accepting file-like objects from python code would be nice, but isn't
really necessary.  Simple strings would suffice.  It's easy enough for
application code to read the strings from the appropriate files.  Of
course, the ssl module (or an underlying library) would need a way to
determine the data format within the strings.  Unfortunately, I didn't
notice an equivalent of SSL_CTX_use_PrivateKey_file() that accepts a
file's contents instead of its path.  SSL_CTX_use_RSAPrivateKey() looks
like the next best thing.

>much of the mechanism of a Certificate object is already there;
>perhaps adding an opaque Key object wouldn't be too bad."

That's encouraging.

>From the openssl docs I've read so far, it looks like certificates and
keys have several formats and use patterns.  That seems to me like
another argument in favor of supporting separate Certificate and Key
objects, even if they're only minimally implemented to begin with.  In
other words, I don't imagine the presence of Certificate and Key objects
would muck up the ssl module's api.

In order to keep compatibility with socket.ssl, perhaps any new
certificate and key objects should be accepted as alternatives to the
existing certfile and keyfile args, but the latter should still be allowed?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3823>
_______________________________________

From report at bugs.python.org  Wed Sep 10 23:47:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Sep 2008 21:47:23 +0000
Subject: [issue3827] memoryview.size is redundant
In-Reply-To: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>
Message-ID: <1221083243.75.0.21222525748.issue3827@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66374.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3827>
_______________________________________

From report at bugs.python.org  Wed Sep 10 23:58:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Sep 2008 21:58:44 +0000
Subject: [issue3658] fix for pychecker property complaints
In-Reply-To: <1219583429.18.0.798677952106.issue3658@psf.upfronthosting.co.za>
Message-ID: <1221083924.45.0.478551529891.issue3658@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I agree with Antoine, so I'm just going to close this as rejected.
There's little benefit in it, but there is potential harm.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3658>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:20:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 22:20:27 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221085227.78.0.687282410565.issue3640@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can someone have a look at this patch?
It is not 64bit nor Windows specific; its goal is to reduce the size of 
local variables in batch_list(), which is easy to verify.

The point is to check the correctness of the code, specially around 
errors checks and reference counting.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:25:14 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 22:25:14 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1221085514.6.0.347378580401.issue3743@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r66377 and r66378.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:29:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Sep 2008 22:29:03 +0000
Subject: [issue3743] PY_FORMAT_SIZE_T is not for PyString_FromFormat
In-Reply-To: <1220215238.73.0.721040984863.issue3743@psf.upfronthosting.co.za>
Message-ID: <1221085743.21.0.0423733321359.issue3743@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

You forgot to update Parser/asdl_c.py; I did it in r66379.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3743>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:32:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Sep 2008 22:32:42 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221085962.12.0.474749284008.issue3640@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:32:48 2008
From: report at bugs.python.org (SunriseProgrammer)
Date: Wed, 10 Sep 2008 22:32:48 +0000
Subject: [issue3830] Tarfile has incorrect USTAR "VERSION" field (should be 00;
	is 0 NUL)
In-Reply-To: <1221085968.85.0.567851806053.issue3830@psf.upfronthosting.co.za>
Message-ID: <1221085968.85.0.567851806053.issue3830@psf.upfronthosting.co.za>


New submission from SunriseProgrammer <peterdanielsmith at gmail.com>:

The 'tarfile' object make incorrect header blocks.  There's a USTAR 
'MAGIC' string that's supposed to be followed by a version; that version 
is supposed to be two '0' (digit zero -- ascii 48) chars with no NUL 
padding at all.

Python 2.4.3 has it correct.  Later versions (e.g., 2.5) are carefully 
making the field NUL terminated -- but that's wrong; they aren't 
supposed to be.

File History:
'tarfile.py' was correct in version 41340 and incorrect in version 45954

----------
components: Library (Lib)
messages: 72993
nosy: SunriseProgrammer
severity: normal
status: open
title: Tarfile has incorrect USTAR "VERSION" field (should be 00; is 0 NUL)
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3830>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:38:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Sep 2008 22:38:37 +0000
Subject: [issue3830] Tarfile has incorrect USTAR "VERSION" field (should be 00;
	is 0 NUL)
In-Reply-To: <1221085968.85.0.567851806053.issue3830@psf.upfronthosting.co.za>
Message-ID: <1221086317.71.0.193867364833.issue3830@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3830>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:40:28 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 22:40:28 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1221086428.14.0.732786313621.issue3642@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch looks good to me and Martin's analysis of the test being useless
on a platform where size_t > uint_t makes sense.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Thu Sep 11 00:48:34 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Sep 2008 22:48:34 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221086914.19.0.762671213223.issue3781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Code looks good.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Thu Sep 11 01:24:58 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Wed, 10 Sep 2008 23:24:58 +0000
Subject: [issue3756] re.escape() does not work with bytes()
In-Reply-To: Your message of "Wed, 10 Sep 2008 17:44:49 GMT."
	<1221068688.96.0.502604419475.issue3756@psf.upfronthosting.co.za>
Message-ID: <20080910232453.A063160081D@longblack.object-craft.com.au>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

>Looks fine, except I used frozenset for the _alphanum* variables and
>reverted to double quotes like the rest of the file.  Submitted as r66366.

All good. Thankyou.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3756>
_______________________________________

From report at bugs.python.org  Thu Sep 11 01:54:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Sep 2008 23:54:55 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221090895.07.0.666208146263.issue3811@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Code point 0x0370 is now a printable character.
r66381 corrected the failures by simply changing it to 0x0378, until the 
next unicodedata upgrade...
I wonder if there is a value that is guaranteed to stay non-printable.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Thu Sep 11 02:06:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Sep 2008 00:06:07 +0000
Subject: [issue3821] trace module bug when using --missing
In-Reply-To: <1220976433.09.0.355914664139.issue3821@psf.upfronthosting.co.za>
Message-ID: <1221091567.02.0.655679193644.issue3821@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a simple test suite for the trace module, and two corrections to 
make it work.

The test file is suitable for 2.6 (simply replace test.support with 
test.test_support)

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11460/trace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3821>
_______________________________________

From report at bugs.python.org  Thu Sep 11 02:26:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Sep 2008 00:26:46 +0000
Subject: [issue3827] memoryview.size is redundant
In-Reply-To: <1220998722.51.0.437899578247.issue3827@psf.upfronthosting.co.za>
Message-ID: <1221092806.1.0.240528376164.issue3827@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This causes test_ctypes to fail.
r66382 corrects the test to use len(v) instead of v.size

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3827>
_______________________________________

From report at bugs.python.org  Thu Sep 11 03:08:54 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 11 Sep 2008 01:08:54 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1221090895.07.0.666208146263.issue3811@psf.upfronthosting.co.za>
Message-ID: <ca471dc20809101808o78aef7b2l4be4c1bb3aec5d16@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

2008/9/10 Amaury Forgeot d'Arc <report at bugs.python.org>:
> Code point 0x0370 is now a printable character.
> r66381 corrected the failures by simply changing it to 0x0378, until the
> next unicodedata upgrade...
> I wonder if there is a value that is guaranteed to stay non-printable.

The control characters?

Added file: http://bugs.python.org/file11461/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080911/0c377d18/attachment.txt>

From report at bugs.python.org  Thu Sep 11 03:09:44 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 11 Sep 2008 01:09:44 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <1220938674.27.0.672775002692.issue3811@psf.upfronthosting.co.za>
Message-ID: <1221095384.92.0.72235375297.issue3811@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file11461/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Thu Sep 11 03:13:59 2008
From: report at bugs.python.org (Steve Smith)
Date: Thu, 11 Sep 2008 01:13:59 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>


New submission from Steve Smith <tarkasteve at gmail.com>:

Both Connection and Pipe objects expose their underlying file
descriptors, which is useful for accessing them in an event-driven
manner.  However the higher-level Queue does not make the underlying
pipe available; to get at them you must access private member attributes
which is fragile.  It would be good to have a well-defined API for
accessing either the pipe objects or the underlying FDs.

----------
components: Extension Modules
messages: 73001
nosy: TarkaSteve
severity: normal
status: open
title: Multiprocessing: Expose underlying pipe in queues
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Thu Sep 11 04:00:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 02:00:06 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1221098406.26.0.474756371153.issue3831@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Thu Sep 11 04:30:14 2008
From: report at bugs.python.org (vajda)
Date: Thu, 11 Sep 2008 02:30:14 +0000
Subject: [issue3832] add force_shared Library option to create shared lib even
	with use_stub=False
In-Reply-To: <1221100214.51.0.623800325069.issue3832@psf.upfronthosting.co.za>
Message-ID: <1221100214.51.0.623800325069.issue3832@psf.upfronthosting.co.za>


New submission from vajda <vajda at osafoundation.org>:

setuptools is growing the capability to build regular shared libraries
(as opposed to python extensions). JCC
(http://svn.osafoundation.org/pylucene/trunk/jcc/jcc) uses this
capability to build the JCC runtime into a regular shared library shared
by all python extensions it builds and by programs embedding python
(such as a Java VM when running JCC-built eggs from Apache Tomcat).

This bug is about adding another option to the setuptools Library class
called force_shared which forces setuptools to create a shared library
from a Library instance even though the dl module may not be present to
generate stubs. This is important on Linux. Note that using this flag
then implies that the library itself is responsible for calling        
dlopen(buf, RTLD_NOW | RTLD_GLOBAL) on the relevant libpython.so before
initializing the python runtime is initialized.

A patch against the setuptools 0.6 branch svn is attached.
The idea for this patch came from a conversation on IRC:
http://chandlerproject.org/script/getIrcTranscript.cgi?channel=chandler&date=20080910&startTime=1729

----------
components: Distutils
files: patch.st
messages: 73002
nosy: pje, vajda
severity: normal
status: open
title: add force_shared Library option to create shared lib even with use_stub=False
type: feature request
Added file: http://bugs.python.org/file11462/patch.st

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3832>
_______________________________________

From report at bugs.python.org  Thu Sep 11 06:07:56 2008
From: report at bugs.python.org (Jimmy Retzlaff)
Date: Thu, 11 Sep 2008 04:07:56 +0000
Subject: [issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be
	installed on one machine
In-Reply-To: <1221106076.33.0.246620485581.issue3833@psf.upfronthosting.co.za>
Message-ID: <1221106076.33.0.246620485581.issue3833@psf.upfronthosting.co.za>


New submission from Jimmy Retzlaff <jimmy at retzlaff.com>:

I'm seeing the same symptoms that are described in issue 1543 with the
2.6b3 MSIs. Namely, when you run one of the MSIs (either 32-bit or
64-bit) then the other will refuse to install. This is on XP Pro x64 SP2.

python-3.0b3.msi and python-3.0b3.amd64.msi exhibit the same problem.

Having 32-bit and 64-bit version coexist makes it much easier to build
extensions for and test on both versions at the same time.

----------
components: Installation, Windows
messages: 73003
nosy: jretz
severity: normal
status: open
title: python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3833>
_______________________________________

From report at bugs.python.org  Thu Sep 11 07:46:21 2008
From: report at bugs.python.org (vajda)
Date: Thu, 11 Sep 2008 05:46:21 +0000
Subject: [issue3832] add force_shared Library option to create shared lib even
	with use_stub=False
In-Reply-To: <1221100214.51.0.623800325069.issue3832@psf.upfronthosting.co.za>
Message-ID: <1221111981.26.0.892839995684.issue3832@psf.upfronthosting.co.za>


vajda <vajda at osafoundation.org> added the comment:

This bug can be closed. It moved to the setuptools issue tracker as
issue 43.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3832>
_______________________________________

From report at bugs.python.org  Thu Sep 11 08:05:23 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 11 Sep 2008 06:05:23 +0000
Subject: [issue3811] Update Unicode database to 5.1.0
In-Reply-To: <ca471dc20809101808o78aef7b2l4be4c1bb3aec5d16@mail.gmail.com>
Message-ID: <48C8B520.30203@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The control characters?

Indeed, also the private-use characters. test_unicode explicitly
comments that the test is about unassigned characters, although
I don't understand the purpose of that test (it then also tests
a surrogate character, which is also guaranteed to remain
unprintable).

One of the characters that is guaranteed to remain unassigned is
U+FFFE (and its mirrors in other planes, e.g. U+1FFFE, ...).
This guarantee is made to support the BOM. Along with U+FFFF,
these are non-characters. #765036 once suggested that Python should
refuse to represent them at all, but that proposal was rejected.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3811>
_______________________________________

From report at bugs.python.org  Thu Sep 11 08:15:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 11 Sep 2008 06:15:38 +0000
Subject: [issue3832] add force_shared Library option to create shared lib even
	with use_stub=False
In-Reply-To: <1221100214.51.0.623800325069.issue3832@psf.upfronthosting.co.za>
Message-ID: <1221113738.11.0.304251092946.issue3832@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3832>
_______________________________________

From report at bugs.python.org  Thu Sep 11 08:24:30 2008
From: report at bugs.python.org (Heikki Toivonen)
Date: Thu, 11 Sep 2008 06:24:30 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1221114270.43.0.500989682044.issue1589@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

Ok, thank you for clarifications. Now I understand why the hostname
checking isn't the solution that fits every problem. I am still not
completely clear how you'd do the checking otherwise, for example to
verify the service you are talking to is what you think it is.

But still, I think dealing with email servers is another common use case
where hostname check is adequate most of the time. I am sure there are
other cases like this. Therefore I am still of the opinion that the
default should be to do the hostname check. Yes, make it overridable,
but doing the check is safer than not doing any checking IMO because
even if the check is incorrect for a certain purpose the developer is
likely to notice an error quickly and inclined to do some other security
check instead of not doing anything and thinking they have a secure system.

If you want to continue the discussion, we should maybe take this to
some other forum, like comp.lang.python.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Sep 11 08:58:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 11 Sep 2008 06:58:07 +0000
Subject: [issue3642] Objects/obmalloc.c:529: warning: comparison is always
	false due to limited range of data type
In-Reply-To: <1219366981.65.0.722546455294.issue3642@psf.upfronthosting.co.za>
Message-ID: <1221116287.73.0.484629814464.issue3642@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now committed the new patch as r66383 and r66384

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3642>
_______________________________________

From report at bugs.python.org  Thu Sep 11 08:59:53 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Sep 2008 06:59:53 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221116393.39.0.658904832224.issue3781@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +patch -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Thu Sep 11 09:19:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 11 Sep 2008 07:19:02 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221117542.65.0.73865672068.issue3640@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please apply. My only question is why the 3.0 patch
integrates the find_recursionlimit change, whereas the 2.6 patch does not.

----------
assignee: mhammond -> amaury.forgeotdarc
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Thu Sep 11 10:34:22 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 11 Sep 2008 08:34:22 +0000
Subject: [issue3830] Tarfile has incorrect USTAR "VERSION" field (should be 00;
	is 0 NUL)
In-Reply-To: <1221085968.85.0.567851806053.issue3830@psf.upfronthosting.co.za>
Message-ID: <1221122062.8.0.803375289774.issue3830@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

This problem existed only in the first 2.5 release.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3830>
_______________________________________

From report at bugs.python.org  Thu Sep 11 11:37:50 2008
From: report at bugs.python.org (Anthon van der Neut)
Date: Thu, 11 Sep 2008 09:37:50 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1221125870.51.0.025704182006.issue3531@psf.upfronthosting.co.za>


Anthon van der Neut <anthon at mnt.org> added the comment:

FWIW:
I have performance problems on Windows XP (SP2) with Python 2.5.1 that
could be caused by this behaviour.
My code regularily calculates the sha1 sum of 10.000 files and because
in another reuse of the code had to deal with files too big to fit in memory
I set a limit of 256Mb. It looks like that is now allocated and
deallocated for every one of the 10.000 files, making things *very* slow.

----------
nosy: +anthon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Thu Sep 11 11:53:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 11 Sep 2008 09:53:07 +0000
Subject: [issue3110] Multiprocessing package build problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1221126787.89.0.744550104201.issue3110@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

According to POSIX, if no determinate value for SEM_VALUE_MAX can be
given, the actual value should be queried with
sysconf(_SC_SEM_VALUE_MAX), and SEM_VALUE_MAX should not be defined;
this is in particular the case when the value depends on the system
configuration (such as available memory). _POSIX_SEM_VALUE_MAX specifies
the minimum value guaranteed by POSIX.

Now, it is not plausible why SEM_VALUE_MAX should vary by installation,
as it just depends on what integer type is used to represent the
counter. So more likely, Sun wrote its header files at a time when the
spec was not finished, so they didn't want to clutter the global namespace.

IOW, I think the patch is fine as it stands. If you are over-cautious,
you should test whether _SC_SEM_VALUE_MAX is defined, and use sysconf in
that case, and only fall back to _SEM_VALUE_MAX, then
_POSIX_SEM_VALUE_MAX, then fail, if sysconf isn't available.

If you do make this change, please stop using Py_BuildValue to convert a
C int to a Python int; use PyInt_FromLong instead.

----------
keywords:  -needs review
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3110>
_______________________________________

From report at bugs.python.org  Thu Sep 11 12:38:14 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 11 Sep 2008 10:38:14 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221129494.72.0.298685110284.issue3783@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

I like Skip's version better, because it's closer to the dbm
"specification" instead of trying to mimic bsddb (first, last, etc.).
I'd like to keep such things out.

I've made a few changes to the sandbox project which I will check in
later today. The most important change is support for a "fast mode",
which doesn't commit changes until you call the synch() method. synch()
is also called on close().

Perhaps we should do automatic commits every n (like 1000) changes, too?

What's all this ORDER BY in both your implementations about? The dbm
"spec" says nothing about keys being ordered AFAIC. Can we get rid of these?

----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 12:42:33 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 11 Sep 2008 10:42:33 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221129753.06.0.333599672757.issue3783@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

One question about Josiah's _check_value(). SQLite is less crippled than
other simplistic databases and also supports integers, reals and blobs
in addition to strings.

Shouldn't we make this accessible to users? Or is compatibility with
other dbm implementations more important?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 13:05:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Sep 2008 11:05:44 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221131144.9.0.0781169443671.issue3640@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- cpickle.patch and find_recursion_limit.patch are for 2.6
- cpickle.patch-3.0.patch groups the two previous patches, adapted to 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Thu Sep 11 14:10:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 11 Sep 2008 12:10:29 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221135029.69.0.052513333122.issue3640@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, ok. It's all fine, then.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Thu Sep 11 14:22:25 2008
From: report at bugs.python.org (Christopher Arndt)
Date: Thu, 11 Sep 2008 12:22:25 +0000
Subject: [issue3834] wsgiref.validator.InputWrapper readline method has wrong
	signature
In-Reply-To: <1221135745.13.0.140429283158.issue3834@psf.upfronthosting.co.za>
Message-ID: <1221135745.13.0.140429283158.issue3834@psf.upfronthosting.co.za>


New submission from Christopher Arndt <chris at chrisarndt.de>:

The readline method in the InputWrapper class in wsgiref.validate does
not  accept any arguments and therefore is not compatible with the
"file-like" interface, where the readline method accepts an optional
"size" argument. 

This breaks code that wraps file objects with their own wrapper class
and tries to call the readline method of the wrapped object with a
"size" argument.

Current code::

    def readline(self):
        v = self.input.readline()
        assert_(type(v) is type(""))
        return v


Should be::

    def readline(self, *args):
        v = self.input.readline(*args)
        assert_(type(v) is type(""))
        return v

----------
components: Library (Lib)
messages: 73016
nosy: strogon14
severity: normal
status: open
title: wsgiref.validator.InputWrapper readline method has wrong signature
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3834>
_______________________________________

From report at bugs.python.org  Thu Sep 11 14:28:28 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 11 Sep 2008 12:28:28 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221136108.96.0.0975079499702.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Applied to trunk for 2.6 in r66386.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Thu Sep 11 14:46:19 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 11 Sep 2008 12:46:19 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1221129494.72.0.298685110284.issue3783@psf.upfronthosting.co.za>
Message-ID: <18633.3120.233439.488260@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Gerhard> What's all this ORDER BY in both your implementations about?
    Gerhard> The dbm "spec" says nothing about keys being ordered AFAIC. Can
    Gerhard> we get rid of these?

I'd like to guarantee that zip(db.keys(), db.values() == db.items().

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:02:54 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 11 Sep 2008 13:02:54 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1221138174.92.0.348556112395.issue3831@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Steve, I'm a little nervous about exposing the underlying Queue pipes in 
an official API simply due to the fact that it is an advanced use case, 
and we do want to keep the API simple, and relatively close to the core 
Queue implementation.

Do you have an example use-case/code? This will not be making it into 
python 2.6/3.0 - it will need to wait until 2.7 and 3.1 at very least.

----------
nosy: +roudkerk
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:10:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 13:10:43 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <18633.3120.233439.488260@montanaro-dyndns-org.local>
Message-ID: <1221138620.5667.1.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 11 septembre 2008 ? 12:46 +0000, Skip Montanaro a ?crit :
> Gerhard> What's all this ORDER BY in both your implementations about?
>     Gerhard> The dbm "spec" says nothing about keys being ordered AFAIC. Can
>     Gerhard> we get rid of these?
> 
> I'd like to guarantee that zip(db.keys(), db.values() == db.items().

It doesn't sound very useful, and it may hurt performance on big tables.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:21:12 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 11 Sep 2008 13:21:12 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>


New submission from Helmut Jarausch <jarausch at skynet.be>:

With version 3.0 (SVN 66386)

import pydoc
pydoc.gui()

gives

>>> Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/threading.py", line 507, in 
_bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.0/threading.py", line 462, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/pydoc.py", line 1989, in serve
    DocServer(port, callback).serve_until_quit()
  File "/usr/local/lib/python3.0/pydoc.py", line 1971, in __init__
    self.base.__init__(self, self.address, self.handler)
  File "/usr/local/lib/python3.0/socketserver.py", line 401, in __init__
    self.server_activate()
  File "/usr/local/lib/python3.0/pydoc.py", line 1982, in 
server_activate
    if self.callback: self.callback(self)
  File "/usr/local/lib/python3.0/pydoc.py", line 2072, in ready
    text='Python documentation server at\n' + server.url)
  File "/usr/local/lib/python3.0/tkinter/__init__.py", line 1199, in 
configure
    return self._configure('configure', cnf, kw)
  File "/usr/local/lib/python3.0/tkinter/__init__.py", line 1190, in 
_configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: out of stack space (infinite loop?)

----------
components: Extension Modules
messages: 73021
nosy: HWJ
severity: normal
status: open
title: tkinter goes into an infinite loop (pydoc.gui)
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:24:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 13:24:48 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1221139488.88.0.348990528786.issue3531@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My code regularily calculates the sha1 sum of 10.000 files and because
> in another reuse of the code had to deal with files too big to fit in
> memory I set a limit of 256Mb.

Why don't you use a sensible buffer size, e.g. 1MB? Reading data in
256MB chunks sounds foolish in any case.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:29:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 13:29:23 +0000
Subject: [issue3531] file read preallocs 'size' bytes which can cause memory
	problems
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1221139763.65.0.58740302429.issue3531@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Andrew, as for memory reallocation issues, you may take a look at #3526
where someone has similar problems on SunOS.

If nobody objects, I will close the present bug as invalid.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:37:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 13:37:28 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1221131144.9.0.0781169443671.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221140201.5667.5.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, this isn't caused by the present issue, but you'll notice
that in the latest trunk, some tests in find_recursion_limit.py fail
with an AttributeError instead of RuntimeError. This is likely caused by
a PyDict_GetItem() call discarding the RuntimeError somewhere and
returning NULL, which in turn raises an AttributeError (as I explained
on the mailing-list).

A quick way to fix it would be to use "except (AttributeError,
RuntimeError)" in the testing func of find_recursion_limit.py.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:42:00 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 11 Sep 2008 13:42:00 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221140520.5.0.828837548992.issue3783@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

> I'd like to guarantee that zip(db.keys(), db.values() == db.items().

Ok. If that isn't guaranteed elsewhere just drop it here?

FWIW that will also work without the ORDER BY, because you're getting
the rows back in the same ORDER. Something cheaper would also be "ORDER
BY ROWID". I still propose to just do without the ORDER BY.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:48:04 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 11 Sep 2008 13:48:04 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1221138620.5667.1.camel@fsol>
Message-ID: <18633.8505.897080.992468@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

>> I'd like to guarantee that zip(db.keys(), db.values() == db.items().

    Antoine> It doesn't sound very useful, and it may hurt performance on
    Antoine> big tables.

Actually, I think Python guarantees (for dicts at least - other mappings
should probably follow suit) that if you call keys() then call values()
without making any changes to the dict that their orders match, e.g., that

    zip(d.keys(), d.values()) == d.items()

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:50:38 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 11 Sep 2008 13:50:38 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1221140520.5.0.828837548992.issue3783@psf.upfronthosting.co.za>
Message-ID: <18633.8660.225082.527839@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Gerhard> FWIW that will also work without the ORDER BY, because you're
    Gerhard> getting the rows back in the same ORDER. Something cheaper
    Gerhard> would also be "ORDER BY ROWID". I still propose to just do
    Gerhard> without the ORDER BY.

As long as SQLite guarantees that the ordering is identical, then sure, dump
the ORDER BY clause.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 15:53:19 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 11 Sep 2008 13:53:19 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <18633.8660.225082.527839@montanaro-dyndns-org.local>
Message-ID: <48C922B1.8030306@ghaering.de>


Gerhard H?ring <gh at ghaering.de> added the comment:

Skip Montanaro wrote:
> Skip Montanaro <skip at pobox.com> added the comment:
> 
> Gerhard> FWIW that will also work without the ORDER BY, because you're
>     Gerhard> getting the rows back in the same ORDER. Something cheaper
>     Gerhard> would also be "ORDER BY ROWID". I still propose to just do
>     Gerhard> without the ORDER BY.
> 
> As long as SQLite guarantees that the ordering is identical, then sure, dump
> the ORDER BY clause.

It doesn't guarantee it, but the implementation behaves like this.

-- Gerhard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 16:03:56 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 11 Sep 2008 14:03:56 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221141836.06.0.316155980373.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Blocked merge in the py3k branch since it requires some fiddling to
handle the change from test.test_support to test.support. I'll post a
new patch here for the py3k forward port when I can (I may not make it
before 3.0b4 though, so unassigning for the moment).

----------
assignee: ncoghlan -> 
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Thu Sep 11 16:07:28 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 14:07:28 +0000
Subject: =?utf-8?q?[issue3531]_file_read_preallocs_'size'_bytes_which_can_cause_memory=09problems?=
In-Reply-To: <48C924A4.10005@mnt.org>
Message-ID: <1221142028.5667.9.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 11 septembre 2008 ? 16:01 +0200, Anthon van der Neut a ?crit :
> The thing however was resolved by reading multiple smaller chunks indeed
> 1Mb if the filesize exceeds 1Mb (in the latter case the original read()
> is done.

It's too complicated. Just use chunks in all cases (even small files)
and you are done. There should be no visible performance downside to
doing so.

Using fixed-size chunks to read binary data from a file of an unknown
size isn't a Python-specific idiom, really. It's the same in C, C++,
PHP, etc.

----------
title: file read preallocs 'size' bytes which can cause memory problems -> file read preallocs 'size' bytes which can cause memory	problems

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Thu Sep 11 16:09:22 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 11 Sep 2008 14:09:22 +0000
Subject: [issue3103] sqlite defines a few global symbols.
In-Reply-To: <1213344046.17.0.166963020016.issue3103@psf.upfronthosting.co.za>
Message-ID: <1221142162.09.0.580618624956.issue3103@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

I've fixed that in the externally maintained pysqlite. I suppose it's
too late to bring this into 2.6 or 3.0, right?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3103>
_______________________________________

From report at bugs.python.org  Thu Sep 11 16:18:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 14:18:48 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <18633.8505.897080.992468@montanaro-dyndns-org.local>
Message-ID: <1221142609.5667.19.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 11 septembre 2008 ? 13:48 +0000, Skip Montanaro a ?crit :
> Actually, I think Python guarantees (for dicts at least - other mappings
> should probably follow suit) that if you call keys() then call values()
> without making any changes to the dict that their orders match, e.g., that
> 
>     zip(d.keys(), d.values()) == d.items()

Perhaps. I've never written any code that relies this, though, and it
doesn't sound like an useful guarantee since you can just use the
items() method anyway. It probably dates back to an era when list
comprehensions didn't exist, and extracting keys or values from the
items list required several lines of code and costly method calls.

Also, the point is that Python dicts can make that guarantee without
being any slower. It may not be the same for an RDBMS backend. Why?
Because, depending on the backend, index and data can be stored in
separate areas with different storage layouts (e.g. keys are in a B tree
while values are just dumped sequentially). If you only ask for
unordered keys, they will be read in optimal (sequential) index order,
and if you only ask for unordered values, they will be read in optimal
(sequential) data order, which is not the same. This is true for e.g.
MySQL.

(also, IMO this discussion proves that the module shouldn't be included
in Python 3.0. It's too young, its API hasn't even settled down)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 16:20:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 14:20:46 +0000
Subject: [issue3103] sqlite defines a few global symbols.
In-Reply-To: <1213344046.17.0.166963020016.issue3103@psf.upfronthosting.co.za>
Message-ID: <1221142846.58.0.139946510947.issue3103@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If they aren't part of a public API I think it's ok to fix them in
2.6/3.0. It is a bug fix, not a feature change.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3103>
_______________________________________

From report at bugs.python.org  Thu Sep 11 16:33:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 14:33:59 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221143639.74.0.242553592748.issue3783@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I might add that calling keys() then values() is suboptimal, because it
will issue two SQL queries while calling items() will issue just one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 17:14:56 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 11 Sep 2008 15:14:56 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1221146096.35.0.38167883203.issue3766@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/issue3766>
_______________________________________

From report at bugs.python.org  Thu Sep 11 18:03:16 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 16:03:16 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1221148996.4.0.214286279668.issue3766@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thorben, is the problem still there if you use fork() rather than
launching a separate thread for the server?

The implementation of the recv() method is straightforward and I don't
see anything that could cause a huge latency there, it's just a simple
wrapper over the C library's recv() function. The waiting certainly
occurs inside the OS rather than inside the Python interpreter.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Thu Sep 11 18:04:47 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 11 Sep 2008 16:04:47 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1221114270.43.0.500989682044.issue1589@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0809110903y56c9bf58xc5551427a1192413@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I think that, where it's appropriate, you can do that.  Just don't put it in
the SSL module.

Bill

On Wed, Sep 10, 2008 at 11:24 PM, Heikki Toivonen <report at bugs.python.org>wrote:

>
> Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:
>
> Ok, thank you for clarifications. Now I understand why the hostname
> checking isn't the solution that fits every problem. I am still not
> completely clear how you'd do the checking otherwise, for example to
> verify the service you are talking to is what you think it is.
>
> But still, I think dealing with email servers is another common use case
> where hostname check is adequate most of the time. I am sure there are
> other cases like this. Therefore I am still of the opinion that the
> default should be to do the hostname check. Yes, make it overridable,
> but doing the check is safer than not doing any checking IMO because
> even if the check is incorrect for a certain purpose the developer is
> likely to notice an error quickly and inclined to do some other security
> check instead of not doing anything and thinking they have a secure system.
>
> If you want to continue the discussion, we should maybe take this to
> some other forum, like comp.lang.python.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1589>
> _______________________________________
>

Added file: http://bugs.python.org/file11463/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080911/47f791db/attachment.txt>

From report at bugs.python.org  Thu Sep 11 18:12:07 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 11 Sep 2008 16:12:07 +0000
Subject: [issue3836] 2to3 broken due to mixed 2.5 and 3.0 syntax
In-Reply-To: <1221149527.76.0.741904769923.issue3836@psf.upfronthosting.co.za>
Message-ID: <1221149527.76.0.741904769923.issue3836@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

In the py3k SVN head(r66389) of lib2to3, the main.py used Python 2.x's
print syntax, and the refactor.py used Python 3.0's exception syntax. So
the 2to3 finally broken on both Python 2.5 and 3.0.

Well, it able to run with Python 2.6, but also have a lot of errors like
this:

Traceback (most recent call last):
  File "/usr/bin/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/home/kid/python-site/lib2to3/main.py", line 71, in main
    rt = refactor.RefactoringTool(fixer_names, rt_opts, explicit=explicit)
  File "/home/kid/python-site/lib2to3/refactor.py", line 119, in __init__
    self.pre_order, self.post_order = self.get_fixers()
  File "/home/kid/python-site/lib2to3/refactor.py", line 138, in get_fixers
    mod = __import__(fix_mod_path, {}, {}, ["*"])
  File "/home/kid/python-site/lib2to3/fixes/fix_dict.py", line 38, in
<module>
    class FixDict(fixer_base.BaseFix):
  File "/home/kid/python-site/lib2to3/fixes/fix_dict.py", line 76, in
FixDict
    p1 = patcomp.compile_pattern(P1)
  File "/home/kid/python-site/lib2to3/patcomp.py", line 186, in
compile_pattern
    return PatternCompiler().compile_pattern(pattern)
  File "/home/kid/python-site/lib2to3/patcomp.py", line 57, in
compile_pattern
    root = self.driver.parse_tokens(tokens, debug=debug)
  File "/home/kid/python-site/lib2to3/pgen2/driver.py", line 45, in
parse_tokens
    for quintuple in tokens:
  File "/home/kid/python-site/lib2to3/patcomp.py", line 34, in
tokenize_wrapper
    tokens = tokenize.generate_tokens(driver.generate_lines(input).__next__)
AttributeError: 'generator' object has no attribute '__next__'

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 73037
nosy: bhy, collinwinter
severity: normal
status: open
title: 2to3 broken due to mixed 2.5 and 3.0 syntax
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3836>
_______________________________________

From report at bugs.python.org  Thu Sep 11 18:13:42 2008
From: report at bugs.python.org (Thorben)
Date: Thu, 11 Sep 2008 16:13:42 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <17573_1221149000_m8BG3Hwu019782_1221148996.4.0.214286279668.issue3766@psf.upfronthosting.co.za>
Message-ID: <3b5d765a0809110913k46e97dcfh5d68f0d4b03ea0e1@mail.gmail.com>


Thorben <thkruege at uos.de> added the comment:

The problem exists even if the server part is replaced by a server
written in C. I only wrote up the dummy server in python to be able to
provide a testcase.

The C server works with reasonable speed when connected to a client
written in perl by the way. My employer is quite disappointed with
Python's performance... (He provided the profiler data for the Mac by
the way) I almost wish that I did something wrong, but this does not
seem to be the case.

Nevertheless, I will try out your suggestion.

Thanks for replying,

Thorben

2008/9/11 Antoine Pitrou <report at bugs.python.org>:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Thorben, is the problem still there if you use fork() rather than
> launching a separate thread for the server?
>
> The implementation of the recv() method is straightforward and I don't
> see anything that could cause a huge latency there, it's just a simple
> wrapper over the C library's recv() function. The waiting certainly
> occurs inside the OS rather than inside the Python interpreter.
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3766>
> _______________________________________
>

----------
nosy: +Thorben

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Thu Sep 11 18:25:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 16:25:32 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1221150332.52.0.767637122156.issue3766@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can use setsockopt() to set the TCP_NODELAY flag and see if that
improves things; sending thousands of 4-bytes packets isn't exactly the
expected utilization of TCP.

As I said, socket.recv() is just a thin wrapper above the same-named C
library function. Your code expects the kernel's TCP stack to send
things as soon as you ask it to, but TCP is a high-level stream protocol
and implementations usually have sophisticated algorithms in order to
minimize the number of individual packets sent over the wire.

By the way, if you want to build network applications (clients and
servers), I suggest you take a look at the Twisted framework. It will
free you from many low-level issues, although it won't prevent you from
shooting yourself in the foot :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Thu Sep 11 18:28:55 2008
From: report at bugs.python.org (Janet Swisher)
Date: Thu, 11 Sep 2008 16:28:55 +0000
Subject: [issue3837] Comment for html_logo setting is out of date
In-Reply-To: <1221150535.52.0.0971276007323.issue3837@psf.upfronthosting.co.za>
Message-ID: <1221150535.52.0.0971276007323.issue3837@psf.upfronthosting.co.za>


New submission from Janet Swisher <swisher at enthought.com>:

In Sphinx 0.4.2, the handling of the html_logo setting was changed to
use a relative path, like latex_logo, rather than the static path.
However, the comment for html_logo in the quickstart template was not
changed. This caused me confusion because Sphinx did not copy my logo
file from the static path.

Current::

  # The name of an image file (within the static path) to place at the
top of
  # the sidebar.
  #html_logo = None

Revised::

  # The name of an image file (relative to this directory) to place at
the top of
  # the sidebar.
  #html_logo = None

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 73041
nosy: georg.brandl, jmswisher
severity: normal
status: open
title: Comment for html_logo setting is out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3837>
_______________________________________

From report at bugs.python.org  Thu Sep 11 18:32:51 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 11 Sep 2008 16:32:51 +0000
Subject: [issue3836] 2to3 broken due to mixed 2.5 and 3.0 syntax
In-Reply-To: <1221149527.76.0.741904769923.issue3836@psf.upfronthosting.co.za>
Message-ID: <1221150771.96.0.102729881028.issue3836@psf.upfronthosting.co.za>


Haoyu Bai <divinekid at gmail.com> added the comment:

A patch on main.py to fix this.

----------
keywords: +patch
Added file: http://bugs.python.org/file11464/fix_syntax.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3836>
_______________________________________

From report at bugs.python.org  Thu Sep 11 19:50:53 2008
From: report at bugs.python.org (Thorben)
Date: Thu, 11 Sep 2008 17:50:53 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <20449_1221150334_m8BGPXWL020865_1221150332.52.0.767637122156.issue3766@psf.upfronthosting.co.za>
Message-ID: <3b5d765a0809111050y1432ce41gd87cd8cc58f0db7f@mail.gmail.com>


Thorben <thkruege at uos.de> added the comment:

2008/9/11 Antoine Pitrou <report at bugs.python.org>:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> You can use setsockopt() to set the TCP_NODELAY flag and see if that
> improves things; sending thousands of 4-bytes packets isn't exactly the
> expected utilization of TCP.

You are obviously right, but IIRC, I mentioned that this is simply a
dummy testcase...

now thats interesting:
adding the line "sock.setsockopt(SOL_TCP, TCP_NODELAY, 1) " decreased
the delay by half. It still is extremely high but it's a start.

Do you think I could get that value down much further? I don't know
much about TCP...

> As I said, socket.recv() is just a thin wrapper above the same-named C
> library function. Your code expects the kernel's TCP stack to send
> things as soon as you ask it to, but TCP is a high-level stream protocol
> and implementations usually have sophisticated algorithms in order to
> minimize the number of individual packets sent over the wire.

Would be interesting to examine the differences between the Perl
wrapper and the Python wrapper to figure out why Perl "does the right
thing" in this case and Python doesn't.

> By the way, if you want to build network applications (clients and
> servers), I suggest you take a look at the Twisted framework. It will
> free you from many low-level issues, although it won't prevent you from
> shooting yourself in the foot :-)

Thanks, I'll make sure to try it out.

> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3766>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Thu Sep 11 19:59:52 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 11 Sep 2008 17:59:52 +0000
Subject: [issue3838] test_tarfile error on cygwin (Directory not empty)
In-Reply-To: <1221155992.48.0.592399874075.issue3838@psf.upfronthosting.co.za>
Message-ID: <1221155992.48.0.592399874075.issue3838@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

This differs from issue3824. test_tarfile claims following error at the
end of test.

Traceback (most recent call last):
  File "test_tarfile.py", line 1210, in <module>
    test_main()
  File "test_tarfile.py", line 1207, in test_main
    shutil.rmtree(TEMPDIR)
  File "/home/WhiteRabbit/python-dev/trunk/Lib/shutil.py", line 225, in
rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/home/WhiteRabbit/python-dev/trunk/Lib/shutil.py", line 223, in
rmtree
    os.rmdir(path)
OSError: [Errno 90] Directory not empty:
'/cygdrive/c/DOCUME~1/WHITER~1/LOCALS~1
/Temp/test_tarfile_tmp'

I've attached patch.

----------
files: test_tarfile.patch
keywords: easy, patch
messages: 73044
nosy: ocean-city
severity: normal
status: open
title: test_tarfile error on cygwin (Directory not empty)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11465/test_tarfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3838>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:08:34 2008
From: report at bugs.python.org (Clovis Fabricio)
Date: Thu, 11 Sep 2008 18:08:34 +0000
Subject: [issue3839] wsgi.simple_server resets 'Content-Length' header on
	empty content even if app defined it.
In-Reply-To: <1221156514.39.0.145827705782.issue3839@psf.upfronthosting.co.za>
Message-ID: <1221156514.39.0.145827705782.issue3839@psf.upfronthosting.co.za>


New submission from Clovis Fabricio <nosklo+python at gmail.com>:

The finish_content method in wsgiref.handlers.BaseHandler class resets
Content-Length to "0" if there was no content returned by the
application, even if the application has set it already.

That makes impossible to implement things like HEAD requests in the
application, which should return the Content-Length without returning
actual content.

The desired behavior would be to respect the header set by the wsgi
application, using "0" as a default value instead.

----------
components: Library (Lib)
files: wsgiref.handlers.py.patch
keywords: patch
messages: 73045
nosy: nosklo
severity: normal
status: open
title: wsgi.simple_server resets 'Content-Length' header on empty content even if app defined it.
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11466/wsgiref.handlers.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3839>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:26:45 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 11 Sep 2008 18:26:45 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221157605.43.0.863187200707.issue3783@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

> I like Skip's version better, because it's closer to the dbm
> "specification" instead of trying to mimic bsddb (first, last, etc.).
> I'd like to keep such things out.

dbm.sqlite is meant as a potential replacement of dbm.bsddb.  Since 
people do use the extra methods (.first(), .last(), etc.), not having 
them could lead to breakage.

Separating them out into a subclass (regular open doesn't have it, but 
btopen does), along with all of the other order guarantees (the ORDER BY 
clauses in the SQL statements), could keep it fast for people who don't 
care about ordering, and keep it consistent for those who do care about 
ordering.

Attached you will find an updated version.

Added file: http://bugs.python.org/file11467/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:27:24 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 11 Sep 2008 18:27:24 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221157644.71.0.472316603615.issue3783@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file11412/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:27:36 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 11 Sep 2008 18:27:36 +0000
Subject: [issue3840] test_urllib fails on cygwin
In-Reply-To: <1221157656.48.0.996285676684.issue3840@psf.upfronthosting.co.za>
Message-ID: <1221157656.48.0.996285676684.issue3840@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

test_urllib's test_geturl fails with following messege.

test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "/home/WhiteRabbit/python-dev/trunk/Lib/test/test_urllib.py",
line 84, in
 test_geturl
    self.assertEqual(self.returned_obj.geturl(), self.pathname)
AssertionError: 'file:///tmp/@test' != '/tmp/@test'

test_support.TESTFN is /tmp/@test on cygwin, and Lib/urllib.py(484,485)
specially cares about leading slash. 

            if file[:1] == '/':
                urlfile = 'file://' + file

If this is geturl()'s design, probably test should be changed like
attached patch.

----------
components: Tests
files: test_urllib.patch
keywords: patch
messages: 73047
nosy: ocean-city
severity: normal
status: open
title: test_urllib fails on cygwin
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11468/test_urllib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3840>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:32:56 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 18:32:56 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <3b5d765a0809111050y1432ce41gd87cd8cc58f0db7f@mail.gmail.com>
Message-ID: <1221157940.31770.9.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> now thats interesting:
> adding the line "sock.setsockopt(SOL_TCP, TCP_NODELAY, 1) " decreased
> the delay by half. It still is extremely high but it's a start.

Did you do it on both the client and server sockets?

> Would be interesting to examine the differences between the Perl
> wrapper and the Python wrapper to figure out why Perl "does the right
> thing" in this case and Python doesn't.

Perhaps the Perl wrapper is less thin as the Python one. In any case,
it's by design if the Python socket wrapper doesn't try to be "smart":
the intent is to provide an access to the C API and let people do what
they want with it. Smart things are relegated to higher-level modules or
libraries.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:41:35 2008
From: report at bugs.python.org (Stephen McInerney)
Date: Thu, 11 Sep 2008 18:41:35 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>


New submission from Stephen McInerney <spmcinerney at hotmail.com>:

IDLE exhibits quirky behavior when displaying strings longer than 4093 
characters

Python versions: believed to be all. I found this on Python 2.5 / IDLE 
1.2.2
OS: Windows Vista; let me know if it repros on others.

Testcase attached has a length-4094 string.
IDLE will not display this unless your cursor is inside the string.
If you delete characters so length <= 4093, IDLE displays it ok again.

----------
components: IDLE
messages: 73049
nosy: spmcinerney
severity: normal
status: open
title: IDLE: quirky behavior when displaying strings longer than 4093 characters
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:53:56 2008
From: report at bugs.python.org (Thorben)
Date: Thu, 11 Sep 2008 18:53:56 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <28963_1221157977_m8BIWuvS029897_1221157940.31770.9.camel@fsol>
Message-ID: <3b5d765a0809111152n243e2a14oa87b590c0c54abcf@mail.gmail.com>


Thorben <thkruege at uos.de> added the comment:

2008/9/11 Antoine Pitrou <report at bugs.python.org>:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> now thats interesting:
>> adding the line "sock.setsockopt(SOL_TCP, TCP_NODELAY, 1) " decreased
>> the delay by half. It still is extremely high but it's a start.
>
> Did you do it on both the client and server sockets?

Yes, obviously. Although adding it to the client socket did make no
difference after I had already done so for the server. Still
communication is too slow by orders of magnitude. (Sorry for pointing
this out again)

>> Would be interesting to examine the differences between the Perl
>> wrapper and the Python wrapper to figure out why Perl "does the right
>> thing" in this case and Python doesn't.
>
> Perhaps the Perl wrapper is less thin as the Python one. In any case,
> it's by design if the Python socket wrapper doesn't try to be "smart":
> the intent is to provide an access to the C API and let people do what
> they want with it. Smart things are relegated to higher-level modules or
> libraries.

I would greatly appreciate any help on the subject. How do *BSD
sockets differ from Linux sockets and what do I do to make things
faster. I think this might be where the real issue is. Low level
networking voodoo. Do you think twisted might help me there?

> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3766>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Thu Sep 11 20:59:22 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 11 Sep 2008 18:59:22 +0000
Subject: [issue3840] test_urllib fails on cygwin
In-Reply-To: <1221157656.48.0.996285676684.issue3840@psf.upfronthosting.co.za>
Message-ID: <1221159562.81.0.610389926306.issue3840@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I cannot create patch now, but test_site error comes from same reason.
>test_support.TESTFN is /tmp/@test on cygwin

After I applied following adhok patch, test passed.

Index: Lib/test/test_site.py
===================================================================
--- Lib/test/test_site.py       (revision 66385)
+++ Lib/test/test_site.py       (working copy)
@@ -126,7 +126,7 @@
 class PthFile(object):
     """Helper class for handling testing of .pth files"""

-    def __init__(self, filename_base=TESTFN, imported="time",
+    def __init__(self, filename_base="@test", imported="time",
                     good_dirname="__testdir__", bad_dirname="__bad"):
         """Initialize instance variables"""
         self.filename = filename_base + ".pth"

site.py's addpackage() is doing

    fullname = os.path.join(sitedir, name)

and on my cygwin, this equals to

    os.path.join(
        "/home/WhiteRabbit/python-dev/trunk/lib/test",
        "/tmp/@test.pth") #=> "/tmp/@test.pth"

probably this is not good. (I cannot figure out what site.py is doing
though)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3840>
_______________________________________

From report at bugs.python.org  Thu Sep 11 21:04:14 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Thu, 11 Sep 2008 19:04:14 +0000
Subject: [issue3842] can't run close through itertools.chain on inner generator
In-Reply-To: <1221159854.86.0.0250666743089.issue3842@psf.upfronthosting.co.za>
Message-ID: <1221159854.86.0.0250666743089.issue3842@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

There is no way to get generators to clean up (run their 'finally'
clause) when used as an inner iterable to chain:

>>> def gen(n):
...     try:
...         # do stuff yielding values
...     finally:
...         # clean up
>>> c = chain.from_iterable(map(gen, (1,2,3)))
>>> next(c)
0
>>> # done with c, but can't clean up inner gen!

Could you add a 'close' method to itertools.chain that would call close
(if present) on both the inner and other iterable?  Then clean up could
be done as:

>>> with closing(chain.from_iterable(map(gen, (1,2,3)))) as c:
...    next(c)
>>> # generator finalized by "with closing"!

----------
components: Extension Modules
messages: 73052
nosy: dangyogi
severity: normal
status: open
title: can't run close through itertools.chain on inner generator
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3842>
_______________________________________

From report at bugs.python.org  Thu Sep 11 22:01:37 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 11 Sep 2008 20:01:37 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <48C922B1.8030306@ghaering.de>
Message-ID: <18633.30190.521021.410203@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

>> As long as SQLite guarantees that the ordering is identical, then
    >> sure, dump the ORDER BY clause.

    Gerhard> It doesn't guarantee it, but the implementation behaves like
    Gerhard> this.

If the behavior isn't guaranteed, I think you need to retain ORDER BY.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 22:14:04 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 11 Sep 2008 20:14:04 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1221143639.74.0.242553592748.issue3783@psf.upfronthosting.co.za>
Message-ID: <18633.31665.640911.365762@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> I might add that calling keys() then values() is suboptimal,
    Antoine> because it will issue two SQL queries while calling items()
    Antoine> will issue just one.

Well, sure, but heaven only knows what an application programmer will do...

S

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 11 22:58:28 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 11 Sep 2008 20:58:28 +0000
Subject: [issue3840] if TESTFN == "/tmp/@test", some tests fail
In-Reply-To: <1221157656.48.0.996285676684.issue3840@psf.upfronthosting.co.za>
Message-ID: <1221166708.92.0.241674233073.issue3840@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Same happend in test_import.py too.

>test_support.TESTFN is /tmp/@test on cygwin
This was false information. There was a directry named @test, so
open(TESTFN, "w+") in test_support.py failed, "/tmp/@test" was used instead.

Several tests seem to assume TESTFN is relative path (filename?), so
maybe should we use @test2 as TESTFN if @test is not writable and vise
versa? (Or simply test fails if @test is not writable)

----------
title: test_urllib fails on cygwin -> if TESTFN == "/tmp/@test", some tests fail
versions:  -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3840>
_______________________________________

From report at bugs.python.org  Thu Sep 11 23:01:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 21:01:31 +0000
Subject: [issue3836] 2to3 broken due to mixed 2.5 and 3.0 syntax
In-Reply-To: <1221149527.76.0.741904769923.issue3836@psf.upfronthosting.co.za>
Message-ID: <1221166891.06.0.297965105471.issue3836@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

main.py is really not a public interface, but it should be fixed.

----------
assignee: collinwinter -> benjamin.peterson
nosy: +benjamin.peterson
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3836>
_______________________________________

From report at bugs.python.org  Thu Sep 11 23:05:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 21:05:18 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1221141836.06.0.316155980373.issue3781@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809111402v6d05c5d9la272ffb93bae60c9@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Thu, Sep 11, 2008 at 9:03 AM, Nick Coghlan <report at bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Blocked merge in the py3k branch since it requires some fiddling to
> handle the change from test.test_support to test.support. I'll post a
> new patch here for the py3k forward port when I can (I may not make it
> before 3.0b4 though, so unassigning for the moment).

The best way to do that is:

(trunk) $ svn diff -c mergerevision Lib/test/test_support.py > diff.patch
(py3k) $ patch Lib/test/support.py < diff.patch

>
> ----------
> assignee: ncoghlan ->
> versions:  -Python 2.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3781>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Thu Sep 11 23:06:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Sep 2008 21:06:16 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221167176.56.0.21602368121.issue3640@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed as r66390 and r66391.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Thu Sep 11 23:06:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 21:06:28 +0000
Subject: [issue3836] 2to3 broken due to mixed 2.5 and 3.0 syntax
In-Reply-To: <1221149527.76.0.741904769923.issue3836@psf.upfronthosting.co.za>
Message-ID: <1221167188.78.0.938675318747.issue3836@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66392.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3836>
_______________________________________

From report at bugs.python.org  Thu Sep 11 23:09:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 21:09:31 +0000
Subject: [issue3842] can't run close through itertools.chain on inner generator
In-Reply-To: <1221159854.86.0.0250666743089.issue3842@psf.upfronthosting.co.za>
Message-ID: <1221167371.47.0.578311775234.issue3842@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3842>
_______________________________________

From report at bugs.python.org  Thu Sep 11 23:25:10 2008
From: report at bugs.python.org (maix)
Date: Thu, 11 Sep 2008 21:25:10 +0000
Subject: [issue3843] hexadecimal, not decimal
In-Reply-To: <1221168310.48.0.733026524014.issue3843@psf.upfronthosting.co.za>
Message-ID: <1221168310.48.0.733026524014.issue3843@psf.upfronthosting.co.za>


New submission from maix <mailmaix at gmail.com>:

On http://docs.python.org/dev/library/string.html, at the format string
documentation, it says:

> The '#' option is only valid for integers, and only for binary, octal,
or *decimal* output. If present, it specifies that the output will be
prefixed by '0b', '0o', or '0x', respectively.

The decimal is wrong, hexadecimal is meant there.

----------
assignee: georg.brandl
components: Documentation
messages: 73060
nosy: georg.brandl, maix
severity: normal
status: open
title: hexadecimal, not decimal
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3843>
_______________________________________

From report at bugs.python.org  Thu Sep 11 23:58:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 21:58:53 +0000
Subject: [issue3834] wsgiref.validator.InputWrapper readline method has wrong
	signature
In-Reply-To: <1221135745.13.0.140429283158.issue3834@psf.upfronthosting.co.za>
Message-ID: <1221170333.32.0.936830132632.issue3834@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> pje
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3834>
_______________________________________

From report at bugs.python.org  Fri Sep 12 00:02:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 22:02:58 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221170578.52.0.0330552233108.issue3657@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I can reproduce this on 2.6.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Fri Sep 12 00:04:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 22:04:30 +0000
Subject: [issue3843] hexadecimal, not decimal
In-Reply-To: <1221168310.48.0.733026524014.issue3843@psf.upfronthosting.co.za>
Message-ID: <1221170670.86.0.609375974957.issue3843@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks! Fixed in r66394.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3843>
_______________________________________

From report at bugs.python.org  Fri Sep 12 00:07:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Sep 2008 22:07:58 +0000
Subject: [issue586680] -S hides standard dynamic modules
Message-ID: <1221170878.27.0.504339236012.issue586680@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Note that this does cause incompatibility between development copies and
installed copies:

$ python -S -c "import itertools; print itertools"
<module 'itertools' from ...>

$ ./python -S -c "import itertools; print itertools"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named itertools

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue586680>
_______________________________________

From report at bugs.python.org  Fri Sep 12 00:14:49 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Thu, 11 Sep 2008 22:14:49 +0000
Subject: [issue3834] wsgiref.validator.InputWrapper readline method has wrong
	signature
In-Reply-To: <1221135745.13.0.140429283158.issue3834@psf.upfronthosting.co.za>
Message-ID: <1221171289.5.0.353230124383.issue3834@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Per PEP 333:

"""The optional "size" argument to readline() is not supported, as it
may be complex for server authors to implement, and is not often used in
practice."""

The whole point of this code is to catch broken programs that pass an
argument to readline() -- they are not WSGI-compliant.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3834>
_______________________________________

From report at bugs.python.org  Fri Sep 12 00:20:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Sep 2008 22:20:28 +0000
Subject: [issue3837] Comment for html_logo setting is out of date
In-Reply-To: <1221150535.52.0.0971276007323.issue3837@psf.upfronthosting.co.za>
Message-ID: <1221171628.8.0.995863081336.issue3837@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66397.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3837>
_______________________________________

From report at bugs.python.org  Fri Sep 12 00:59:33 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Thu, 11 Sep 2008 22:59:33 +0000
Subject: =?utf-8?q?[issue3531]_file_read_preallocs_'size'_bytes_which_can_cause_memory=09problems?=
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1221173973.2.0.662537288794.issue3531@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

I'm still undecided on if this is a bug or not.  The problem occurs even 
when I'm not reading "data from a file of an unknown size."  My example 
causes a MemoryError on my machine even though the file I'm reading 
contains 0 bytes.

The problem is Python's implementation is "alloc the requested bytes and 
truncate if needed" vs what I expected "read chunks at a time up to the 
requested number of bytes."  There's nothing in the documentation which 
states the implementation, although "Note that this method may call the 
underlying C function fread more than once in an effort to acquire as 
close to size bytes as possible." leans slightly towards my 
interpretation.

I looked a little for real-world cases that could cause a denial-of-
service attack but didn't find one.

If there is a problem, it will occur very rarely.  Go ahead an mark it 
as "will not fix" or something similar.  I don't think the change in the 
code is justifiable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Fri Sep 12 01:31:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Sep 2008 23:31:06 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <18633.31665.640911.365762@montanaro-dyndns-org.local>
Message-ID: <1221175826.5533.1.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, sure, but heaven only knows what an application programmer will do...

If the docs clearly explain that there is no guarantee, we don't need
heaven.
I would find it strange to potentially ruin performance just for a
guarantee which has no useful purpose.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 01:59:49 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 11 Sep 2008 23:59:49 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221177589.98.0.849035260527.issue3783@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

> I would find it strange to potentially ruin performance just for a
> guarantee which has no useful purpose.

Benchmarks to prove or disprove performance changes?  Subclasses to 
offer different order by semantics (see the version I uploaded for an 
example)?  Consistent behavior wrt dictionaries?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 02:13:23 2008
From: report at bugs.python.org (Steve Smith)
Date: Fri, 12 Sep 2008 00:13:23 +0000
Subject: [issue3831] Multiprocessing: Expose underlying pipe in queues
In-Reply-To: <1221095639.45.0.136100950642.issue3831@psf.upfronthosting.co.za>
Message-ID: <1221178403.05.0.507988966141.issue3831@psf.upfronthosting.co.za>


Steve Smith <tarkasteve at gmail.com> added the comment:

Hi Jesse,

The use-case I had is mind is enabling asyncronous (i.e. select() style)
notification of data being available on the queue, which is more elegant
(and efficient) than polling with get().  Example code showing how this
works with GTK is available here:

http://haltcondition.net/?p=2319

I understand wanting to keep the API simple, however the underlying
posix-level file-descriptors for pipes and connections are already
exposed via fileno(); the actual API change would just be a matter of
changing '_reader' and '_writer' to 'reader' and 'writer' (implicitly
guaranteeing their consistency).

Would it help if I attached a patch showing the proposed change to the
module?  I realise the API is frozen now but it would be nice to have
this further down the line.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3831>
_______________________________________

From report at bugs.python.org  Fri Sep 12 02:26:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Sep 2008 00:26:07 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1221177589.98.0.849035260527.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221179131.9366.20.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Benchmarks to prove or disprove performance changes?

Agreed, benchmarks should be run.

> Subclasses to 
> offer different order by semantics (see the version I uploaded for an
> example)?

If you like, but "ordering semantics" is something which is just as
easily done in Python, so I don't understand the point of integrating it
in the dbm layer...

> Consistent behavior wrt dictionaries?

It sounds like an example of foolish consistency to me. The performance
characteristics are certainly too different to consider dbm.anything a
transparent replacement for standard dicts. And dbm.sqlite only accepts
strings, not the wide range of datatypes that dicts accept as keys and
values... so, given the big picture, I don't see why you care about such
a mostly pointless detail.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 03:18:06 2008
From: report at bugs.python.org (Anthony Lenton)
Date: Fri, 12 Sep 2008 01:18:06 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1221182286.15.0.289191996898.issue1441530@psf.upfronthosting.co.za>


Anthony Lenton <antoniolenton at gmail.com> added the comment:

It's probably just a typo from copying from an editor, but there is a
bug in the workaround.  It should be:

maxRead = 1000000
class MySSL (imaplib.IMAP4_SSL):
  def read (self, n):
    #print "..Attempting to read %d bytes" % n
      if n <= maxRead:
        return imaplib.IMAP4_SSL.read (self, n)
      else:
        soFar = 0
        result = ""
        while soFar < n:
          thisFragmentSize = min(maxRead, n-soFar)
          #print "..Reading fragment size %s" % thisFragmentSize
          fragment =\
            imaplib.IMAP4_SSL.read (self, thisFragmentSize)
          result += fragment
          soFar += thisFragmentSize # only a few, so not a tragic o/head
        return result

(With one less level of indentation in the last line).
Apart from that, the fix works wonderfully.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Fri Sep 12 03:28:57 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 12 Sep 2008 01:28:57 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1221175826.5533.1.camel@fsol>
Message-ID: <18633.50615.329532.529298@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

>> Well, sure, but heaven only knows what an application programmer will
    >> do...

    Antoine> If the docs clearly explain that there is no guarantee, we
    Antoine> don't need heaven.  I would find it strange to potentially ruin
    Antoine> performance just for a guarantee which has no useful purpose.

>From <http://docs.python.org/lib/typesmapping.html>:

    If items(), keys(), values(), iteritems(), iterkeys(), and itervalues()
    are called with no intervening modifications to the dictionary, the
    lists will directly correspond. This allows the creation of (value, key)
    pairs using zip(): "pairs = zip(a.values(), a.keys())". The same
    relationship holds for the iterkeys() and itervalues() methods: "pairs =
    zip(a.itervalues(), a.iterkeys())" provides the same value for
    pairs. Another way to create the same list is "pairs = [(v, k) for (k,
    v) in a.iteritems()]".

While the emphasis is on dictionaries, it seems to me that page describes
the notation and properties of mappings in general, not specifically
dictionaries.

I think it might be worthwhile to get a verdict from Guido on this one.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 03:32:11 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 12 Sep 2008 01:32:11 +0000
Subject: [issue3844] Script: find untested C functions
In-Reply-To: <1221183130.16.0.392255875498.issue3844@psf.upfronthosting.co.za>
Message-ID: <1221183130.16.0.392255875498.issue3844@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

The attached script reports C functions not flexed by unittests. It
needs a 'coverage' build and a run of the tests. Coverage data is then
passed to gcov and those functions with zero calls written to a text
file, grouped by source file.

It's also pretty ugly.

Reviews/suggestions are most welcome :)

I'm finishing a related script that patches the source with 'printf's,
so any false positives are easy to spot and it's clear when some action
or test exercises a previously untested C function. It already works,
but is much uglier then this one ;)

----------
components: Tests
files: ccoverage.py
messages: 73073
nosy: ajaksu2
severity: normal
status: open
title: Script: find untested C functions
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11469/ccoverage.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3844>
_______________________________________

From report at bugs.python.org  Fri Sep 12 03:33:41 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 12 Sep 2008 01:33:41 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221183221.7.0.144438691928.issue3783@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

> If you like, but "ordering semantics" is something which is just as
> easily done in Python, so I don't understand the point of integrating
> it in the dbm layer...

Actually, the db layer is *exactly* where it should be implemented, 
especially when an index can already exist (as is the case with the 
implementation I provided), especially when the total size of keys can 
easily overflow memory.  Implementing ordering semantics in Python would 
be a waste of what the db is good at: storing and ordering data.

> It sounds like an example of foolish consistency to me. The 
> performance characteristics are certainly too different to consider 
> dbm.anything a transparent replacement for standard dicts. And 
> dbm.sqlite only accepts strings, not the wide range of datatypes that 
> dicts accept as keys and values... so, given the big picture, I don't 
> see why you care about such a mostly pointless detail.

No one here has ever claimed that dbm should be a replacement for dicts, 
even if shelve attempts to do so.  This module should provide a shelve 
interface that mirrors bsddb's interface.  One of the things that was 
offered earlier was that since sqlite can store ints, floats, etc., as 
keys, maybe we should offer that ability.  I think that the base should 
act like a regular dbm object.  I think that a key-ordering should be 
available.  And if we are to offer arbitrary keys (ints, floats, unicode 
strings, byte strings, or None), it should be unordered like the base 
version.

I've uploaded a new copy of sq_dict that offers unordered shelve and 
arbitrary keys in a shelve db.

Added file: http://bugs.python.org/file11470/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 03:34:12 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 12 Sep 2008 01:34:12 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221183252.71.0.0892603620218.issue3783@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file11467/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 03:41:01 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 12 Sep 2008 01:41:01 +0000
Subject: [issue3844] Script: find untested C functions
In-Reply-To: <1221183130.16.0.392255875498.issue3844@psf.upfronthosting.co.za>
Message-ID: <1221183661.36.0.567065294513.issue3844@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Here's example output of a run against 3.0. The number after a function
name is its length in lines (as gcov counts them :).

False positives include:
./Objects/weakrefobject.c gc_clear
./Modules/readline.c on_completion_display_matches_hook

Added file: http://bugs.python.org/file11471/uncovered.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3844>
_______________________________________

From report at bugs.python.org  Fri Sep 12 05:11:36 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 12 Sep 2008 03:11:36 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1221189096.21.0.652738466311.issue3766@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I've tested it on Windows XP. MSG_WAITALL is not supported, but I 
replaced it using a while loop. I didn't notice any extraneous delay.

500 packets @ 2 tokens each (500 very short lists)
0.140999794006
         16008 function calls in 0.146 CPU seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
     1500    0.036    0.000    0.036    0.000 {method 'recv' of 
'_socket.socket'
 objects}
     1500    0.033    0.000    0.033    0.000 <string>:1(sendall)
     1500    0.016    0.000    0.065    0.000 Client.py:15(read_int)
     1500    0.015    0.000    0.053    0.000 Client.py:7(send_int)
      500    0.009    0.000    0.077    0.000 
Client.py:22(read_int_list)
      500    0.007    0.000    0.060    0.000 
Client.py:10(send_int_list)
     1500    0.007    0.000    0.010    0.000 struct.py:77(unpack)
     1500    0.005    0.000    0.005    0.000 struct.py:54(pack)
      500    0.004    0.000    0.141    0.000 Client.py:31(spam)
     2001    0.004    0.000    0.004    0.000 {len}
        1    0.003    0.003    0.146    0.146 runme.py:11(bench)
     1500    0.003    0.000    0.003    0.000 {method 'unpack' of 
'Struct' objec
ts}
     1001    0.003    0.000    0.003    0.000 {range}
     1000    0.002    0.000    0.002    0.000 {method 'append' of 
'list' objects
}
        1    0.000    0.000    0.000    0.000 struct.py:35(_compile)
        2    0.000    0.000    0.000    0.000 {time.time}
        1    0.000    0.000    0.146    0.146 <string>:1(<module>)
        1    0.000    0.000    0.000    0.000 {method 'disable' of 
'_lsprof.Prof
iler' objects}


None
================================================================================


1 packet @ 50000 tokens (1 very long list)
4.89100003242
         450019 function calls in 4.893 CPU seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    50001    1.212    0.000    1.212    0.000 <string>:1(sendall)
    50001    1.062    0.000    1.062    0.000 {method 'recv' of 
'_socket.socket'
 objects}
    50001    0.594    0.000    2.282    0.000 Client.py:15(read_int)
    50001    0.517    0.000    1.982    0.000 Client.py:7(send_int)
        1    0.354    0.354    2.732    2.732 
Client.py:22(read_int_list)
    50001    0.335    0.000    0.524    0.000 struct.py:77(unpack)
    50001    0.253    0.000    0.253    0.000 struct.py:54(pack)
    50001    0.189    0.000    0.189    0.000 {method 'unpack' of 
'Struct' objec
ts}
        1    0.176    0.176    2.158    2.158 
Client.py:10(send_int_list)
    50002    0.102    0.000    0.102    0.000 {len}
    50000    0.097    0.000    0.097    0.000 {method 'append' of 
'list' objects
}
        2    0.002    0.001    0.002    0.001 {range}
        1    0.002    0.002    4.893    4.893 runme.py:19(bench2)
        1    0.000    0.000    4.890    4.890 Client.py:31(spam)
        2    0.000    0.000    0.000    0.000 {time.time}
        1    0.000    0.000    4.893    4.893 <string>:1(<module>)
        1    0.000    0.000    0.000    0.000 {method 'disable' of 
'_lsprof.Prof
iler' objects}

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Fri Sep 12 07:39:30 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 12 Sep 2008 05:39:30 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221197970.56.0.455159067074.issue3783@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file11470/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 07:43:57 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 12 Sep 2008 05:43:57 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1221198237.15.0.808466528695.issue3783@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Here's a version with views from Python 3.0 for keys, values, and items 
:) .  I know that no one hear likes my particular implementation (though 
it offers more or less the full interface), but the Keys, Values, and 
Items classes in the following version are quite generic (they only 
require that the base class implement __iter__, _itervalues, and 
_iteritems), and reasonably optimized.  They could probably be moved 
into the generic dbm stuff and used by everyone.

Added file: http://bugs.python.org/file11472/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 10:02:38 2008
From: report at bugs.python.org (Thorben)
Date: Fri, 12 Sep 2008 08:02:38 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <20537_1221189099_m8C3BbQd021213_1221189096.21.0.652738466311.issue3766@psf.upfronthosting.co.za>
Message-ID: <3b5d765a0809120101m22c9fd36lb1415335e4d92c81@mail.gmail.com>


Thorben <thkruege at uos.de> added the comment:

That's more like it. Now I'd like to see the same behavior on Linux...

2008/9/12 Gabriel Genellina <report at bugs.python.org>:
>
> Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:
>
> I've tested it on Windows XP. MSG_WAITALL is not supported, but I
> replaced it using a while loop. I didn't notice any extraneous delay.
>
> 500 packets @ 2 tokens each (500 very short lists)
> 0.140999794006
>         16008 function calls in 0.146 CPU seconds
>
>   Ordered by: internal time
>
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>     1500    0.036    0.000    0.036    0.000 {method 'recv' of
> '_socket.socket'
>  objects}
>     1500    0.033    0.000    0.033    0.000 <string>:1(sendall)
>     1500    0.016    0.000    0.065    0.000 Client.py:15(read_int)
>     1500    0.015    0.000    0.053    0.000 Client.py:7(send_int)
>      500    0.009    0.000    0.077    0.000
> Client.py:22(read_int_list)
>      500    0.007    0.000    0.060    0.000
> Client.py:10(send_int_list)
>     1500    0.007    0.000    0.010    0.000 struct.py:77(unpack)
>     1500    0.005    0.000    0.005    0.000 struct.py:54(pack)
>      500    0.004    0.000    0.141    0.000 Client.py:31(spam)
>     2001    0.004    0.000    0.004    0.000 {len}
>        1    0.003    0.003    0.146    0.146 runme.py:11(bench)
>     1500    0.003    0.000    0.003    0.000 {method 'unpack' of
> 'Struct' objec
> ts}
>     1001    0.003    0.000    0.003    0.000 {range}
>     1000    0.002    0.000    0.002    0.000 {method 'append' of
> 'list' objects
> }
>        1    0.000    0.000    0.000    0.000 struct.py:35(_compile)
>        2    0.000    0.000    0.000    0.000 {time.time}
>        1    0.000    0.000    0.146    0.146 <string>:1(<module>)
>        1    0.000    0.000    0.000    0.000 {method 'disable' of
> '_lsprof.Prof
> iler' objects}
>
>
> None
> ================================================================================
>
>
> 1 packet @ 50000 tokens (1 very long list)
> 4.89100003242
>         450019 function calls in 4.893 CPU seconds
>
>   Ordered by: internal time
>
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>    50001    1.212    0.000    1.212    0.000 <string>:1(sendall)
>    50001    1.062    0.000    1.062    0.000 {method 'recv' of
> '_socket.socket'
>  objects}
>    50001    0.594    0.000    2.282    0.000 Client.py:15(read_int)
>    50001    0.517    0.000    1.982    0.000 Client.py:7(send_int)
>        1    0.354    0.354    2.732    2.732
> Client.py:22(read_int_list)
>    50001    0.335    0.000    0.524    0.000 struct.py:77(unpack)
>    50001    0.253    0.000    0.253    0.000 struct.py:54(pack)
>    50001    0.189    0.000    0.189    0.000 {method 'unpack' of
> 'Struct' objec
> ts}
>        1    0.176    0.176    2.158    2.158
> Client.py:10(send_int_list)
>    50002    0.102    0.000    0.102    0.000 {len}
>    50000    0.097    0.000    0.097    0.000 {method 'append' of
> 'list' objects
> }
>        2    0.002    0.001    0.002    0.001 {range}
>        1    0.002    0.002    4.893    4.893 runme.py:19(bench2)
>        1    0.000    0.000    4.890    4.890 Client.py:31(spam)
>        2    0.000    0.000    0.000    0.000 {time.time}
>        1    0.000    0.000    4.893    4.893 <string>:1(<module>)
>        1    0.000    0.000    0.000    0.000 {method 'disable' of
> '_lsprof.Prof
> iler' objects}
>
> ----------
> nosy: +gagenellina
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3766>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Fri Sep 12 10:44:07 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Sep 2008 08:44:07 +0000
Subject: [issue3842] can't run close through itertools.chain on inner generator
In-Reply-To: <1221159854.86.0.0250666743089.issue3842@psf.upfronthosting.co.za>
Message-ID: <1221209047.08.0.842271376394.issue3842@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You somehow must tell the iterator that you are done with it.
This is best done by a "del c" in your first snippet, since c is the
last reference to the iterator. 
To do this in a function (or a context manager), the trick is to wrap
the map() iterator inside a generator function.

def wrapiterator(it):
    for x in it:
        yield x

Then your sample becomes:
>>> with closing(wrapiterator(chain.from_iterable(
...                  map(gen, (1,2,3))))) as c:
...    next(c)


Which of course can be rewritten as:

def closingiterator(it):
    def wrapper():
        for x in it:
            yield x
    return closing(wrapper())

>>> with closingiterator(chain.from_iterable(map(gen, (1,2,3))))) as c:
...    next(c)


This works because the only reference to the map() iterator is held by
the wrapper generator function. Calling its close() method will
terminate the function, delete its locals, ultimately call the
deallocator of the gen() iterator, which will fire the "finally" block.

Your proposal implies that all c-based iterators need to grow a "close"
method. This is not practical, and is best simulated with this wrapper
generator: close()ing the wrapper will (recursively) destroy the iterators.
If this also works for you, I suggest to close this issue.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3842>
_______________________________________

From report at bugs.python.org  Fri Sep 12 12:49:35 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 12 Sep 2008 10:49:35 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1221198237.15.0.808466528695.issue3783@psf.upfronthosting.co.za>
Message-ID: <18634.18674.652661.591771@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Josiah> I know that no one hear likes my particular implementation
    Josiah> (though it offers more or less the full interface)...

I think implementing as much of the bsddb interface as you can is fine.  I
agree people used first, next, last, etc and having them present is a good
idea.  My initial aim was to get a replacement for use with shelve.  Its
limitations shouldn't deter people from extending it (or the other dbm.*
modules) in other ways.

Even if all the modules aren't going to be widely cross-platform I see no
reason they can't strive to be more-or-less API-compatible.

Skip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Fri Sep 12 14:05:53 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Sep 2008 12:05:53 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221221153.25.0.205917373502.issue3657@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'm not sure that pickling random.random is a good idea; did you try to
pickle the random.seed function?
Their definition look very similar (at the end of random.py:
   _inst = Random()
   seed = _inst.seed
   random = _inst.random
) but Random.seed is a python method, whereas Random.random is inherited
from _randommodule.c.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Fri Sep 12 13:35:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Sep 2008 11:35:52 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221219352.51.0.256963452875.issue3657@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The explanation is actually simple, do not blame bsddb :-)

random.random is a built-in method, so its __module__ attribute is not
set. To find it, pickle.whichmodule loops through all sys.modules, and
pick the first one that contains the function.

I reproduced the problem with a simple file:
    # someModule.py
    from random import random

then, start python and:
>>> import someModule, random, pickle
>>> pickle.dumps(random.random, 0)
'csomeModule\nrandom\np0\n.'

You may have to change the name of "someModule", to be sure that it
appears before "random" in sys.modules. Tested on Windows and x86_64 Linux.

To correct this, one direction would be to search only built-in or
extension modules; for bound methods (random.random.__self__ is not
None), try to dump separately the instance and the method name (but
getattr(random._inst, 'random') is not random.random).
Or simply change the test...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Fri Sep 12 14:11:56 2008
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 12 Sep 2008 12:11:56 +0000
Subject: [issue3845] memory access before short string when checking suffix
In-Reply-To: <1221221516.48.0.283023383502.issue3845@psf.upfronthosting.co.za>
Message-ID: <1221221516.48.0.283023383502.issue3845@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

forwarded from https://launchpad.net/bugs/234798

Bug reporter writes:

Python/pythonrun.c's PyRun_SimpleFileExFlags() assumes the filename's
extension
starts four characters back from the end. But what if the filename is
only one
character long? Memory before the filename is referenced which is probably
outside the memory allocated for the string. Here's the relevant bits of
code,
boring lines deleted.

    int
    PyRun_SimpleFileExFlags(FILE *fp, const char *filename, int closeit,
                            PyCompilerFlags *flags)
    {
        ext = filename + strlen(filename) - 4;
        if (maybe_pyc_file(fp, filename, ext, closeit)) {
            if (strcmp(ext, ".pyo") == 0)
                Py_OptimizeFlag = 1;
    }

    static int
    maybe_pyc_file(FILE *fp, const char* filename, const char* ext, int
closeit)
    {
        if (strcmp(ext, ".pyc") == 0 || strcmp(ext, ".pyo") == 0)
            return 1;
    }

A trivial solution is:

    len = strlen(filename);
    ext = filename + len - len > 4 ? 4 : 0;

This will make ext point to the NUL terminator unless filename has room
for the desired /\.py[co]$/ suffix *and* at least one character
beforehand, since I don't suppose it's intended that ".pyo" is a valid
pyo file.

----------
components: Interpreter Core
messages: 73083
nosy: doko
severity: normal
status: open
title: memory access before short string when checking suffix
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3845>
_______________________________________

From report at bugs.python.org  Fri Sep 12 14:15:15 2008
From: report at bugs.python.org (Dan OD)
Date: Fri, 12 Sep 2008 12:15:15 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221221715.91.0.959030691495.issue3774@psf.upfronthosting.co.za>


Dan OD <djo35 at cam.ac.uk> added the comment:

Please forgive my rookie bug filing:

I'm getting this bug / crash sometimes when Menu.delete() is called too

It seems to be because self.index( ) sometimes returns None which is of 
course un-iterable and delete() tries to iterate through it:

for i in range(self.index(index1), self.index(index2)+1):

As a fix the previous (simpler) delete works for me, but I don't 
understand the purpose of the extra self.deletecommand() code appended 
so I'm probably missing something.

My crash:
  File "C:\CCPN\ccpn\python\memops\gui\Menu.py", line 127, in 
deleteMenuItems
    self.delete(0, Tkinter.END)
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 2665, in delete
    for i in range(self.index(index1), self.index(index2)+1):
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

----------
nosy: +indiedan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 14:18:19 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Sep 2008 12:18:19 +0000
Subject: [issue1651995] sgmllib _convert_ref UnicodeDecodeError exception,
	new in 2.5
Message-ID: <1221221899.83.0.127048122775.issue1651995@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: normal -> high
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1651995>
_______________________________________

From report at bugs.python.org  Fri Sep 12 14:18:29 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Sep 2008 12:18:29 +0000
Subject: [issue1651995] sgmllib _convert_ref UnicodeDecodeError exception,
	new in 2.5
Message-ID: <1221221909.82.0.745573220886.issue1651995@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1651995>
_______________________________________

From report at bugs.python.org  Fri Sep 12 14:18:42 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Sep 2008 12:18:42 +0000
Subject: [issue1651995] sgmllib _convert_ref UnicodeDecodeError exception,
	new in 2.5
Message-ID: <1221221922.43.0.668620826678.issue1651995@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1651995>
_______________________________________

From report at bugs.python.org  Fri Sep 12 14:45:32 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 12 Sep 2008 12:45:32 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221223532.56.0.511065650507.issue3774@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>for i in range(self.index(index1), self.index(index2)+1):

Probably your working copy is bit old. Please try latest file.
This issue was fixed in r65971. :-)

# I've added nosy list from issue1342811.

----------
nosy: +benjamin.peterson, gpolo, loewis, schuppenies, svenil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 15:57:56 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 13:57:56 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>


New submission from Gerhard H?ring <gh at ghaering.de>:

I'd really like this change to get into Python 2.6. It's pretty trivial
(just releases the GIL when compiling SQLite statements), but improves
concurrency for SQLite. This means less "database is locked" errors for
our users.

Could somebody please review this and give me an ok to check it in?

----------
assignee: ghaering
files: sqlite_concurrency_prepare.diff
keywords: patch
messages: 73086
nosy: ghaering
severity: normal
status: open
title: sqlite3 module: Improved concurrency
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file11473/sqlite_concurrency_prepare.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:02:45 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 14:02:45 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221228165.02.0.178726431951.issue3846@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
keywords: +needs review -patch
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:05:23 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 14:05:23 +0000
Subject: [issue3847] Begging for review
In-Reply-To: <48CA76C2.4080107@ghaering.de>
Message-ID: <48CA76C2.4080107@ghaering.de>


New submission from Gerhard H?ring <gh at ghaering.de>:

Could one of you please give me a review for the trivial patch at 
http://bugs.python.org/issue3846  It releases the GIL around 
sqlite3_prepare calls to improve concurrency.

Many thanks

-- Gerhard

----------
files: unnamed
messages: 73087
nosy: ghaering, josiah.carlson
severity: normal
status: open
title: Begging for review
Added file: http://bugs.python.org/file11474/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3847>
_______________________________________
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 3431
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080912/7b173458/attachment.eml>

From report at bugs.python.org  Fri Sep 12 16:26:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Sep 2008 14:26:31 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221229591.88.0.445004988274.issue3846@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Your patch seems obvious, however:

- Is there the possibility that sqlite3_prepare() calls back into a
function in the _sqlite module or other python code? In this case the
GIL has to be re-acquired.

- What if another thread closes the current connection (or drop a table,
etc.) in-between? Is sqlite really thread-safe?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:27:04 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 14:27:04 +0000
Subject: [issue3103] sqlite defines a few global symbols.
In-Reply-To: <1213344046.17.0.166963020016.issue3103@psf.upfronthosting.co.za>
Message-ID: <1221229624.38.0.420790360555.issue3103@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Patch to Python 2.6 with Misc/NEWS entry if we want to close this now.

Added file: http://bugs.python.org/file11475/patch_sqlite3_global_symbols.dif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3103>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:56:14 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 14:56:14 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221231374.18.0.223307389573.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Python 2.6b2 was released with this bug, and got fixed later.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:56:51 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 14:56:51 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221231411.31.0.752171845411.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I meant beta3, sorry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:58:33 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 14:58:33 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221231513.06.0.476097302687.issue3846@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

1. SQLite calling back

Good that you mention it. During sqlite3_prepare, SQLite can call the
authorizer_callback. Fortunately, it already acquires/releases the GIL
appropriately already.

2. Other thread closing connection, etc.

Connections/cursors cannot be shared among Python threads. Well, with
newer SQLite releases I think it is possible. But we have checks in
place that raise an error if you do it. These are the various calls to
pysqilte_check_thread in the code. If the table is dropped,
sqlite3_prepare will just raise an error about the statement not being
valid.

If, however, the table is dropped between sqlite3_prepare and
sqlite3_step, then the SQLITE_SCHEMA error code is returned. We then try
to recompile the statement (it might have just been an ALTER TABLE and
the statement is valid after compiling it again). If that still fails,
we promote the error to Python (cursor.c lines 605ff).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:59:25 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 14:59:25 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221231565.99.0.107797902523.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Oops, sorry, I misread the bug report, reopening it (let me go eat
something now).

----------
keywords:  -easy, needs review
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 16:59:42 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 14:59:42 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221231582.88.0.896904299373.issue3774@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
keywords: +easy, needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:21:36 2008
From: report at bugs.python.org (Dan OD)
Date: Fri, 12 Sep 2008 15:21:36 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221232896.05.0.362949427171.issue3774@psf.upfronthosting.co.za>


Dan OD <djo35 at cam.ac.uk> added the comment:

Thanks guys - I was running an old build. revision 65971 fixed this as Hirokazu mentioned.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:49:56 2008
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Sep 2008 15:49:56 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1221234596.42.0.701241376043.issue1597850@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> In particular, I think that X-compiling is a common request

added another one to the list.

justification: pywebkitgtk cross-compiling for win32, using mingw32.
i'm not paying for microsoft license fees, i'm not paying for a
computer capable of running msvc, i'm not paying for the bandwidth
to download msvc and/or set it up.

much happier with mingw32, but mingw32 runs like an absolute dog
under wine - and often wine_server hangs.  (at least a 20x performance
hit for running msys and mingw32 under wine).

so... that leaves cross-compiling.

i need the development libraries from python 2.5 in order to create
a windows version of pywebkitgtk.

----------
nosy: +lkcl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:51:45 2008
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 12 Sep 2008 15:51:45 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian <ionel.mc at gmail.com>:

The docs on epoll object's register method say: "Registering a file
descriptor that?s already registered is not an error, and has the same
effect as registering the descriptor exactly once."

However when calling register twice with the same fd it will fail with a
bogus "IOError: [Errno 17] File exists" error.

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 73096
nosy: georg.brandl, ionel.mc
severity: normal
status: open
title: select.epoll calling register with the same fd fails
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/issue3848>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:52:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Sep 2008 15:52:30 +0000
Subject: [issue2747] Documentation of new gobject types fails
In-Reply-To: <1209835134.72.0.0778910402245.issue2747@psf.upfronthosting.co.za>
Message-ID: <1221234750.0.0.264707787703.issue2747@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This turns out to be caused by the same problem that caused the
SQLAlchemy model failure: the module was imported twice by autodoc.

Should now be fixed in trunk and 0.4.x branch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2747>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:54:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Sep 2008 15:54:02 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1221234842.79.0.365154804233.issue3848@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> christian.heimes
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3848>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:56:50 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Sep 2008 15:56:50 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1221235010.81.0.588890437653.issue3848@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'll look into it. kqueue should be checked for the issue, too.

Barry: I don't think it's a release blocker but it's your call.

----------
nosy: +barry
priority:  -> critical
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3848>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:58:10 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 15:58:10 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221235090.17.0.269954195507.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The patch attached is probably the most direct way to fix it, but, can
someone remind why we just don't call deletecommand (if there is a
command to delete) and let it try to remove the command from _tclCommand
then ? (note that this is not really the case for this bug report).
I'm attaching a patch that is a bit "different". It relies on the fact
that if the menu entry was created with add_command but no command was
specified, then there is no command to specify. And if a command was
specified then _tclCommands would be a list and deletecommand would work
properly.

Added file: http://bugs.python.org/file11476/issue3774.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:58:25 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Sep 2008 15:58:25 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1221235105.26.0.985637187012.issue3848@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Not a blocker.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3848>
_______________________________________

From report at bugs.python.org  Fri Sep 12 17:59:18 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 15:59:18 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221235158.53.0.47532585527.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Again, I meant the previously attached patch (the one by ocean-city) was
the most direct way.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 18:03:14 2008
From: report at bugs.python.org (skomoroh)
Date: Fri, 12 Sep 2008 16:03:14 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221235394.69.0.37945228332.issue3774@psf.upfronthosting.co.za>


skomoroh <skomoroh at gmail.com> added the comment:

Seems I found the bug.

I've attached the patch for current py3k-trunk.

Added file: http://bugs.python.org/file11477/menu_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 18:07:14 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 16:07:14 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221235634.19.0.418824789245.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

My patch already does what is proposed in your patch, except yours may
possibly not work. It is not guaranteed that "self.entrycget(i,
'command')" will return an empty string if the command associated to
that menu entry is an empty string. Tcl may return another object
containing the representation of this menu command so that if statement
will evalute as True while its representation is actually an empty string.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 18:10:23 2008
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 12 Sep 2008 16:10:23 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1221235823.09.0.264012160667.issue3848@psf.upfronthosting.co.za>


Maries Ionel Cristian <ionel.mc at gmail.com> added the comment:

Why don't just fix the docs ?
I think it's consistent with the epoll api the way it is now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3848>
_______________________________________

From report at bugs.python.org  Fri Sep 12 18:25:53 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Sep 2008 16:25:53 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1221236753.98.0.730071407383.issue3848@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It's not consistent with Python's select.poll API. But exarkun and I
think that an exception is fine here. The exception makes it easier to
spot issues.

The patch updates the docs and adds some tests for corner cases to
test_epoll.py

----------
keywords: +patch
Added file: http://bugs.python.org/file11478/epoll.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3848>
_______________________________________

From report at bugs.python.org  Fri Sep 12 18:33:47 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Sep 2008 16:33:47 +0000
Subject: [issue3655] latexwriter: \footnotemark can only take numbers as
	arguments
In-Reply-To: <1219525862.69.0.109867227566.issue3655@psf.upfronthosting.co.za>
Message-ID: <1221237227.11.0.487967913431.issue3655@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is now tracked in http://code.google.com/p/sphinx/issues/detail?id=13.

----------
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3655>
_______________________________________

From report at bugs.python.org  Fri Sep 12 19:04:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Sep 2008 17:04:25 +0000
Subject: [issue3848] select.epoll calling register with the same fd fails
In-Reply-To: <1221234705.58.0.620689980642.issue3848@psf.upfronthosting.co.za>
Message-ID: <1221239065.01.0.939082933781.issue3848@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This should be removed from the docs patch:

-   Register a fd descriptor with the epoll object.
+  Register a fd descriptor with the epoll object.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3848>
_______________________________________

From report at bugs.python.org  Fri Sep 12 19:33:30 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 12 Sep 2008 17:33:30 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221240810.88.0.321661698971.issue3774@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

self.deletecommand doesn't remove menu item, so we don't have to care
about index shifting like bellow. +1 for gpolo's patch.

>>> a = [0, 1, 2, 3]
>>> for i in xrange(len(a)):
...     del a[i]
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
IndexError: list assignment index out of range


I'm not sure (self._tclCommands is not None) check is not really needed.
I was looking for the place self._tclCommands is initialized, and found
_register() is that place, but what is 'needcleanup'? :-0
But probably, gpolo's patch is right.


P.S.
This is not related to this issue, I think
"""Delete menu items between INDEX1 and INDEX2 (not included)."""
should be changed to
"""Delete menu items between INDEX1 and INDEX2 (included)."""

Please look at http://www.tcl.tk/man/tcl8.5/TkCmd/menu.htm#M59

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 19:59:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 12 Sep 2008 17:59:04 +0000
Subject: [issue3847] Begging for review
In-Reply-To: <48CA76C2.4080107@ghaering.de>
Message-ID: <1221242344.04.0.548095539714.issue3847@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think you meant to send this to the tracker.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3847>
_______________________________________

From report at bugs.python.org  Fri Sep 12 19:58:59 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 17:58:59 +0000
Subject: [issue3847] Begging for review
In-Reply-To: <48CA76C2.4080107@ghaering.de>
Message-ID: <1221242339.87.0.75708832865.issue3847@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

I accidentally created this issue

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3847>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:23:37 2008
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Sep 2008 18:23:37 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1221243817.14.0.640746488683.issue1597850@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

the cross-compile fails on Parser/acceler.c
the reason is because the included file, pyconfig.h,
has "#define gid_t int" for use by the mingw32 compiler,
which is... bad!
removing gid_t from pyconfig.h bizarrely fixes the
compile without.. so far.. any issues....

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:27:15 2008
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Sep 2008 18:27:15 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1221244035.06.0.0545235050777.issue1597850@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

pyport.h line 773 - commenting out the test for LONG_BIT != 8 *
SIZEOF_LONG - we're cross-compiling amd64 host, target mingw32 - 32-bit.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:34:22 2008
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Sep 2008 18:34:22 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1221244462.8.0.390450531403.issue1597850@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

line 199 of thread_pthread.h  and line 221:
Python/thread_pthread.h:200: error: aggregate value used where an
integer was expected

hmmm... maybe this is due to me using mingw32 based on gcc 4.4.4.

well, a quick #if 0 seems to fix it :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:35:49 2008
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Sep 2008 18:35:49 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1221244549.56.0.481383897309.issue1597850@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

posixmodule.c - line 2328:
add this:

#if ( defined(__MINGW32__) || defined(__WATCOMC__) ||
defined(PYCC_VACPP) ) && !defined(__QNX__)
    res = mkdir(path);
#else
    res = mkdir(path, mode);
#endif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:38:37 2008
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Sep 2008 18:38:37 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1221244717.43.0.257443444013.issue1597850@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

posixmodule: line 3530:

#ifdef __MINGW32__
    master_fd = open(DEV_PTY_FILE, O_RDWR); /* open master */
#else
    master_fd = open(DEV_PTY_FILE, O_RDWR | O_NOCTTY); /* open master */
#endif

not sure i should be compiling posixmodule under mingw32 :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:40:24 2008
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Sep 2008 18:40:24 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1221244824.0.0.408713036985.issue1597850@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

line 6193:

#if !defined(__MINGW32__) && !defined(MS_WINDOWS) && defined(HAVE_FCNTL_H)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:48:57 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 12 Sep 2008 18:48:57 +0000
Subject: [issue3103] sqlite defines a few global symbols.
In-Reply-To: <1213344046.17.0.166963020016.issue3103@psf.upfronthosting.co.za>
Message-ID: <1221245337.3.0.911503380865.issue3103@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is fine, please try to apply it before rc1. If rc1 gets
missed, it should be defered to 2.7.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3103>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:52:21 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Fri, 12 Sep 2008 18:52:21 +0000
Subject: [issue3842] can't run close through itertools.chain on inner generator
In-Reply-To: <1221209047.08.0.842271376394.issue3842@psf.upfronthosting.co.za>
Message-ID: <48CAB978.2010204@gmail.com>


Bruce Frederiksen <dangyogi at gmail.com> added the comment:

What you propose is not portable code.  It won't work on jython or 
ironpython or pypy because they don't have reference counting garbage 
collectors that immediately reclaim objects.

Also I'm not asking that all c-based iterators grow a 'close' method 
(though this would be nice! :-) ).

For all other c-based iterators, you can do:

with closing(gen()) as argument:
    for x in map(fn, argument): ...

which is portable.

So I am only asking that 'close' be added to itertools.chain because 
there is no portable solution there.

-bruce

Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> You somehow must tell the iterator that you are done with it.
> This is best done by a "del c" in your first snippet, since c is the
> last reference to the iterator. 
> To do this in a function (or a context manager), the trick is to wrap
> the map() iterator inside a generator function.
>
> def wrapiterator(it):
>     for x in it:
>         yield x
>
> Then your sample becomes:
>   
>>>> with closing(wrapiterator(chain.from_iterable(
>>>>         
> ...                  map(gen, (1,2,3))))) as c:
> ...    next(c)
>
>
> Which of course can be rewritten as:
>
> def closingiterator(it):
>     def wrapper():
>         for x in it:
>             yield x
>     return closing(wrapper())
>
>   
>>>> with closingiterator(chain.from_iterable(map(gen, (1,2,3))))) as c:
>>>>         
> ...    next(c)
>
>
> This works because the only reference to the map() iterator is held by
> the wrapper generator function. Calling its close() method will
> terminate the function, delete its locals, ultimately call the
> deallocator of the gen() iterator, which will fire the "finally" block.
>
> Your proposal implies that all c-based iterators need to grow a "close"
> method. This is not practical, and is best simulated with this wrapper
> generator: close()ing the wrapper will (recursively) destroy the iterators.
> If this also works for you, I suggest to close this issue.
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3842>
_______________________________________

From report at bugs.python.org  Fri Sep 12 20:59:55 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 18:59:55 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221245995.4.0.821360500234.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This "needcleanup" parameter indicates that the function added to
_tclCommands needs to (and will) be removed later. Nevertheless, I
believe the proper initialization of _tclCommands should be done elsewhere.


And about that docstring.. yes, the change is needed. (I could swear I
saw it fixed some time ago, but no.. it didn't happen)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:03:50 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 19:03:50 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1221246230.28.0.62841802965.issue3841@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Where is the test case ?

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:04:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 12 Sep 2008 19:04:16 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221246256.85.0.659998107983.issue3846@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Asking in the same direction: what is the consequence of this patch when
check_same_thread is False? Couldn't that result in very problematic
overlappings, e.g. when two threads try to execute statements on the
same cursor?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:05:43 2008
From: report at bugs.python.org (raz)
Date: Fri, 12 Sep 2008 19:05:43 +0000
Subject: [issue3849] FUD in documentation for urllib.urlopen()
In-Reply-To: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>
Message-ID: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>


New submission from raz <filter-pythonbugs at mbox.bz>:

The documentation for urllib.urlopen() states:

"One caveat: the read() method, if the size argument is omitted or
negative, may not read until the end of the data stream; there is no
good way to determine that the entire stream from a socket has been read
in the general case."

To an innocent reader this effectively translates to:
"The read() method may silently truncate your data but we won't tell you
any details about it."

The paragraph should be clarified as follows:

- Under what circumstances can truncation happen (which protocols are
affected, under which conditions?)
- What are safe use-cases where truncation can not happen (e.g. the
common case of a simple HTTP-GET)

----------
assignee: georg.brandl
components: Documentation
messages: 73122
nosy: georg.brandl, raz
severity: normal
status: open
title: FUD in documentation for urllib.urlopen()
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3849>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:14:13 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 19:14:13 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221246853.47.0.413203668397.issue3774@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

New patch, this one fixes the docstring previously mentioned and may set
_tclCommands to an empty list at BaseWidget.__init__

Added file: http://bugs.python.org/file11479/issue3774_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:22:00 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 19:22:00 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221247320.71.0.666478867637.issue3846@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Interesting. I was smart enough to not document check_same_thread in the
sqlite3 incarnation of the module.

This has nothing to do with releasing/aquiring the GIL around
sqlite3_prepare, though. Adding the macros was just an oversight.
They're there for all other nontrivial SQLite API calls (sqlite3_step,
sqlite3_reset, sqlite3_open, sqlite3_finalize and also already for the
"BEGIN"/"COMMIT" and "ROLLBACK" versions of sqlite3_prepare in connection.c.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:24:47 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 19:24:47 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221247487.36.0.244355608068.issue3846@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Just to be explicit: check_same_thread is unsupported and while it's
undocumented in sqlite3, the old pysqlite docs say that when you use it,
you have to make sure the connections/cursors are protected otherwise
(via your own mutexes).

[In the current pysqlite docs it's not documented at all at the moment,
because I derived these from the Python sqlite3 ones]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:28:55 2008
From: report at bugs.python.org (Tim Peters)
Date: Fri, 12 Sep 2008 19:28:55 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221247735.11.0.280771762014.issue3657@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

No thought went into picking random.random in the test -- it was just a
random ;-) choice.  Amaury's analysis of the source of non-determinism
is on target, and the easiest fix is to pick a coded-in-Python function
to pickle instead.  I suggest, e.g., changing the sporadically failing
doctest to:

>>> import pickletools
>>> dis(pickle.dumps(pickletools.dis, 0))
    0: c    GLOBAL     'pickletools dis'
   17: p    PUT        0
   20: .    STOP
highest protocol among opcodes = 0

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:38:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 12 Sep 2008 19:38:31 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221247320.71.0.666478867637.issue3846@psf.upfronthosting.co.za>
Message-ID: <48CAC534.7090200@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This has nothing to do with releasing/aquiring the GIL around
> sqlite3_prepare, though. 

You mean, it doesn't make things worse, but I believe they do
(even if so only slightly). If you have two threads simultaneously
attempting an execute on a cursor, one will run into the prepare.

That thread will (now) release the GIL, allowing the second thread
to run into the prepare. That thread will replace the statement object
in the cursor, so when the first thread returns, the statement has
changed underneath, and it will associate any return code with the
incorrect statement object.

In this form, this can't currently happen. Without detailed review,
I can readily believe that there are many other cases where a
False check_same_thread can give surprising results.

> They're there for all other nontrivial SQLite API calls (sqlite3_step,
> sqlite3_reset, sqlite3_open, sqlite3_finalize and also already for the
> "BEGIN"/"COMMIT" and "ROLLBACK" versions of sqlite3_prepare in connection.c.

On the grounds that the code is already full of these GIL release calls,
I'll approve this additional one.

I encourage you to review the entire issue, though, and document
somewhere what promises are made under what conditions. Then a later
review can validate that the promises are really kept.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:40:45 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 12 Sep 2008 19:40:45 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221248445.21.0.0191714045093.issue3846@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:53:53 2008
From: report at bugs.python.org (Van Lindberg)
Date: Fri, 12 Sep 2008 19:53:53 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221249233.16.0.569749631735.issue3617@psf.upfronthosting.co.za>


Van Lindberg <van.lindberg at gmail.com> added the comment:

Sorry for the long comment. There are two parts to this comment. First,
my recommendation, and second, the somewhat tedious analysis of the
Microsoft EULAs. The second part is the verbiage to justify the first.

Recommendation
==============

To comply with Microsoft's EULA, the PSF should include text like the
following in the Windows binary installer license text:

----

"This program is linked with and uses Microsoft Distributable Code,
copyrighted by Microsoft Corporation. The Microsoft Distributable Code
includes the following files:

[...]

If you further distribute programs that include the Microsoft
Distributable Code, you must comply with the restrictions on
distribution specified by Microsoft. In particular, you must require
distributors and external end users to agree to terms that protect the
Microsoft Distributable Code at least as much as Microsoft's own
requirements for the Distributable Code. See Microsoft's documentation
(included in its developer tools and on its website at microsoft.com)
for specific details.

Redistribution of the Windows binary build of the Python interpreter
complies with this agreement, provided that you do not:

- alter any copyright, trademark or patent notice in Microsoft's
Distributable Code;

- use Microsoft?s trademarks in your programs? names or in a way that
suggests your programs come from or are endorsed by Microsoft;

- distribute Microsoft's Distributable Code to run on a platform other
than Microsoft operating systems, run-time technologies or application
platforms;

- include Microsoft Distributable Code in malicious, deceptive or
unlawful programs; or

- modify or distribute the source code of any Microsoft Distributable
Code so that any part of it becomes subject to an Excluded License.  An
Excluded License is one that requires, as a condition of use,
modification or distribution, that the code be disclosed or distributed
in source code form; or others have the right to modify it.

These restrictions apply only to the Microsoft Distributable Code as
defined above, not to Python itself or any programs running on the
Python interpreter. The redistribution of the Python interpreter and
libraries is governed by the Python Software License included with this
file, or by other licenses as marked.

----

Commentary on the distribution requirements
===========================================

VS 2008 (labels added for clarity)
----------------------------------


"ii.    Distribution Requirements.  For any Distributable Code you
distribute, you must
    
(A) add significant primary functionality to it in your programs;"

This term is satisfied by the addition of the Python interpreter.


(B) "for any Distributable Code having a filename extension of .lib,
distribute only the results of running such Distributable Code through a
linker with your program;"

This prohibits distributing libraries in .lib form. Based on what I see
in the MSI, we do not do this. We do include _msi.lib, but that is not
Microsoft's _msi.lib, but the ready-for linking version of MvL's msilib.


(C) "distribute Distributable Code included in a setup program only as
part of that setup program without modification;"

Python does not include any Distributable Code included in a setup program.


(D) "require distributors and external end users to agree to terms that
protect it at least as much as this agreement;"

This term specifies that any Distributable Code that we distribute must
itself have some sort of agreement that protects Microsoft's rights in
"it" (the code) "at least as much as this agreement."

The important term here is "it." The antecedent here is "Distributable
Code you distribute," (Microsoft's code, in this case the msvcrt.dll),
not "your programs" (Python). 


(E) "display your valid copyright notice on your programs; and"

Python complies with this requirement, as we display our own license
agreement and include sys.copyright.


(F) "indemnify, defend, and hold harmless Microsoft from any claims,
including attorneys? fees, related to the distribution or use of your
programs."

Under this provision, we agree not to sue Microsoft for distributing Python.


"iii. Distribution Restrictions.  You may not

(G) alter any copyright, trademark or patent notice in the Distributable
Code;"

Python complies with this requirement, as the Microsoft Distributable
Code is distributed unaltered.


(H) "use Microsoft?s trademarks in your programs? names or in a way that
suggests your programs come from or are endorsed by Microsoft;"

Python complies with this requirement, as we do use Microsoft's
trademarks in the program name and we don't suggest that Python comes
from or is endorsed by Microsoft.


(I) "distribute Distributable Code to run on a platform other than
Microsoft operating systems, run-time technologies or application
platforms;"

While Python could technically run on non-Microsoft platforms (e.g.
Wine), the Windows binary distribution is explicitly provided *for
Windows.* Other platforms are provided source code or explicit binaries.
Therefore, the PSF does not "distribute Distributable Code to run on a
platform other than Microsoft operating systems."


(J) "include Distributable Code in malicious, deceptive or unlawful
programs; or"

Python complies with this requirement, as it is not malicious,
deceptive, or unlawful.


(K) "modify or distribute the source code of any Distributable Code so
that any part of it becomes subject to an Excluded License.  An Excluded
License is one that requires, as a condition of use, modification or
distribution, that

    the code be disclosed or distributed in source code form; or

    others have the right to modify it."
    
Python complies with this requirement, as it does not express any claim
or licensing requirement on any part of the code that goes into a binary
distribution.


-----

(VS 7.1 EULA)
-------------

The analysis for the VS 7.1 EULA is similar to the 2008 EULA above.

"3.1    General Distribution Requirements.  

(a)    If you choose to redistribute Sample Code, or Redistributable
Code (collectively, the ?Redistributables?) as described in Section 2,
you agree:"  

The PSF redistributes "Redistributables", so this section applies to us.

"(i) except as otherwise noted in Section?2.1 (Sample Code), to
distribute the Redistributables only in object code form and in
conjunction with and as a part of a software application product
developed by you that adds significant and primary functionality to the
Redistributables (?Licensee Software?);"

This is similar to requirement (A) above in the 2008 EULA. The Python
interpreter fulfills this requirement.


"(ii)?that the Redistributables only operate in conjunction with
Microsoft Windows platforms;"

As discussed above relative to paragraph (I) above, and end user could
conceivably take the Windows binary distribution of Python and run it on
Wine. Regardless, the Windows binary build is clearly marked for use on
the Microsoft Windows platform and other platforms have their own
builds. Accordingly, Python fulfills this requirement.


"(iii)?that if the Licensee Software is distributed beyond Licensee?s
premises or externally from Licensee?s organization, to distribute the
Licensee Software containing the Redistributables pursuant to an end
user license agreement (which may be ?break-the-seal?, ?click-wrap? or
signed), with terms no less protective than those contained in this EULA;"

The wording in the VS 7.1 EULA is not as clear as in the 2008 EULA, but
these license terms only apply to the Microsoft Redistributables, not to
Python itself. The PSF will comply with this provision by incorporating
Microsoft's terms by reference and explicitly applying them to the
Microsoft Redistributables only.


"(iv)?not to use Microsoft?s name, logo, or trademarks to market the
Licensee Software;"

As discussed relative to paragraph (H) above, Python complies with this
provision.


"(v) to display your own valid copyright notice which shall be
sufficient to protect Microsoft?s copyright in the Software;"

As discussed relative to paragraph (E) above, Python complies with this
provision.


"(vi)?not to remove or obscure any copyright, trademark or patent
notices that appear on the Software as delivered to you;"

As discussed relative to paragraph (G) above, Python complies with this
provision.


"(vii) to indemnify, hold harmless, and defend Microsoft from and
against any claims or lawsuits, including attorney?s fees, that arise or
result from the use or distribution of the Licensee Software;"

As discussed relative to paragraph (F) above, Python complies with this
provision.


"(viii)?to otherwise comply with the terms of this EULA;"

The PSF and the Python Windows binary distribution otherwise comply with
the EULA.


"and (ix)?agree that Microsoft reserves all rights not expressly granted."

The PSF can agree to this provision, again as it refers only to the
Microsoft Distributable Code, not Python itself.

  
"You also agree not to permit further distribution of the
Redistributables by your end users except you may permit further
redistribution of the Redistributables by your distributors to your
end-user customers if your distributors only distribute the
Redistributables in conjunction with, and as part of, the Licensee
Software, you comply with all other terms of this EULA, and your
distributors comply with all restrictions of this EULA that are
applicable to you." 

This provision has two parts. First, the PSF agrees to only allow the
redistribution of the Microsoft Distributable Code with the Python
interpreter, and second, redistributions of the Microsoft Distributable
Code need to comply with the EULA.

The provided statement complies with both of these provisions by making
the restrictions on the Microsoft Distributable Code clear and by
incorporating Microsoft's restrictions by reference.


"If you use the Redistributables, then in addition to your compliance
with the applicable distribution requirements described for the
Redistributables, the following also applies.  Your license rights to
the Redistributables are conditioned upon your not (i) creating
derivative works of the Redistributables in any manner that would cause
the Redistributables in whole or in part to become subject to any of the
terms of an Excluded License; or (ii) distributing the Redistributables
(or derivative works thereof) in any manner that would cause the
Redistributables to become subject to any of the terms of an Excluded
License.  An ?Excluded License? is any license that requires as a
condition of use, modification and/or distribution of software subject
to the Excluded License, that such software or other software combined
and/or distributed with such software be (x) disclosed or distributed in
source code form; (y)?licensed for the purpose of making derivative
works; or (z) redistributable at no charge."

As discussed relative to paragraph (K) above, Python complies with this
provision, as it does not express any claim or licensing requirement on
any part of the code that goes into a binary distribution.

----------
nosy: +vanl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Fri Sep 12 21:59:32 2008
From: report at bugs.python.org (Stephen McInerney)
Date: Fri, 12 Sep 2008 19:59:32 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1221249572.37.0.997369566864.issue3841@psf.upfronthosting.co.za>


Stephen McInerney <spmcinerney at hotmail.com> added the comment:

(I previously attached testcase with the web form, but it doesn't seem 
to work. So I'm pasting it here:)

# Generate a length-4094 string.
# IDLE will not display this unless your cursor is inside the string.
# If you delete characters so length <= 4093, IDLE displays it ok.
# Python versions: believed to be all
# OS: Windows Vista (maybe others)

#verylongstring = "1 3 5 7 9 " * 409 + "1 3 "
verylongstring = "1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 
9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 
1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 
7 9 1 3 "
print len(verylongstring)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:04:54 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 12 Sep 2008 20:04:54 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1221249894.39.0.67658569339.issue3841@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I don't think I can reproduce this under Linux with the idlelib in
python-trunk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:06:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Sep 2008 20:06:55 +0000
Subject: [issue3850] find_recursion_limit.py is broken
In-Reply-To: <1221250015.74.0.0718109598315.issue3850@psf.upfronthosting.co.za>
Message-ID: <1221250015.74.0.0718109598315.issue3850@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

find_recursion_limit.py in trunk is broken: it fails with an
AttributeError while a RuntimeError is expected. This has appeared due
to the recent changes in recursion limit handling, but the problem is
deeper. As I explained on the ML, functions like PyDict_GetItem()
discard any exception that occur inside them, and return NULL instead.
The caller can then interpret the NULL as an "attribute missing" and
raise AttributeError.

The obvious quick fix is to replace "except RuntimeError" with "except
(RuntimeError, AttributeError)" in find_recursion_limit.py.

----------
components: Demos and Tools
keywords: easy
messages: 73131
nosy: pitrou
priority: high
severity: normal
status: open
title: find_recursion_limit.py is broken
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:07:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Sep 2008 20:07:45 +0000
Subject: [issue3640] test_cpickle crash on AMD64 Windows build
In-Reply-To: <1219360903.53.0.323822932018.issue3640@psf.upfronthosting.co.za>
Message-ID: <1221250065.57.0.209326099538.issue3640@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've opened #3850 for the find_recursion_limit problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3640>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:10:05 2008
From: report at bugs.python.org (Stephen McInerney)
Date: Fri, 12 Sep 2008 20:10:05 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1221250205.37.0.688566230728.issue3841@psf.upfronthosting.co.za>


Stephen McInerney <spmcinerney at hotmail.com> added the comment:

This may well be Windows-only or maybe even Windows Vista-only.

I don't have ready access to other OS installs so could someone who 
does please try to repro?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:11:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Sep 2008 20:11:44 +0000
Subject: [issue3850] find_recursion_limit.py is broken
In-Reply-To: <1221250015.74.0.0718109598315.issue3850@psf.upfronthosting.co.za>
Message-ID: <1221250304.35.0.118408771441.issue3850@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11480/find_recursion_limit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:15:21 2008
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 12 Sep 2008 20:15:21 +0000
Subject: [issue3851] IDLE: Pressing "Home" on Windows places cursor before
	">>>" instead of after. Solution offered.
Message-ID: <1221250521.44.0.602385655324.issue3851@psf.upfronthosting.co.za>


Changes by Roger Serwy <roger.serwy at gmail.com>:


----------
nosy: serwy
severity: normal
status: open
title: IDLE: Pressing "Home" on Windows places cursor before ">>>" instead of after. Solution offered.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3851>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:17:23 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 12 Sep 2008 20:17:23 +0000
Subject: [issue3850] find_recursion_limit.py is broken
In-Reply-To: <1221250015.74.0.0718109598315.issue3850@psf.upfronthosting.co.za>
Message-ID: <1221250643.68.0.0581293583829.issue3850@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Could you use PyDict_GetItemWithError() to avoid this?

----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:19:10 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Sep 2008 20:19:10 +0000
Subject: [issue3850] find_recursion_limit.py is broken
In-Reply-To: <1221250015.74.0.0718109598315.issue3850@psf.upfronthosting.co.za>
Message-ID: <1221250750.94.0.938451716524.issue3850@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's not my code, it's the interpreter's code which uses
PyDict_GetItem() all over the place, and the aim of
find_recursion_limit.py is precisely to test the function call paths
inside the interpreter.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3850>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:19:16 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 12 Sep 2008 20:19:16 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221250756.79.0.310971656539.issue3657@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:20:35 2008
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 12 Sep 2008 20:20:35 +0000
Subject: [issue3851] IDLE: Pressing "Home" on Windows places cursor before
	">>>" instead of after. Solution offered.
In-Reply-To: <1221250835.7.0.322524713176.issue3851@psf.upfronthosting.co.za>
Message-ID: <1221250835.7.0.322524713176.issue3851@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Pressing "Home" on Windows XP in the PyShell window places the cursor
before ">>>" instead of after it. On Linux, this behaves correctly.

The problem is in PyShell.py in the home_callback(). At line 1064:

if event.state != 0 and event.keysym == "Home":
    return

"event.state" returns 8 on Windows when Home is pressed, thus the
callback never executes. Here are two solutions:

event.mc_state != 0

or

(event.state & 1) != 0

This fixes the problem on Windows, and still works under Linux.

----------
components: +IDLE
type:  -> behavior
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3851>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:21:02 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Sep 2008 20:21:02 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221250862.54.0.495169889248.issue3657@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

But it still means pickling a function/method defined in a builtin
extension module can give wrong results, doesn't it deserve being fixed?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:35:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 12 Sep 2008 20:35:47 +0000
Subject: [issue3849] FUD in documentation for urllib.urlopen()
In-Reply-To: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>
Message-ID: <1221251747.79.0.889354410316.issue3849@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Would you be interested in working on a patch?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3849>
_______________________________________

From report at bugs.python.org  Fri Sep 12 22:42:22 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 12 Sep 2008 20:42:22 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221252142.61.0.844794082356.issue3617@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thank you, Van, for this comprehensive analysis.

By including your text we'll also bypass the issues with finding the
EULA file in the Visual Studio installation.

The text should be easy to add as extra file and we can then reference
this file in the MSI installer builder (much like we do for all other
3rd party licenses. I can't help with that in the next few days, though,
since I'm on vacation the next week.

One nit I found with the text, but that may not be legally relevant: The
MS website does not appear to list the EULA texts anywhere.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Fri Sep 12 23:31:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 12 Sep 2008 21:31:01 +0000
Subject: [issue3842] can't run close through itertools.chain on inner generator
In-Reply-To: <1221159854.86.0.0250666743089.issue3842@psf.upfronthosting.co.za>
Message-ID: <1221255061.88.0.829846051737.issue3842@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, am going to reject this.   The use cases are somewhat uncommon
and I don't want to clutter-up tools that need to remain as simple as
possible.  The pure python code for chain() is so simple that it's not
hard to roll your own version as needed.

----------
resolution: works for me -> rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3842>
_______________________________________

From report at bugs.python.org  Fri Sep 12 23:40:25 2008
From: report at bugs.python.org (Tim Peters)
Date: Fri, 12 Sep 2008 21:40:25 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221255625.85.0.707726952986.issue3657@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Amaury, yes, it would be nice if pickle were more reliable here.  But
that should be the topic of a different tracker issue.  Despite the
Title, this issue is really about sporadic pickletools.py failures, and
the pickletools tests are trying to test pickletools, not pickle.py (or
cPickle).  Changing the test as suggested makes it reliably test what
it's trying to test (namely that pickletools.dis() produces sensible
output for pickle's GLOBAL opcode).  Whether pickle/cPickle should do a
better job of building GLOBAL opcodes in the first place is a distinct
issue.

In any case, since pickle/cPickle have worked this way forever, and the
only known bad consequence to date is accidental sporadic test failures
in pickletools.py, the underlying pickle/cPickle issue shouldn't be a
release blocker regardless.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Fri Sep 12 23:41:33 2008
From: report at bugs.python.org (unutbu)
Date: Fri, 12 Sep 2008 21:41:33 +0000
Subject: [issue3318] Documentation: timeit: "lower bound" should read "upper
	bound"
In-Reply-To: <1220992931.31.0.275267255012.issue3318@psf.upfronthosting.co.za>
Message-ID: <581721.76640.qm@web39606.mail.mud.yahoo.com>


unutbu <driabslg at yahoo.com> added the comment:

Let B = the set of all possible times on a particular machine (the machine on which the timeit script is run).
Let x = the minimum of B. 
Then "the lowest value is an upper bound for x".
This is correct, accurate, not an oxymoron.
The above does not refer to an ideal machine, nor does it refer to the fastest machine.

Let's try to agree on a principle: Every statement made in documentation should be correct and have meaningful substance. 

If we can agree on this principle, then I think we will have to agree that the paragraph:

"""
Note: It's tempting to calculate mean and standard deviation from the result vector and report these. However, this is not very useful. In a typical case, the lowest value gives a lower bound for how fast your machine can run the given code snippet; higher values in the result vector are typically not caused by variability in Python's speed, but by other processes interfering with your timing accuracy. So the min() of the result is probably the only number you should be interested in. After that, you should look at the entire vector and apply common sense rather than statistics.
"""

can not stay the way it is.

Here is why:

The correctness of the sentence, "In a typical case, the lowest value gives a lower bound for how fast your machine can run the given code snippet" relies on the presence of the word "typical". But what does typical mean? Here we come to the second half of the principle: the sentence must have meaning and substance.

By relying on the word typical, we reduce the sentence to meaninglessness, because there is no way to endow the word "typical" with meaning without also making the sentence incorrect. For example, if we tried to make the sentence 

"In a typical case, the lowest value gives a lower bound for how fast your machine can run the given code snippet"

mean

"If you run the snippet 100 times, the lowest value would be less than the time in 50 cases"

then you run the risk of making a claim that may not be true.

The critical reader will be forced to simply throw away the entire paragraph as nonsense.

The uncritical reader may believe the output of timeit.repeat is less than or equal to x, which is simply not true. The output of timeit.repeat might not even be near x (whatever near means!) if for example, the script were being run on a server while lots of other processes were being run, or if there was a process with nice priority -19 running simultaneously.

What do you think we should do?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3318>
_______________________________________

From report at bugs.python.org  Fri Sep 12 23:52:51 2008
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 12 Sep 2008 21:52:51 +0000
Subject: [issue3852] kqueue.control requires 2 params while docs say
	max_events (the second) defaults to 0
In-Reply-To: <1221256371.42.0.0336253245305.issue3852@psf.upfronthosting.co.za>
Message-ID: <1221256371.42.0.0336253245305.issue3852@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian <ionel.mc at gmail.com>:

http://docs.python.org/dev/library/select.html#id1

Docs say: "select.control(changelist, max_events=0[, timeout=None])"
However, control requires 2 params ("TypeError: control() takes at least
2 arguments (1 given)").

Also, it should be "kqueue" not "select" (There are 2 more like this
"epoll.fromfd(fd)" in the kqueue section, "select.kqueue(ident,
filter=KQ_FILTER_READ, flags=KQ_ADD, fflags=0, data=0, udata=0)" instead
of "select.kevent( ... ")

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 73144
nosy: georg.brandl, ionel.mc
severity: normal
status: open
title: kqueue.control requires 2 params while docs say max_events (the second) defaults to 0
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3852>
_______________________________________

From report at bugs.python.org  Sat Sep 13 00:06:20 2008
From: report at bugs.python.org (Van Lindberg)
Date: Fri, 12 Sep 2008 22:06:20 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221257180.62.0.493107003569.issue3617@psf.upfronthosting.co.za>


Van Lindberg <van.lindberg at gmail.com> added the comment:

The important part is that we point out the Microsoft redistributables
are subject to Microsoft's restrictions; we don't need to point to a
specific EULA URL. People installing Python will agree to the license
terms as they apply to the different pieces of the binary, and thus
satisfy the PSF's obligation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Sat Sep 13 00:35:03 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 22:35:03 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221258903.89.0.0288077426718.issue3846@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Thanks, Martin.

Commited as r66414.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Sat Sep 13 00:40:49 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 22:40:49 +0000
Subject: [issue3103] sqlite defines a few global symbols.
In-Reply-To: <1213344046.17.0.166963020016.issue3103@psf.upfronthosting.co.za>
Message-ID: <1221259249.22.0.384517348472.issue3103@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Committed in r66412.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3103>
_______________________________________

From report at bugs.python.org  Sat Sep 13 00:45:53 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 22:45:53 +0000
Subject: [issue3853] Windows SQLite DLL should be built with multithreading
	enabled
In-Reply-To: <1221259553.44.0.029573220749.issue3853@psf.upfronthosting.co.za>
Message-ID: <1221259553.44.0.029573220749.issue3853@psf.upfronthosting.co.za>


New submission from Gerhard H?ring <gh at ghaering.de>:

According to http://www.sqlite.org/faq.html#q6 SQLite should be built
with SQLITE_THREADSAFE defined when the library is used in a
multithreaded context.

This doesn't mean that the connection objects can then be shared between
threads. This they cannot. But that if the SQLite API is used from more
than one thread, then the library must be built with the
SQLITE_THREADSAFE option.

----------
assignee: loewis
components: Build, Windows
keywords: easy
messages: 73148
nosy: ghaering, loewis
priority: high
severity: normal
status: open
title: Windows SQLite DLL should be built with multithreading enabled
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3853>
_______________________________________

From report at bugs.python.org  Sat Sep 13 00:49:51 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 22:49:51 +0000
Subject: [issue3854] Document sqlite3 vs. threads
In-Reply-To: <1221259791.8.0.815426917686.issue3854@psf.upfronthosting.co.za>
Message-ID: <1221259791.8.0.815426917686.issue3854@psf.upfronthosting.co.za>


New submission from Gerhard H?ring <gh at ghaering.de>:

In Issue3846, Martin proposed """"[...] I encourage you to review the
entire issue, though, and document
somewhere what promises are made under what conditions. Then a later
review can validate that the promises are really kept."""

Currently it's documented nowhere how the C implementation of the
sqlite3 module handles multithreading issues.

----------
assignee: ghaering
components: Documentation
messages: 73149
nosy: ghaering
priority: normal
severity: normal
status: open
title: Document sqlite3 vs. threads
type: feature request
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3854>
_______________________________________

From report at bugs.python.org  Sat Sep 13 00:51:00 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 22:51:00 +0000
Subject: [issue3846] sqlite3 module: Improved concurrency
In-Reply-To: <1221227876.91.0.178214200062.issue3846@psf.upfronthosting.co.za>
Message-ID: <1221259860.27.0.373093591671.issue3846@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Issue3854 was created for documenting sqlite3 vs. threads.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3846>
_______________________________________

From report at bugs.python.org  Sat Sep 13 00:53:15 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 12 Sep 2008 22:53:15 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1221259995.5.0.69668234676.issue3659@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

I'll look into this.

----------
assignee:  -> ghaering
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Sat Sep 13 01:02:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 12 Sep 2008 23:02:27 +0000
Subject: [issue3852] kqueue.control requires 2 params while docs say
	max_events (the second) defaults to 0
In-Reply-To: <1221256371.42.0.0336253245305.issue3852@psf.upfronthosting.co.za>
Message-ID: <1221260547.81.0.423938817435.issue3852@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee: georg.brandl -> christian.heimes
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3852>
_______________________________________

From report at bugs.python.org  Sat Sep 13 01:03:03 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Sep 2008 23:03:03 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221260583.75.0.948283743472.issue3657@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Sat Sep 13 01:11:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 12 Sep 2008 23:11:07 +0000
Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as
	Python comments
In-Reply-To: <1188181252.17.0.123349198402.issue1034@psf.upfronthosting.co.za>
Message-ID: <1221261067.19.0.928926415115.issue1034@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On the patch:
1. I think both a log message and the comment should be written. The
point needs to be reinforced to users.
2. I'd like to see some tests.
3. Maybe an option to turn the auto comments off?


This is interesting. I'd like to have someone else weigh in before it is
applied though.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1034>
_______________________________________

From report at bugs.python.org  Sat Sep 13 01:50:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 12 Sep 2008 23:50:01 +0000
Subject: [issue3000] 2to3 doesn't handle print(whatever);
	print nor string.* functions
In-Reply-To: <1212070891.46.0.168640128737.issue3000@psf.upfronthosting.co.za>
Message-ID: <1221263401.78.0.260467858256.issue3000@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The print problem was fixed in r66418. The string problem is a duplicate
of #2899.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3000>
_______________________________________

From report at bugs.python.org  Sat Sep 13 01:51:17 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 12 Sep 2008 23:51:17 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1221263477.85.0.314036196808.issue3321@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Sep 13 01:51:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 12 Sep 2008 23:51:20 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1221263480.88.0.324312347449.issue3358@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Nick, it would be nice if your patch had a test.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Sat Sep 13 02:06:46 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 13 Sep 2008 00:06:46 +0000
Subject: [issue1681984] unittest documentation is incomplete
Message-ID: <1221264406.33.0.630289994114.issue1681984@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1681984>
_______________________________________

From report at bugs.python.org  Sat Sep 13 02:16:34 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 13 Sep 2008 00:16:34 +0000
Subject: [issue3288] float.as_integer_ratio method is not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1221264994.62.0.118669333113.issue3288@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

While writing docs for as_integer_ratio(), I noticed a few typos in the
docstrings of the new float methods.  Patch attached.

----------
nosy: +akuchling
Added file: http://bugs.python.org/file11481/float-docstring.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________

From report at bugs.python.org  Sat Sep 13 02:17:04 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 13 Sep 2008 00:17:04 +0000
Subject: [issue3632] use string_print() in gdb
In-Reply-To: <1219322380.25.0.792509106776.issue3632@psf.upfronthosting.co.za>
Message-ID: <1221265024.58.0.0106516737497.issue3632@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I would love to have this patch, along with those of #3631 and #3610,
included in Misc as diffs. This would make it easier to get the improved
functionality in a new development box, besides allowing distributions
to apply them at will.

----------
nosy: +ajaksu2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3632>
_______________________________________

From report at bugs.python.org  Sat Sep 13 02:28:15 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 13 Sep 2008 00:28:15 +0000
Subject: [issue3288] float.as_integer_ratio method is not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1221265695.92.0.831023428882.issue3288@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The attached patch documents the as_integer_ratio method; I'll commit it 
once Barry allows commits.

Added file: http://bugs.python.org/file11482/stdtypes.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________

From report at bugs.python.org  Sat Sep 13 02:46:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 00:46:16 +0000
Subject: [issue3311] block operation on closed socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1221266776.62.0.00131828674748.issue3311@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3311>
_______________________________________

From report at bugs.python.org  Sat Sep 13 02:46:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 00:46:36 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1221266796.95.0.504450118965.issue3321@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Sep 13 03:00:42 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 13 Sep 2008 01:00:42 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1221267642.27.0.539260361813.issue3321@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Without someone offering some windows help, I won't be able to do a patch. 
My windows fu is lacking.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Sep 13 04:00:01 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 13 Sep 2008 02:00:01 +0000
Subject: [issue687648] classic division in demos/ directory
Message-ID: <1221271201.45.0.291954050195.issue687648@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Changes to curses/ committed in rev. 66424.

Changes to threading/ committed in rev. 66425.

Changes to Demo/classes/Dates.py committed in rev. 66426.

Changes to md5driver/ committed in rev. 66427.

Rest of the changes committed in rev. 66428.

Robert, thank you very much for your patch!

----------
assignee:  -> akuchling
nosy: +akuchling
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue687648>
_______________________________________

From report at bugs.python.org  Sat Sep 13 04:04:42 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 13 Sep 2008 02:04:42 +0000
Subject: [issue3850] find_recursion_limit.py is broken
In-Reply-To: <1221250015.74.0.0718109598315.issue3850@psf.upfronthosting.co.za>
Message-ID: <1221271482.17.0.648592552301.issue3850@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The patch seems fine to me.

The docstring at the top of the file says:

It ends when Python causes a segmentation fault because the limit is
too high.  On platforms like Mac and Windows, it should exit with a
MemoryError.

On my Macbook, it segfaults; perhaps that docstring applied only 
to MacOS 9?

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3850>
_______________________________________

From report at bugs.python.org  Sat Sep 13 04:12:32 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 13 Sep 2008 02:12:32 +0000
Subject: [issue3288] float.as_integer_ratio method is not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1221271952.66.0.623203783336.issue3288@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Patch committed in rev. 66435.

Do we want to mention it in the tutorial?  If not,
this issue could now be closed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________

From report at bugs.python.org  Sat Sep 13 04:29:21 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Sep 2008 02:29:21 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221272961.79.0.119887468587.issue3825@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Atomic groups and possessive quantifiers appear to be relatively new:
http://en.wikipedia.org/wiki/Regular_expressions
for instance, has no mention of either that I found.

http://www.regular-expressions.info/atomic.html
http://www.regular-expressions.info/possessive.html
seemed pretty clear to me.  If they accurately describe what you are
adding, they might be a starting point for the needed new manual
sections.  They should include a warning about carefully ordering
alternatives lest one prune too much.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 13 04:32:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 02:32:50 +0000
Subject: [issue2366] Fixer for new metaclass syntax is needed
In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za>
Message-ID: <1221273170.72.0.773049162847.issue2366@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Added in r66438.

One open issue is that the comment is lost in the following example:

class X:
    __metaclass__ = Meta # Spam

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2366>
_______________________________________

From report at bugs.python.org  Sat Sep 13 05:57:31 2008
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 13 Sep 2008 03:57:31 +0000
Subject: [issue3855] Windows installation did not work; tried on two machines
In-Reply-To: <1221278251.1.0.519873479487.issue3855@psf.upfronthosting.co.za>
Message-ID: <1221278251.1.0.519873479487.issue3855@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I installed 3.0b3 using the Windows MSI installer on two machines, one
running 32-bit Windows XP Professional on a 64-bit AMD processor with
Python 2.5 already installed, and another a Parallels Desktop on an
Intel MacBook running Windows XP Professional with no previous Python
installation.  Both failed to run either python or pythonw, saying "This
application has failed to start because the application configuration is
incorrect. Reinstalling the application may fix the problem."

Building 3.0b3 on my MacBook from source and doing an altinstall runs fine.

I'm sorry if this is a ridiculous submission, but I have done plenty of
this sort of thing on both platforms before and am just stumped, and I
have a fairly urgent need to try something on Windows.

----------
components: Installation
messages: 73164
nosy: MLModel
severity: normal
status: open
title: Windows installation did not work; tried on two machines
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3855>
_______________________________________

From report at bugs.python.org  Sat Sep 13 06:14:47 2008
From: report at bugs.python.org (Tim Peters)
Date: Sat, 13 Sep 2008 04:14:47 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221279287.54.0.322756532803.issue3657@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

BTW, note that the Title of this issue is misleading: 
pickle.whichmodule() uses object identity ("is":

    if ...  getattr(module, funcname, None) is func:

) to determine whether the given function object is supplied by a
module, so it's /not/ the case that a "wrong" function can be pickled. 
The worst that can happen is that the correct function is pickled but
obtained from a possibly surprising module.  For example, random.random
can't be confused with any other function named "random".

I expect this is why nobody has ever complained about it:  unless you're
looking at the strings embedded in the pickle GLOBAL opcode, it's
unlikely to have a visible consequence.

It would still be nice if pickle could identify "the most natural"
module for a given function, but hard to make a case that doing so would
be much more than /just/ "nice".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Sat Sep 13 06:15:19 2008
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 13 Sep 2008 04:15:19 +0000
Subject: [issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3
In-Reply-To: <1221279319.19.0.623858705455.issue3856@psf.upfronthosting.co.za>
Message-ID: <1221279319.19.0.623858705455.issue3856@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

IDLE fails to start on my MacBook [OS 10.5, v2.6b3 and v3.0b3, built
from source].  At the call to delete in the backtrace below index1 is 1
and index2 is 'end'.

python2.6 lib/python2.6/idlelib/idle.py
Traceback (most recent call last):
  File "lib/python2.6/idlelib/idle.py", line 21, in <module>
    idlelib.PyShell.main()
  File "/usrlocal/lib/python2.6/idlelib/PyShell.py", line 1396, in main
    shell = flist.open_shell()
  File "/usrlocal/lib/python2.6/idlelib/PyShell.py", line 275, in open_shell
    self.pyshell = PyShell(self)
  File "/usrlocal/lib/python2.6/idlelib/PyShell.py", line 816, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/usrlocal/lib/python2.6/idlelib/OutputWindow.py", line 16, in
__init__
    EditorWindow.__init__(self, *args)
  File "/usrlocal/lib/python2.6/idlelib/EditorWindow.py", line 234, in
__init__
    self.update_recent_files_list()
  File "/usrlocal/lib/python2.6/idlelib/EditorWindow.py", line 763, in
update_recent_files_list
    menu.delete(1, END)  # clear, and rebuild:
  File "/usrlocal/lib/python2.6/lib-tk/Tkinter.py", line 2665, in delete
    for i in range(self.index(index1), self.index(index2)+1):
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

----------
components: IDLE
messages: 73166
nosy: MLModel
severity: normal
status: open
title: IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3
type: crash
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3856>
_______________________________________

From report at bugs.python.org  Sat Sep 13 08:01:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 13 Sep 2008 06:01:00 +0000
Subject: [issue3855] Windows installation did not work; tried on two machines
In-Reply-To: <1221278251.1.0.519873479487.issue3855@psf.upfronthosting.co.za>
Message-ID: <1221285660.2.0.779565194799.issue3855@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of issue3820.

If you need to try something now, try 3.0b2.

----------
nosy: +loewis
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3855>
_______________________________________

From report at bugs.python.org  Sat Sep 13 10:16:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 13 Sep 2008 08:16:31 +0000
Subject: [issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be
	installed on one machine
In-Reply-To: <1221106076.33.0.246620485581.issue3833@psf.upfronthosting.co.za>
Message-ID: <1221293791.14.0.791013716362.issue3833@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the reminder. This is now fixed in r66439 and r66440, as well
as 2.6rc1 (although I haven't actually tested it, due to lack of access
to an AMD64 system right now - please report whether it works).

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3833>
_______________________________________

From report at bugs.python.org  Sat Sep 13 10:16:51 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 13 Sep 2008 08:16:51 +0000
Subject: [issue3857] ImportError: No module named test.test_support
In-Reply-To: <1221293811.9.0.758930333034.issue3857@psf.upfronthosting.co.za>
Message-ID: <1221293811.9.0.758930333034.issue3857@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

The following 2 line program fails under Python 2.6rc1: 
Python 2.6b3 (r26b3:66303, Sep  8 2008, 13:45:13) [MSC v.1500 32 bit
(Intel)] on win32

as downloaded today (2008-09-13):

#---- start program ---
import urllib
fh = urllib.urlopen('http://bugs.python.org/')
#---- end program ---

with the messages:
Traceback (most recent call last):
  File "bug.py", line 2, in <module>
    fh = urllib.urlopen('http://bugs.python.org/')
  File "d:\Python26\lib\urllib.py", line 87, in urlopen
    return opener.open(url)
  File "d:\Python26\lib\urllib.py", line 203, in open
    return getattr(self, name)(url)
  File "d:\Python26\lib\urllib.py", line 285, in open_http
    import httplib
  File "d:\Python26\lib\httplib.py", line 72, in <module>
    from test.test_support import catch_warning
ImportError: No module named test.test_support

The program works fine on Python 2.5

----------
components: Library (Lib)
messages: 73169
nosy: wplappert
severity: normal
status: open
title: ImportError: No module named test.test_support
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3857>
_______________________________________

From report at bugs.python.org  Sat Sep 13 10:41:51 2008
From: report at bugs.python.org (Jimmy Retzlaff)
Date: Sat, 13 Sep 2008 08:41:51 +0000
Subject: [issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be
	installed on one machine
In-Reply-To: <1221106076.33.0.246620485581.issue3833@psf.upfronthosting.co.za>
Message-ID: <1221295311.25.0.979596667631.issue3833@psf.upfronthosting.co.za>


Jimmy Retzlaff <jimmy at retzlaff.com> added the comment:

Works great on 2.6rc1. Thanks!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3833>
_______________________________________

From report at bugs.python.org  Sat Sep 13 11:16:32 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 13 Sep 2008 09:16:32 +0000
Subject: [issue3857] ImportError: No module named test.test_support
In-Reply-To: <1221293811.9.0.758930333034.issue3857@psf.upfronthosting.co.za>
Message-ID: <1221297392.56.0.406152022999.issue3857@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

OK, by now I know exactly what the problem is: The Windows installer
allows you the option of DESELECTING the "Test Suite". Initially I
deselected the Test Suite because I thought I do not need it. But this
is wrong. urllib loads test.test_support. 

In my opinion you must not be able to deselect a feature if this feature
is needed for the proper running of Python.

PS.: Forget all the bits about "Python 2.6b3 (r26b3:66303, Sep  8 2008,
13:45:13) [MSC v.1500 32 bit (Intel)] on win32": I just was too fast. I
have verified the bug now with proper 2.6rc1: Python 2.6rc1
(r26rc1:66438, Sep 13 2008, 09:20:38) [MSC v.1500 32 bit (Intel)].

Thanks a lot for the wonderful programming language Python!!

----------
components: +Windows -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3857>
_______________________________________

From report at bugs.python.org  Sat Sep 13 11:36:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Sep 2008 09:36:05 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1221298565.57.0.0651033220947.issue3321@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Note that Windows does not crash in such cases:

>>> import socket, _multiprocessing
>>> obj = _multiprocessing.Connection(44977608)
>>> obj.poll()
IOError: [Errno 10038] An operation was attempted on something that is
not a socket

>>> s = socket.socket()
>>> obj = _multiprocessing.Connection(s.fileno())
>>> obj.poll()
False
>>> s.close()
>>> obj.poll()
IOError: [Errno 10038] An operation was attempted on something that is
not a socket


So some "#ifndef MS_WINDOWS" should be enough...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Sep 13 11:53:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Sep 2008 09:53:41 +0000
Subject: [issue3857] ImportError: No module named test.test_support
In-Reply-To: <1221293811.9.0.758930333034.issue3857@psf.upfronthosting.co.za>
Message-ID: <1221299621.37.0.538120659165.issue3857@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I just installed python 2.6rc1, and I don't get the error at all.
are you sure that you did not install a 2.6b3 afterwards?

The content of your file d:\Python26\lib\httplib.py does not match with
mine, suggest a version mismatch.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3857>
_______________________________________

From report at bugs.python.org  Sat Sep 13 12:53:25 2008
From: report at bugs.python.org (Ralph Corderoy)
Date: Sat, 13 Sep 2008 10:53:25 +0000
Subject: [issue3845] memory access before short string when checking suffix
In-Reply-To: <1221221516.48.0.283023383502.issue3845@psf.upfronthosting.co.za>
Message-ID: <1221303205.97.0.935379030995.issue3845@psf.upfronthosting.co.za>


Changes by Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:


----------
nosy: +ralph.corderoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3845>
_______________________________________

From report at bugs.python.org  Sat Sep 13 12:59:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 10:59:09 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1221279287.54.0.322756532803.issue3657@psf.upfronthosting.co.za>
Message-ID: <1221303546.5613.1.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I expect this is why nobody has ever complained about it:  unless you're
> looking at the strings embedded in the pickle GLOBAL opcode, it's
> unlikely to have a visible consequence.

Well, it may have a consequence if pickle picks the "random" function
from a third-party module named "foobar", and you give the pickle to a
friend and expect it to work for him while he hasn't installed module
"foobar".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Sat Sep 13 13:17:16 2008
From: report at bugs.python.org (John J Lee)
Date: Sat, 13 Sep 2008 11:17:16 +0000
Subject: [issue3858] make install tries to install files outside of --prefix
In-Reply-To: <1221304636.86.0.265861415772.issue3858@psf.upfronthosting.co.za>
Message-ID: <1221304636.86.0.265861415772.issue3858@psf.upfronthosting.co.za>


New submission from John J Lee <jjlee at users.sourceforge.net>:

./configure --prefix=DIR && make && make install tries to install files
in directories outside of DIR.  This happens both with trunk (r66412)
and 2.6b3.  This is a problem for users of GNU stow, for example.  I
know that certainly this worked fairly recently on the py3k branch, for
example, and I believe it also used to work on trunk.

I'm not certain whether in this particular run the --prefix directory
existed or not prior to make install, but I certainly get essentially
the same failure regardless of whether that directory exists.

~/src/Python-2.6b3$ ./configure  --prefix=/home/john/stow/python26b3
...
~/src/Python-2.6b3$ make
...
~/src/Python-2.6b3$ make install
/usr/bin/install -c python-config
/home/john/stow/python26b3/bin/python2.6-config
rm python-config
./python -E ./setup.py install \
	   	--prefix=/home/john/stow/python26b3 \
		--install-scripts=/home/john/stow/python26b3/bin \
		--install-platlib=/home/john/stow/python26b3/lib/python2.6/lib-dynload \
		--root=/
running install
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers

Failed to find the necessary bits to build these modules:
_bsddb             _tkinter           bsddb185        
dbm                gdbm               sunaudiodev     
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.

running build_scripts
running install_lib
copying build/lib.linux-i686-2.6/_random.so ->
/home/john/lib/python2.6/site-packages
error: could not delete
'/home/john/lib/python2.6/site-packages/_random.so': Permission denied
make: *** [sharedinstall] Error 1

----------
messages: 73175
nosy: jjlee
severity: normal
status: open
title: make install tries to install files outside of --prefix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3858>
_______________________________________

From report at bugs.python.org  Sat Sep 13 13:31:19 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 11:31:19 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1221305479.23.0.100207430016.issue3766@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, obviously. Although adding it to the client socket did make no
> difference after I had already done so for the server. Still
> communication is too slow by orders of magnitude. (Sorry for pointing
> this out again)

Well, if this precise use case is really important for you, I suggest
using Wireshark (or any other packet analyzer) to see what happens in
terms of latency between packets over the wire.

Something else: try replacing "localhost" with "127.0.0.1", perhaps your
DNS resolution eats a lot of time.

> I would greatly appreciate any help on the subject. How do *BSD
> sockets differ from Linux sockets and what do I do to make things
> faster.

I don't know, but I suspect the difference is more in the TCP stack
implementation than in the sockets layer.

In any case, I'm gonna close this bug, as this is very likely not a
Python problem. Please ask further questions on comp.lang.python, lots
of people there may help you :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Sat Sep 13 13:31:45 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 11:31:45 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1221305505.33.0.710846881983.issue3766@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Sat Sep 13 13:33:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 11:33:36 +0000
Subject: [issue3858] make install tries to install files outside of --prefix
In-Reply-To: <1221304636.86.0.265861415772.issue3858@psf.upfronthosting.co.za>
Message-ID: <1221305616.53.0.382045033705.issue3858@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Installation
priority:  -> critical
type:  -> behavior
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3858>
_______________________________________

From report at bugs.python.org  Sat Sep 13 14:02:20 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 13 Sep 2008 12:02:20 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1221307340.84.0.196788789146.issue3321@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I thought socket handle on BeOS is not file descripter neighter. (I'm
not sure BeOS is still supported or not)

>Another solution would be to reuse code from Modules/selectmodule.c.

You mean this code?

if (v < 0 || v >= FD_SETSIZE) {
	PyErr_SetString(PyExc_ValueError,
		    "filedescriptor out of range in select()");
	goto finally;
}

Cygwin's thread is somewhat troublesome, so I'm not sure I can test this
issue on cygwin but, (I'm now building python --with-threads) if clash
happens in conn_poll(_multiprocessing/connection.h)'s FD_SET, I think
this kind of check is needed... (At least safer)

----------
keywords:  -needs review
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Sep 13 14:08:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 12:08:37 +0000
Subject: [issue3850] find_recursion_limit.py is broken
In-Reply-To: <1221271482.17.0.648592552301.issue3850@psf.upfronthosting.co.za>
Message-ID: <1221307714.5613.5.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On my Macbook, it segfaults; perhaps that docstring applied only 
> to MacOS 9?

Well, I just tried under Windows and the interpreter neither segfaults
nor prints a MemoryError, it aborts silently. I guess the comment is
either out of date or too optimistic about a supposedly deterministic
behaviour of C stack overflows on those platforms.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3850>
_______________________________________

From report at bugs.python.org  Sat Sep 13 14:10:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 13 Sep 2008 12:10:33 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1221307833.05.0.324647156923.issue3321@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Sep 13 14:47:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Sep 2008 12:47:56 +0000
Subject: [issue3853] Windows SQLite DLL should be built with multithreading
	enabled
In-Reply-To: <1221259553.44.0.029573220749.issue3853@psf.upfronthosting.co.za>
Message-ID: <1221310076.04.0.288437201365.issue3853@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It seems that it is already the case. On Windows, a one-big-source-file
version of sqlite is used, fetched from
http://svn.python.org/projects/external/sqlite-3.5.9 
(see Tools/buildbot/external-common.bat)

and in this file, SQLITE_THREADSAFE is always set to 1, unless you
explicitely compile with "THREADSAFE=0".

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3853>
_______________________________________

From report at bugs.python.org  Sat Sep 13 15:06:40 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 13 Sep 2008 13:06:40 +0000
Subject: [issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3
In-Reply-To: <1221279319.19.0.623858705455.issue3856@psf.upfronthosting.co.za>
Message-ID: <1221311200.34.0.717108733758.issue3856@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This bug was fixed after b3 was released (r65971). You should retry it
using python 2.6rc1 or update your sources for py3k.

----------
nosy: +gpolo
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3856>
_______________________________________

From report at bugs.python.org  Sat Sep 13 15:35:50 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 13 Sep 2008 13:35:50 +0000
Subject: [issue3851] IDLE: Pressing "Home" on Windows places cursor before
	">>>" instead of after. Solution offered.
In-Reply-To: <1221250835.7.0.322524713176.issue3851@psf.upfronthosting.co.za>
Message-ID: <1221312950.55.0.173961375802.issue3851@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Did you mean "(event.state & 10) != 0" instead of "(event.state & 1) !=
0" ? Otherwise it won't work when event.state is 8.

I'm attaching a patch that does the same thing that is done on py3k
branch and python-trunk.

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file11483/issue_3851.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3851>
_______________________________________

From report at bugs.python.org  Sat Sep 13 15:35:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Sep 2008 13:35:51 +0000
Subject: [issue3859] test_sys.Sizeof fails on win64
In-Reply-To: <1221312951.19.0.765623147021.issue3859@psf.upfronthosting.co.za>
Message-ID: <1221312951.19.0.765623147021.issue3859@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

the "AMD64 W2k8 3.0" buildbot always fail test_sys:

...
    check(range(66000), size(h + '3l'))
...
AssertionError: wrong size for <class 'range'>: got 56, expected 48

The previous line of the test is:
    check(range(1), size(h + '3P'))
(win64 is the only platform where 'P' has a different size than 'l')
Why are there two versions of the structure? There is only one range 
object.

I suggest to replace the failing line with:
    check(range(66000), size(h + '3P'))
to properly reflect the three PyObject* of the structure.

----------
components: Tests
keywords: needs review
messages: 73181
nosy: amaury.forgeotdarc
priority: critical
severity: normal
status: open
title: test_sys.Sizeof fails on win64
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3859>
_______________________________________

From report at bugs.python.org  Sat Sep 13 15:39:55 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 13 Sep 2008 13:39:55 +0000
Subject: [issue3698] incompatible arguments in warning formatting for idle
In-Reply-To: <1219840200.32.0.559754862412.issue3698@psf.upfronthosting.co.za>
Message-ID: <1221313195.64.0.023815894895.issue3698@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Duplicate of issue3391

----------
nosy: +gpolo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3698>
_______________________________________

From report at bugs.python.org  Sat Sep 13 15:40:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 13:40:07 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221313207.39.0.715971515656.issue3825@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, the patch must be pretty incomplete, since there are almost
no changes to _sre.c. Am I missing something?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 13 15:40:23 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 13:40:23 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1221313223.16.0.734497020467.issue2636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See also #3825.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Sep 13 15:53:32 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 13 Sep 2008 13:53:32 +0000
Subject: [issue1482122] Shift+Backspace exhibits odd behavior
Message-ID: <1221314012.64.0.601548434076.issue1482122@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've just found some discussion about the problem here:

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/577df9cfa39e6688/49484ac512f13693?lnk=gst&q=shift+backspace#49484ac512f13693

Hope this is enough to close this issue, as it is not a tkinter neither
idle issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482122>
_______________________________________

From report at bugs.python.org  Sat Sep 13 16:07:50 2008
From: report at bugs.python.org (unutbu)
Date: Sat, 13 Sep 2008 14:07:50 +0000
Subject: [issue3318] Documentation: timeit: "lower bound" should read "upper
	bound"
In-Reply-To: <1220992931.31.0.275267255012.issue3318@psf.upfronthosting.co.za>
Message-ID: <455070.73671.qm@web39602.mail.mud.yahoo.com>


unutbu <driabslg at yahoo.com> added the comment:

Georg, please forgive me. I thought a sample size of 3 was much too small to make a claim about the typical case, but it appears after doing a computer experiment that I was wrong:

#!/usr/bin/env python
from __future__ import division
import timeit
import random

repeat=100
num=100

def test_func():
    l=1
    for idx in range(10000):
        l=l*idx

timer=timeit.Timer('test_func()','from __main__ import test_func')

data=timer.repeat(repeat=repeat,number=num)

def test_timer():
    sample=random.sample(data,3)
    minval=min(sample)
    onerun=random.choice(data)
    return 1 if minval<onerun else 0

successes=[test_timer() for idx in range(repeat)]
print "Those runs for which the claim in the documentation is true:",successes
s=sum(successes)
l=len(successes)
print "probability that the claim is true: %s/%s = %s"%(s,l,s/l)

Returns:

% timeit-statistics.py
Those runs for which the claim in the documentation is true: [0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 0, 1]
probability that the claim is true: 74/100 = 0.74

I'm satisfied the documentation is correct, and I'm really sorry for wasting your time.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3318>
_______________________________________

From report at bugs.python.org  Sat Sep 13 16:19:59 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 13 Sep 2008 14:19:59 +0000
Subject: [issue3638] tkinter.mainloop() is meanling less and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1221315599.39.0.620941080133.issue3638@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Looks fine to me. 
But I can't see the reason to keep this as a module function in python
2.6 so I would remove it there too.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Sep 13 16:22:24 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 13 Sep 2008 14:22:24 +0000
Subject: [issue3638] tkinter.mainloop() is meaningless and crash: remove it
In-Reply-To: <1219356014.43.0.144260212562.issue3638@psf.upfronthosting.co.za>
Message-ID: <1221315744.21.0.592278116712.issue3638@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
title: tkinter.mainloop() is meanling less and crash: remove it -> tkinter.mainloop() is meaningless and crash: remove it

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3638>
_______________________________________

From report at bugs.python.org  Sat Sep 13 17:16:46 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Sep 2008 15:16:46 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221319006.14.0.06717561522.issue3825@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


Removed file: http://bugs.python.org/file11451/regex_2.5.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 13 17:20:47 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Sep 2008 15:20:47 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221319247.41.0.166381288765.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Corrected the diff file, again. :-(

The atomic groups and possessive quantifiers are as described at
http://www.regular-expressions.info.

Added file: http://bugs.python.org/file11484/regex_2.5.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 13 17:26:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 15:26:28 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221319588.58.0.928157466763.issue3825@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy:  -benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 13 17:30:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 15:30:46 +0000
Subject: [issue2369] Fixer for new integer literals are needed
In-Reply-To: <1205784031.99.0.585423038669.issue2369@psf.upfronthosting.co.za>
Message-ID: <1221319846.62.0.267904690638.issue2369@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

fix_numliterals has been around for a while now. :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2369>
_______________________________________

From report at bugs.python.org  Sat Sep 13 17:35:56 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sat, 13 Sep 2008 15:35:56 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221320156.06.0.627973854298.issue3825@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

A bit more information on the changes to the core engine that are
responsible for the 2x speedup (on what?) would be nice to have, I think
(especially since you seem to have removed the KMP prefix scanner).

(Isn't there a RE benchmark suite somewhere under tests?)

----------
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 13 17:44:12 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 13 Sep 2008 15:44:12 +0000
Subject: [issue3321] _multiprocessing.Connection() doesn't check handle
In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za>
Message-ID: <1221320652.62.0.624713381809.issue3321@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've implemented "another solution". test_open() in
test_multithreading.patch won't pass though.... It'll raise error in
conn.poll() not in constructor.

$ ./dummy.exe b.py
Traceback (most recent call last):
  File "b.py", line 6, in <module>
    conn.poll()
IOError: [Errno 9] Bad file descriptor

test_operations() will pass.

Added file: http://bugs.python.org/file11485/another_solution.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3321>
_______________________________________

From report at bugs.python.org  Sat Sep 13 19:14:53 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 13 Sep 2008 17:14:53 +0000
Subject: [issue3857] ImportError: No module named test.test_support
In-Reply-To: <1221293811.9.0.758930333034.issue3857@psf.upfronthosting.co.za>
Message-ID: <1221326093.27.0.392543235986.issue3857@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

Please close this issue. Between 2.6b3 and 2.6rc1 Lib/httplib.py has
been changed. Sorry about the confusion!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3857>
_______________________________________

From report at bugs.python.org  Sat Sep 13 19:16:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 17:16:21 +0000
Subject: [issue3857] ImportError: No module named test.test_support
In-Reply-To: <1221293811.9.0.758930333034.issue3857@psf.upfronthosting.co.za>
Message-ID: <1221326181.9.0.762369759881.issue3857@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3857>
_______________________________________

From report at bugs.python.org  Sat Sep 13 19:34:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 17:34:18 +0000
Subject: [issue3859] test_sys.Sizeof fails on win64
In-Reply-To: <1221312951.19.0.765623147021.issue3859@psf.upfronthosting.co.za>
Message-ID: <1221327258.66.0.978067105531.issue3859@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> schuppenies
nosy: +schuppenies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3859>
_______________________________________

From report at bugs.python.org  Sat Sep 13 21:29:02 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 13 Sep 2008 19:29:02 +0000
Subject: [issue3860] GzipFile and BZ2File should support context manager
	protocol
In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za>
Message-ID: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

When you've become used to writing

with open("xzy", "w") as f: 

it's strange when it doesn't work for gzip.open or bz2.BZ2File.
Or is there a reason for them not being context managers?

----------
components: Library (Lib)
messages: 73194
nosy: hagen
severity: normal
status: open
title: GzipFile and BZ2File should support context manager protocol
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3860>
_______________________________________

From report at bugs.python.org  Sat Sep 13 21:32:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 19:32:07 +0000
Subject: [issue3860] GzipFile and BZ2File should support context manager
	protocol
In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za>
Message-ID: <1221334327.96.0.845705613722.issue3860@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3860>
_______________________________________

From report at bugs.python.org  Sat Sep 13 21:33:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 13 Sep 2008 19:33:37 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221334417.9.0.596359099178.issue3617@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Van, your recommendation is much appreciated. I'll add your text to the
LICENSE file of the next release candidates.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Sat Sep 13 22:31:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 20:31:48 +0000
Subject: [issue3850] find_recursion_limit.py is broken
In-Reply-To: <1221250015.74.0.0718109598315.issue3850@psf.upfronthosting.co.za>
Message-ID: <1221337908.92.0.431107247824.issue3850@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Bug fixed and module comments updated in r66457.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3850>
_______________________________________

From report at bugs.python.org  Sat Sep 13 23:10:47 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Sep 2008 21:10:47 +0000
Subject: =?utf-8?q?[issue3531]_file_read_preallocs_'size'_bytes_which_can_cause_memory=09problems?=
In-Reply-To: <1218248985.75.0.478147960205.issue3531@psf.upfronthosting.co.za>
Message-ID: <1221340247.79.0.181373166862.issue3531@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3531>
_______________________________________

From report at bugs.python.org  Sat Sep 13 23:33:05 2008
From: report at bugs.python.org (Neil Hodgson)
Date: Sat, 13 Sep 2008 21:33:05 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221341585.75.0.557592984222.issue3617@psf.upfronthosting.co.za>


Neil Hodgson <nyamatongwe at users.sourceforge.net> added the comment:

The recommended addition includes the 'excluded license' section which 
appears unnecessary as Python does not distribute any source code 
redistributables, only the .DLL file which is a binary executable. 
Including this is likely to confuse those who wish to use the GPL when 
distributing projects which include Python since the license is trying 
to limit their redistributing something they will not be able to find 
and so remove from Python.

----------
nosy: +nyamatongwe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Sat Sep 13 23:38:23 2008
From: report at bugs.python.org (Van Lindberg)
Date: Sat, 13 Sep 2008 21:38:23 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221341903.29.0.511471243046.issue3617@psf.upfronthosting.co.za>


Van Lindberg <van.lindberg at gmail.com> added the comment:

Neil, you are right. I was thinking about linking to the binary dll
(which some people think might impose licensing restrictions under some
circumstances), but the text does refer to the source code.

As Python does not distribute any source code from Microsoft, it is
better to remove the last restriction identified by Neil from the
recommended text (and fix the grammar accordingly).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Sat Sep 13 23:56:52 2008
From: report at bugs.python.org (maix)
Date: Sat, 13 Sep 2008 21:56:52 +0000
Subject: [issue3843] hexadecimal, not decimal
In-Reply-To: <1221168310.48.0.733026524014.issue3843@psf.upfronthosting.co.za>
Message-ID: <1221343012.25.0.456420508688.issue3843@psf.upfronthosting.co.za>


maix <mailmaix at gmail.com> added the comment:

I'll just reuse that since it's such a little thing (complain if that's
not okay then I won't do again :) ):

On http://docs.python.org/dev/whatsnew/2.6.html , it says
> The bsddb module also has a new maintainer, Jes|uacute|s Cea
Should be a ? I think :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3843>
_______________________________________

From report at bugs.python.org  Sun Sep 14 00:15:32 2008
From: report at bugs.python.org (John J Lee)
Date: Sat, 13 Sep 2008 22:15:32 +0000
Subject: [issue3858] make install tries to install files outside of --prefix
In-Reply-To: <1221304636.86.0.265861415772.issue3858@psf.upfronthosting.co.za>
Message-ID: <1221344132.18.0.099532024796.issue3858@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

OK, this was because I had a .pydistutils.cfg file containing the
following (ironically, put there following somebody's recipe for
installing setuptools packages using stow):

[install]
install_lib=~/lib/python$py_version_short/site-packages
install_scripts=~/bin
 
[easy_install]
site_dirs=~/lib/python$py_version_short/site-packages

Removing that file, make install no longer tries to install files
outside of the directory passed to --prefix

So this bug is not valid, and I don't think there's any regression.

There's probably another bug about making it awkward to invent a
consistent way of installing Python software using tools like stow, but
I'm not sure whether that bug lies with Python or with setuptools, or both.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3858>
_______________________________________

From report at bugs.python.org  Sun Sep 14 00:55:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Sep 2008 22:55:21 +0000
Subject: [issue3843] hexadecimal, not decimal
In-Reply-To: <1221168310.48.0.733026524014.issue3843@psf.upfronthosting.co.za>
Message-ID: <1221346521.39.0.901025443485.issue3843@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

No problem! Fixed in r66458.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3843>
_______________________________________

From report at bugs.python.org  Sun Sep 14 02:34:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Sep 2008 00:34:44 +0000
Subject: [issue3858] make install tries to install files outside of --prefix
In-Reply-To: <1221304636.86.0.265861415772.issue3858@psf.upfronthosting.co.za>
Message-ID: <1221352484.02.0.289168378656.issue3858@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

OK, thanks for the report anyway :)

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3858>
_______________________________________

From report at bugs.python.org  Sun Sep 14 03:25:12 2008
From: report at bugs.python.org (Mike Auty)
Date: Sun, 14 Sep 2008 01:25:12 +0000
Subject: [issue3861] distutils CCompiler._compile doesn't require lang keyword
	argument
In-Reply-To: <1221355512.51.0.884487193093.issue3861@psf.upfronthosting.co.za>
Message-ID: <1221355512.51.0.884487193093.issue3861@psf.upfronthosting.co.za>


New submission from Mike Auty <mike.auty at gmail.com>:

I'm testing out Python-2.6b3 and attempted to build wxpython-2.8.8.1. 
It creates a subclassed CCompiler (MyUnixCCompiler), which overrides the
_compile function, with the following signature:

_compile(self, obj, src, ext, cc_args, extra_postargs, pp_opts)

This is the same function signature found in distutils/ccompiler.py
(line 705).  However, it gets called further up in
distutils/ccompiler.py (at line 699) with a lang keyword argument. 
Since **kwargs or similar isn't included in the signature, it raises an
exception.

The best solution seems like removing the lang=lang keyword argument on
line 669, but it's not clear why this was added or what consumers use
this new addition.  Changing the signature would be an interface break
and require old code to be updated, but might allow for a **kwargs entry
that would allow for future additions.

Please let me know if you need any further information...  5:)

----------
components: Distutils
messages: 73203
nosy: mike.auty at gmail.com
severity: normal
status: open
title: distutils CCompiler._compile doesn't require lang keyword argument
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3861>
_______________________________________

From report at bugs.python.org  Sun Sep 14 03:30:19 2008
From: report at bugs.python.org (Reed O'Brien)
Date: Sun, 14 Sep 2008 01:30:19 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>


New submission from Reed O'Brien <reed at reedobrien.com>:

or in FreeBSD?

2.6rc1 and 3.0b3 both fail test_array on FreeBSD7 amd64

test_array passes in 2.5.2 on the same machine but fails test_list the
same as test_array...

*** Signal 9

----------
components: Tests
messages: 73204
nosy: robrien
severity: normal
status: open
title: test_array fails on FreeBSD7 amd64
type: crash
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Sun Sep 14 04:22:00 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Sun, 14 Sep 2008 02:22:00 +0000
Subject: [issue3859] test_sys.Sizeof fails on win64
In-Reply-To: <1221312951.19.0.765623147021.issue3859@psf.upfronthosting.co.za>
Message-ID: <1221358920.4.0.633999286273.issue3859@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

You are right, it should be '3P'. When merging to py3k I changed the
previous line, but not the one causing trouble.

----------
keywords: +patch
Added file: http://bugs.python.org/file11486/test_sys.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3859>
_______________________________________

From report at bugs.python.org  Sun Sep 14 05:25:56 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 14 Sep 2008 03:25:56 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221362756.25.0.437604640017.issue3617@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Sun Sep 14 10:55:48 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Sep 2008 08:55:48 +0000
Subject: [issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error
In-Reply-To: <1213472808.51.0.731079646072.issue3111@psf.upfronthosting.co.za>
Message-ID: <1221382548.78.0.0733914020509.issue3111@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Setting this to a release blocker, because it is affecting Neal's
automated execution of the regression test suite with a debug build.

----------
nosy: +ncoghlan
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3111>
_______________________________________

From report at bugs.python.org  Sun Sep 14 10:58:58 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Sep 2008 08:58:58 +0000
Subject: [issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error
In-Reply-To: <1213472808.51.0.731079646072.issue3111@psf.upfronthosting.co.za>
Message-ID: <1221382738.25.0.60946094018.issue3111@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Scratch that - it's more likely to be Neal's setup which is at fault,
which I will be questioning on python-dev shortly (there are 3 other
tests which are failing/getting skipped in Neal's regression test suite)

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3111>
_______________________________________

From report at bugs.python.org  Sun Sep 14 12:12:26 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Sun, 14 Sep 2008 10:12:26 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1221387146.31.0.0417653564604.issue3690@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

As I understood the long object allocation it is implemented as
"PyObject_MALLOC(sizeof(PyVarObject) + size*sizeof(digit))" to avoid
this allocation of extra 2 bytes. So from my understanding, the number 0
allocates memory for the reference count, type, and ob_size, whereas any
other number allocates this plus additional memory required by the
number of digits.

Looking at bool objects in Py3k, arn't they fixed-sized memory-wise,
always allocating the the padded size of _longobject?

> In any case, I also think this doesn't matter much either way. 
Why do you think so?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Sun Sep 14 12:56:58 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 10:56:58 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221389819.0.0.202548967739.issue3862@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

2.6rc1 test_array passes on FreeBSD 6.3 i386.  I don't have a 7.0 box
(either i386 or amd64) accessible at the moment to cross check.

Can you run the test on its own in verbose mode to get a bit more of an
idea where its blowing up? - ie:

user at box$ ./python -E -tt Lib/test/regrtest.py -v test_array

from the build directory.

----------
nosy: +aimacintyre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Sun Sep 14 13:25:10 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 11:25:10 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>


New submission from Andrew I MacIntyre <aimacintyre at users.sourceforge.net>:

sources: 2.6rc1 tarball
system: FreeBSD 6.3 i386, gcc 3.4.6 (system compiler)
build:  ./configure; make

it makes no difference whether test_threading is run as part of make test 
or on its own - process suspends and has to be killed (I left one run the 
best part of an hour with no progress).

a log from a verbose run:
andymac at bullseye$ ./python -E -tt Lib/test/regrtest.py -v test_threading
>logfile 2>&1
test_threading
test_PyThreadState_SetAsyncExc (test.test_threading.ThreadTests) ...   
 started worker thread
    trying nonsensical thread id
    waiting for worker thread to get started
    verifying worker hasn't exited
    attempting to raise asynch exception in worker
    waiting for worker to say it caught the exception
    all OK -- joining worker
ok
test_enumerate_after_join (test.test_threading.ThreadTests) ... ok
test_finalize_runnning_thread (test.test_threading.ThreadTests) ... ok
test_finalize_with_trace (test.test_threading.ThreadTests) ... ok
test_foreign_thread (test.test_threading.ThreadTests) ... ok
test_no_refcycle_through_target (test.test_threading.ThreadTests) ... ok
test_various_ops (test.test_threading.ThreadTests) ... task <thread 0>
will run for 26.0 usec
1 tasks are running
task <thread 1> will run for 25.7 usec
2 tasks are running
task <thread 2> will run for 28.9 usec
3 tasks are running
task <thread 3> will run for 47.1 usec
task <thread 4> will run for 19.8 usec
task <thread 5> will run for 10.0 usec
task <thread 6> will run for 25.4 usec
task <thread 7> will run for 55.5 usectasktask <thread 1> done
<thread 1> is finished. 2 tasks are running

  task <thread 2> done
<thread 2> is finished. 1 tasks are running
2 tasks are running
<thread 0> done
<thread 0> is finished. 1 tasks are running
task <thread 8> will run for 61.3 usec
2 tasks are running
3 tasks are running
task <thread 9> will run for 53.1 usec
waiting for all tasks to complete
task <thread 3> done
<thread 3> is finished. 2 tasks are running
task <thread 4> done
<thread 4> is finished. 1 tasks are running
2 tasks are running
3 tasks are running
task <thread 8> done
<thread 8> is finished. 2 tasks are running
3 tasks are running
task <thread 7> done
<thread 7> is finished. 2 tasks are running
task <thread 6> done
<thread 6> is finished. 1 tasks are running
2 tasks are running
task <thread 5> done
<thread 5> is finished. 1 tasks are running
task <thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_various_ops_large_stack (test.test_threading.ThreadTests) ... with
1MB thread stack size...
task <thread 0> will run for 96.9 usec
1 tasks are running
task <thread 1> will run for 99.4 usec
2 tasks are running
task <thread 2> will run for 0.8 usec
3 tasks are running
task <thread 2> done
<thread 2> is finished. 2 tasks are running
task <thread 3> will run for 89.1 usec
3 tasks are running
task <thread 4> will run for 46.8 usec
task <thread 5> will run for 13.2 usec
task <thread 6> will run for 23.8 usec
tasktask <thread 0> done
<thread 0> is finished. 2 tasks are running
task <thread 7> will run for 41.6 usec 
<thread 1> done
<thread 1> is finished. 1 tasks are running
2 tasks are running
3task <thread 8> will run for 55.8 usec
 tasks are running
waiting for all tasks to complete
task <thread 3> done
<thread 3> is finished. 2 tasks are running
task <thread 9> will run for 53.2 usec 3 tasks are running

task <thread 4> done
<thread 4> is finished. 2 tasks are running
task <thread 5> done
<thread 5> is finished. 1 tasks are running
2 tasks are running
3 tasks are running
task <thread 6> done
<thread 6> is finished. 2 tasks are running
3 tasks are running
task <thread 7> done
<thread 7> is finished. 2 tasks are running
task <thread 8> done
<thread 8> is finished. 1 tasks are running
task <thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_various_ops_small_stack (test.test_threading.ThreadTests) ... with
256kB thread stack size...
task <thread 0> will run for 54.5 usec
1 tasks are running
task <thread 1> will run for 5.2 usec
2 tasks are running
task <thread 2> will run for 2.1 usec
3 tasks are running
task <thread 3> will run for 40.5 usec
task <thread 4> will run for 55.9 usec
task <thread 5> will run for 77.1 usec
task <thread 6> will run for 82.4 usec
task <thread 0> done
<thread 0> is finished. 2 tasks are running
task <thread 1> done
<thread 1> is finished. 1 tasks are running
2 tasks are running
task <thread 7> will run for 100.0 usec
task <thread 8> will run for 64.5 usec
3 tasks are running
waiting for all tasks to complete
task <thread 2> done
<thread 2> is finished. 2 tasks are running
3 tasks are running
task <thread 9> will run for 76.7 usec
task <thread 3> done
<thread 3> is finished. 2 tasks are running
task <thread 4> done
<thread 4> is finished. 1 tasks are running
2 tasks are running
3 tasks are running
task <thread 5> done
<thread 5> is finished. 2 tasks are running
3 tasks are running
task <thread 7> done
<thread 7> is finished. 2 tasks are running
task <thread 6> done
<thread 6> is finished. 1 tasks are running
2 tasks are running
task <thread 8> done
<thread 8> is finished. 1 tasks are running
task <thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_1_join_on_shutdown (test.test_threading.ThreadJoinOnShutdown) ... ok
test_2_join_in_forked_process (test.test_threading.ThreadJoinOnShutdown)
... ok
test_3_join_in_forked_from_thread
(test.test_threading.ThreadJoinOnShutdown) ... Fatal error 'mutex is on
list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c
(errno = 0)

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/andymac/build/Python-2.6rc1/Lib/threading.py", line 522,
in __bootstrap_inner
    self.run()
  File "/home/andymac/build/Python-2.6rc1/Lib/threading.py", line 477,
in run
    self.__target(*self.__args, **self.__kwargs)
  File "<string>", line 14, in worker
OSError: [Errno 4] Interrupted system call

Exception KeyboardInterrupt in <module 'threading' from
'/home/andymac/build/Python-2.6rc1/Lib/threading.pyc'> ignored

----------
messages: 73210
nosy: aimacintyre
severity: normal
status: open
title: 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Sun Sep 14 13:32:02 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 11:32:02 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221391922.24.0.177426586624.issue3863@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I should add that this is a regression of the trunk, as I built and
tested the trunk from an SVN checkout (r63892) in early June and didn't
encounter this issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Sun Sep 14 13:41:54 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 11:41:54 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>


New submission from Andrew I MacIntyre <aimacintyre at users.sourceforge.net>:

sources: 2.6rc1 tarball
system: FreeBSD 6.3 i386, gcc 3.4.6 (system compiler)
build:  ./configure; make

When run as part of the regression suite, test_signal fails.  When run
on its own, it passes.

In the failure case, the runtime of the test (as part of the whole test
run) appears to be several minutes, but when run on its own it completes
in < 10s.

This will require some random order regression runs to try and identify
the prior test which is provoking whatever is going wrong.

This issue has been around for several months at least, as I first
became aware of it with a checkout of r63892 on both FreeBSD 6.3 [gcc
3.4.6] and 7.0 [gcc 4.2.1] for both i386 and amd64 environments, but I
haven't had the opportunity to do the followup checking.

----------
messages: 73212
nosy: aimacintyre
severity: normal
status: open
title: 26.rc1: test_signal issue on FreeBSD 6.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Sun Sep 14 13:42:24 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 11:42:24 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1221392544.64.0.542460764818.issue3864@psf.upfronthosting.co.za>


Changes by Andrew I MacIntyre <aimacintyre at users.sourceforge.net>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Sun Sep 14 13:47:40 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 14 Sep 2008 11:47:40 +0000
Subject: [issue3865] explain that profilers should be used for profiling,
	not benchmarking
In-Reply-To: <1221392860.21.0.302367581665.issue3865@psf.upfronthosting.co.za>
Message-ID: <1221392860.21.0.302367581665.issue3865@psf.upfronthosting.co.za>


New submission from Fredrik Lundh <effbot at users.sourceforge.net>:

You often see people using the profiler for benchmarking instead of
profiling.  I suggest adding a note that explains that the profiler
modules are designed to provide an execution profile for a given
program, not for benchmarking different libraries or, even worse,
benchmarking Python code against C libraries.  Point people to the
"timeit" module if they want resonably accurate results.

(and yes, it would be nice if the copyright text on the page

http://docs.python.org/dev/library/profile.html

was moved to the bottom of the page.  If necessary, add something like
"This description of the profile module is Copyright ? 1994, by InfoSeek
Corporation, all rights reserved.  Full copyright message below" at the
top.)

----------
assignee: georg.brandl
components: Documentation
messages: 73213
nosy: effbot, georg.brandl
severity: normal
status: open
title: explain that profilers should be used for profiling, not benchmarking
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3865>
_______________________________________

From report at bugs.python.org  Sun Sep 14 13:58:06 2008
From: report at bugs.python.org (Kent Johnson)
Date: Sun, 14 Sep 2008 11:58:06 +0000
Subject: [issue3866] int() doesn't 'guess'
In-Reply-To: <1221393486.32.0.176734593985.issue3866@psf.upfronthosting.co.za>
Message-ID: <1221393486.32.0.176734593985.issue3866@psf.upfronthosting.co.za>


New submission from Kent Johnson <kent at kentsjohnson.com>:

The library reference for int() says, "If radix is zero, the proper
radix is guessed based on the contents of string; the interpretation is
the same as for integer literals." The use of the word 'guess' implies
that there is some heuristic used here, that somehow the function will
look at an arbitrary number and figure out the correct radix. This can
confuse newbies:
http://mail.python.org/pipermail/tutor/2008-September/064268.html

'determined' might be a better word. For bonus points link to the
Language Reference page on integer literals:
http://docs.python.org/ref/integers.html

----------
assignee: georg.brandl
components: Documentation
messages: 73214
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: int() doesn't 'guess'
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3866>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:14:00 2008
From: report at bugs.python.org (Andrew Bennetts)
Date: Sun, 14 Sep 2008 12:14:00 +0000
Subject: [issue3867] What's New in 2.6 doesn't mention stricter object.__init__
In-Reply-To: <1221394440.92.0.406696886486.issue3867@psf.upfronthosting.co.za>
Message-ID: <1221394440.92.0.406696886486.issue3867@psf.upfronthosting.co.za>


New submission from Andrew Bennetts <spiv at users.sourceforge.net>:

http://bugs.python.org/issue1683368 changed object.__init__ so that
rejects args/kwargs.  This change should be mentioned in the "What's New
in Python 2.6" document, probably under the "Porting to Python 2.6" heading.

(I noticed this because the stricter object.__init__ has made Python
2.6rc1 (and probably earlier) incompatible with Bazaar, which in one or
two places happened to depend on the pre-2.6 behaviour.)

----------
assignee: georg.brandl
components: Documentation
messages: 73215
nosy: georg.brandl, spiv
severity: normal
status: open
title: What's New in 2.6 doesn't mention stricter object.__init__
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3867>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:21:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Sep 2008 12:21:57 +0000
Subject: [issue3867] What's New in 2.6 doesn't mention stricter object.__init__
In-Reply-To: <1221394440.92.0.406696886486.issue3867@psf.upfronthosting.co.za>
Message-ID: <1221394917.62.0.196659750808.issue3867@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee: georg.brandl -> akuchling
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3867>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:29:45 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 12:29:45 +0000
Subject: [issue3868] patch for review: OS/2 EMX port fixes for 2.6
Message-ID: <1221395385.89.0.276042289673.issue3868@psf.upfronthosting.co.za>


Changes by Andrew I MacIntyre <aimacintyre at users.sourceforge.net>:


----------
components: Build, Interpreter Core, Library (Lib), Tests
files: build_os2emx.patch
keywords: patch, patch
nosy: aimacintyre
severity: normal
status: open
title: patch for review: OS/2 EMX port fixes for 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file11487/build_os2emx.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3868>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:35:33 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 14 Sep 2008 12:35:33 +0000
Subject: [issue3865] explain that profilers should be used for profiling,
	not benchmarking
In-Reply-To: <1221392860.21.0.302367581665.issue3865@psf.upfronthosting.co.za>
Message-ID: <1221395733.56.0.695128378612.issue3865@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

(the reason this is extra bad for C modules is that the profilers
introduce overhead for Python code, but not for C-level functions.  For
example, using the standard profiler to benchmark parser performance for
xml.etree.ElementTree vs. xml.etree.cElementTree will make ET appear to
be about 10 times slower than it actually is.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3865>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:39:31 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 12:39:31 +0000
Subject: [issue3868] patch for review: OS/2 EMX port fixes for 2.6
In-Reply-To: <1221395971.68.0.568143419044.issue3868@psf.upfronthosting.co.za>
Message-ID: <1221395971.68.0.568143419044.issue3868@psf.upfronthosting.co.za>


New submission from Andrew I MacIntyre <aimacintyre at users.sourceforge.net>:

The 2 attached patch files are patches required for the OS/2 EMX port to
build and function:
- build_os2emx.patch - updates to the Makefile and config files in
PC/os2emx;
- source_os2emx.patch - updates to various core/library/test files.
=> Include/pystrcmp.h (OS/2 is like Windows, with the same C lib routines)
=> Lib/test/test_io.py (OS/2 is like Windows again)
=> Objects/floatobject.c (should use macro'd symbols not direct)
=> Python/pymath.c (any platform without HAVE_LOG1P should have
DBL_EPSILON in <float.h>)

For review so that the fixes can be rolled into 2.6 final.

Added file: http://bugs.python.org/file11488/source_os2emx.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3868>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:47:25 2008
From: report at bugs.python.org (Mike Auty)
Date: Sun, 14 Sep 2008 12:47:25 +0000
Subject: [issue3861] distutils CCompiler._compile doesn't require lang keyword
	argument
In-Reply-To: <1221355512.51.0.884487193093.issue3861@psf.upfronthosting.co.za>
Message-ID: <1221396445.9.0.402597424101.issue3861@psf.upfronthosting.co.za>


Mike Auty <mike.auty at gmail.com> added the comment:

Sorry, scratch that, it turned out to be a patch added by a local
packager.  I don't seem to be able to close my own bug, but for anyone
who's triaging this, please mark this as CLOSED/INVALID or similar. 
Sorry for the inconvenience...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3861>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:49:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Sep 2008 12:49:03 +0000
Subject: [issue3861] distutils CCompiler._compile doesn't require lang keyword
	argument
In-Reply-To: <1221355512.51.0.884487193093.issue3861@psf.upfronthosting.co.za>
Message-ID: <1221396543.41.0.625418770204.issue3861@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Your problem seems very similar to http://bugs.gentoo.org/219238
but it seems that the Gentoo installation uses a patched version of 
python. there is no "lang" parameter at all in the official version...

Do you use a patched version of python?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3861>
_______________________________________

From report at bugs.python.org  Sun Sep 14 14:49:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Sep 2008 12:49:34 +0000
Subject: [issue3861] distutils CCompiler._compile doesn't require lang keyword
	argument
In-Reply-To: <1221355512.51.0.884487193093.issue3861@psf.upfronthosting.co.za>
Message-ID: <1221396574.56.0.00800776656195.issue3861@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3861>
_______________________________________

From report at bugs.python.org  Sun Sep 14 15:16:46 2008
From: report at bugs.python.org (Mike Auty)
Date: Sun, 14 Sep 2008 13:16:46 +0000
Subject: [issue3861] distutils CCompiler._compile doesn't require lang keyword
	argument
In-Reply-To: <1221355512.51.0.884487193093.issue3861@psf.upfronthosting.co.za>
Message-ID: <1221398206.8.0.683499731391.issue3861@psf.upfronthosting.co.za>


Mike Auty <mike.auty at gmail.com> added the comment:

You're absolutely right, it was a Gentoo patching issue.  Thanks very
much for the link to the bug, I would never have found it myself!  5:)

I'm off to go try and convince them it's a bad idea to patch interfaces...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3861>
_______________________________________

From report at bugs.python.org  Sun Sep 14 15:26:17 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 13:26:17 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1221398777.23.0.190011705764.issue3770@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

2.6rc1 shows the same failure traceback on FreeBSD 6.3, which is covered
by a section of setup.py the same as Damien added for OpenBSD.

----------
nosy: +aimacintyre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Sun Sep 14 15:27:51 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Sun, 14 Sep 2008 13:27:51 +0000
Subject: =?utf-8?q?[issue3680]_Cycles_with_some_iterator_are=09leaking.?=
In-Reply-To: <1219697025.92.0.458237292903.issue3680@psf.upfronthosting.co.za>
Message-ID: <1221398871.72.0.0117683928888.issue3680@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

> I think it's ok, since the underlying containers will get cleared, thus
> breaking the cycle.

What about the dictiter object which references a tuple (di_result)?
Tuple does not implement tp_clear, but OTOH tuples are immutable and
di_result cannot be assigned.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3680>
_______________________________________

From report at bugs.python.org  Sun Sep 14 16:05:36 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Sep 2008 14:05:36 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221401136.69.0.199918532264.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

3.0 version of the patch attached (it turned that it wasn't so much
test_support itself that caused the forward port problems, as the fact
that most of the tests that use this feature in 2.x are testing
specifically for Py3k warnings, or for other deprecated features that
aren't part of 3.0, so many of the changes either weren't needed, or
their contexts had changed completely).

Added file: http://bugs.python.org/file11489/issue3781_catch_warnings_cleanup_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sun Sep 14 16:05:52 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Sep 2008 14:05:52 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221401152.67.0.373172807146.issue3781@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sun Sep 14 16:35:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Sep 2008 14:35:58 +0000
Subject: [issue3868] patch for review: OS/2 EMX port fixes for 2.6
In-Reply-To: <1221395971.68.0.568143419044.issue3868@psf.upfronthosting.co.za>
Message-ID: <1221402958.24.0.10652328047.issue3868@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patches look good to me. 
I first thought that there could be a difference between PyOS_strnicmp 
and PyOS_mystrnicmp, but both Microsoft's strnicmp and python's PyOS_mystrnicmp are sensitive to the current locale.

Another unrelated issue is to protect all uses of Py_NAN: some builds 
may choose to #define Py_NO_NAN...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3868>
_______________________________________

From report at bugs.python.org  Sun Sep 14 16:40:15 2008
From: report at bugs.python.org (Reed O'Brien)
Date: Sun, 14 Sep 2008 14:40:15 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221403215.69.0.924523804019.issue3862@psf.upfronthosting.co.za>


Reed O'Brien <reed at reedobrien.com> added the comment:

2.6rc2 and Python-3.0b3 test_array detail
 
test_alloc_overflow (test.test_array.DoubleTest) ... Killed

Fills swap space and dumps core.


2.5.2 

test_list
test_addmul (test.test_list.ListTest) ... ok
test_append (test.test_list.ListTest) ... ok
Killed

The FreeBSD ports patches fix this in 2.5.2. Specifically patching
seq_tests.py to limit test_bigrepeat() to  if sys.maxint <= 2147483647.
no other tests fail; so I don't know immediately what else is patched.
Although there are about 25 patches for the 2.5 port.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Sun Sep 14 17:56:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Sep 2008 15:56:58 +0000
Subject: [issue3859] test_sys.Sizeof fails on win64
In-Reply-To: <1221312951.19.0.765623147021.issue3859@psf.upfronthosting.co.za>
Message-ID: <1221407818.32.0.716449924472.issue3859@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Looks good to me.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3859>
_______________________________________

From report at bugs.python.org  Sun Sep 14 18:02:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Sep 2008 16:02:50 +0000
Subject: [issue3866] int() doesn't 'guess'
In-Reply-To: <1221393486.32.0.176734593985.issue3866@psf.upfronthosting.co.za>
Message-ID: <1221408170.61.0.821824174888.issue3866@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the suggestion! Fixed in r66459.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3866>
_______________________________________

From report at bugs.python.org  Sun Sep 14 18:23:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 14 Sep 2008 16:23:02 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1221387146.31.0.0417653564604.issue3690@psf.upfronthosting.co.za>
Message-ID: <48CD3A63.8040109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> In any case, I also think this doesn't matter much either way. 
> Why do you think so?

What's the actual difference that this change makes? At most 8
bytes per object, right? And for two objects in total. So if somebody
would compute memory consumption, they might be off by not more
than 14 bytes, in total. Compared to all the other errors that memory
computation makes (e.g. malloc headers, rounding-up to multiples of
8 in obmalloc) which aren't accounted-for in sys.getsizeof, this
difference is negligible.

What's more, the small_ints aren't dynamically allocated, either,
but instead, each small_int takes a complete PyLongObject. If
that was also considered in long_sizeof, the computation would happen
to be completely correct for bool also.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Sun Sep 14 18:25:16 2008
From: report at bugs.python.org (Daniel)
Date: Sun, 14 Sep 2008 16:25:16 +0000
Subject: [issue3869] Arrow keys not working with Python 2.6rc1
In-Reply-To: <1221409516.57.0.386124150763.issue3869@psf.upfronthosting.co.za>
Message-ID: <1221409516.57.0.386124150763.issue3869@psf.upfronthosting.co.za>


New submission from Daniel <dayiil at yahoo.com>:

On Xubuntu 8.04. In Python2.5 arrow keys allowed you to scroll through
previous lines typed but with 2.6rc1 this stopped working and it's now
just typing the ^[[A^[[B^[[D^[[C characters.

----------
messages: 73229
nosy: Chewie
severity: normal
status: open
title: Arrow keys not working with Python 2.6rc1
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3869>
_______________________________________

From report at bugs.python.org  Sun Sep 14 18:29:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Sep 2008 16:29:04 +0000
Subject: [issue3869] Arrow keys not working with Python 2.6rc1
In-Reply-To: <1221409516.57.0.386124150763.issue3869@psf.upfronthosting.co.za>
Message-ID: <1221409744.84.0.457120442374.issue3869@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This probably has something to do with your readline build? Did you
compile Python yourself?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3869>
_______________________________________

From report at bugs.python.org  Sun Sep 14 19:58:23 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 14 Sep 2008 17:58:23 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1221415103.13.0.0334767939904.issue3864@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Can you check if it is not the itimer tests that are causing that ? I'm
interested in gathering some more info about the problem and hopefully
fixing it now. Take a look into issue2240 and verify if it is related to
your problem, please.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Sun Sep 14 20:25:19 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 14 Sep 2008 18:25:19 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221416719.23.0.734886694742.issue3825@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/issue3825>
_______________________________________

From report at bugs.python.org  Sun Sep 14 21:36:54 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 14 Sep 2008 19:36:54 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1221421014.83.0.945425923606.issue1641@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I try to revamp this issue by attaching a new patch which improves the
work I did against asyncore last time.
The approach proposed in this new patch is the same used in the upcoming
pyftpdlib 0.5.0 version which has been largely tested and benchmarked.
In my opinion, without the addition of an eventual paired heap module
into the stdlib there are no significant faster ways to do this than
using the common heapq module.
The patch in attachment includes:

- various changes which improve the speed execution when operating
against the heap.
- a larger test suite.
- documentation for the new class and its methods.

Josiah, do you have some time to review this?

----------
components: +Installation -Library (Lib)
Added file: http://bugs.python.org/file11490/asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Sun Sep 14 21:37:10 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 14 Sep 2008 19:37:10 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1221421030.4.0.20740032895.issue1641@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


Removed file: http://bugs.python.org/file8977/asyncore.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Sun Sep 14 21:38:54 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 14 Sep 2008 19:38:54 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1221421134.93.0.357653207635.issue1641@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
components: +Library (Lib) -Installation
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Sun Sep 14 21:55:51 2008
From: report at bugs.python.org (Daniel)
Date: Sun, 14 Sep 2008 19:55:51 +0000
Subject: [issue3869] Arrow keys not working with Python 2.6rc1
In-Reply-To: <1221409516.57.0.386124150763.issue3869@psf.upfronthosting.co.za>
Message-ID: <1221422151.78.0.869986691013.issue3869@psf.upfronthosting.co.za>


Daniel <dayiil at yahoo.com> added the comment:

Yes I did the configure / compile myself.

After reading about readline in setup I am still unable to enable it but
I guess it is not a bug in Python but more a user problem.

I am quite puzzled as to why something like this would stop being
enabled by defualt tho, pretty sure I don't know anyone who doesn't use
input history.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3869>
_______________________________________

From report at bugs.python.org  Sun Sep 14 22:01:18 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Sep 2008 20:01:18 +0000
Subject: [issue3869] Arrow keys not working with Python 2.6rc1
In-Reply-To: <1221409516.57.0.386124150763.issue3869@psf.upfronthosting.co.za>
Message-ID: <1221422478.81.0.946227074991.issue3869@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

ubuntu?  make sure you have the libreadline5-dev package installed. 
then make distclean && ./configure && make

----------
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3869>
_______________________________________

From report at bugs.python.org  Sun Sep 14 22:31:06 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 14 Sep 2008 20:31:06 +0000
Subject: =?utf-8?q?[issue3617]_Add_MS_EULA_to_the_list_of_third-party_licenses_in_the=09Windows_installer?=
In-Reply-To: <1219225664.77.0.244141020372.issue3617@psf.upfronthosting.co.za>
Message-ID: <1221424266.46.0.425888869965.issue3617@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in r66460 and r66462; the text that gets included is
in Tools/msi/crtlicense.txt.

----------
keywords:  -easy
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3617>
_______________________________________

From report at bugs.python.org  Sun Sep 14 22:54:53 2008
From: report at bugs.python.org (Daniel)
Date: Sun, 14 Sep 2008 20:54:53 +0000
Subject: [issue3869] Arrow keys not working with Python 2.6rc1
In-Reply-To: <1221409516.57.0.386124150763.issue3869@psf.upfronthosting.co.za>
Message-ID: <1221425693.63.0.185361679812.issue3869@psf.upfronthosting.co.za>


Daniel <dayiil at yahoo.com> added the comment:

That was it.

Needed to install libreadline5-dev.

Then the default settings for readline in Modules/setup needs
uncommented (line 165 in the current version) and it works.

Thank you kindly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3869>
_______________________________________

From report at bugs.python.org  Sun Sep 14 22:55:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Sep 2008 20:55:19 +0000
Subject: [issue3869] Arrow keys not working with Python 2.6rc1
In-Reply-To: <1221409516.57.0.386124150763.issue3869@psf.upfronthosting.co.za>
Message-ID: <1221425719.18.0.138264021579.issue3869@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3869>
_______________________________________

From report at bugs.python.org  Sun Sep 14 22:59:45 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Sep 2008 20:59:45 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221425985.88.0.206923576053.issue3863@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/issue3863>
_______________________________________

From report at bugs.python.org  Sun Sep 14 23:33:52 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 14 Sep 2008 21:33:52 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221428032.83.0.6665544641.issue3835@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

What tcl/tk version are you using ?

Also, can you put a "print(_flatten((self._w, cmd)) +
self._options(cnf))" before the line 1190 in
/usr/local/lib/python3.0/tkinter/__init__.py and tell what it shows when
you call pydoc.gui ?

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Mon Sep 15 00:51:32 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Sep 2008 22:51:32 +0000
Subject: [issue3870] Parser/adsl_c.py requires python in order to build python
In-Reply-To: <1221432692.91.0.760928984013.issue3870@psf.upfronthosting.co.za>
Message-ID: <1221432692.91.0.760928984013.issue3870@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Parser/asdl_c.py starts with  "#! /usr/bin/env python"  and is required
when building python.  The prevents python from being built on systems
without an existing python interpreter installed.  Which came first, the
python or the egg?

found when attempting to build python from subversion on FreeBSD 6.3.

This is what make trys to run that fails:

 ./Parser/asdl_c.py -h ./Include Parser/Python.asdl

----------
components: Build
messages: 73238
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Parser/adsl_c.py requires python in order to build python
type: compile error
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3870>
_______________________________________

From report at bugs.python.org  Mon Sep 15 00:52:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Sep 2008 22:52:00 +0000
Subject: [issue3870] Parser/asdl_c.py requires python in order to build python
In-Reply-To: <1221432692.91.0.760928984013.issue3870@psf.upfronthosting.co.za>
Message-ID: <1221432720.76.0.892415835309.issue3870@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
title: Parser/adsl_c.py requires python in order to build python -> Parser/asdl_c.py requires python in order to build python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3870>
_______________________________________

From report at bugs.python.org  Mon Sep 15 01:08:19 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 14 Sep 2008 23:08:19 +0000
Subject: [issue3871] cross building python for mingw32 with distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

This is a completely new patch against trunk that try to resolve mingw32
build. The first version to show problems with current python builds
system, to propose solutions/work-arounds and to be stating point for
discussion. Also I prefer some issues to be resolved later when we agree
on the basic issues.

The patch is tested in cross-compilation environment and native build
has to be tested too. Also the patch show how to use cross-compilation
environment and require patch posted in
issue 3754 ("minimal cross-compilation support for configure") to be
applied first.

The new patch share many commons with issue 841454 "Cross building
python for mingw32" posted by Andreas Ames, on 2003-11-13), but build
process use distutils instead scons.
Also some mingw related changes from issue 1597850 ("Cross compiling
patches for MINGW" - Han-Wen Nienhuys, from 2006-11-16) are shared too,
but we differ in concept how to use cross-compilation environment.
The correct way is to use $host variable (see issue 3754).

Also my patch use python installed on build system along with some hacks
to overcome distutils limitations.

The main issue "how to select correct compiler" in cross-compilation
environment isn't resolved at all. The patch is tested with installed
python version 2.4. 
Usually the cross-compiler is installed in same directories as native
compiler but tools are prefixed by <CPU>-<VENDOR>- (see meanign of "host
triplet"). In this environment we can't cross-compile even if we select
mingw as compiler in arguments for "setup.py":
The method get_versions() from cygwinccompiler.py call find_executable
for to find gcc, ld, dllwrap but on build system they point to native
compiler and that aren't prefixed. Also the expression "result =
re.search('(\d+\.\d+(\.\d+)*)',out_string)" return as example
'2.17.50.0.6' and later StrictVersion fail since value is not in format
N.N{.N{A{N}}}. If we replace '*' with '?" in regular expression we will
get correct  result, but this isn't right solution.
So the question is 'how to pass compiler to distutils' (as example for
python 2.4) remain open.

Work-around: install mingw cross-suite in own directory (MINGW_ROOT) and
prepend PATH environment variable with both paths:
- $MINGW_ROOT/bin
- $MINGW_ROOT/<MINGW_HOST>/bin where <MINGW_HOST> is something like
i586-pc-mingw32 (depend from you host selected when you build suite).
In this case find_executable will find mingw ld and since -v option
return something like "GNU ld version 2.17.50 20060824", regular
expresion value that make StrictVersion happy.

Note that in both environment configure script find compiler tools
prefixed as example by "i586-pc-mingw32-".
My mingw is build for host "i386-mingw32msvc"(this isn't correct, but is
acceptable for host. For next version I plan to use for build the
correct one, i.e i386-pc-mingw32). So in the final Makefile I see:
CC=             i386-mingw32msvc-gcc
AR=             i386-mingw32msvc-ar
RANLIB=         i386-mingw32msvc-ranlib

Also setup.py set compiler attribute linker_so - for details see
comments in the patch.

Another point is to link installed python in top-build directory so that
on posix system distutils read variables from our makefile instead from
installed in build system. In this case python_build (an internal to
distutils flag) is set.

A, but not common, build issue is that some python 2.4 versions will
search for pyconfig-32.h instead pyconfig.h.
Symptoms:
=======================================
....
running build
running build_ext
error: ./pyconfig-32.h: No such file or directory
....
=======================================
I see this on cent-os (5.0?), but I can't see on slackware 11.0.
This patch don't address this.
Just go in top-build directory and create a link, i.e. "ln -s
./pyconfig.h pyconfig-32.h".


If you system support emulation after build you may run python.
The build python search for modules. After patch modules are with suffix
same as for native build - .pyd. You may thin them to the top-build
directory or to follow binary distribution - create directory DLLs,
enter into it and link pyd-files:
$ for f in ../build/lib.*/*.pyd; do ln -sf $f; done


Differences between mingw build python and binary distribution(native
build):
Mingw build follow posix rules and will create more modules than native
build. In the native build they are part from main executable(buildin).
This is the list:
array, audioop, binascii, _bisect, _bytesio, cmath, _codecs_cn,
_codecs_hk, _codecs_iso2022, _codecs_jp, _codecs_kr, _codecs_tw,
_collections, cPickle, cStringIO, _csv, datetime, _fileio, _functools,
future_builtins, _heapq, _hotshot, imageop, itertools, _json, _locale,
_lsprof, math, mmap, msvcrt, _multibytecodec, operator, parser, _random,
strop, _struct, _subprocess, time, _weakref, _winreg, zlib.
I think that this inconsistency is problem of native build and for now I
don't address it.

Because in my environment I still don't have installed mingw port for
some externals, build of following modules isn't tested:
_bsddb.pyd
_msi.pyd
_sqlite3.pyd
_tkinter.pyd



Known issues:
The float, math and other related tests fail(under emulation and on nt5.1).
The reason is that C runtime function strtod() can't parse as example
numbers with exponent lower than -308, can't parse inf, nan, etc.. The
python source contain a file Python/strtod.c and my attempt to modify
and use it didn't succeed.
Also the configure lack test for "working" strtod and I guess that tests
fail on posix systems without C99 support.
The library mingwex from mingw runtime version 3.15 has working
replacement for stdtod function.
For now my patch will not address old strtod function.

In mingw definition of some functions(as example getaddrinfo and
getnameinfo) depend of value of WINVER. This issue is commented in the
patch. If user define WINVER geater the 0x0500 to CPPFLAGS at configure
time the build will use C-runtime function otherwise fake-function from
getaddrinfo.c and getnameinfo.c. As is commented in the patch if program
is linked with C-runtime functions I expect to fail to run on w2k.
I prefer to left selection of C-runtime for future mingw patches.

The other issue is that I see failure for some tests that use sockets.
This problem isn't investigated yet.

We may group some changes in configure but this require to reorder some
commands as example '--with-pydebug'. Since this isn't mingw issue I
prefer don't change current order. Another example is LIBM - it is set
by configure but setup.py use own rule.

----------
components: Build
files: python-trunk.patch-MINGW
messages: 73239
nosy: rpetrov
severity: normal
status: open
title: cross building python for mingw32 with distutils
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file11491/python-trunk.patch-MINGW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Sep 15 01:20:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Sep 2008 23:20:19 +0000
Subject: [issue3870] Parser/asdl_c.py requires python in order to build python
In-Reply-To: <1221432692.91.0.760928984013.issue3870@psf.upfronthosting.co.za>
Message-ID: <1221434419.5.0.883997647126.issue3870@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Yes, that's why what it builds is included in the svn repo by default.
You can avoid the build problems by touching Include/Python-ast.h and
Python/Python-ast.c.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3870>
_______________________________________

From report at bugs.python.org  Mon Sep 15 01:36:59 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 14 Sep 2008 23:36:59 +0000
Subject: [issue3871] cross building python for mingw32 with distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1221435419.76.0.59505751361.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

P.S.: this patch cover changes in the python C-code proposed in issue
1412448 as include only necessary modifications.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Sep 15 01:48:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Sep 2008 23:48:00 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221436080.2.0.0747158601822.issue3863@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I also see this in release25-maint's test_threading
test_2_join_in_forked_process.

This is likely related to the fixes for issue #874900 but i'm not sure
yet if this is a new problem or just one thats been there for a while
and exposed by the new tests added for that issue.

(also fyi - I used a premade barebones FreeBSD 6.3 VMWare image from
http://www.thoughtpolice.co.uk/vmware/ to reproduce it here)

----------
nosy: +jnoller, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 01:49:48 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 14 Sep 2008 23:49:48 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221436188.04.0.141903135097.issue3863@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
components: +Extension Modules
priority:  -> high
type:  -> crash
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 02:01:01 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Sep 2008 00:01:01 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221436861.23.0.169397073336.issue3863@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

and as expected, also happens with py3k.

----------
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 02:23:32 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Sep 2008 00:23:32 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221438212.33.0.282803548131.issue3863@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fyi the FreeBSD 6.3 libpthread PANIC message comes from the
MUTEX_ASSERT_NOT_OWNED macro which is called from several places here:

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libpthread/thread/Attic/thr_mutex.c?rev=1.52;content-type=text%2Fx-cvsweb-markup;hideattic=0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 04:53:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 15 Sep 2008 02:53:40 +0000
Subject: [issue3867] What's New in 2.6 doesn't mention stricter object.__init__
In-Reply-To: <1221394440.92.0.406696886486.issue3867@psf.upfronthosting.co.za>
Message-ID: <1221447220.78.0.344722218995.issue3867@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the note! Fixed in r66467.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3867>
_______________________________________

From report at bugs.python.org  Mon Sep 15 06:49:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Sep 2008 04:49:31 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221454171.31.0.956135759887.issue3863@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

attaching a stand alone script to exercise the bug.  based on the
prints, the error appears to happen during the t.start() call to launch
the joiningfunc() thread from the child processes worker thread (its the
main/only thread in the child process so far).

Added file: http://bugs.python.org/file11492/fbsd_thr_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 07:44:24 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Sep 2008 05:44:24 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221457464.87.0.378904297165.issue3863@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

instrumenting Python/thread_pthread.h and turning on thread debugging in
Python/thread.c, FreeBSD raises the Fatal error within pthread_create().

I'm inclined to say that this is a FreeBSD 6.3 bug.  The
fbsd_thr_crash.py test case is a good way to reproduce the problem.  I'd
imagine a similar bit of C code could be written.

What should we do in Python for this?  Just disable this unit test on
FreeBSD?

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 09:00:59 2008
From: report at bugs.python.org (romkyns)
Date: Mon, 15 Sep 2008 07:00:59 +0000
Subject: [issue3826] Self-reference in BaseHTTPRequestHandler descendants
	causes stuck connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1221462059.68.0.38339790089.issue3826@psf.upfronthosting.co.za>


romkyns <ws.python at starkov.name> added the comment:

Someone suggested I test this in 2.6rc1. The problem does not exist in
2.6rc1, only in 3.0b2.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Mon Sep 15 09:30:37 2008
From: report at bugs.python.org (Dominique Wahli)
Date: Mon, 15 Sep 2008 07:30:37 +0000
Subject: [issue3872] Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>


New submission from Dominique Wahli <dwahli at gmail.com>:

Component ComboBox from Tix raise an error in Python 2.6rc1 (Windows XP):

Traceback (most recent call last):
  File "D:\PCE\Tools\PCSUpdate\test_combotix.py", line 11, in <module>
    app = TestTix()
  File "D:\PCE\Tools\PCSUpdate\test_combotix.py", line 6, in __init__
    w = ComboBox(self)
  File "C:\Python26\lib\lib-tk\Tix.py", line 579, in __init__
    cnf, kw)
  File "C:\Python26\lib\lib-tk\Tix.py", line 307, in __init__
    self.tk.call(widgetName, self._w, *extra)
_tkinter.TclError: unknown color name "{#c3c3c3}"

----------
components: Tkinter
files: test_combotix.py
messages: 73249
nosy: dwahli
severity: normal
status: open
title: Tix ComboBox error
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file11493/test_combotix.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Mon Sep 15 10:12:01 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 15 Sep 2008 08:12:01 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1221466321.78.0.258022569645.issue3690@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

> What's the actual difference that this change makes?

It would provide more accurate results, even in the light of being not
perfect.

> [..] each small_int takes a complete PyLongObject. If that was also
> considered in long_sizeof, the computation would happen to be
> completely correct for bool also.

So how should this bug report be handled? Provide a patch to handle
getsizeof correctly for small_ints? 'wont fix' because there are issues
anyway? I would prefer the former and try to come up with a patch if you
think it is worthwhile.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Mon Sep 15 11:08:40 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 15 Sep 2008 09:08:40 +0000
Subject: [issue3288] float.as_integer_ratio method is not documented
In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za>
Message-ID: <1221469720.01.0.807967449122.issue3288@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Do we want to mention it in the tutorial?  If not,
> this issue could now be closed.

I think it might be worth mentioning both this and float.hex in the 
tutorial---it would fit well into the floating-point issues section.

Here's a patch.

Added file: http://bugs.python.org/file11494/tutorial_hex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3288>
_______________________________________

From report at bugs.python.org  Mon Sep 15 11:44:30 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 15 Sep 2008 09:44:30 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1221466321.78.0.258022569645.issue3690@psf.upfronthosting.co.za>
Message-ID: <20080915114427.9dtq3a7nggsogs4o@webmail.df.eu>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So how should this bug report be handled? Provide a patch to handle
> getsizeof correctly for small_ints? 'wont fix' because there are issues
> anyway? I would prefer the former and try to come up with a patch if you
> think it is worthwhile.

Fixing it for small_ints would be fine with me - there is specialized
code for long sizeof already. It's the explosion of boolobject that I
dislike.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Mon Sep 15 12:32:13 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 15 Sep 2008 10:32:13 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1221474733.46.0.821098356476.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

It doesn't appear to me to be related to issue 2240, as my build linked
against libpthread:

$ ldd ./python
./python:
        libutil.so.5 => /lib/libutil.so.5 (0x28187000)
        libm.so.4 => /lib/libm.so.4 (0x28193000)
        libpthread.so.2 => /lib/libpthread.so.2 (0x281a9000)
        libc.so.6 => /lib/libc.so.6 (0x281ce000)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Mon Sep 15 12:44:14 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 15 Sep 2008 10:44:14 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221475454.46.0.566639517097.issue3863@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I've briefly got a FreeBSD 7.0 amd64 setup available, and test_threading
passes in this environment.

Short term fix I'd suggest is to only disable this part of the test for
FreeBSD 6.x and earlier (ie platforms freebsd4, freebsd5, freebsd6).

I also checked my OS/2 EMX build and wasn't surprised to see it fail on
the same part of test_threading - fork() on OS/2 EMX is fragile enough
without threads in the mix.

If a disabler is added for FreeBSD as above, 'os2emx' should be in the
same list.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 13:21:09 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Mon, 15 Sep 2008 11:21:09 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221477669.15.0.479257741789.issue3825@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Well, I implemented this months ago, but have been busy with other
things so I haven't updated in a while.  I noticed that the current
version is missing my patches for Atomic Grouping / Possessive
Qualifiers and a number of other patches I added in #2636 , but I do
have working test cases and documentation updates for all the features
I've so far implemented as well as splitting my work into separate
sub-issues to make individual selection easier -- though with a number
of my modifications, I found that there are SO MANY co-dependencies
between, say, an engine modification (item 9) and adding Atomic Grouping
/ Possessive Qualifiers (item 1) and using shared Engine Constants (item
10) that I need a branch for Atomic, a branch for Atomic + Engine Mod 1,
Atomic + Engine Mod 2, Atomic + Shared Constants, Atomic + Engine Mod 1
+ Shared Constants AND Atomic + Engine Mod 2 + Shared Constants, and
those were just THREE item co-dependencies.  My code is all off of the
trunk line for 2.6 and is currently available via my Bazaar repository
under https://code.launchpad.net/~timehorse, where you can access any
source tree via the bazaar version control client.  The main reason I
got stumped in my development which might otherwise have implemented ALL
the issues I intended by now is that very situation I just described
where development of new features is NOT mutually independent.  You can
see by all my branches that the multiplicity of A or B or C is just
nightmarish, but what had to be done to keep issues independent.

Anyway, I'm looking forward to having a look at your suggestions and
think we may take best advantage with combining our work visa vi these
things; after all, there's no point re-inventing the wheel.

Thanks again for your contribution, Matthew!

----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 15 14:15:28 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 15 Sep 2008 12:15:28 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221480928.87.0.598549009663.issue3862@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I've temporarily got a 7.0 amd64 system running and can confirm what you
see.  I checked out the 2.5.2 port patches you mentioned, but all the
ones that seemed related are already in the 2.6rc1 sources.

On a hunch, I used ulimit -v is used to set a process virtual memory
size limit, and the test completed satisfactorily (I set it to 1048756,
ie 1GB).

I'm as yet none the wiser as to what to do with this info...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Mon Sep 15 14:44:22 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 15 Sep 2008 12:44:22 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221482662.42.0.810668253159.issue3862@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

On FreeBSD 7.0 i386, test_array passes without ulimit -v needing to be
set (ie its still the default "unlimited".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Mon Sep 15 14:48:05 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 15 Sep 2008 12:48:05 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221482885.14.0.942054807313.issue3863@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

test_threading also passes on FreeBSD 7.0 i386.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 14:50:49 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Mon, 15 Sep 2008 12:50:49 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221483049.57.0.567360621574.issue3835@psf.upfronthosting.co.za>


Helmut Jarausch <jarausch at skynet.be> added the comment:

I'm using Tcl/Tk  8.5.4  here

        print(":::")
        print(_flatten((self._w, cmd)) + self._options(cnf))

produces:
:::
('.3073836300', 'configure', '-yscrollcommand', '3077632332set')
:::
('.3073835564.3073835660', 'configure', '-text', 'Python documentation 
server at\nhttp://localhost:7464/')
>>> Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python3.0/threading.py", line 507, in 
_bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.0/threading.py", line 462, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.0/pydoc.py", line 1989, in serve
    DocServer(port, callback).serve_until_quit()
  File "/usr/local/lib/python3.0/pydoc.py", line 1971, in __init__
    self.base.__init__(self, self.address, self.handler)
  File "/usr/local/lib/python3.0/socketserver.py", line 401, in __init__
    self.server_activate()
  File "/usr/local/lib/python3.0/pydoc.py", line 1982, in 
server_activate
    if self.callback: self.callback(self)
  File "/usr/local/lib/python3.0/pydoc.py", line 2072, in ready
    text='Python documentation server at\n' + server.url)
  File "/usr/local/lib/python3.0/tkinter/__init__.py", line 1201, in 
configure
    return self._configure('configure', cnf, kw)
  File "/usr/local/lib/python3.0/tkinter/__init__.py", line 1192, in 
_configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: out of stack space (infinite loop?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Mon Sep 15 15:18:14 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 15 Sep 2008 13:18:14 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1221484694.24.0.508353692041.issue3863@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I've attached a simple patch which deactivates
test_3_join_in_forked_from_thread on FreeBSD 6.x and earlier, and also
OS/2 EMX.  With this patch, test_threading completes but...

$ ./python -E -tt Lib/test/regrtest.py test_threading
test_threading
1 test OK.
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

----------
keywords: +patch
Added file: http://bugs.python.org/file11495/test_threading_fbsd6.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Mon Sep 15 15:19:55 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 15 Sep 2008 13:19:55 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221484795.03.0.646251212706.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I know what you mean about the dependencies!

My current problem is that now I'm working with the current trunk, which
means using Visual C++ Express 2008 instead of 2005. When debugging it's
behaving like the debug info is out of date (showing the wrong values
for variables in the debugger, single-stepping to the wrong line, etc).
Rebuilding doesn't fix it. This might take a while. :-(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 15 15:24:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Sep 2008 13:24:35 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221485075.63.0.71026354388.issue3825@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

If you use Visual C++ Express 2005, you can build python from the
PC\VS8.0 directory.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 15 16:13:24 2008
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 15 Sep 2008 14:13:24 +0000
Subject: [issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3
In-Reply-To: <1221311200.34.0.717108733758.issue3856@psf.upfronthosting.co.za>
Message-ID: <p06240806c4f418cc8b33@[10.0.1.221]>


Mitchell Model <mlm at acm.org> added the comment:

Theis the first time I've submitted bug reports to Python.org's 
development efforts, though I've been using Python for many years.  I 
don't know what the procedures are for followup to emails like you 
sent me, and given that the address is reports at bugs.python.org, I'm 
not even sure who -- if anyone -- reads a response like this.  Please 
tell me how to follow up and anything else you'd like to suggest 
about how I could help more effectively.

I retried IDLE it with Python 2.6rc1 and  got a very helpful and 
elaborate error message about not being able to start the subprocess, 
what port it was trying to connect to, and a pointer to information 
about running it without a subprocess.  I had my Mac's Security 
Firewall set to allow all incoming connections, so I don't know why 
it was refusing this one, but I changed the settings to "Set access 
for specific services and applications" and added idle26 and idle30. 
IDLE 2.6rc1 now works.

However, I checked out 3.0 sources from the Subversion repository 
yesterday, but am still getting a problem, though a different one, 
with IDLE30:

Traceback (most recent call last):
   File "<string>", line 1, in <module>
   File "/usrlocal/lib/python3.0/idlelib/run.py", line 76, in main
     sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'

Should I just assume that the development problem will be taking care 
of things like this, or is it helpful for me to report them when I 
encounter them?

Thanks for your response.

	--- Mitchell

>Guilherme Polo <ggpolo at gmail.com> added the comment:
>
>This bug was fixed after b3 was released (r65971). You should retry it
>using python 2.6rc1 or update your sources for py3k.
>
>----------
>nosy: +gpolo
>resolution:  -> out of date
>status: open -> closed
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue3856>
>_______________________________________

Added file: http://bugs.python.org/file11496/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3856>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080915/293383ce/attachment.txt>

From report at bugs.python.org  Mon Sep 15 16:58:10 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 14:58:10 +0000
Subject: [issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3
In-Reply-To: <1221279319.19.0.623858705455.issue3856@psf.upfronthosting.co.za>
Message-ID: <1221490690.17.0.341926062139.issue3856@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The people in the nose list will receive emails each time a message is
sent to the issue.

Now back to your new problem.. the new problem you are reporting here
has been discussed at http://bugs.python.org/issue3628 (where you will
find a solution).

And your final question.. It is very nice if people report any problems
they find, they all will be noticed but some will receive more attention
than others. In your specific bug report, it happened to be already
fixed in the current development version so I just sent a "standard
message". So, finishing up, it is always good to search for issues that
may be the one you are reporting so duplicates are not created.
Sometimes you won't be able to find them, that is fine, but if you find
one be sure to add something to it (if you have something to add) or
don't create a duplicate.

Sorry if this response is too dry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3856>
_______________________________________

From report at bugs.python.org  Mon Sep 15 17:30:22 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 15:30:22 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221492622.4.0.241596018419.issue3835@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uhm, is it caused only by the combination of tk 8.5.4 and py3k, or does
the same happen with tk 8.5.4 and python-trunk ? What about tk 8.5.3 (or
some other of tk 8.5 series) or even tk 8.4.16 and {python-trunk, py3k} ? 

It would be good if you could test some other combination, specially
because I can't reproduce it here with other versions (but I'm compiling
8.5.4 here now).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Mon Sep 15 17:49:45 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 15 Sep 2008 15:49:45 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1221493785.37.0.981783913878.issue2486@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry for the silence:  new country + new job + no internet connection 
outside work = not many opportunities to spend time on this (or any 
other part of Python) at the moment.

I do now have a version 0.2 of the deccoeff type, and more importantly a 
version of decimal.py that's adapted to use it;  all tests in 
test_decimal.py pass, which is a start.  But there's significant work to 
be done tidying up the code, identifying speed-critical bits, and moving 
those bits from Python to C.

I'm wondering where to post the code;  I could post a tarball here but 
it's a bit unwieldy.  Perhaps it would be worth creating a new branch to 
work on this?

This definitely seems like a (>=) two-person task;  any help would be 
much appreciated!  Thanks Facundo and Nick for comments so far.  I also 
wonder whether there are alternative approaches that might do better.

If we follow this approach, I'm doubtful about doing this for 3.0.1; 
even though the API is unchanged, this seems like too big a change for a 
bugfix release, with too great a risk of breakage.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Mon Sep 15 18:37:32 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 15 Sep 2008 16:37:32 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

Unpickling e.g. a large list seems to be really slow in Python 3.0.

The attached test script gives the following results for pickling and
unpickling a list of 1M zeros, showing that although the C
implementation seems to be used in Python 3.0, unpickling is even slower
than with the "pickle" module of Python 2.6!

[hagenf at cluster-06 hagenf]$ python pickletst.py
2.71067500114
2.77484893799
[hagenf at cluster-06 hagenf]$ python3.0 pickletst.py
0.0925059318542
5.76121616364

----------
components: Library (Lib)
files: pickletst.py
messages: 73267
nosy: hagen
severity: normal
status: open
title: Unpickling is really slow
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file11497/pickletst.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Mon Sep 15 18:51:49 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Sep 2008 16:51:49 +0000
Subject: [issue3782] os.write accepts unicode strings
In-Reply-To: <1220568095.62.0.876870722017.issue3782@psf.upfronthosting.co.za>
Message-ID: <1221497509.16.0.490762132728.issue3782@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. I've covered all direct uses of os.write() in the
standard library, but perhaps there are indirect uses. Please review.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11498/oswrite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3782>
_______________________________________

From report at bugs.python.org  Mon Sep 15 18:56:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Sep 2008 16:56:48 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1221497808.63.0.443382083799.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Do the numbers vary if you read the whole file at once and then unpickle
the resulting bytes string?
Large parts of the IO library are written in Python in 3.0, which might
explain the discrepancy.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:07:26 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 17:07:26 +0000
Subject: [issue1602742] itemconfigure returns incorrect text property of text
	items
Message-ID: <1221498446.83.0.546724325562.issue1602742@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The problem is actually on Tkinter side, not really tcl/tk fault here.
Tkinter should be formatting that text option as "{text here}" when the
value contains one or more spaces (it is actually fine to use this tcl
formatting when there are no spaces either).

To try this yourself, just change text to:
text = "{sample text with spaces}"

I can't look at Tkinter source right now to propose a correct solution,
but will do later (today hopefully).

----------
nosy: +gpolo
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602742>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:17:55 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 15 Sep 2008 17:17:55 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1221499075.18.0.309655777101.issue3873@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Yes, it gets much better, but even so (first reading file and timing
only "loads") unpickling takes four times as long in Python 3.0 as with
the old cPickle module:

[hagenf at cluster-06 hagenf]$ python pickletst2.py
0.0744678974152
0.0514161586761
[hagenf at cluster-06 hagenf]$ python3.0 pickletst3.py
0.0911619663239
0.208593845367

But I guess this can still be blamed on the BytesIO implementation...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:18:15 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 15 Sep 2008 17:18:15 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221499095.28.0.753872500589.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Used Visual C++ Express 2005 and the PC\VS8.0 directory. Same problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:24:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Sep 2008 17:24:27 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1221499467.48.0.115217431862.issue3873@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed. If I replace the file with 
    f = io.BytesIO(open("tst", "rb").read())
timings are divided by 20...

After quick profiling, it seems that PyLong_New would benefit from a
free list. len(bytearray) is called very often.
To stay simple, it would be enough to only store longs of length 1 (<2**15).

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:31:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Sep 2008 17:31:04 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221499864.46.0.728725056394.issue3825@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do you have some big source files, of more than 10000 lines?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:31:12 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 17:31:12 +0000
Subject: [issue1222721] tk + setlocale problems...
Message-ID: <1221499872.35.0.531920001169.issue1222721@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222721>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:38:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Sep 2008 17:38:29 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1221500309.53.0.0211179136003.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Gregory had patches for a freelist of long objects in #2013.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:38:44 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 17:38:44 +0000
Subject: [issue1160383] digit-only tag values are mishandled in Tkinter
Message-ID: <1221500324.19.0.15997233962.issue1160383@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160383>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:38:51 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 17:38:51 +0000
Subject: [issue775309] button methods tkButtonDown, etc don't work
Message-ID: <1221500331.09.0.396792100955.issue775309@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775309>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:39:27 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 17:39:27 +0000
Subject: [issue1581476] Text search gives bad count if called from variable
	trace
Message-ID: <1221500367.44.0.187378048548.issue1581476@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581476>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:44:08 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 17:44:08 +0000
Subject: [issue1257772] tkapp read-only attributes
Message-ID: <1221500648.32.0.292440572014.issue1257772@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This was fixed in r38525

----------
nosy: +gpolo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1257772>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:47:17 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 15 Sep 2008 17:47:17 +0000
Subject: [issue1257772] tkapp read-only attributes
Message-ID: <1221500837.32.0.342700584873.issue1257772@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

My bad, r39219 is the one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1257772>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:49:40 2008
From: report at bugs.python.org (maix)
Date: Mon, 15 Sep 2008 17:49:40 +0000
Subject: [issue2138] Add a factorial function
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1221500980.82.0.10792981579.issue2138@psf.upfronthosting.co.za>


maix <mailmaix at gmail.com> added the comment:

I think the unit test is wrong, or at least not as is intended:

You put some numbers in values and shuffle them. But you don't use them
but just range(10) for testing.

----------
nosy: +maix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
_______________________________________

From report at bugs.python.org  Mon Sep 15 19:56:09 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 15 Sep 2008 17:56:09 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221501369.61.0.600898143461.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

_sre.c is over 6000, but it does contain macros. I didn't have this
problem when based on Python 2.5.2 in Express 2005.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 15 20:58:44 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Mon, 15 Sep 2008 18:58:44 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221505124.43.0.7729269173.issue3825@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

I have uploaded my test cases for Atomic Grouping / Possessive
Qualifier, which is the common code we seem to have developed, as this
may be of use to you.  I also have documentation, but for now, would you
mind running these tests against your code to see what the test outputs
and also, how did you come up with the 2x result?  Was that running the
test suite?  Usually, the regexp module is benchmarked against its test
suite and there are timings built into that, so it may be useful if you
could run the unmodified Lib/test/test_re.py you got from the trunk
against the original code before modification and your modification, and
do so a few times to get a good average result on multi-tasking systems,
and post the results here so we can get a good statistical feel for how
your new engine improves efficiency.  Certainly, I support any Engine
that works faster, as I myself have tried to make it faster but ended up
with something 8% slower instead, alas.

Also, good thinking on fixing the Negative Look-behind variable-width
issue; I wish I'd thought of that, but I am curious about something: did
you remove the optimization for fixed-width look-behind?  The old code
only allowed fixed with because that test can be done quickly; I noticed
your code adds a lot of new REV opcodes to handle back-tracking and I
assume look-behind logic for variable-width look-behind.  It would be
handy if the compiler and engine would be able to differentiate between
fixed-width look-behind (optimized as was originally) and variable-width
(using your advanced code).

Thanks to AMK for some of these suggestions.  Your changes are quite
radical though so I am still trying to wade through them all and I still
don't have a full-picture of how you've changed things, but there are
some good ideas here, IMHO, especially if you do indeed get 2x speedup.

Added file: http://bugs.python.org/file11499/test_re.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 15 23:08:20 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Sep 2008 21:08:20 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1221512900.43.0.882635114442.issue2486@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is the kind of project where the sandbox is useful - Facundo's
original decimal work was done there, as was the attempt at a complete
rewrite of the decimal module in C (which turned out to be a less than
optimal approach to the speed problem).

So I would suggest either a new directory in the sandbox, or re-using
Facundo's original directory (which includes the telco benchmark)

http://svn.python.org/view/sandbox/trunk/decimal

And I agree that it is far more sensible to target 2.7/3.1 at this stage
- the 3.0 slowdown, while real, actually isn't as bad as I expected, and
even if it's large enough to be unacceptable to heavy users of Decimal,
the only consequence is that they will have to hold off on migrating to
3.x for 12-18 months.

Should we add something specific to the 3.0 release notes pointing out
that there is approximately a 25% slowdown in the decimal module
relative to 2.x?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Mon Sep 15 23:53:29 2008
From: report at bugs.python.org (jeff)
Date: Mon, 15 Sep 2008 21:53:29 +0000
Subject: [issue3874] documentation bug: HTMLParser needs to document
	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>


New submission from jeff <freyley at gmail.com>:

the unknown_decl function is critical to dealing with MS Office
generated HTML files. There's no documentation of that. The default
behavior of the function is to error, which is reasonable, but it should
be stated in the documentation.

----------
components: Library (Lib)
messages: 73282
nosy: freyley
severity: normal
status: open
title: documentation bug: HTMLParser needs to document unknown_decl
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3874>
_______________________________________

From report at bugs.python.org  Tue Sep 16 00:21:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 15 Sep 2008 22:21:27 +0000
Subject: [issue3782] os.write accepts unicode strings
In-Reply-To: <1220568095.62.0.876870722017.issue3782@psf.upfronthosting.co.za>
Message-ID: <1221517287.47.0.620221232409.issue3782@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Assuming you've run the test suite, go ahead and apply.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3782>
_______________________________________

From report at bugs.python.org  Tue Sep 16 00:52:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 15 Sep 2008 22:52:28 +0000
Subject: [issue3875] provide a "cmem" role
In-Reply-To: <1221519147.92.0.0786016698466.issue3875@psf.upfronthosting.co.za>
Message-ID: <1221519147.92.0.0786016698466.issue3875@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This would be a useful counterpart to the cmember directive.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 73284
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: provide a "cmem" role
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3875>
_______________________________________

From report at bugs.python.org  Tue Sep 16 01:03:50 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Sep 2008 23:03:50 +0000
Subject: [issue3782] os.write accepts unicode strings
In-Reply-To: <1220568095.62.0.876870722017.issue3782@psf.upfronthosting.co.za>
Message-ID: <1221519830.74.0.700448483143.issue3782@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks, committed in r66469.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3782>
_______________________________________

From report at bugs.python.org  Tue Sep 16 01:56:27 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 15 Sep 2008 23:56:27 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1221522987.17.0.0738278395421.issue2486@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Nick said:

> So I would suggest either a new directory in the sandbox, or 
> re-using Facundo's original directory (which includes the 
> telco benchmark)

+1


> And I agree that it is far more sensible to target 2.7/3.1 at 
> this stage - the 3.0 slowdown, while real, actually isn't as bad 
> as I expected, and even if it's large enough to be unacceptable 
> to heavy users of Decimal, the only consequence is that they will 

I'm not seeing this job as a way to solve the 3.0 slowdown, but more as
the way to slowly, but steadily, replace parts of Decimal from Python to
C as needed.

So, I'm +1 to target this to 3.1, and I'm -0 to register the slowdown in
the releases notes (those who use Decimal aren't really in it for speed...).

Thank you!!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Tue Sep 16 02:05:30 2008
From: report at bugs.python.org (Gary Poster)
Date: Tue, 16 Sep 2008 00:05:30 +0000
Subject: [issue3829] Tuple comparison masking exception
In-Reply-To: <1221078780.65.0.750398332014.issue3829@psf.upfronthosting.co.za>
Message-ID: <1221523530.07.0.14683915298.issue3829@psf.upfronthosting.co.za>


Changes by Gary Poster <gary at modernsongs.com>:


----------
nosy: +gary

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3829>
_______________________________________

From report at bugs.python.org  Tue Sep 16 03:12:37 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 16 Sep 2008 01:12:37 +0000
Subject: [issue1160383] digit-only tag values are mishandled in Tkinter
Message-ID: <1221527557.82.0.524156368932.issue1160383@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I don't see the bug here. items in a Canvas may be named either as id or
as a tag. If you specify items by something that is actually accepted as
an integer ("123" for instance) then it is assumed to refer to a single
item with id 123.

In your case you have an item with id "1", and when you do: 

c.find_withtag("123")

Tk tries to find an item with that id, which doesn't exist and returns
an empty tuple.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160383>
_______________________________________

From report at bugs.python.org  Tue Sep 16 03:38:14 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 16 Sep 2008 01:38:14 +0000
Subject: [issue1602742] itemconfigure returns incorrect text property of text
	items
Message-ID: <1221529094.5.0.583673150408.issue1602742@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uhm, now I see.. Tkinter already formats it correctly, and you shouldn't
be using itemconfigure for this task. If you try it directly in tk, like
this:

canvas .c
.c create text 0 0 -text {a b}
.c itemconfigure 1 -text

You would get something like this:

-text {} {} {} {a b}

While

.c itemcget 1 -text

Will return the same as Python: "a b"

Now what remains is to see how useful is to use itemconfigure for this,
and if it is worth making canvas.itemconfigure(id)['text'][-1] return "a
b" instead of ("a", "b"). Changing Misc._configure is too risky given
there are no tests for Tkinter (and I find it weird sometimes, someone
will still have to explain me why Tkinter plays with cnf and kw all the
time), the other option involves leaving these special needings in Text
and is something I dislike because other widgets could use these new
things that would be added. 
Yet another option would be to start writing unit tests for Tkinter and
much of these bugs would end up being caught and hopefully fixed properly.

----------
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602742>
_______________________________________

From report at bugs.python.org  Tue Sep 16 03:42:11 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 16 Sep 2008 01:42:11 +0000
Subject: [issue775309] button methods tkButtonDown, etc don't work
Message-ID: <1221529331.07.0.0128005344334.issue775309@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

tkButtonDown and co. are long gone, you shouldn't be relying on them. If
you get tk sources, you will see that tkButtonDown is called when you do
btn.event_generate('<1>').

The best thing to do here is actually remove these methods that call
commands that shouldn't be used anymore and are not directly available.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775309>
_______________________________________

From report at bugs.python.org  Tue Sep 16 04:28:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Sep 2008 02:28:17 +0000
Subject: [issue2619] Document PEP 3118
In-Reply-To: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>
Message-ID: <1221532097.19.0.328729987248.issue2619@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The bulk of the C-API is in r66476. Somebody definitely needs to review
it; I mostly extracted it directly from the PEP, and I understand that's
a little different from reality here. I'll lower priority, and we can
close it after some looks at my changes. Thanks!

----------
priority: deferred blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2619>
_______________________________________

From report at bugs.python.org  Tue Sep 16 07:10:52 2008
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 16 Sep 2008 05:10:52 +0000
Subject: [issue3876] multiprocessing does not compile on *BSD and potentialy
	other systems
In-Reply-To: <1221541852.59.0.453473189868.issue3876@psf.upfronthosting.co.za>
Message-ID: <1221541852.59.0.453473189868.issue3876@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

Compiling `multiprocessing` on OpenBSD fails. `iovec` is not declared.

Adding the following line to multiprocessing.c solves the problem:
#include <sys/uio.h>

But right after I got:
./python:build/lib.openbsd-4.4-amd64-2.6/_multiprocessing.so: undefined
symbol 'sem_timedwait'

It looks like multiprocessing is using a function that is not defined in
OpenBSD and very likely on other BSD's (FreeBSD & NetBSD don't have a
man page for this function)

According to this page, some other systems don't have this function:
http://www.gnu.org/software/gnulib/manual/html_node/sem_005ftimedwait.html

----------
components: Extension Modules
messages: 73291
nosy: henry.precheur
severity: normal
status: open
title: multiprocessing does not compile on *BSD and potentialy other systems
type: compile error
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3876>
_______________________________________

From report at bugs.python.org  Tue Sep 16 07:22:22 2008
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 16 Sep 2008 05:22:22 +0000
Subject: [issue3877] test_fileio fails on OpenBSD 4.4
In-Reply-To: <1221542542.67.0.83676817672.issue3877@psf.upfronthosting.co.za>
Message-ID: <1221542542.67.0.83676817672.issue3877@psf.upfronthosting.co.za>


New submission from Henry Precheur <henry at precheur.org>:

test_fileio
test test_fileio failed -- Traceback (most recent call last):
  File "/home/henry/compile/python2.6/Lib/test/test_fileio.py", line
155, in testAbles
    self.assertEquals(f.seekable(), False)
AssertionError: True != False

Apparently it is expected to "fail" for *BSD systems since darwin,
freebsd and sunos / solaris are not expected to pass this test:

                    if sys.platform != "darwin" and \
                       not sys.platform.startswith('freebsd') and \
                       not sys.platform.startswith('sunos'):
                        # Somehow /dev/tty appears seekable on some BSDs
                        self.assertEquals(f.seekable(), False)

I just added openbsd to the list and the test works. I would also
suggest to add netbsd, since it is very very likely to have the same
behavior.

----------
components: Extension Modules
files: test_fileio_openbsd.diff
keywords: patch
messages: 73292
nosy: henry.precheur
severity: normal
status: open
title: test_fileio fails on OpenBSD 4.4
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11500/test_fileio_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3877>
_______________________________________

From report at bugs.python.org  Tue Sep 16 09:54:34 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 16 Sep 2008 07:54:34 +0000
Subject: [issue3859] test_sys.Sizeof fails on win64
In-Reply-To: <1221312951.19.0.765623147021.issue3859@psf.upfronthosting.co.za>
Message-ID: <1221551674.12.0.682281903924.issue3859@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Fixed in r66480.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3859>
_______________________________________

From report at bugs.python.org  Tue Sep 16 12:10:12 2008
From: report at bugs.python.org (T.Morin)
Date: Tue, 16 Sep 2008 10:10:12 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>
Message-ID: <1221559812.1.0.774290263407.issue2574@psf.upfronthosting.co.za>


Changes by T.Morin <thomas-python at treizh.net>:


----------
nosy: +tmorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2574>
_______________________________________

From report at bugs.python.org  Tue Sep 16 13:39:03 2008
From: report at bugs.python.org (Matthijs Kooijman)
Date: Tue, 16 Sep 2008 11:39:03 +0000
Subject: [issue1611944] sndhdr.what() does not recognize wav file
Message-ID: <1221565143.96.0.798153397652.issue1611944@psf.upfronthosting.co.za>


Matthijs Kooijman <matthijs at stdin.nl> added the comment:

I've written a new patch, which works a bit better. You can find the new
patch attached.

I've restructed the patch to prevent code duplication. Also, it now
works with other chunks than bext (I had a file with a list chunk which
triggered my interest in this bug). This is done with a hardcoded list
of valid chunks. However, it seems that there is no complete list of
valid chunk types, so it might be better to remove the chunk type check
alltogether.

Also, this patch explicitly checks for overflow, since taking a slice of
a sequence does not seem to trigger an IndexError, but just return an
empty sequence.

----------
keywords: +patch
nosy: +matthijs
Added file: http://bugs.python.org/file11501/sndhdr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1611944>
_______________________________________

From report at bugs.python.org  Tue Sep 16 14:00:31 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Tue, 16 Sep 2008 12:00:31 +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: <1221566431.72.0.323986074747.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Update 16 Sep 2008:

Based on the work for issue #3825, I would like to simply update the
item list as follows:

1) Atomic Grouping / Possessive Qualifiers (See also Issue #433030)
[Complete]

2) Match group names as attributes (e.g. match.foo) [Complete save
issues outlined above]

3) Match group indexing (e.g. match['foo'], match[3])

4) Perl-style back-references (e.g. compile(r'(a)\g{-1}'), and possibly
adding the r'\k' escape sequence for keywords.

5) Parenthesis-Aware Python Comment (e.g. r'(?P#...)') [Complete]

6) Expose support for Template expressions (expressions without repeat
operators), adding test cases and documentation for existing code.

7) Larger compiled Regexp cache (256 vs. 100) and reduced thrashing
risk. [Complete]

8) Character Classes (e.g. r'[:alphanum:]')

9) Proposed Engine redesigns and cleanups (core item only contains
cleanups and comments to the current design but does not modify the design).

9-1) Single-loop Engine redesign that runs 8% slower than current.
[Complete]

9-1-1) 3-loop Engine redesign that runs 10% slower than current. [Complete]

9-2) Matthew Bernett's Engine redesign as per issue #3825

10) Have all C-Python shared constants stored in 1 place
(sre_constants.py) and generated by that into C constants
(sre_constants.h). [Complete AFAICT]

11) Scan Perl 5.10.0 for other potential additions that could be
implemented for Python.

12) Documentation suggestions by Jim J. Jewett [Complete]

13) Add grouptuples method to the Match object (i.e. match.grouptuples()
returns (<index>, <name or None>, <value>) ) suitable for iteration.

14) UNICODE match group names, as per PEP-3131.

15) Add __doc__ strings and other Python niceties to the Pattern_Type,
Match_Type and Scanner_Type (experimental).

16) Implement any remaining TODOs and FIXMEs in the Regexp modules.

16-1) Allow for the disassociation of a source string from a Match_Type,
assuming this will still leave the object in a "reasonable" state.

17) Variable-length [Positive and Negative] Look-behind assertions, as
described and implemented in Issue #3825.

---

Now, we have a combination of Items 1, 9-2 and 17 available in issue
#3825, so for now, refer to that issue for the 01+09-02+17 combined
solution.  Eventually, I hope to merge the work between this and that issue.

I sadly admit I have made not progress on this since June because
managing 30 some lines of development, some of which having complex
diamond branching, e.g.:

01 is the child of Issue2636
09 is the child of Issue2636
10 is the child of Issue2636
09-01 is the child of 09
09-01-01 is the child of 09-01
01+09 is the child of 01 and 09
01+10 is the child of 01 and 10
09+10 is the child of 09 and 10
01+09-01 is the child of 01 and 09-01
01+09-01-01 is the child of 01 and 09-01-01
09-01+10 is the child of 09-01 and 10
09-01-01+10 is the child of 09-01-01 and 10

Which all seems rather simple until you wrap your head around:

01+09+10 is the child of 01, 09, 10, 01+09, 01+10 AND 09+10!

Keep in mind the reason for all this complex numbering is because many
issues cannot be implemented in a vacuum: If you want Atomic Grouping,
that's 1 implementation, if you want Shared Constants, that's a
different implementation. but if you want BOTH Atomic Grouping and
Shared Constants, that is a wholly other implementation because each
implementation affects the other.  Thus, I end up with a plethora of
branches and a nightmare when it comes to merging which is why I've been
so slow in making progress.  Bazaar seems to be very confused when it
comes to a merge in 6 parts between, for example 01, 09, 10, 01+09,
01+10 and 09+10, as above.  It gets confused when it sees the same
changes applied in a previous merge applied again, instead of simply
realizing that the change in one since last merge is EXACTLY the same
change in the other since last merge so effectively there is nothing to
do; instead, Bazaar gets confused and starts treating code that did NOT
change since last merge as if it was changed and thus tries to role back
the 01+09+10-specific changes rather than doing nothing and generates a
conflict.  Oh, that I could only have a version control system that
understood the kind of complex branching that I require!

Anyway, that's the state of things; this is me, signing out!

----------
title: Regexp 2.6 (modifications to current re 2.2.2) -> Regexp 2.7 (modifications to current re 2.2.2)
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Sep 16 14:09:17 2008
From: report at bugs.python.org (anupam)
Date: Tue, 16 Sep 2008 12:09:17 +0000
Subject: [issue3878] urllib2 is not working with proxy for HTTPS
In-Reply-To: <1221566957.02.0.0947477641414.issue3878@psf.upfronthosting.co.za>
Message-ID: <1221566957.02.0.0947477641414.issue3878@psf.upfronthosting.co.za>


New submission from anupam <anupam.basak at gmail.com>:

urllib2.openurl is not working with proxy for HHTPS. Please provide me 
solution for this.

----------
components: Library (Lib)
messages: 73296
nosy: anupam
severity: normal
status: open
title: urllib2 is not working with proxy for HTTPS
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3878>
_______________________________________

From report at bugs.python.org  Tue Sep 16 14:25:52 2008
From: report at bugs.python.org (Dan OD)
Date: Tue, 16 Sep 2008 12:25:52 +0000
Subject: [issue3774] tkinter Menu.delete bug
In-Reply-To: <1220534371.28.0.918007681781.issue3774@psf.upfronthosting.co.za>
Message-ID: <1221567952.55.0.837093180008.issue3774@psf.upfronthosting.co.za>


Dan OD <djo35 at cam.ac.uk> added the comment:

It may be because I'm calling delete incorrectly (I don't think so - see 
below) but I'm getting an error

  File "C:\CCPN\ccpn\python\memops\gui\Menu.py", line 127, in 
deleteMenuItems
    self.delete(0, Tkinter.END)
  File "C:\Python-2.6_svn\lib\lib-tk\Tkinter.py", line 2670, in delete
    if c in self._tclCommands:
TypeError: argument of type 'NoneType' is not iterable

Which can easily be fixed with 

- if c in self._tclCommands:
+ if c and c in self._tclCommands:

line 2670 Tkinter.py

Should I create a patch or have I missed something? Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3774>
_______________________________________

From report at bugs.python.org  Tue Sep 16 14:37:17 2008
From: report at bugs.python.org (vila)
Date: Tue, 16 Sep 2008 12:37:17 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>


New submission from vila <v.ladeuil+bugs-python at free.fr>:

With or without this patch, running:

./python.exe -E -tt ./Lib/test/regrtest.py -l -u network 
test_urllib2net test_urllibnet test_socketserver test_SimpleHTTPServer 

succeeds

Since this is a regression from 2.5, can this patch be applied to 2.6
final ?

----------
files: bug-no-proxy.patch
keywords: patch
messages: 73298
nosy: vila
severity: normal
status: open
title: 2.6 regression in urllib.getproxies_environment
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11502/bug-no-proxy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Tue Sep 16 14:55:27 2008
From: report at bugs.python.org (jan matejek)
Date: Tue, 16 Sep 2008 12:55:27 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221569727.9.0.403872070517.issue3879@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/issue3879>
_______________________________________

From report at bugs.python.org  Tue Sep 16 15:11:06 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Sep 2008 13:11:06 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221570666.88.0.728657518074.issue3862@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Does the attached patch help fix this at all?  I encountered possibly the 
same problem on a 64-bit Mac build of Python, and this patch fixed the 
problem for me.

----------
keywords: +patch
nosy: +marketdickinson
Added file: http://bugs.python.org/file11503/64bit_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Tue Sep 16 15:45:16 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Sep 2008 13:45:16 +0000
Subject: [issue3880] _tkinter._flatten() doesn't check PySequence_Size() error
	code
In-Reply-To: <1221572716.31.0.755070088085.issue3880@psf.upfronthosting.co.za>
Message-ID: <1221572716.31.0.755070088085.issue3880@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PySequence_Size() returns -1 on TypeError (object has no size), but 
_tkinter._flatten() ignores this error. Here is a patch with a 
testcase for _tkinter.

----------
components: Library (Lib)
files: _tkinter_flatten.patch
keywords: patch
messages: 73300
nosy: haypo
severity: normal
status: open
title: _tkinter._flatten() doesn't check PySequence_Size() error code
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11504/_tkinter_flatten.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3880>
_______________________________________

From report at bugs.python.org  Tue Sep 16 15:48:38 2008
From: report at bugs.python.org (Jacob)
Date: Tue, 16 Sep 2008 13:48:38 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>


New submission from Jacob <jacoberen at gmail.com>:

Hello.

I run Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) on Windows Vista
Home Premium.
IDLE won't start if not installed in the default directory.
When insalled in a custom directory, running idle.py
(\Lib\idlelib\idle.py) produces this error:

"Traceback (most recent call last):
File "C:\Programmer\Python\lib\idlelib\idle.py", line 21, in <module>
idlelib.PyShell.main()
File "C:\Programmer\Python\lib\idlelib\PyShell.py", line 1390, in main
root= Tk(className="Idle")
File "C:\Programmer\Python\lib\idlelib\Tkinter.py", line 1636, in
__init__ self.tk = _tkinter.create(screenName, baseName, className,
interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following
directories: {C:\Programmer\Python\tcl\tcl8.4}
{C:\Programmer\Python\tcl\tcl8.4} C:/Programmer/Python/tcl/tcl8.4
C:/Programmer/Python/lib/tcl8.4 C:/Programmer/Python/lib/tcl8.4
C:/lib/tcl8.4 C:/library C:/tcl8.4/library


This probable means that Tcl wasn't installed properly."

----------
components: IDLE, Library (Lib), Windows
messages: 73301
nosy: kimsey0
severity: normal
status: open
title: IDLE won't start in custom directory.
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Tue Sep 16 17:19:44 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 16 Sep 2008 15:19:44 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221578384.49.0.640494203401.issue3835@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Just reproduced the issue under python-trunk with tcl/tk 8.5.4 and 8.5.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Tue Sep 16 17:42:21 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 16 Sep 2008 15:42:21 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221579741.18.0.323609509935.issue3835@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

But it happens only if you don't build tcl/tk with --enable-threads =)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Tue Sep 16 19:00:30 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 16 Sep 2008 17:00:30 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221584430.03.0.487380627372.issue3835@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

If you remove the widget.config calls in GUI.ready you will notice the
problem "goes away", but note that this method is called from another
thread while you have a non-thread-safe tcl/tk lib (I'm assuming you
didn't compile it with --enable-threads). So.. using multiple threads in
Python while Tcl is compiled without --enable-threads isn't supported at
all.

To reproduce the problem try this (change Tkinter to tkinter if py3k):


import threading
import Tkinter

lbl = Tkinter.Label(text="hi")
threading.Thread(target=lambda: lbl.configure(text="hi there")).start()
lbl.mainloop()


If your tcl/tk libs weren't compiled with --enable-threads this should
get you an "TclError: out of stack space (infinite loop?)". A
documentation note may be added somewhere, but nothing much else is
going to happen (that is what I believe at least).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Tue Sep 16 19:20:40 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 16 Sep 2008 17:20:40 +0000
Subject: [issue3878] urllib2 is not working with proxy for HTTPS
In-Reply-To: <1221566957.02.0.0947477641414.issue3878@psf.upfronthosting.co.za>
Message-ID: <1221585640.17.0.185110342619.issue3878@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Anupam, if you are in a hurry, please patch your installation with
patches uploaded to this Issue1424152.
Otherwise, you got to wait for 2.6.1 or 3.0.1 for the above fix to come
as a release.

This is a duplicate issue, can be closed.

Thanks.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3878>
_______________________________________

From report at bugs.python.org  Tue Sep 16 20:20:58 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 16 Sep 2008 18:20:58 +0000
Subject: [issue2887] bsddb3 needs to be ported to Python 3.0
In-Reply-To: <1210915662.48.0.494614370174.issue2887@psf.upfronthosting.co.za>
Message-ID: <1221589258.02.0.516007533303.issue2887@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

bsddb is officially dropped in Python 3.0. Too bad :(. I close this issue.

bsddb supports Python 3.0 via a separate project, downloadable from PYPI.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2887>
_______________________________________

From report at bugs.python.org  Tue Sep 16 20:30:51 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 16 Sep 2008 18:30:51 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1221589851.02.0.0562670945989.issue3720@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Tue Sep 16 20:57:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 16 Sep 2008 18:57:39 +0000
Subject: [issue3878] urllib2 is not working with proxy for HTTPS
In-Reply-To: <1221566957.02.0.0947477641414.issue3878@psf.upfronthosting.co.za>
Message-ID: <1221591459.44.0.0901664297271.issue3878@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> urllib/urllib2: HTTPS over (Squid) Proxy fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3878>
_______________________________________

From report at bugs.python.org  Tue Sep 16 22:33:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Sep 2008 20:33:47 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221597227.95.0.510902025528.issue3879@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It would be nice to have a test for the patch.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Tue Sep 16 22:40:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Sep 2008 20:40:25 +0000
Subject: [issue1611944] sndhdr.what() does not recognize wav file
Message-ID: <1221597625.3.0.615777693173.issue1611944@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1611944>
_______________________________________

From report at bugs.python.org  Tue Sep 16 22:49:19 2008
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 16 Sep 2008 20:49:19 +0000
Subject: [issue3549] Missing IDLE Preferences on Mac
In-Reply-To: <1218662954.17.0.753425221317.issue3549@psf.upfronthosting.co.za>
Message-ID: <1221598159.4.0.27873492059.issue3549@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

Compiling with configure --enable-framework, from updated SVN sources
today plus the change suggested in issue 3628, IDLE works with both
2.6rc1 and 3.0b3.  There is still no options menu, but there is now a
Preferences item on the IDLE menu, where this more appropriately belongs
on the Mac.  However, IDLE Help still refers to the Options menu; on the
Mac, the Help information should refer to the Preferences item on the
IDLE menu instead of Options item, or at least add a comment that that's
where the functionality of Options appears on the Mac.

----------
nosy: +MLModel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3549>
_______________________________________

From report at bugs.python.org  Tue Sep 16 22:56:55 2008
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 16 Sep 2008 20:56:55 +0000
Subject: [issue3882] Bottom buttons of IDLE Preferences Pane on Mac not wide
	enough for their text.
In-Reply-To: <1221598615.03.0.258221712329.issue3882@psf.upfronthosting.co.za>
Message-ID: <1221598615.03.0.258221712329.issue3882@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The text of the buttons on the bottom of the Mac IDLE Preferences pane
is cut off in 2.6rc1 and 3.0b3 (framework builds).  This was not true in
2.5.1.

----------
messages: 73309
nosy: MLModel
severity: normal
status: open
title: Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text.
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3882>
_______________________________________

From report at bugs.python.org  Tue Sep 16 22:57:25 2008
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 16 Sep 2008 20:57:25 +0000
Subject: [issue3883] Bottom buttons of IDLE Preferences Pane on Mac not wide
	enough for their text.
In-Reply-To: <1221598645.05.0.789748104063.issue3883@psf.upfronthosting.co.za>
Message-ID: <1221598645.05.0.789748104063.issue3883@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The text of the buttons on the bottom of the Mac IDLE Preferences pane
is cut off in 2.6rc1 and 3.0b3 (framework builds).  This was not true in
2.5.1.

----------
components: IDLE
messages: 73310
nosy: MLModel
severity: normal
status: open
title: Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text.
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3883>
_______________________________________

From report at bugs.python.org  Tue Sep 16 22:58:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Sep 2008 20:58:04 +0000
Subject: [issue3882] Bottom buttons of IDLE Preferences Pane on Mac not wide
	enough for their text.
In-Reply-To: <1221598615.03.0.258221712329.issue3882@psf.upfronthosting.co.za>
Message-ID: <1221598684.89.0.472472117084.issue3882@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3882>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:06:11 2008
From: report at bugs.python.org (Kirill Simonov)
Date: Tue, 16 Sep 2008 21:06:11 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>


New submission from Kirill Simonov <xi at gamma.dn.ua>:

I wonder why the module 'turtle' was moved to the 'tkinter' package.  It
is not a part of Tk, it does not provide new or extend existing tkinter
API.  While it uses tkinter, so do pydoc or idle; this is just an
implementation detail.  If some day a new GUI library replaces tkinter
in the standard Python library, turtle's interface will not have to be
changed, only the implementation.  Moreover this change unnecessarily
breaks all existing demos and tutorials that use turtle.  Why do this if
it does not give any substantial benefits?  Finally, 'import turtle' is
easier than 'from tkinter import turtle' for complete newbies in
programming, who are the primary users of this module.

So I propose to keep turtle a top-level module as it was in Python 1 and 2.

----------
components: Library (Lib)
messages: 73311
nosy: kirill_simonov
severity: normal
status: open
title: turtle in the tkinter package?
type: feature request
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:09:49 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Sep 2008 21:09:49 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I found two differents bugs using Fusil the fuzzer.

(1) On db_env_create() error in newDBEnvObject(), self->db_env is not 
set and so use of this pointer may crashs.

(2) DBEnv_dealloc() may raise an exception (DBEnv_close_internal() 
calls makeDBError()) but the garbage collector dislike exceptions!

Example of (2):
----
$ python
>>> import gc, _bsddb; env=_bsddb.DBEnv(3); del env
>>> gc.collect(); gc.collect()
Exception bsddb.db.DBNoServerError: (-30992, 'DB_NOSERVER: Fatal 
error, no RPC server -- No Berkeley DB RPC server environment') 
in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
----

----------
components: Library (Lib)
files: _bsddb.patch
keywords: patch
messages: 73312
nosy: haypo
severity: normal
status: open
title: errors on _bsddb creation and dealloc
versions: Python 2.6
Added file: http://bugs.python.org/file11505/_bsddb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:13:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Sep 2008 21:13:00 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221599580.73.0.345519874791.issue3885@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> jcea
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:15:22 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Sep 2008 21:15:22 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221599722.33.0.753365634606.issue3885@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About the bug (1): it also occurs in DBEnv_dealloc() but 
DBEnv_dealloc() is directly called from newDBEnvObject() with 
Py_DECREF(self);. The two bugs can be reproduces with dummy DBenv() 
arguments, eg. "DBEnv(92)".

Backtrace using gdb:
-----
$ gdb ./python
...
>>> import _bsddb; _bsddb.DBenv(92)
...
Program received signal SIGSEGV, Segmentation fault.

0xb7cc8f5e in DBEnv_close_internal (self=0x83385f0, flags=0) 
at ../Modules/_bsddb.c:3989
3989            err = self->db_env->close(self->db_env, flags);
(gdb) print self->db_env
$1 = (DB_ENV *) 0xfffffffe
-----

There db_env value is not set.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:16:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Sep 2008 21:16:34 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1221599794.82.0.472897958646.issue3884@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Unfortunately, as we are approaching 3.0rc1, it is too late to make a
change like this. I'm assigning this to Brett if he has an opinion, but
I don't expect this change to be able to happen.

----------
assignee:  -> brett.cannon
nosy: +benjamin.peterson, brett.cannon
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:22:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 16 Sep 2008 21:22:44 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1221600164.29.0.478853193415.issue3881@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Do you have TCL_DIR or TK_DIR environment variables set?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:26:40 2008
From: report at bugs.python.org (Jacob)
Date: Tue, 16 Sep 2008 21:26:40 +0000
Subject: [issue3881] IDLE won't start in custom directory.
In-Reply-To: <1221572918.25.0.474796677446.issue3881@psf.upfronthosting.co.za>
Message-ID: <1221600400.79.0.184550558855.issue3881@psf.upfronthosting.co.za>


Jacob <jacoberen at gmail.com> added the comment:

No, nothing.
It's just a standart clean installation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3881>
_______________________________________

From report at bugs.python.org  Tue Sep 16 23:54:23 2008
From: report at bugs.python.org (Mark Hirota)
Date: Tue, 16 Sep 2008 21:54:23 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1221602063.76.0.529945396943.issue1757072@psf.upfronthosting.co.za>


Mark Hirota <markhirota at users.sourceforge.net> added the comment:

I'd like to piggyback on this issue if okay :D

I have some zipfiles I'm working with that contain junk in the extra 
fields. The ZipFile object croaks at the call to the 
ZipInfo._decodeExtra() call when it could really just ignore the error.

Example of traceback:

>>> zf = zipfile.ZipFile('bad.zip', 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "zipfile.py", line 346, in __init__
    self._GetContents()
  File "zipfile.py", line 366, in _GetContents
    self._RealGetContents()
  File "zipfile.py", line 424, in _RealGetContents
    x._decodeExtra()
  File "zipfile.py", line 267, in _decodeExtra
    tp, ln = unpack('<hh', extra[:4])
  File "/usr/lib/python2.5/struct.py", line 87, in unpack
    return o.unpack(s)
struct.error: unpack requires a string argument of length 4

While I'm working to track down the source of the "extra junk" -- this 
type of error falls into the same category: Python zipfile hits an 
issue that most zip tools are fine with.

----------
nosy: +markhirota

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_______________________________________

From report at bugs.python.org  Wed Sep 17 00:31:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 16 Sep 2008 22:31:26 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1221604286.98.0.804780465557.issue3884@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

As Benjamin said, it's too late in the release cycle to change this.

Plus turtle is entirely Tk-dependent so putting in the package makes
sense to me. It also isn't important enough to be a top-level package.
Finally, I disagree that telling a newbie to type ``from tkinter import
turtle`` is any more difficult than to tell them to type ``import
tkinter``; if they don't know about importing then either form won't
make sense to them.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Wed Sep 17 00:49:22 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 16 Sep 2008 22:49:22 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221605362.72.0.522552742256.issue3885@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Good catch. I've patched my private branch. Following 2.6 patches, if
anybody can provide a review, since we are in RC status.

I was wondering if we must protect other objects from raising exceptions
in GC. For example, DB objects.

What do you think?.

(I have broken my left wrist ten days ago. If you can write a testcase
showing the issue and a patch for it, would be very nice).

----------
keywords: +needs review
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 17 02:21:15 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Sep 2008 00:21:15 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221610875.18.0.847204540632.issue3885@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a test to reproduce the crash. I don't know db_env_create() 
function, so I don't know what are "invalid arguments". So I used 
~DB_RPCCLIENT. "gc.collect()" is to detect the bug (2).

About other objects dealloc method...

DBEnv_dealloc()
  `-> DBEnv_close_internal(): RETURN_IF_ERR()
DB_dealloc()
  `-> DB_close_internal(): RETURN_IF_ERR()
DBC_dealloc() 
  `-> DBC_close_internal(): RETURN_IF_ERR()
DBSequence_dealloc()
  `-> DBSequence_close_internal(): RETURN_IF_ERR()
DBTxn_dealloc()
  `-> DBTxn_abort_discard_internal(): RETURN_IF_ERR()

DBLock_dealloc() looks ok.

Added file: http://bugs.python.org/file11506/_bsddb_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 17 03:02:14 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Sep 2008 01:02:14 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

CVE-2008-2316
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2316) notes that
_hashopenssl.c has a potential integer overflow. Attached is the patch
sent to PSRT.

----------
components: Extension Modules
files: CVE-2008-2316-trunk.diff
keywords: patch, patch
messages: 73321
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Integer overflow in _hashopenssl.c (CVE-2008-2316)
type: security
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11507/CVE-2008-2316-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Wed Sep 17 03:05:11 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Sep 2008 01:05:11 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1221613511.96.0.627979121449.issue2620@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Wed Sep 17 04:02:55 2008
From: report at bugs.python.org (John Ehresman)
Date: Wed, 17 Sep 2008 02:02:55 +0000
Subject: [issue3887] Python 2.6 doesn't run after installation on amd64
In-Reply-To: <1221616975.51.0.807116578154.issue3887@psf.upfronthosting.co.za>
Message-ID: <1221616975.51.0.807116578154.issue3887@psf.upfronthosting.co.za>


New submission from John Ehresman <jpe at wingware.com>:

The amd64 python 2.6rc1 won't run after installation on Vista.  It fails
with the error (from the event log) of 

Activation context generation failed for "C:\Python26\python.exe".Error
in manifest or policy file "C:\Python26\Microsoft.VC90.CRT.MANIFEST" on
line 11. Component identity found in manifest does not match the
identity of the component requested. Reference is
Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
Definition is
Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
Please use sxstrace.exe for detailed diagnosis.

Looking at the C:\Python26\Microsoft.VC90.CRT.MANIFEST file, the
processorArchitecture is set to x86

----------
components: Windows
messages: 73322
nosy: jpe
severity: normal
status: open
title: Python 2.6 doesn't run after installation on amd64
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3887>
_______________________________________

From report at bugs.python.org  Wed Sep 17 09:15:26 2008
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 17 Sep 2008 07:15:26 +0000
Subject: [issue3888] [PATCH] Document more deprecated modules in What's New in
	Python 2.6
In-Reply-To: <1221635726.9.0.855015498496.issue3888@psf.upfronthosting.co.za>
Message-ID: <1221635726.9.0.855015498496.issue3888@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:

The What's New doc is missing a few of these, I've added the ones 
mentioned in PEP 361 that weren't already there.

I also corrected popen2's entry; it's always deprecated in 2.6, not just 
in the 3.0 warnings mode

----------
assignee: georg.brandl
components: Documentation
files: whatsnew-depmod2.6-r66484.diff
keywords: patch
messages: 73323
nosy: georg.brandl, pjenvey
severity: normal
status: open
title: [PATCH] Document more deprecated modules in What's New in Python 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file11508/whatsnew-depmod2.6-r66484.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3888>
_______________________________________

From report at bugs.python.org  Wed Sep 17 10:08:00 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Wed, 17 Sep 2008 08:08:00 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221638880.41.0.627810913039.issue3835@psf.upfronthosting.co.za>


Helmut Jarausch <jarausch at skynet.be> added the comment:

Many thanks, that solved the problem.

Since the cause of the problem wasn't easy to find out
(for me, at least)

would be possible to check at import time if Tcl/Tk has been
configured with threads enabled?

Helmut.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Wed Sep 17 10:28:42 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Sep 2008 08:28:42 +0000
Subject: [issue3887] Python 2.6 doesn't run after installation on amd64
In-Reply-To: <1221616975.51.0.807116578154.issue3887@psf.upfronthosting.co.za>
Message-ID: <1221640122.53.0.0323455863662.issue3887@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> loewis
nosy: +loewis
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3887>
_______________________________________

From report at bugs.python.org  Wed Sep 17 10:30:53 2008
From: report at bugs.python.org (Stephen McInerney)
Date: Wed, 17 Sep 2008 08:30:53 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1221640253.92.0.653014360126.issue3841@psf.upfronthosting.co.za>


Stephen McInerney <spmcinerney at hotmail.com> added the comment:

Other people have reported it does NOT occur with either:

Win XP / Python 2.5 / Idle 1.2 
Mac OS X 10.5.4 / Python 2.5.2 / IDLE 1.2.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Wed Sep 17 10:47:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 17 Sep 2008 08:47:09 +0000
Subject: [issue3888] [PATCH] Document more deprecated modules in What's New in
	Python 2.6
In-Reply-To: <1221635726.9.0.855015498496.issue3888@psf.upfronthosting.co.za>
Message-ID: <1221641229.14.0.752743205109.issue3888@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the patch, committed as r66485.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3888>
_______________________________________

From report at bugs.python.org  Wed Sep 17 10:53:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Sep 2008 08:53:44 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221641624.71.0.373281108932.issue3885@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I thought first that the problem was during the execution of
gc.collect(), but its not: when configured --with-pydebug, the exception
is printed before:

>>> import gc, _bsddb; env=_bsddb.DBEnv(3); del env
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
bsddb.db.DBNoServerError: (-30992, 'DB_NOSERVER: Fatal error, no RPC
server -- No Berkeley DB RPC server environment')

gc.collect() is just a rude way to display this "XXX undetected error".
(Victor: does Fusil check for this? gc.collect() will not fail if there
is another exception in-between, or in debug mode)

Now, to the _bsddb module: in general, the following pattern is wrong:
   dummy = someFunction();
   Py_XDECREF(dummy);
because it does nothing about an eventual exception set. If the
exception can be discarded, PyErr_Clear() must be called.

I think there is an invariant to keep in each function: return NULL if
and only if an exception is set. Many places in _bsddb do not respect this.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 17 11:38:34 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Sep 2008 09:38:34 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221641624.71.0.373281108932.issue3885@psf.upfronthosting.co.za>
Message-ID: <200809171137.44812.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> gc.collect() is just a rude way to display this "XXX undetected error".
> (Victor: does Fusil check for this? gc.collect() will not fail if there
> is another exception in-between, or in debug mode)

I stopped to fuzz Python using --pydebug because a critical design error in 
CPython reference counting: http://bugs.python.org/issue3299 (some modules 
use PyObject_DEL() instead of Py_DECREF() whereas PyObject_DEL() creates 
inconsistent objects in the double linked object list). Since nobody cares 
about this issue, I don't use pydebug anymore.

> Now, to the _bsddb module: in general, the following pattern is wrong:
>    dummy = someFunction();
>    Py_XDECREF(dummy);
> because it does nothing about an eventual exception set. If the
> exception can be discarded, PyErr_Clear() must be called.

Well, we have to choices: don't raise an error, or clear the exception if an 
exception is raised.

> I think there is an invariant to keep in each function: return NULL if
> and only if an exception is set. Many places in _bsddb do not respect this.

Where? dealloc() callback prototype is "void tp_dealloc(...)": no result! It's 
not possible to tell Python that an error occured.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 17 12:17:59 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 17 Sep 2008 10:17:59 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1221646679.92.0.665160360798.issue3299@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Wed Sep 17 12:23:08 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 17 Sep 2008 10:23:08 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221646988.47.0.55436201169.issue3885@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

So, the right thing to do seems to drop the "check_error" flag and just
do a "PyErr_Clear()" if necessary in the dealloc code.

This must be done in all dealloc code: DBEnv, DB, DBSequence and DBCursor.

Do you agree?.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 17 13:25:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Sep 2008 11:25:21 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221650721.73.0.457296195922.issue3885@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Not only in these functions, but anywhere "dummy=" is followed by a
Py_XDECREF(dummy);

And code like this must also be changed (in DB_open):
    if (makeDBError(err)) {
        PyObject *dummy;

        dummy=DB_close_internal(self,0);
        Py_XDECREF(dummy);
        return NULL;
    }
if DB_close_internal() raises an exception it will replace the original
error set by makeDBError(). I'm not sure this is desirable.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 17 14:34:18 2008
From: report at bugs.python.org (Greg Darke)
Date: Wed, 17 Sep 2008 12:34:18 +0000
Subject: [issue3889] Demo/parser/unparse.py
In-Reply-To: <1221654858.66.0.853855104786.issue3889@psf.upfronthosting.co.za>
Message-ID: <1221654858.66.0.853855104786.issue3889@psf.upfronthosting.co.za>


New submission from Greg Darke <greg at tsukasa.net.au>:

When the unparse demo is run on a file containing a 'from x import y'
statement, it incorrectly outputs it as 'from x import , y'.

The attached patch fixes this.

----------
components: Demos and Tools
files: fix_import_from_bug.patch
keywords: patch
messages: 73331
nosy: gregdarke
severity: normal
status: open
title: Demo/parser/unparse.py
versions: Python 2.5
Added file: http://bugs.python.org/file11509/fix_import_from_bug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3889>
_______________________________________

From report at bugs.python.org  Wed Sep 17 15:09:04 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 17 Sep 2008 13:09:04 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221656944.46.0.628266327502.issue3835@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The patch attached checks for that when an interpreter is created, not
really at import time but should be enough.

But my real concern is that tkinter thinks it will work properly when
Python is using threads and Tcl wasn't compiled with --enable-threads.
Maybe that was true some time ago or maybe in other platforms, but isn't
the case anymore.

----------
keywords: +patch
Added file: http://bugs.python.org/file11510/issue_3835.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Wed Sep 17 15:10:11 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 17 Sep 2008 13:10:11 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1221657011.79.0.246105479289.issue3835@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3835>
_______________________________________

From report at bugs.python.org  Wed Sep 17 15:11:32 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 17 Sep 2008 13:11:32 +0000
Subject: [issue3880] _tkinter._flatten() doesn't check PySequence_Size() error
	code
In-Reply-To: <1221572716.31.0.755070088085.issue3880@psf.upfronthosting.co.za>
Message-ID: <1221657092.91.0.930536893667.issue3880@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Looks fine, doesn't break anything in Tkinter either.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3880>
_______________________________________

From report at bugs.python.org  Wed Sep 17 15:18:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Sep 2008 13:18:10 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221657490.27.0.193359730629.issue3885@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> I stopped to fuzz Python using --pydebug because a critical design
> error in CPython reference counting

I won't comment on this, but to get the extra checks you could arrange
that ceval.c is compiled with CHECKEXC defined. "./configure
BASECFLAGS=-DCHECKEXC" did the trick for me.

> Where? dealloc() callback prototype is "void tp_dealloc(...)": 
> no result! It's not possible to tell Python that an error occured.

Exactly. You cannot return NULL (or -1 for other kind of functions), so
no exception may be raised; PyErr_Clear() calls are necessary.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 17 18:15:47 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Wed, 17 Sep 2008 16:15:47 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221668147.39.0.742100540413.issue3862@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

Mark, your patch will probably get the test to pass, but the underlying
reason the test is failing appears to be unexpected behaviour of the
platform malloc().

FreeBSD 7.0 introduced a new malloc() implementation that relies on
mmap() and this is behaving differently to the malloc() implementation
in FreeBSD 6.3 which relied on sbrk().

I have posted a query about the new malloc()'s behaviour to a FreeBSD
forum and will report what I find out.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Wed Sep 17 19:06:35 2008
From: report at bugs.python.org (jan matejek)
Date: Wed, 17 Sep 2008 17:06:35 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221671195.72.0.125067165918.issue3886@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/issue3886>
_______________________________________

From report at bugs.python.org  Wed Sep 17 19:33:21 2008
From: report at bugs.python.org (Matteo Bertini)
Date: Wed, 17 Sep 2008 17:33:21 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1221672801.05.0.244817242672.issue1068268@psf.upfronthosting.co.za>


Matteo Bertini <matteob at naufraghi.net> added the comment:

Upgrade subprocess.py patch to 25-maint r65475
(apply cleanly with http://bugs.python.org/issue2113 fixed)

----------
keywords: +patch
Added file: http://bugs.python.org/file11511/subprocess-eintr-safety-25maint-r65475.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Wed Sep 17 19:34:04 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 17 Sep 2008 17:34:04 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>
Message-ID: <1221672844.0.0.0752138405269.issue2574@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I tried applying this patch to a clean SVN checkout of the 2.6 trunk on
an OS X Leopard machine and it works (except for the part which patches
configure.in).  I then built the source tree and ran the test_socket
test, which also worked fine.  I don't see any tests for the specific
functionality in the patch, or any patch to the documentation of the
socket module.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2574>
_______________________________________

From report at bugs.python.org  Wed Sep 17 19:45:20 2008
From: report at bugs.python.org (bms)
Date: Wed, 17 Sep 2008 17:45:20 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1221672844.0.0.0752138405269.issue2574@psf.upfronthosting.co.za>
Message-ID: <48D1421B.8050405@incunabulum.net>


bms <bms at incunabulum.net> added the comment:

Bill Janssen wrote:
> Bill Janssen <bill.janssen at gmail.com> added the comment:
>
> I tried applying this patch to a clean SVN checkout of the 2.6 trunk on
> an OS X Leopard machine and it works (except for the part which patches
> configure.in).  I then built the source tree and ran the test_socket
> test, which also worked fine.  I don't see any tests for the specific
> functionality in the patch, or any patch to the documentation of the
> socket module.
>   

Good to hear of your build success on OS X, don't know about 
configure.in off the top of my had.

Exercising the API fully requires an SSM capable multicast LAN.

It's been a few months, as far as I can remember I did add the ssm 
methods and arguments to the built-in documentation for the socket object?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2574>
_______________________________________

From report at bugs.python.org  Wed Sep 17 20:21:33 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 17 Sep 2008 18:21:33 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <48D1421B.8050405@incunabulum.net>
Message-ID: <4b3e516a0809171120u57fef792if6f77aebe84bf16b@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

On Wed, Sep 17, 2008 at 10:45 AM, bms <report at bugs.python.org> wrote:

>
> Exercising the API fully requires an SSM capable multicast LAN.
>

Let's hope the PARC network is still up-to-date.  It was when we were
developing multicast here some 15-20 years ago :-).

Bill

Added file: http://bugs.python.org/file11512/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2574>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080917/01d6b34b/attachment.txt>

From report at bugs.python.org  Wed Sep 17 20:44:59 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 17 Sep 2008 18:44:59 +0000
Subject: [issue3870] Parser/asdl_c.py requires python in order to build python
In-Reply-To: <1221432692.91.0.760928984013.issue3870@psf.upfronthosting.co.za>
Message-ID: <1221677099.62.0.716139949261.issue3870@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I think it would be a good idea to change the Makefile so that it
touches these files when no python interpreter is available.

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3870>
_______________________________________

From report at bugs.python.org  Wed Sep 17 20:49:12 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 17 Sep 2008 18:49:12 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1221677352.85.0.499675886246.issue3547@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Here is a patch, with test, that fixes this problem.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11513/bitfields.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Wed Sep 17 22:35:52 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 17 Sep 2008 20:35:52 +0000
Subject: [issue3890] ssl.SSLSocket.recv() implementation may not work with
	non-blocking sockets
In-Reply-To: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>
Message-ID: <1221683752.69.0.81133093826.issue3890@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

As discussed on the python-dev ml I noticed something in the ssl.py code
which seems to be wrong. This is the ssl.SSLSocket.recv() method:

    def recv (self, buflen=1024, flags=0): 
        if self._sslobj: 
            if flags != 0: 
                raise ValueError( 
                    "non-zero flags not allowed in calls to sendall() 
on %s" % 
                    self.__class__) 
            while True: 
                try: 
                    return self.read(buflen) 
                except SSLError, x: 
                    if x.args[0] == SSL_ERROR_WANT_READ: 
                        continue 
                    else: 
                        raise x 
        else: 
            return socket.recv(self, buflen, flags) 

I don't know the low levels but that while statement which continues 
in case of SSL_ERROR_WANT_READ seems to be wrong (blocking), at least 
when dealing with non-blocking sockets. I think the proper way of 
doing recv() here is letting SSL_ERROR_WANT_READ propagate and let the 
upper application (e.g. asyncore) deal with it.

----------
components: Library (Lib)
messages: 73342
nosy: giampaolo.rodola, janssen, josiah.carlson, josiahcarlson
severity: normal
status: open
title: ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3890>
_______________________________________

From report at bugs.python.org  Wed Sep 17 22:49:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 17 Sep 2008 20:49:38 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221684578.41.0.388263697333.issue3886@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm ok with this patch.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Wed Sep 17 23:17:09 2008
From: report at bugs.python.org (Roy Smith)
Date: Wed, 17 Sep 2008 21:17:09 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

Unless I'm missing something, the only way to tell if a deque is empty is 
to try and pop() something and catch the resulting IndexError.  This is 
not only awkward, but mutates the data structure when you may not want to.

It should be trivial to implement, and run in O(1) time.

----------
components: Library (Lib)
messages: 73344
nosy: roysmith
severity: normal
status: open
title: collections.deque should have empty() method
type: feature request
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Wed Sep 17 23:20:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 17 Sep 2008 21:20:19 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221686419.87.0.544441419002.issue3891@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> rhettinger
components: +Extension Modules
nosy: +rhettinger
versions: +Python 2.7, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Wed Sep 17 23:26:42 2008
From: report at bugs.python.org (Roy Smith)
Date: Wed, 17 Sep 2008 21:26:42 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221686802.9.0.957326008593.issue3891@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

I just realized my request may have been ambiguous; empty() is a
predicate, not a verb.  Doc should be something like:

"""Return true if the deque is empty.  Return false otherwise."""

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Wed Sep 17 23:47:20 2008
From: report at bugs.python.org (Roy Smith)
Date: Wed, 17 Sep 2008 21:47:20 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221688040.62.0.349435175288.issue3891@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Sigh.  It looks like you can do what I want after all, by just using the 
deque object itself, i.e.:

q = deque()
while (q):
   ...

This should be changed to a docs bug -- the doc page for deque should 
mention this, or include an example of this usage.  It's logical that it 
works this way, but not entirely obvious.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Thu Sep 18 00:10:50 2008
From: report at bugs.python.org (Nick Edds)
Date: Wed, 17 Sep 2008 22:10:50 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1221689450.52.0.519229514007.issue2876@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Sorry about the delay with this. I've finally found some time to work on
this, so it should be completed within the next couple of days.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Thu Sep 18 03:18:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 01:18:24 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This happens on the Windows buildbot everything once and a while [1]:

======================================================================
FAIL: test01_basic_replication
(bsddb.test.test_replication.DBReplicationManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"S:\buildbots\python\trunk.nelson-windows\build\lib\bsddb\test\test_replication.py",
line 122, in test01_basic_replication
    self.assertTrue(time.time()<timeout)
AssertionError

----------------------------------------------------------------------

http://python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/159/step-test/0

----------
assignee: jcea
components: Extension Modules
messages: 73348
nosy: benjamin.peterson, jcea
severity: normal
status: open
title: bsddb: test01_basic_replication fails on Windows sometimes
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 03:23:38 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 01:23:38 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221701018.07.0.804657697563.issue3886@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66496.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Thu Sep 18 03:40:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 01:40:00 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221702000.45.0.994515708468.issue3886@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Hmm. It's seems 3.0 will require a different patch. I can't get the
merging to work...

----------
priority: release blocker -> deferred blocker
resolution: fixed -> 
status: closed -> open
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Thu Sep 18 03:43:36 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 01:43:36 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221702216.29.0.569087017249.issue3892@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 03:45:00 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 01:45:00 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221702300.97.0.408266050764.issue3892@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

We're going to disable this test for 2.6rc2.  Please jcea and
gregory.p.smith, take a look at it for 2.6 final.  I've made it a
deferred blocker for that release.

----------
nosy: +barry
priority:  -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 03:52:26 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 18 Sep 2008 01:52:26 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221702746.74.0.430538078533.issue3892@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I instrumented the code a little.  The error is happening because
self.client_startupdone never gets set to True.  This is supposed to be
set in the client_startupdone() method.  It expects an event type of
db.DB_EVENT_REP_STARTUPDONE, but we see exactly one call to this
function with a value of 2, which is apparently DB_EVENT_REP_CLIENT. 
After this call no further calls are made to the method and after 10
seconds the test gives up.

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 04:02:45 2008
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Thu, 18 Sep 2008 02:02:45 +0000
Subject: [issue3893] timedelta overflows in a surprising way
In-Reply-To: <1221703365.36.0.177542323007.issue3893@psf.upfronthosting.co.za>
Message-ID: <1221703365.36.0.177542323007.issue3893@psf.upfronthosting.co.za>


New submission from Shannon -jj Behrens <jjinux at users.sourceforge.net>:

I was very surprised by the following behavior:

>>> from datetime import datetime
>>> now = datetime.today()
>>> future = datetime.today()
>>> (now - future).seconds
86395

I know that http://docs.python.org/lib/datetime-timedelta.html says
"This is exact, but may overflow", but I was really expecting a negative
number of seconds.

Feel free to close this bug if you disagree.

----------
components: Library (Lib)
messages: 73353
nosy: jjinux
severity: normal
status: open
title: timedelta overflows in a surprising way
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3893>
_______________________________________

From report at bugs.python.org  Thu Sep 18 04:27:36 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Sep 2008 02:27:36 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221704856.59.0.87124150773.issue3891@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

What would you suggest?  The docs already say:

    Though list objects support similar operations, they are optimized 
for fast fixed-length operations and incur O(n) memory movement costs 
for pop(0) and insert(0, v) operations which change both the size and 
position of the underlying data representation.

How would you suck elements out of a list?  Probably with something 
like:

    while mylist:
      elt = mylist.pop()

Aside from possible performance issues it's not clear that you would use 
a deque object differently than a list in this context.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Thu Sep 18 04:31:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Sep 2008 02:31:17 +0000
Subject: [issue3894] imageop issue
In-Reply-To: <1221705077.19.0.351380267701.issue3894@psf.upfronthosting.co.za>
Message-ID: <1221705077.19.0.351380267701.issue3894@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

http://psf.upfronthosting.co.za/roundup/security/issue2

----------
components: Extension Modules
messages: 73355
nosy: brett.cannon
severity: normal
status: open
title: imageop issue
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3894>
_______________________________________

From report at bugs.python.org  Thu Sep 18 04:31:34 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Sep 2008 02:31:34 +0000
Subject: [issue3894] imageop issue
In-Reply-To: <1221705077.19.0.351380267701.issue3894@psf.upfronthosting.co.za>
Message-ID: <1221705094.26.0.994784712099.issue3894@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3894>
_______________________________________

From report at bugs.python.org  Thu Sep 18 04:32:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Sep 2008 02:32:46 +0000
Subject: [issue3895] _lsprof issue
In-Reply-To: <1221705166.83.0.0369639810422.issue3895@psf.upfronthosting.co.za>
Message-ID: <1221705166.83.0.0369639810422.issue3895@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

http://psf.upfronthosting.co.za/roundup/security/issue3

----------
components: Extension Modules
messages: 73356
nosy: brett.cannon
priority: deferred blocker
severity: normal
status: open
title: _lsprof issue
type: crash
versions: Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3895>
_______________________________________

From report at bugs.python.org  Thu Sep 18 04:50:33 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 18 Sep 2008 02:50:33 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221706233.43.0.43386588526.issue3892@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

As discussed with Barry on #python-dev, I committed r66498 which skips
the failing assertion on Windows and replaces it with some noise to
stderr.  Note that only that one assertion fails - the rest of the test
passes on Windows.

Also, Brett Cannon on #python-dev experimented and could see the
callback function being called a number of times - with 2 first as
Windows does, but then a number of other times and once with the
expected value.  I'm afraid I've no insight into why these aren't
delivered on Windows.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 05:14:29 2008
From: report at bugs.python.org (Roy Smith)
Date: Thu, 18 Sep 2008 03:14:29 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221707669.55.0.0929188085432.issue3891@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

In retrospect, it's obvious that "while mydeque" is indeed the way to 
process the queue, yet, when I was reading the docs, I didn't come away 
with that.

The statement, "list objects support similar operations", is wishy-washy.  
It is not the same as saying "deque is a subclass of list" (which isn't 
true), nor "the set of operations supported by deque is a superset of 
those supported by list" (which also isn't true).  Thus, you're left 
having to interpret the statement as a handwave that deques are sort-of 
list-like things, with some (indeterminate) set of operations in common.  
It's not at all obvious (or at least it wasn't to me) that one of those 
operations is evaluating the container in a boolean context to test for 
emptiness.

Anyway, to more concretely answer your question, I'd just make the plain 
statement, "An empty deque evaluates as false", somewhere right on the 
page where the methods are listed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Thu Sep 18 06:06:11 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Sep 2008 04:06:11 +0000
Subject: [issue2210] Nested module import clutters package namespace
In-Reply-To: <1204286639.84.0.689580155696.issue2210@psf.upfronthosting.co.za>
Message-ID: <1221710771.56.0.18826268041.issue2210@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The reason this happens is to support ``import pack.y``. When you
reference the module in this way it is accessing the 'y' attribute on
the 'pack' module. If import didn't set it this form of importing would
never work.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2210>
_______________________________________

From report at bugs.python.org  Thu Sep 18 06:34:37 2008
From: report at bugs.python.org (Tim Peters)
Date: Thu, 18 Sep 2008 04:34:37 +0000
Subject: [issue3893] timedelta overflows in a surprising way
In-Reply-To: <1221703365.36.0.177542323007.issue3893@psf.upfronthosting.co.za>
Message-ID: <1221712477.52.0.054249158619.issue3893@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Not a bug.  Try (future - now).seconds instead so that the timedelta is
positive.  As explained in the docs, a negative timedelta is normalized
so that only the .days attribute is negative, and, as the docs also say,
"normalization of negative values may be surprising at first".  The
.seconds and .microseconds attributes are always non-negative.

>>> from datetime import datetime
>>> now = datetime.today()
>>> future = datetime.today()
>>> (now - future).seconds
86390
>>> (future - now).seconds
9
>>> now - future
datetime.timedelta(-1, 86390, 146000) # only .days is negative

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3893>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:41:35 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:41:35 +0000
Subject: [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1221716495.89.0.559038516546.issue3628@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3628>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:41:24 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:41:24 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1221716484.58.0.406016808399.issue3723@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:41:46 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:41:46 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1221716506.59.0.204523959842.issue3666@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:41:57 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:41:57 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1221716517.07.0.214582034028.issue3664@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:42:05 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:42:05 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1221716525.56.0.289842855585.issue3626@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:42:14 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:42:14 +0000
Subject: [issue3661] sys.call_tracing segfaults
In-Reply-To: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
Message-ID: <1221716534.77.0.514991885253.issue3661@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3661>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:42:23 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:42:23 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1221716543.43.0.281308053886.issue3685@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:42:32 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:42:32 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1221716552.45.0.648720064007.issue1210@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:42:42 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:42:42 +0000
Subject: [issue3775] Update RELNOTES file
In-Reply-To: <1220536018.76.0.0823799232176.issue3775@psf.upfronthosting.co.za>
Message-ID: <1221716562.55.0.797105132795.issue3775@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3775>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:42:51 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:42:51 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1221716571.22.0.172195454887.issue3623@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:43:10 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:43:10 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1221716590.84.0.55500212059.issue3187@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:43:01 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:43:01 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1221716581.23.0.876544196282.issue3787@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:43:28 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:43:28 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1221716608.82.0.898768062773.issue1717@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:43:20 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:43:20 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1221716600.2.0.815577772271.issue3574@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:43:36 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:43:36 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1221716616.51.0.57044387315.issue3799@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:43:45 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:43:45 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1221716625.07.0.236382557056.issue3781@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:43:53 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:43:53 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221716633.53.0.552452833136.issue3886@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:44:02 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:44:02 +0000
Subject: [issue3894] imageop issue
In-Reply-To: <1221705077.19.0.351380267701.issue3894@psf.upfronthosting.co.za>
Message-ID: <1221716642.78.0.582792738375.issue3894@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3894>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:44:10 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:44:10 +0000
Subject: [issue3895] _lsprof issue
In-Reply-To: <1221705166.83.0.0369639810422.issue3895@psf.upfronthosting.co.za>
Message-ID: <1221716650.17.0.387798223869.issue3895@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3895>
_______________________________________

From report at bugs.python.org  Thu Sep 18 07:44:17 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Sep 2008 05:44:17 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221716657.96.0.542626296875.issue3892@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 08:16:40 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Sep 2008 06:16:40 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1221718600.5.0.838907715906.issue3547@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Updated patch.

Added file: http://bugs.python.org/file11514/bitfields-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Thu Sep 18 08:16:57 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Sep 2008 06:16:57 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1221718617.96.0.472440059633.issue3547@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


Removed file: http://bugs.python.org/file11513/bitfields.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Thu Sep 18 09:39:29 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 18 Sep 2008 07:39:29 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1221723569.74.0.44154624074.issue3187@psf.upfronthosting.co.za>


Helmut Jarausch <jarausch at skynet.be> added the comment:

Hi,
is this assumed to be fixed in 3.0rc1 ?

with SVN 66506  (3.0rc1+) 
for dirname, subdirs, files in os.walk(bytes(Top,'iso-8859-1')) :

still gives an error here:

    for dirname, subdirs, files in os.walk(bytes(Top,'iso-8859-1')) :
  File "/usr/local/lib/python3.0/os.py", line 268, in walk
    if isdir(join(top, name)):
  File "/usr/local/lib/python3.0/posixpath.py", line 64, in join
    if b.startswith('/'):
TypeError: expected an object with the buffer interface

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Thu Sep 18 09:55:52 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 18 Sep 2008 07:55:52 +0000
Subject: [issue3896] idle should be installed as idle3.0
In-Reply-To: <1221724552.48.0.46813625894.issue3896@psf.upfronthosting.co.za>
Message-ID: <1221724552.48.0.46813625894.issue3896@psf.upfronthosting.co.za>


New submission from Helmut Jarausch <jarausch at skynet.be>:

Python-3.0rc1+ still installs idle as 'idle' and will therefore
overwrite an installed idle of version 2.5.x

It should be installed as  'idle3.0'  conforming to 'python3.0'

----------
components: Installation
messages: 73363
nosy: HWJ
severity: normal
status: open
title: idle should be installed as idle3.0
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3896>
_______________________________________

From report at bugs.python.org  Thu Sep 18 10:17:22 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Sep 2008 08:17:22 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1221725842.17.0.437533013327.issue3547@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Updated the unittest so that it works on Windows, too.

Added file: http://bugs.python.org/file11515/bitfields-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Thu Sep 18 10:17:32 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Sep 2008 08:17:32 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1221725852.83.0.877865688234.issue3547@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


Removed file: http://bugs.python.org/file11514/bitfields-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Thu Sep 18 10:17:34 2008
From: report at bugs.python.org (Dieter Kadelka)
Date: Thu, 18 Sep 2008 08:17:34 +0000
Subject: [issue3897] collections
In-Reply-To: <1221725854.26.0.119924443633.issue3897@psf.upfronthosting.co.za>
Message-ID: <1221725854.26.0.119924443633.issue3897@psf.upfronthosting.co.za>


New submission from Dieter Kadelka <Dieter.Kadelka at stoch.uni-karlsruhe.de>:

Line 179 in Setup.dist should be replaced by

#_collections _collectionsmodule.c # Container types

_collectionsmodule.c doesn't exist any longer

----------
components: Extension Modules
messages: 73365
nosy: kadelka
severity: normal
status: open
title: collections
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3897>
_______________________________________

From report at bugs.python.org  Thu Sep 18 10:23:25 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Sep 2008 08:23:25 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221726205.23.0.0117737637185.issue3862@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Alan.  I realised my answer was a shallow one after reading (too
late!) the thread you started on python-dev.

However, I have a suspicion that that particular array test
(test_alloc_overflow) was merely meant to test the code in
newarrayobject, at around line 427 of arraymodule.c, which looks like:

 	/* Check for overflow */
	if (nbytes / descr->itemsize != (size_t)size) {
		return PyErr_NoMemory();
	}

and that the test dated from an era when it was fairly safe to assume
that a size_t was at most 32 bits.  I'd guess that test_alloc_overflow
was never intended to be a test of OS malloc failure behaviour.

So the array test is wrong, and I think this patch should be applied
anyway.  I admit this doesn't help with the much more interesting
question of what's going on with malloc on FreeBSD.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Thu Sep 18 10:23:19 2008
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Thu, 18 Sep 2008 08:23:19 +0000
Subject: [issue3893] timedelta overflows in a surprising way
In-Reply-To: <1221703365.36.0.177542323007.issue3893@psf.upfronthosting.co.za>
Message-ID: <1221726199.12.0.664340909986.issue3893@psf.upfronthosting.co.za>


Shannon -jj Behrens <jjinux at users.sourceforge.net> added the comment:

Yes, that makes perfect sense.  Sorry, I missed that part of the docs. 
Please feel free to close this bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3893>
_______________________________________

From report at bugs.python.org  Thu Sep 18 10:24:24 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Sep 2008 08:24:24 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221726264.46.0.54437777971.issue3862@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

s/Alan/Andrew/.  Need more coffee.  Apologies.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Thu Sep 18 12:44:42 2008
From: report at bugs.python.org (vila)
Date: Thu, 18 Sep 2008 10:44:42 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221734682.91.0.250739236256.issue3879@psf.upfronthosting.co.za>


vila <v.ladeuil+bugs-python at free.fr> added the comment:

Here you are

Added file: http://bugs.python.org/file11516/issue3879.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Thu Sep 18 13:22:51 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 18 Sep 2008 11:22:51 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221736971.46.0.318564376983.issue3892@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Adding Nelson to the nosy list, since I'm unable to debug any Windows
issue by myself.

I'm very interested in the report saying that MS Windows Berkeley DB
correctly sends the db.DB_EVENT_REP_STARTUPDONE event in his setup. That
could indicate some issue in the buildbot.

Barry, I don't consider this a "release blocker" for 2.6.0. This is a
very advanced feature (database replication). This must be solved, but
2.6 doesn't need to be delayed for it.

----------
nosy: +Trent.Nelson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 13:25:53 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 18 Sep 2008 11:25:53 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221737153.79.0.994196762042.issue3892@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

?Somebody can try this issue in a Windows box?. It could be a Berkeley
DB bug in that platform, but I would like to verify this before
informing Oracle.

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 13:51:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 11:51:27 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221738687.13.0.746691657014.issue3879@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Thu Sep 18 13:51:29 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 18 Sep 2008 11:51:29 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221738689.8.0.342778675296.issue3886@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

http://bugs.python.org/issue3026 is about the same issue (with a working
patch added 2 months ago). It's really sad that it sat there for so
long. I could have spent that time on something else...

(btw. my patch also made the hash functions interruptible, this is
something you might consider).

----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Thu Sep 18 13:53:12 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 18 Sep 2008 11:53:12 +0000
Subject: [issue3026] integer overflow in hashlib causes wrong results for
	cryptographic hash functions [was: mmap broken with large files
	on 64bit system]
In-Reply-To: <1212373498.52.0.766248013838.issue3026@psf.upfronthosting.co.za>
Message-ID: <1221738792.8.0.399095655776.issue3026@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

same issue in http://bugs.python.org/issue3886.
it's sad that no one took a look at the patch...
now, it should probably be closed...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3026>
_______________________________________

From report at bugs.python.org  Thu Sep 18 14:05:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 18 Sep 2008 12:05:27 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221739527.29.0.573149547809.issue3886@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a security issue, the patch should also be backport to 2.5 (and 2.4
if applicable)

----------
nosy: +loewis
versions: +Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Thu Sep 18 14:06:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 18 Sep 2008 12:06:26 +0000
Subject: [issue3026] integer overflow in hashlib causes wrong results for
	cryptographic hash functions [was: mmap broken with large files
	on 64bit system]
In-Reply-To: <1212373498.52.0.766248013838.issue3026@psf.upfronthosting.co.za>
Message-ID: <1221739586.75.0.962641354095.issue3026@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, closing. Thanks for the patch, anyway.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3026>
_______________________________________

From report at bugs.python.org  Thu Sep 18 14:07:31 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Sep 2008 12:07:31 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1221739651.58.0.857188739628.issue3666@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Why not just have atexit_callfuncs call atexit_cleanup at the end of its
execution?

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Thu Sep 18 14:19:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 18 Sep 2008 12:19:15 +0000
Subject: [issue3898] 3.0 documentation fails to build
In-Reply-To: <1221740355.36.0.716115348573.issue3898@psf.upfronthosting.co.za>
Message-ID: <1221740355.36.0.716115348573.issue3898@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

In 3.0rc1, I get, for "make htmlhelp"

... contents copyright distutils/apiref Exception occurred:
  File
"/cygdrive/c/loewis/3k/python/Doc/tools/pygments/lexers/__init__.py", lin
e 83, in get_lexer_by_name
    raise ClassNotFound('no lexer for alias %r found' % _alias)
ClassNotFound: no lexer for alias 'python3' found

The full traceback is

Traceback (most recent call last):
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/__init__.py", line
128, in main
    app.build(all_files, filenames)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/application.py",
line 122, in build
    self.builder.build_update()
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line
242, in build_update
    'out of date' % len(to_build))
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line
282, in build
    self.write(docnames, updated_docnames, method)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line
319, in write
    self.write_doc(docname, doctree)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line
510, in write_doc
    self.docwriter.write(doctree, destination)
  File
"/cygdrive/c/loewis/3k/python/Doc/tools/docutils/writers/__init__.py",
line 78, in write
    self.translate()
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/htmlwriter.py",
line 32, in translate
    self.document.walkabout(visitor)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/docutils/nodes.py", line
159, in walkabout
    child.walkabout(visitor)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/docutils/nodes.py", line
159, in walkabout
    child.walkabout(visitor)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/docutils/nodes.py", line
159, in walkabout
    child.walkabout(visitor)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/docutils/nodes.py", line
159, in walkabout
    child.walkabout(visitor)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/docutils/nodes.py", line
159, in walkabout
    child.walkabout(visitor)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/docutils/nodes.py", line
151, in walkabout
    visitor.dispatch_visit(self)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/docutils/nodes.py", line
1502, in dispatch_visit
    return method(node)
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/htmlwriter.py",
line 191, in visit_literal_block
    lang, linenos))
  File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/highlighting.py",
line 169, in highlight_block
    lexer = lexers[lang] = get_lexer_by_name(lang)
  File
"/cygdrive/c/loewis/3k/python/Doc/tools/pygments/lexers/__init__.py",
line 83, in get_lexer_by_name
    raise ClassNotFound('no lexer for alias %r found' % _alias)
ClassNotFound: no lexer for alias 'python3' found

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 73377
nosy: georg.brandl, loewis
severity: normal
status: open
title: 3.0 documentation fails to build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3898>
_______________________________________

From report at bugs.python.org  Thu Sep 18 14:21:26 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Sep 2008 12:21:26 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1221740486.46.0.589522226306.issue3666@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

The attached patch causes an exception to print
at exit on my Mac:

>>> import sys, atexit
>>> atexit.register(lambda: 1, 0, 0, (x for x in (1,2)), 0, 0)
<function <lambda> at 0x5c91e0>
>>> sys.exit()
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, str found

Without the patch I get the same TypeError but it's
followed by a Bus error.

I don't know if the patch is right or wrong, better or worse than the
status quo, but I'll toss it out there for consideration.  It
certainly seems to subscribe to Christian's theme of calling
atexit_cleanup() earlier.

----------
keywords: +patch
Added file: http://bugs.python.org/file11517/atexit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Thu Sep 18 14:57:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 18 Sep 2008 12:57:12 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1221742632.32.0.481778544207.issue3862@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch looks fine to me, except that the failure message is now out
of date.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Thu Sep 18 15:14:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Sep 2008 13:14:29 +0000
Subject: [issue3898] 3.0 documentation fails to build
In-Reply-To: <1221740355.36.0.716115348573.issue3898@psf.upfronthosting.co.za>
Message-ID: <1221743669.46.0.817167049103.issue3898@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You'll have to update the Pygments library; try a "rm -r tools/pygments;
make update".

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3898>
_______________________________________

From report at bugs.python.org  Thu Sep 18 15:27:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Sep 2008 13:27:31 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1221744451.86.0.879106191692.issue3666@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Skip:
I suggest you move the cleanup call before PyErr_Restore(). The current
code doesn't re-raise exception raised in the cleanup function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Thu Sep 18 15:35:51 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 18 Sep 2008 13:35:51 +0000
Subject: [issue3899] test_ssl.py doesn't properly test ssl integration with
	asyncore
In-Reply-To: <1221744950.78.0.538519688245.issue3899@psf.upfronthosting.co.za>
Message-ID: <1221744950.78.0.538519688245.issue3899@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

The AsyncoreEchoServer class in test_ssl.py doesn't actually test a real
integration with asyncore since the do_handshake_on_connect flag is set
to True and hence temporarily blocks the asyncore polling loop as long
as the ssl handshake finishes.
The patch in attachment subclasses some asyncore internals so that a
non-blocking ssl handshake takes place.

Tested under Windows XP SP3, Python 2.6rc1.

----------
components: Library (Lib)
files: test_ssl.patch
keywords: patch
messages: 73382
nosy: giampaolo.rodola, janssen, josiah.carlson, josiahcarlson
severity: normal
status: open
title: test_ssl.py doesn't properly test ssl integration with asyncore
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file11518/test_ssl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3899>
_______________________________________

From report at bugs.python.org  Thu Sep 18 15:55:09 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Sep 2008 13:55:09 +0000
Subject: [issue3102] ctypes defines global symbols
In-Reply-To: <1213343694.16.0.290726791228.issue3102@psf.upfronthosting.co.za>
Message-ID: <1221746109.95.0.68585294296.issue3102@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Is it too late to fix this for Python 2.6 and Python 3.0?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3102>
_______________________________________

From report at bugs.python.org  Thu Sep 18 16:16:49 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Sep 2008 14:16:49 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1221747409.8.0.157735548627.issue3666@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

New patch.  This also makes the various atexit_*
functions static.

Added file: http://bugs.python.org/file11519/atexit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Thu Sep 18 16:22:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Sep 2008 14:22:19 +0000
Subject: [issue3900] ctypes: wrong calling convention for _string_at
In-Reply-To: <1221747739.05.0.0591955430203.issue3900@psf.upfronthosting.co.za>
Message-ID: <1221747739.05.0.0591955430203.issue3900@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Our application server running on top of Twisted crashs 1 to 3 times 
per day. It uses a ctypes binding for libnetfilter_conntrack (dump 
Linux conntrack table) which is running in a dedicated thread. So we 
get:
 - Python 2.5.2
 - Twisted 8.1.0-3
 - Linux 2.6.26-1-amd64 SMP x86_64

The crash does not occur in the "ctypes" thread but it the main thread 
(another CPython thread). The backtrace is incoherent which means that 
it's a multithreading problem. So I used helgrind (Valgrind tool) to 
watch invalid memory accesses, and here is one:

==30545== Possible data race during write of size 4 at 0x4EC1E60
==30545==    at 0x808F616: PyString_FromStringAndSize 
(stringobject.c:78)
==30545==    by 0x4D3CBD9: string_at (_ctypes.c:4568)
==30545==    by 0x4D4654E: ffi_call_SYSV (sysv.S:60)
==30545==    by 0x4D46396: ffi_call (ffi.c:221)
==30545==    by 0x4D3E9F1: _call_function_pointer (callproc.c:668)
==30545==    by 0x4D3F147: _CallProc (callproc.c:991)
==30545==    by 0x4D3B0DA: CFuncPtr_call (_ctypes.c:3373)
==30545==    by 0x8060E0A: PyObject_Call (abstract.c:1861)
==30545==    by 0x80CB391: do_call (ceval.c:3784)
==30545==    by 0x80CAD69: call_function (ceval.c:3596)
==30545==    by 0x80C7B6F: PyEval_EvalFrameEx (ceval.c:2272)
==30545==    by 0x80C9329: PyEval_EvalCodeEx (ceval.c:2836)
==30545==   Old state: shared-readonly by threads #1, #4
==30545==   New state: shared-modified by threads #1, #4
==30545==   Reason:    this thread, #1, holds no consistent locks
==30545==   Location 0x4EC1E60 has never been protected by any lock

In _CallProc() the test ((flags & FUNCFLAG_PYTHONAPI) == 0) is True, 
which means that the GIL is released. But it's a bug because as you 
can see, string_at() uses PyString_FromStringAndSize() which requires 
the GIL!

Finally, the bug comes from ctypes module, not _ctypes: ctypes just 
uses the wrong calling convention. Using PYFUNCPTR() instead of 
CFUNCPTR(), the Helgrind warning goes away ;-)

Note about Helgrind: This tools really rocks!!!

----------
components: Library (Lib)
files: ctypes_string_at.patch
keywords: patch
messages: 73385
nosy: haypo
severity: normal
status: open
title: ctypes: wrong calling convention for _string_at
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11520/ctypes_string_at.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3900>
_______________________________________

From report at bugs.python.org  Thu Sep 18 16:22:26 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Sep 2008 14:22:26 +0000
Subject: [issue3900] ctypes: wrong calling convention for _string_at
In-Reply-To: <1221747739.05.0.0591955430203.issue3900@psf.upfronthosting.co.za>
Message-ID: <1221747746.83.0.353657493659.issue3900@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3900>
_______________________________________

From report at bugs.python.org  Thu Sep 18 16:43:07 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 18 Sep 2008 14:43:07 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221748987.61.0.233604606325.issue3892@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've tried this issue on VC6 + db4.7.25.0 + win2k, and I could reproduce
error.

I added following patch for investigation.

Index: Lib/bsddb/test/test_replication.py
===================================================================
--- Lib/bsddb/test/test_replication.py  (revision 66483)
+++ Lib/bsddb/test/test_replication.py  (working copy)
@@ -40,6 +40,7 @@
                 self.confirmed_master=True

         def client_startupdone(a,b,c) :
+            print "DBReplicationManager:", (a, b, c)
             if b==db.DB_EVENT_REP_STARTUPDONE :
                 self.client_startupdone=True

@@ -201,6 +202,7 @@
                 self.confirmed_master = True

         def client_startupdone(a,b,c) :
+            print "DBBaseReplication:", (a, b, c)
             if b == db.DB_EVENT_REP_STARTUPDONE :
                 self.client_startupdone = True

And this is result.

DBReplicationManager: (<DBEnv object at 0x00A80148>, 2, None)
DBReplicationManager: (<DBEnv object at 0x00A80148>, 5, 0)
DBBaseReplication: (<DBEnv object at 0x00B35CD0>, 2, None)
DBBaseReplication: (<DBEnv object at 0x00B35CD0>, 5, 13)
DBBaseReplication: (<DBEnv object at 0x00B35CD0>, 7, None)
DBBaseReplication: (<DBEnv object at 0x00B49658>, 2, None)
DBBaseReplication: (<DBEnv object at 0x00B49658>, 5, 13)
DBBaseReplication: (<DBEnv object at 0x00B49730>, 2, None)
DBBaseReplication: (<DBEnv object at 0x00B49730>, 5, 13)

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 18 17:20:14 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 18 Sep 2008 15:20:14 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221751214.14.0.187822924648.issue3885@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

> Not only in these functions, but anywhere "dummy=" is followed by a
> Py_XDECREF(dummy);

Please, clarify this. I don't see your point.

> And code like this must also be changed (in DB_open):
>    if (makeDBError(err)) {
>        PyObject *dummy;
>
>        dummy=DB_close_internal(self,0);
>        Py_XDECREF(dummy);
>        return NULL;
>    }
> if DB_close_internal() raises an exception it will replace the
> original error set by makeDBError(). I'm not sure this is desirable.

I agree this could be an issue that need to be studied. Please, post a
new bug report for that (to be addressed in 2.6.1, I think, since this
issue doesn't crash the interpreter).

I post a patch for the bugs originally indicated in this bug report, an
another one (db.verify() regression).

*Please Review*. I will update python 2.6 svn when the review is done.
Thanks.

Added file: http://bugs.python.org/file11521/bsddb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Thu Sep 18 18:16:44 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Sep 2008 16:16:44 +0000
Subject: [issue3900] ctypes: wrong calling convention for _string_at
In-Reply-To: <1221747739.05.0.0591955430203.issue3900@psf.upfronthosting.co.za>
Message-ID: <1221754604.87.0.0605633019214.issue3900@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

This is already fixed in SVN, see issue #3554.

----------
assignee:  -> theller
nosy: +theller
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3900>
_______________________________________

From report at bugs.python.org  Thu Sep 18 18:19:39 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Sep 2008 16:19:39 +0000
Subject: [issue3900] ctypes: wrong calling convention for _string_at
In-Reply-To: <1221747739.05.0.0591955430203.issue3900@psf.upfronthosting.co.za>
Message-ID: <1221754779.79.0.733270168018.issue3900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This is already fixed in SVN, see issue #3554

Oh... cool because next release will fix it, and fuck because it took 
me hours to found this bug...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3900>
_______________________________________

From report at bugs.python.org  Thu Sep 18 18:10:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 18 Sep 2008 16:10:22 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221754222.53.0.501669963188.issue3885@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> > Not only in these functions, but anywhere "dummy=" is followed by a
> > Py_XDECREF(dummy);
> 
> Please, clarify this. I don't see your point.

If dummy is NULL, a pending exception has been set (with PyErr_SetString
or another similar function). If you simply ignore this, your function
will return a valid object, but PyErr_Occurred() returns True. This is
not correct and will fail in subtle ways (like with gc.collect()); in
debug mode, a message "XXX undetected error" is printed.
You must either clear the exception, or return NULL from your function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Thu Sep 18 18:40:41 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 18 Sep 2008 16:40:41 +0000
Subject: [issue3901] Slight readme.txt fix (VC9)
In-Reply-To: <1221756041.2.0.713379827172.issue3901@psf.upfronthosting.co.za>
Message-ID: <1221756041.2.0.713379827172.issue3901@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I'm not VC9 guy, but it looks not up-to-date on _bsddb section.

----------
assignee: georg.brandl
components: Documentation
files: slight_readme_fix.patch
keywords: patch
messages: 73391
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: Slight readme.txt fix (VC9)
versions: Python 2.6
Added file: http://bugs.python.org/file11522/slight_readme_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3901>
_______________________________________

From report at bugs.python.org  Thu Sep 18 19:31:40 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Sep 2008 17:31:40 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221759100.62.0.0232383845732.issue3886@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Sorry about missing your work, Ralf. In the rush to getting a fix in for
2.6rc2 we went with the patch Apple sent to the security mailing list
when the CVE was reported to us.

And 2.5 has already been patched by r66497, so removing that as a
version that needs a patch.

----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Thu Sep 18 20:11:46 2008
From: report at bugs.python.org (Eyal Lotem)
Date: Thu, 18 Sep 2008 18:11:46 +0000
Subject: [issue3902] distutils does not correctly create packages for compiled
	extensions
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>


New submission from Eyal Lotem <eyal.lotem+py at gmail.com>:

When using either the ext_package keyword argument to setup, or when
using the "pkg.name" module name notation to Extension instances,
distutils installs the compiled extensions into the appropriate package
directory.

However, distutils does not create an __init__.py file in that
directory, so it is not actually a package and is not importable.

----------
components: Distutils
messages: 73393
nosy: Peaker
severity: normal
status: open
title: distutils does not correctly create packages for compiled extensions
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Thu Sep 18 20:21:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 18 Sep 2008 18:21:34 +0000
Subject: [issue3853] Windows SQLite DLL should be built with multithreading
	enabled
In-Reply-To: <1221259553.44.0.029573220749.issue3853@psf.upfronthosting.co.za>
Message-ID: <1221762094.88.0.227332783315.issue3853@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree with Amaury's analysis (except that the preferred way to
override it is to define SQLITE_THREADSAFE directly). If it's not
defined, it defaults to 1.

Closing as works-for-me.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3853>
_______________________________________

From report at bugs.python.org  Thu Sep 18 20:29:09 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 18 Sep 2008 18:29:09 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1221762549.98.0.94348556525.issue3885@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Very good point, Amaury.

I would open a new bug to track this (probably for 2.6.1 time). Can you?.

In the meanwhile, I need review for the inmediate patch, since the crash
is 100% reproductible.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Thu Sep 18 20:35:55 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 18 Sep 2008 18:35:55 +0000
Subject: [issue3887] Python 2.6 doesn't run after installation on amd64
In-Reply-To: <1221616975.51.0.807116578154.issue3887@psf.upfronthosting.co.za>
Message-ID: <1221762955.57.0.740991988687.issue3887@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can't reproduce the problem. Did you install for all users, or just
for you? Do you have the CRT already installed or not?

Can you try replacing the manifest with the attached one (not sure why
it says x86)? You then also need to replace the manifest in DLLs, and
fix the  file name to "../msvcr90.dll".

Added file: http://bugs.python.org/file11523/Microsoft.VC90.CRT.manifest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3887>
_______________________________________

From report at bugs.python.org  Thu Sep 18 22:49:48 2008
From: report at bugs.python.org (John Ehresman)
Date: Thu, 18 Sep 2008 20:49:48 +0000
Subject: [issue3887] Python 2.6 doesn't run after installation on amd64
In-Reply-To: <1221616975.51.0.807116578154.issue3887@psf.upfronthosting.co.za>
Message-ID: <1221770988.25.0.910156881869.issue3887@psf.upfronthosting.co.za>


John Ehresman <jpe at wingware.com> added the comment:

This is on a fresh Vista Ultimate install.  There is no msvcr90.dll
anywhere on the system, if windows file search according to windows file
search (I did check the hidden / system file box).

The first report is from a "for me" install.  After installing for all
users, there's no dll in \python26 and the error log error message of:
Activation context generation failed for "C:\Python26\python.exe".
Dependent Assembly
Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"
could not be found. Please use sxstrace.exe for detailed diagnosis.

I tried using changing the .manifest and got a null pointer access error:
Faulting application python.exe, version 0.0.0.0, time stamp 0x48cb6bcf,
faulting module ntdll.dll, version 6.0.6001.18000, time stamp
0x4791adec, exception code 0xc000007b, fault offset 0x00000000000b1188,
process id 0xa28, application start time 0x01c919c8f9746f89.

I wonder if the x86 dll is being installed rather than the amd64 one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3887>
_______________________________________

From report at bugs.python.org  Thu Sep 18 22:50:25 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 18 Sep 2008 20:50:25 +0000
Subject: [issue3899] test_ssl.py doesn't properly test ssl integration with
	asyncore
In-Reply-To: <1221744950.78.0.538519688245.issue3899@psf.upfronthosting.co.za>
Message-ID: <1221771025.94.0.709839114252.issue3899@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

The server wasn't meant to be non-blocking.  The non-blocking test is
performed when the client (which is non-blocking) connects to it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3899>
_______________________________________

From report at bugs.python.org  Thu Sep 18 22:58:35 2008
From: report at bugs.python.org (Georg Grafendorfer)
Date: Thu, 18 Sep 2008 20:58:35 +0000
Subject: [issue3903] pickle error in python3.0rc1
In-Reply-To: <1221771515.01.0.0624093584871.issue3903@psf.upfronthosting.co.za>
Message-ID: <1221771515.01.0.0624093584871.issue3903@psf.upfronthosting.co.za>


New submission from Georg Grafendorfer <guruvienna at hotmail.com>:

Hi all,
I compiled Python3.0rc1 with the usual ./configure make make test make
install on my Athlon XP 1800 (32 bit), using Debian Etch as OS, the
following works on Python2.4 (default in Debian Etch), but not with
Python3.0rc1:

>>> import pickle
>>> d = {'ID':345, 'AD':'Hallo'}
>>> f = open('test.hhh', 'wb')
>>> pickle.dump(d,f,2)
>>> f.close()
>>> f = open('test.hhh', 'r')
>>> pickle.load(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/pickle.py", line 1325, in load
    return Unpickler(file, encoding=encoding, errors=errors).load()
  File "/usr/local/lib/python3.0/io.py", line 1728, in read
    eof = not self._read_chunk()
  File "/usr/local/lib/python3.0/io.py", line 1557, in _read_chunk
    self._set_decoded_chars(self._decoder.decode(input_chunk, eof))
  File "/usr/local/lib/python3.0/io.py", line 1294, in decode
    output = self.decoder.decode(input, final=final)
  File "/usr/local/lib/python3.0/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 0:
unexpected code byte
>>>

the same if you specifiy protocol number 3, it works also in
Python3.0rc1 if you specifiy 'rb' instead of 'r' as file opening method,
but according to the Python library reference it should work also with
'r'.  How should one know with which protocol the object was pickled?

Thanks very much, 

Georg

----------
components: Extension Modules
messages: 73399
nosy: Georg
severity: normal
status: open
title: pickle error in python3.0rc1
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3903>
_______________________________________

From report at bugs.python.org  Thu Sep 18 23:04:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 21:04:51 +0000
Subject: [issue3903] pickle error in python3.0rc1
In-Reply-To: <1221771515.01.0.0624093584871.issue3903@psf.upfronthosting.co.za>
Message-ID: <1221771891.13.0.678578870813.issue3903@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Pickled files should *always* be used in binary mode.

The 3.0 pickle documentation states this:

"Be sure to always open pickle files created with protocols >= 1 in
binary mode. For the old ASCII-based pickle protocol 0 you can use
either text mode or binary mode as long as you stay consistent.

A pickle file written with protocol 0 in binary mode will contain lone
linefeeds as line terminators and therefore will look ?funny? when
viewed in Notepad or other editors which do not support this format."


[1] http://docs.python.org/dev/3.0/library/pickle.html#usage

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3903>
_______________________________________

From report at bugs.python.org  Thu Sep 18 23:30:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 21:30:03 +0000
Subject: [issue3893] timedelta overflows in a surprising way
In-Reply-To: <1221703365.36.0.177542323007.issue3893@psf.upfronthosting.co.za>
Message-ID: <1221773403.91.0.332826857779.issue3893@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3893>
_______________________________________

From report at bugs.python.org  Thu Sep 18 23:44:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 21:44:18 +0000
Subject: [issue3897] collections
In-Reply-To: <1221725854.26.0.119924443633.issue3897@psf.upfronthosting.co.za>
Message-ID: <1221774258.5.0.367355517493.issue3897@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Why do you think it doesn't exist? It appears to be alive and healthy in
Modules/_collectionsmodule.c.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3897>
_______________________________________

From report at bugs.python.org  Thu Sep 18 23:47:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 21:47:05 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221774425.5.0.215180041486.issue3886@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

hashlib doesn't exist in Python 2.4, so I'm not very worried about it. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Fri Sep 19 00:05:37 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Thu, 18 Sep 2008 22:05:37 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1221775537.16.0.71221547115.issue2550@psf.upfronthosting.co.za>


Changes by Forest Wilkinson <forest at users.sourceforge.net>:


----------
nosy: +forest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2550>
_______________________________________

From report at bugs.python.org  Fri Sep 19 00:15:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 22:15:13 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1221776113.07.0.834448629456.issue3723@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Maybe, I'm not seeing the whole problem, but can't we just add
_PySys_Init and _PyBuiltin_Init to config.c like in the attached patch?
Obviously, we will eventually want to make a separate state to store
module globals in, but I think this will work for 3.0 final.

----------
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file11524/add_init_funcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Fri Sep 19 00:27:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 18 Sep 2008 22:27:34 +0000
Subject: [issue3102] ctypes defines global symbols
In-Reply-To: <1213343694.16.0.290726791228.issue3102@psf.upfronthosting.co.za>
Message-ID: <1221776854.73.0.789905752564.issue3102@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Formally, I can't answer that question; you need to ask the RM.

Informally, I think only serious bugs can be fixed now; this bug is not
serious.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3102>
_______________________________________

From report at bugs.python.org  Fri Sep 19 00:27:57 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Thu, 18 Sep 2008 22:27:57 +0000
Subject: [issue3904] asynchat async_chat __init__() arguments changed in
	python 2.6
In-Reply-To: <1221776877.68.0.695076876479.issue3904@psf.upfronthosting.co.za>
Message-ID: <1221776877.68.0.695076876479.issue3904@psf.upfronthosting.co.za>


New submission from Forest Wilkinson <forest at users.sourceforge.net>:

In python 2.6rc2, the async_chat.__init__() parameters have changed. 
The first arg was called 'conn' in python 2.5, and it is now called
'sock'.  This change breaks code that worked with previous python 2.x
versions, if that code followed the example in the official docs:

  class http_request_handler(asynchat.async_chat):
    def __init__(self, conn, addr, sessions, log):
      asynchat.async_chat.__init__(self, conn=conn)

The change also breaks the 2.6 docs, as they have not been updated to
reflect the newly renamed parameter.
http://docs.python.org/dev/library/asynchat.html#id1

The change appears to come from Nadeem Vawda as part of issue1519.  (See
msg57989.)

I expect that existing python code could be modified to work around the
problem by using positional args instead of keyword args.  However, I
didn't expect to have to update my working code to accommodate such a
change in the python 2.x code line.  I agree that 'sock' is a better
name for the parameter, especially since it matches the same in
asyncore.dispatcher, but should the change really happen before python
3.0?  If so, let's at least update the docs.

----------
components: Library (Lib)
messages: 73405
nosy: forest, nvawda
severity: normal
status: open
title: asynchat async_chat __init__() arguments changed in python 2.6
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3904>
_______________________________________

From report at bugs.python.org  Fri Sep 19 00:29:19 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 18 Sep 2008 22:29:19 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1221776959.86.0.986906860411.issue3886@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Python 2.4 uses an 'int' for ob_size so it does not appear at first
glance that its sha module (what hashlib was derived from) is
susceptible to this bug when compiled as 64-bit.

----------
keywords: +64bit
nosy: +gregory.p.smith
versions:  -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Fri Sep 19 00:33:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 22:33:25 +0000
Subject: [issue3904] asynchat async_chat __init__() arguments changed in
	python 2.6
In-Reply-To: <1221776877.68.0.695076876479.issue3904@psf.upfronthosting.co.za>
Message-ID: <1221777205.55.0.0948177011592.issue3904@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> josiahcarlson
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3904>
_______________________________________

From report at bugs.python.org  Fri Sep 19 00:53:37 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 18 Sep 2008 22:53:37 +0000
Subject: [issue3708] os.urandom(1.1): infinite loop
In-Reply-To: <1219879812.7.0.142620771907.issue3708@psf.upfronthosting.co.za>
Message-ID: <1221778417.09.0.0432447055467.issue3708@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

It seems to me that test case will fail on windows and vms platforms.
The case contain os.urandom(1.1) but in posixmodule.c for urandon
functions (windows and vms) exits:
  PyArg_ParseTuple(args, "i:urandom", &howMany))

./python.exe -c 'import os; print "%s" %(os.urandom(1.9))' =>
-c:1: DeprecationWarning: integer argument expected, got float

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3708>
_______________________________________

From report at bugs.python.org  Fri Sep 19 01:07:02 2008
From: report at bugs.python.org (Todd Whiteman)
Date: Thu, 18 Sep 2008 23:07:02 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>


New submission from Todd Whiteman <twhitema at yahoo.com.au>:

I'm getting a 'The handle is invalid' error when using subprocess.Popen
in Python 2.5 (and 2.6). If any of the stdio handles are somehow invalid
or not real io handles (fd is not 0, 1 or 2), and you are not telling
subprocess to PIPE all of the handles, then subprocess throws the
following exception.

The easiest way to reproduce this is using run PythonWin from a Windows
Command Prompt:
  C:\Python\Lib\site-packages\pythonwin\Pythonwin.exe
and then use the following 2 subprocess code lines below:

import subprocess
p = subprocess.Popen(["python", "-c", "print 32"], stdin=None,
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\lib\subprocess.py", line 588, in init_
    errread, errwrite) = self._get_handles(stdin, stdout, stderr)
  File "C:\Python26\lib\subprocess.py", line 703, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "C:\Python26\lib\subprocess.py", line 748, in _make_inheritable
    DUPLICATE_SAME_ACCESS)
WindowsError: [Error 6] The handle is invalid


Specifying PIPE for all subprocess.Popen handles is the only way I've
found to get around this problem:

p = subprocess.Popen(["python", "-c", "print 32"],
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
p.stdin.close()
p.communicate()
('32\r\n', '')

----------
components: Windows
messages: 73408
nosy: trentm, twhitema
severity: normal
status: open
title: subprocess failing in GUI applications on Windows
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Fri Sep 19 01:08:09 2008
From: report at bugs.python.org (Todd Whiteman)
Date: Thu, 18 Sep 2008 23:08:09 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221779289.62.0.0159629751498.issue3905@psf.upfronthosting.co.za>


Todd Whiteman <twhitema at yahoo.com.au> added the comment:

This seems to be somewhat related to issue1124861:
http://bugs.python.org/issue1124861

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Fri Sep 19 01:17:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Sep 2008 23:17:59 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221779879.43.0.691751887872.issue3879@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Georg, you applied the offending patch. Can you comment?

----------
assignee:  -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Fri Sep 19 03:58:54 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 19 Sep 2008 01:58:54 +0000
Subject: [issue586680] -S hides standard dynamic modules
Message-ID: <1221789534.42.0.825275132853.issue586680@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If we think once can reliably add the directory based purely on whether
it starts with "build/lib.", and then potentially check for a suffix of
"-pydebug" if we are in a debug build, I will support adding this to
getpath.c to ditch the distutils import used by site.py.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue586680>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:04:47 2008
From: report at bugs.python.org (Roger Upole)
Date: Fri, 19 Sep 2008 02:04:47 +0000
Subject: [issue3906] lib2to3\main.py will not run
In-Reply-To: <1221789887.71.0.117556285993.issue3906@psf.upfronthosting.co.za>
Message-ID: <1221789887.71.0.117556285993.issue3906@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

On first try:

  File "H:\Python-3.0rc1\Lib\lib2to3\main.py", line 10, in <module>
    from . import refactor
ValueError: Attempted relative import in non-package

And after changing that line to
from lib2to3 import refactor
it still dies with

  File "H:\Python-3.0rc1\Lib\lib2to3\main.py", line 86, in <module>
    sys.exit(main())
TypeError: main() takes at least 1 positional argument (0 given)

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 73412
nosy: collinwinter, rupole
severity: normal
status: open
title: lib2to3\main.py will not run
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3906>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:08:20 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 19 Sep 2008 02:08:20 +0000
Subject: [issue3904] asynchat async_chat __init__() arguments changed in
	python 2.6
In-Reply-To: <1221776877.68.0.695076876479.issue3904@psf.upfronthosting.co.za>
Message-ID: <1221790100.73.0.402648806429.issue3904@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Fixed documentation in revision 66510.  Also, the parameters changed 
long before rc2. ;)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3904>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:13:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 19 Sep 2008 02:13:26 +0000
Subject: [issue586680] -S hides standard dynamic modules
In-Reply-To: <1221789534.42.0.825275132853.issue586680@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809181913w32b6a427he19d65b2868fc87b@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Thu, Sep 18, 2008 at 6:58 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> Brett Cannon <brett at python.org> added the comment:
>
> If we think once can reliably add the directory based purely on whether
> it starts with "build/lib.", and then potentially check for a suffix of
> "-pydebug" if we are in a debug build,

... and if there is more than one match in the build directory, either
error out or choose one of the directories somehow. I guess the real
question is how often to people actually have multiple versions of
their built libraries in build/.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue586680>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:15:26 2008
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 19 Sep 2008 02:15:26 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221790526.53.0.0445145960689.issue3892@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

We are seeing one more error almost identical to the one I fixed (even
the method name is the same), but its at line 315 - this is the last
error in the Windows buildbot!  Please let me know if you would like me
to make a similar "fix" to this line, or if you think you will be able
to back out my hack or skip the test some other way.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:24:03 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 19 Sep 2008 02:24:03 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1221791043.75.0.352455775322.issue1641@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I have an updated sched.py module which significantly improves the 
performance of the cancel() operation on scheduled events (amortized 
O(log(n)), as opposed to O(n) as it is currently).  This is sufficient 
to make sched.py into the equivalent of a pair heap.

>From there, it's all a matter of desired API and features.

My opinion on the matter: it would be very nice to have the asyncore 
loop handle all of the scheduled events internally.  However, being able 
to schedule and reschedule events is a generally useful feature, and 
inserting the complete functionality into asyncore would unnecessarily 
hide the feature and make it less likely to be used by the Python 
community.

In asyncore, I believe that it would be sufficient to offer the ability 
to call a function within asyncore.loop() before the asyncore.poll() 
call, whose result (if it is a number greater than zero, but less than 
the normal timeout) is the timeout passed to asyncore.poll().  Obviously  
the function scheduler would be written with this asyncore API in mind.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:33:05 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Fri, 19 Sep 2008 02:33:05 +0000
Subject: [issue3899] test_ssl.py doesn't properly test ssl integration with
	asyncore
In-Reply-To: <1221744950.78.0.538519688245.issue3899@psf.upfronthosting.co.za>
Message-ID: <1221791585.25.0.229562912277.issue3899@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Being able to test the async features of both sides of the SSL 
connection is a good thing.

Also, the subclass provides a useful example for users who want to use 
asyncore and ssl servers without blocking on an incoming connection.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3899>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:47:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Sep 2008 02:47:58 +0000
Subject: [issue3906] lib2to3\main.py will not run
In-Reply-To: <1221789887.71.0.117556285993.issue3906@psf.upfronthosting.co.za>
Message-ID: <1221792478.63.0.65839759283.issue3906@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

lib2to3/main.py is not an entry point. You should use the top level 2to3
script.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3906>
_______________________________________

From report at bugs.python.org  Fri Sep 19 04:58:25 2008
From: report at bugs.python.org (endolith)
Date: Fri, 19 Sep 2008 02:58:25 +0000
Subject: [issue3907] "for line in file" doesn't work for pipes
In-Reply-To: <1221793104.87.0.563162519119.issue3907@psf.upfronthosting.co.za>
Message-ID: <1221793104.87.0.563162519119.issue3907@psf.upfronthosting.co.za>


New submission from endolith <endolith at gmail.com>:

One of the principles of Python is that "There should be one-- and
preferably only one --obvious way to do it."  It seems that the "for
line in file" idiom is The Way to iterate over the lines of a file, and
older more explicit methods are deprecated.  PEP 234 says that this:

    for line in file:
        ...

is equivalent to this:

    for line in iter(file.readline, ""):
        ...

or this:

    while 1:
        line = file.readline()
        if not line:
            break
        ...

However, "for line in file" does not behave the same as the other two if
the file is a named pipe.  This is presumably due to the "hidden
read-ahead buffer" in the low-level implementation of the next() method
of the file iterator
(http://docs.python.org/lib/bltin-file-objects.html), meant to increase
the speed at which it reads regular physical files.  Since not enough
data exists in the pipe to fill the buffer yet, the lines are only read
in a burst after the buffer has been filled or when the pipe is closed.
 My application is monitoring a pipe for new lines from a logging
program, and I want each line read as soon as it is written.  Sure,
there are other ways to get this functionality, but I don't see why "for
line in file" shouldn't behave the same way for any file-like object.

I wonder if it can be made to internally use the read-ahead buffer for
closed physical files, and a different method for open named pipes.  I
wonder if reading pipes character-by-character causes any significant
slowdown compared to the read-ahead buffer when the pipe resides in
memory instead of a disk.

Forgive me if this is not really a bug, but it seems to my beginner eyes
that things are not working the way they should.

http://python-forum.org/pythonforum/viewtopic.php?t=9300
http://ubuntuforums.org/showthread.php?t=916518

----------
components: Interpreter Core
messages: 73419
nosy: endolith
severity: normal
status: open
title: "for line in file" doesn't work for pipes
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3907>
_______________________________________

From report at bugs.python.org  Fri Sep 19 05:17:18 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 19 Sep 2008 03:17:18 +0000
Subject: [issue3851] IDLE: Pressing "Home" on Windows places cursor before
	">>>" instead of after. Solution offered.
In-Reply-To: <1221250835.7.0.322524713176.issue3851@psf.upfronthosting.co.za>
Message-ID: <1221794238.75.0.158196471663.issue3851@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3851>
_______________________________________

From report at bugs.python.org  Fri Sep 19 05:17:24 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 19 Sep 2008 03:17:24 +0000
Subject: [issue3851] IDLE: Pressing "Home" on Windows places cursor before
	">>>" instead of after. Solution offered.
In-Reply-To: <1221250835.7.0.322524713176.issue3851@psf.upfronthosting.co.za>
Message-ID: <1221794244.83.0.710299012188.issue3851@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file11483/issue_3851.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3851>
_______________________________________

From report at bugs.python.org  Fri Sep 19 07:19:22 2008
From: report at bugs.python.org (Trent Mick)
Date: Fri, 19 Sep 2008 05:19:22 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221801562.12.0.921026362979.issue3905@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

The failure is in the DuplicateHandle call that subprocess makes on, in
this case, the stdin handle (as returned by
`GetStdHandle(STD_INPUT_HANDLE)`) call earlier.

Two cases here:

1. When this is run in a subsystem:windows process (like PythonWin or
IDLE) that is launched from Windows Explorer (e.g. from a Start Menu
shortcut or Desktop shortcut) then `GetStdHandle(STD_INPUT_HANDLE)`
returns None. 

[http://msdn.microsoft.com/en-us/library/ms683231(VS.85).aspx]
> If an application does not have associated standard handles,
> such as a service running on an interactive desktop, and has
> not redirected them, the return value is NULL.

In this case you *don't* get the error that Todd described, because the
code path taken in subprocess.py then use CreatePipe for the `p2cread`
variable on which `DuplicateHandle` is called.

2. However, when the subsystem:windows process is launched from the
cmd.exe shell the `GetStdHandle` call returns a value -- in Todd's and
my testing, the value 3.

The code path in subprocess.py then calls `DuplicateHandle` on this in
`Popen._make_inheritable`. This fails with traceback Todd posted.

My *guess* at what the problem is stems from this comment in the MSDN
docs on console handles:

[http://msdn.microsoft.com/en-us/library/ms682075(VS.85).aspx]
> A process can use the DuplicateHandle function to create a 
> duplicate console handle that has different access or 
> inheritability from the original handle. Note, however,
> that a process can create a duplicate console handle only
> for its own use. This differs from other handle types (such
> as file, pipe, or mutex objects), for which DuplicateHandle
> can create a duplicate that is valid for a different process.

My guess is that the stdin handle (3) is inherited from the shell
(cmd.exe) and attempting to `DuplicateHandle` on it violates the clause
that you can on dupe a console handle of your own. I'm not sure of that
though.

Anyone else have more light to shed on this?

If this is the case I'm not sure what a possible or good solution could
be for subprocess.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Fri Sep 19 07:56:45 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 19 Sep 2008 05:56:45 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221803805.73.0.107311625666.issue3892@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

just make a similar "fix" for now.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Fri Sep 19 08:07:12 2008
From: report at bugs.python.org (Dieter Kadelka)
Date: Fri, 19 Sep 2008 06:07:12 +0000
Subject: [issue3897] collections
In-Reply-To: <1221774258.5.0.367355517493.issue3897@psf.upfronthosting.co.za>
Message-ID: <48D3418E.9040209@stoch.uni-karlsruhe.de>


Dieter Kadelka <Dieter.Kadelka at stoch.uni-karlsruhe.de> added the comment:

Benjamin Peterson wrote:

Hello,
in Modules/Setup.dist line 179 you find
    #collections collectionsmodule.c # Container types
I think this line has to be changed to
    #_collections _collectionsmodule.c # Container types

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3897>
_______________________________________

From report at bugs.python.org  Fri Sep 19 10:35:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 19 Sep 2008 08:35:13 +0000
Subject: [issue3907] "for line in file" doesn't work for pipes
In-Reply-To: <1221793104.87.0.563162519119.issue3907@psf.upfronthosting.co.za>
Message-ID: <1221813313.69.0.319309336913.issue3907@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Python 2.6 and 3.0 come with a completely new I/O implementation, which
correctly handle pipes in this regard (I just tested).

http://docs.python.org/dev/library/io.html

With the 3.0 version, the built-in open() is an alias for io.open;
with 2.6, you have to use io.open() explicitely.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3907>
_______________________________________

From report at bugs.python.org  Fri Sep 19 12:59:13 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 19 Sep 2008 10:59:13 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <20080909182855.GD3400@gmail.com>
Message-ID: <20080919105901.GA4190@gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

This is working as designed and Requestor has not supplied any further
information on why he thinks it a bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3819>
_______________________________________

From report at bugs.python.org  Fri Sep 19 14:07:13 2008
From: report at bugs.python.org (Senthil)
Date: Fri, 19 Sep 2008 12:07:13 +0000
Subject: [issue3609] does parse_header really belong in CGI module?
In-Reply-To: <1219193477.24.0.768590998992.issue3609@psf.upfronthosting.co.za>
Message-ID: <1221826033.01.0.16704753013.issue3609@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3609>
_______________________________________

From report at bugs.python.org  Fri Sep 19 15:47:31 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 19 Sep 2008 13:47:31 +0000
Subject: [issue3908] Strange heapq behavior on Python 3.0 when overriding
	__le__
In-Reply-To: <1221832051.64.0.219061878163.issue3908@psf.upfronthosting.co.za>
Message-ID: <1221832051.64.0.219061878163.issue3908@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

import heapq

class foo:
    def __init__(self):
        self.timeout = 0
    def __le__(self, other):
        return self.timeout <= other.timeout

heap = []
heapq.heappush(heap, foo())
heapq.heappush(heap, foo())


This code on Python 2.x works without problems, by using Python3.0-RC1
it raises the following exception:


    heapq.heappush(heap, foo())
TypeError: unorderable types: foo() < foo()


Note that the previous 3.0 beta didn't have such problem.

----------
components: Library (Lib)
messages: 73425
nosy: giampaolo.rodola
severity: normal
status: open
title: Strange heapq behavior on Python 3.0 when overriding __le__
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3908>
_______________________________________

From report at bugs.python.org  Fri Sep 19 16:05:17 2008
From: report at bugs.python.org (=?utf-8?q?Sascha_M=C3=BCller?=)
Date: Fri, 19 Sep 2008 14:05:17 +0000
Subject: [issue3908] Strange heapq behavior on Python 3.0 when overriding
	__le__
In-Reply-To: <1221832051.64.0.219061878163.issue3908@psf.upfronthosting.co.za>
Message-ID: <1221833117.0.0.732693205238.issue3908@psf.upfronthosting.co.za>


Sascha M?ller <mailbox at saschamueller.com> added the comment:

heapq expects a _lt_ method, and the error doesn't occur when the _le_
method is changed to _lt. According to the SVN log, this was changed due
to consistency with lists.sort().

----------
nosy: +einmaliger -giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3908>
_______________________________________

From report at bugs.python.org  Fri Sep 19 16:16:33 2008
From: report at bugs.python.org (=?utf-8?q?Sascha_M=C3=BCller?=)
Date: Fri, 19 Sep 2008 14:16:33 +0000
Subject: [issue3908] Strange heapq behavior on Python 3.0 when overriding
	__le__
In-Reply-To: <1221832051.64.0.219061878163.issue3908@psf.upfronthosting.co.za>
Message-ID: <1221833793.81.0.258750125657.issue3908@psf.upfronthosting.co.za>


Changes by Sascha M?ller <mailbox at saschamueller.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3908>
_______________________________________

From report at bugs.python.org  Fri Sep 19 16:41:30 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 19 Sep 2008 14:41:30 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221835290.57.0.854441507681.issue3905@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

I do not really know if this is related to this, but I suspect yes.
On my w2k+sp4 box, swiss french, Python 3.0rc1, IDLE does not start or
more precisely it starts by opening the following message box:

Subprocess Startup Error
---------------------------
IDLE's subprocess didn't make connection.  Either IDLE can't start a
subprocess or personal firewall software is blocking the connection.

It is certainly neither a firewall issue, nor a tkinter issue (tkinter 
applications are working fine.)

No problem with the 3.0b2 realease, 3.0b3: not tested.

----------
nosy: +jmfauth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Fri Sep 19 17:27:09 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 19 Sep 2008 15:27:09 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221838029.65.0.881102886416.issue3905@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

jmfauth: please try to run idle from a command prompt:

> cd <path_to_python3.0rc1>
> python Lib/idlelib/idle.py

Do you see interesting output there?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Fri Sep 19 17:27:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 19 Sep 2008 15:27:40 +0000
Subject: [issue3887] Python 2.6 doesn't run after installation on amd64
In-Reply-To: <1221616975.51.0.807116578154.issue3887@psf.upfronthosting.co.za>
Message-ID: <1221838060.71.0.0446513694496.issue3887@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You were right; the x86 version of the CRT was included. This is now
fixed in r66514 and r66515.

If you want to try it out, try

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6rc2.amd64.msi
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6rc2.amd64.msi.asc

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3887>
_______________________________________

From report at bugs.python.org  Fri Sep 19 18:32:13 2008
From: report at bugs.python.org (jan matejek)
Date: Fri, 19 Sep 2008 16:32:13 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1221841933.74.0.111368833686.issue1424152@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/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Sep 19 18:46:47 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Fri, 19 Sep 2008 16:46:47 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:

I try to build PDF documentation from current Python-2.6rc2 and Python-
3.0rc1 versions. I tried the process under Windows XP and also Linux 
(Ubuntu). The results are the same. The documentation is not built 
correctly, mostly the table of contents and always the index is missing. 
pdflatex always stops with the same error:

! Too many }'s.
l.122 }

Line 122 refers to the file sphinx.sty.

After stopping, I rerun pdflatex with the command "R" to completion. 
This run has been created via the 3.0rc1 files, based on WindowsXP.

I will include a log file from the pdflatex build process. The error is 
in line 364 of file tutorial.log. 

The pdflatex (WindowsXP) version is:
MiKTeX-pdfTeX 2.7.3147 (1.40.9) (MiKTeX 2.7)
Copyright (C) 1982 D. E. Knuth, (C) 1996-2006 Han The Thanh
TeX is a trademark of the American Mathematical Society.

In case you need more docu, please let me know.

Winfried

----------
assignee: georg.brandl
components: Documentation
files: tutorial.zip
messages: 73430
nosy: georg.brandl, wplappert
severity: normal
status: open
title: Building PDF documentation from tex files
type: crash
versions: Python 2.5, Python 3.0
Added file: http://bugs.python.org/file11525/tutorial.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Fri Sep 19 18:50:59 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Fri, 19 Sep 2008 16:50:59 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1221843059.97.0.0609537687472.issue3909@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

modified version info: 2.6, 3.0

----------
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Fri Sep 19 19:08:11 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 19 Sep 2008 17:08:11 +0000
Subject: [issue3908] Strange heapq behavior on Python 3.0 when overriding
	__le__
In-Reply-To: <1221832051.64.0.219061878163.issue3908@psf.upfronthosting.co.za>
Message-ID: <1221844091.07.0.0191902954215.issue3908@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It's supposed to be that way.  In 2.6 we support both to help with 
transition. In 3.0, we've cleaned up and made the APIs consistent. Try to 
get in the habit of defining all six rich comparisons to bulletproof code 
and not rely on undocumented implementation details.

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3908>
_______________________________________

From report at bugs.python.org  Fri Sep 19 19:28:51 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 19 Sep 2008 17:28:51 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221845331.84.0.567489243555.issue3905@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>cd python30

C:\Python30>python Lib/idlelib/idle.py
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python30\lib\idlelib\run.py", line 76, in main
    sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'

C:\Python30>

Sorry if I can help here, things like socket and subprocess are not my
cup of tea.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Fri Sep 19 19:49:36 2008
From: report at bugs.python.org (jan matejek)
Date: Fri, 19 Sep 2008 17:49:36 +0000
Subject: [issue3910] 2.6 regression in socket.ssl method
In-Reply-To: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>
Message-ID: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>


New submission from jan matejek <jmatejek at suse.cz>:

python 2.6's compatibility socket.ssl() method does not handle 'sock'
parameter in the same way.

in 2.5, ssl() looked like this:

def ssl(sock, keyfile=None, certfile=None):
    if hasattr(sock, "_sock"):
        sock = sock._sock
    return _realssl(sock, keyfile, certfile)

in 2.6 the call is handed to ssl.sslwrap_simple, which then blindly does
_ssl.sslwrap(sock._sock, 0, keyfile, certfile, CERT_NONE,
PROTOCOL_SSLv23, None)
instead of checking whether the sock is the socket itself or the socket
object.
This causes code that passes the socket directly to fail with
"AttributeError: '_socket.socket' object has no attribute '_sock'
"

the attached patch fixes the behavior.

----------
components: Library (Lib)
files: bug-sslwrap-simple.patch
keywords: patch
messages: 73434
nosy: matejcik
severity: normal
status: open
title: 2.6 regression in socket.ssl method
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11526/bug-sslwrap-simple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3910>
_______________________________________

From report at bugs.python.org  Fri Sep 19 20:08:02 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 19 Sep 2008 18:08:02 +0000
Subject: [issue3911] ftplib.FTP.makeport() bug
In-Reply-To: <1221847682.44.0.529655554535.issue3911@psf.upfronthosting.co.za>
Message-ID: <1221847682.44.0.529655554535.issue3911@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

Python 3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ftplib
>>> f = ftplib.FTP()
>>> f.connect('mirrors.kernel.org')
'220 Welcome to mirrors.kernel.org.'
>>> f.login()
'230 Login successful.'
>>> f.debugging = 1
>>> f.makeport()
*cmd* 'PORT 10,0,0,1,18.21875,56'
*resp* '500 Illegal PORT command.'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python30\lib\ftplib.py", line 300, in makeport
    resp = self.sendport(host, port)
  File "C:\python30\lib\ftplib.py", line 260, in sendport
    return self.voidcmd(cmd)
  File "C:\python30\lib\ftplib.py", line 249, in voidcmd
    return self.voidresp()
  File "C:\python30\lib\ftplib.py", line 224, in voidresp
    resp = self.getresp()
  File "C:\python30\lib\ftplib.py", line 219, in getresp
    raise error_perm(resp)
ftplib.error_perm: 500 Illegal PORT command.
>>>



Path in attachment.

----------
components: Library (Lib)
files: ftplib.patch
keywords: patch
messages: 73435
nosy: giampaolo.rodola
severity: normal
status: open
title: ftplib.FTP.makeport() bug
versions: Python 3.0
Added file: http://bugs.python.org/file11527/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3911>
_______________________________________

From report at bugs.python.org  Fri Sep 19 20:49:14 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 19 Sep 2008 18:49:14 +0000
Subject: [issue3908] Strange heapq behavior on Python 3.0 when overriding
	__le__
In-Reply-To: <1221832051.64.0.219061878163.issue3908@psf.upfronthosting.co.za>
Message-ID: <1221850154.11.0.493698194302.issue3908@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Ok, thanks for the hints.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3908>
_______________________________________

From report at bugs.python.org  Fri Sep 19 21:37:15 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 19 Sep 2008 19:37:15 +0000
Subject: [issue3910] 2.6 regression in socket.ssl method
In-Reply-To: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>
Message-ID: <1221853035.35.0.114926523626.issue3910@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This makes sense and is a trivial compatibility fix.  anyone disagree?

----------
nosy: +gregory.p.smith, janssen
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3910>
_______________________________________

From report at bugs.python.org  Fri Sep 19 21:40:45 2008
From: report at bugs.python.org (John Ehresman)
Date: Fri, 19 Sep 2008 19:40:45 +0000
Subject: [issue3887] Python 2.6 doesn't run after installation on amd64
In-Reply-To: <1221838060.71.0.0446513694496.issue3887@psf.upfronthosting.co.za>
Message-ID: <48D40025.5020507@wingware.com>


John Ehresman <jpe at wingware.com> added the comment:

The new installer works for both for everyone and for me installs.

Thanks,

John

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3887>
_______________________________________

From report at bugs.python.org  Fri Sep 19 22:13:47 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 19 Sep 2008 20:13:47 +0000
Subject: [issue3910] 2.6 regression in socket.ssl method
In-Reply-To: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>
Message-ID: <1221855227.37.0.900698586476.issue3910@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Looks OK to me.  I think this is a back-port problem from 3.0.

I'll put it in if no one objects.

----------
assignee:  -> janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3910>
_______________________________________

From report at bugs.python.org  Fri Sep 19 22:20:10 2008
From: report at bugs.python.org (Damien Miller)
Date: Fri, 19 Sep 2008 20:20:10 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <alpine.BSO.1.10.0809200617000.3881@fuyu.mindrot.org>


Damien Miller <djmdjm at users.sourceforge.net> added the comment:

So the bug is actually in the multiprocessing module rather than the
unittest. If HAVE_SEM_OPEN is not defined then SemLock is never
built into _multiprocessing.so, but multiprocessing/syncronize.py
unconditionally depends on its presence.

I guess _multiprocessing could always define a dummy SemLock or
synchronize.py could check before it depends on it.

(it would be great to see this fixed for 2.6)

-d

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Fri Sep 19 22:29:28 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 19 Sep 2008 20:29:28 +0000
Subject: [issue3899] test_ssl.py doesn't properly test ssl integration with
	asyncore
In-Reply-To: <1221791585.25.0.229562912277.issue3899@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0809191329k247cc3ddsabecfe6bcc7a0cd9@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Sure, no argument.  I was just making clear what was going on.

Bill

On Thu, Sep 18, 2008 at 7:33 PM, Josiah Carlson <report at bugs.python.org>wrote:

>
> Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:
>
> Being able to test the async features of both sides of the SSL
> connection is a good thing.
>
> Also, the subclass provides a useful example for users who want to use
> asyncore and ssl servers without blocking on an incoming connection.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3899>
> _______________________________________
>

Added file: http://bugs.python.org/file11528/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3899>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080919/dbb40201/attachment.txt>

From report at bugs.python.org  Fri Sep 19 23:12:34 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 19 Sep 2008 21:12:34 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1221858754.86.0.621863918072.issue3770@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Bumping up _ I'll need help with a patch

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Fri Sep 19 23:49:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Sep 2008 21:49:50 +0000
Subject: [issue3628] IDLE does not run with Py30b3
In-Reply-To: <1219305991.9.0.193360679175.issue3628@psf.upfronthosting.co.za>
Message-ID: <1221860990.82.0.49094457343.issue3628@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66518.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3628>
_______________________________________

From report at bugs.python.org  Sat Sep 20 00:27:25 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 19 Sep 2008 22:27:25 +0000
Subject: [issue3838] test_tarfile error on cygwin (Directory not empty)
In-Reply-To: <1221155992.48.0.592399874075.issue3838@psf.upfronthosting.co.za>
Message-ID: <1221863245.35.0.951299642345.issue3838@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3838>
_______________________________________

From report at bugs.python.org  Sat Sep 20 01:16:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Sep 2008 23:16:41 +0000
Subject: [issue3911] ftplib.FTP.makeport() bug
In-Reply-To: <1221847682.44.0.529655554535.issue3911@psf.upfronthosting.co.za>
Message-ID: <1221866201.41.0.293429594607.issue3911@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Why not just use floor divide (//)?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3911>
_______________________________________

From report at bugs.python.org  Sat Sep 20 01:23:24 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 19 Sep 2008 23:23:24 +0000
Subject: [issue3911] ftplib.FTP.makeport() bug
In-Reply-To: <1221847682.44.0.529655554535.issue3911@psf.upfronthosting.co.za>
Message-ID: <1221866604.9.0.626952510017.issue3911@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

At your discretion. I was thinking that it's not encouraging that such
an outstanding bug has passed silently until RC1. IMHO, a minimal test
suite for the ftplib module would be really necessary.

A dummy FTP server returning fixed response codes could be arranged and
used to test the basic FTP class methods.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3911>
_______________________________________

From report at bugs.python.org  Sat Sep 20 01:24:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Sep 2008 23:24:37 +0000
Subject: [issue3911] ftplib.FTP.makeport() bug
In-Reply-To: <1221866604.9.0.626952510017.issue3911@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809191624y419738dbkf1a33d9045338495@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Fri, Sep 19, 2008 at 6:23 PM, Giampaolo Rodola'
<report at bugs.python.org> wrote:
>
> Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:
>
> At your discretion. I was thinking that it's not encouraging that such
> an outstanding bug has passed silently until RC1. IMHO, a minimal test
> suite for the ftplib module would be really necessary.

Yes, testing of some of these modules is quite sad.

>
> A dummy FTP server returning fixed response codes could be arranged and
> used to test the basic FTP class methods.

Would you like to contribute a patch?
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3911>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3911>
_______________________________________

From report at bugs.python.org  Sat Sep 20 02:22:45 2008
From: report at bugs.python.org (Roy Smith)
Date: Sat, 20 Sep 2008 00:22:45 +0000
Subject: [issue3912] unittest. assertAlmostEqual() documentation incomplete
In-Reply-To: <1221870165.22.0.917883186399.issue3912@psf.upfronthosting.co.za>
Message-ID: <1221870165.22.0.917883186399.issue3912@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The third argument, places, is optional, but no indication is given what 
value is used if it is omitted.

----------
assignee: georg.brandl
components: Documentation
messages: 73447
nosy: georg.brandl, roysmith
severity: normal
status: open
title: unittest. assertAlmostEqual() documentation incomplete
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3912>
_______________________________________

From report at bugs.python.org  Sat Sep 20 02:59:57 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 20 Sep 2008 00:59:57 +0000
Subject: [issue3913] compound_stmt syntax includes 'decorated'
In-Reply-To: <1221872397.1.0.255492187185.issue3913@psf.upfronthosting.co.za>
Message-ID: <1221872397.1.0.255492187185.issue3913@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

The python 3.0 Language Reference page describing compound_stmt
(http://docs.python.org/dev/3.0/reference/compound_stmts.html) includes
'decorated'.  But the funcdef and classdef definitions both include
optional decorators.  It looks like this 'decorated' option should be
deleted.

----------
assignee: georg.brandl
components: Documentation
messages: 73448
nosy: dangyogi, georg.brandl
severity: normal
status: open
title: compound_stmt syntax includes 'decorated'
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3913>
_______________________________________

From report at bugs.python.org  Sat Sep 20 03:03:49 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 20 Sep 2008 01:03:49 +0000
Subject: [issue3914] augop definition does not include "//="
In-Reply-To: <1221872629.07.0.183880310815.issue3914@psf.upfronthosting.co.za>
Message-ID: <1221872629.07.0.183880310815.issue3914@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

The definition for 'augop' on the Simple Statements page of the Language
Definition does not include "//=".

http://docs.python.org/dev/3.0/reference/simple_stmts.html#grammar-token-augop

----------
assignee: georg.brandl
components: Documentation
messages: 73449
nosy: dangyogi, georg.brandl
severity: normal
status: open
title: augop definition does not include "//="
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3914>
_______________________________________

From report at bugs.python.org  Sat Sep 20 03:03:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Sep 2008 01:03:59 +0000
Subject: [issue3913] compound_stmt syntax includes 'decorated'
In-Reply-To: <1221872397.1.0.255492187185.issue3913@psf.upfronthosting.co.za>
Message-ID: <1221872639.14.0.855717413781.issue3913@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

If you look at the real Grammar (in Grammar/Grammar), you will see that
this decorated is used in the grammar.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3913>
_______________________________________

From report at bugs.python.org  Sat Sep 20 03:08:28 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Sep 2008 01:08:28 +0000
Subject: [issue3851] IDLE: Pressing "Home" on Windows places cursor before
	">>>" instead of after. Solution offered.
In-Reply-To: <1221250835.7.0.322524713176.issue3851@psf.upfronthosting.co.za>
Message-ID: <1221872908.78.0.93709606558.issue3851@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is supposed to have been fixed by
http://bugs.python.org/issue1196903
but I don't believe there has not been a 2.5 release since then.
I do not know if that patch was or was backported for 2.5.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3851>
_______________________________________

From report at bugs.python.org  Sat Sep 20 03:18:06 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 20 Sep 2008 01:18:06 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1221873486.69.0.377924354525.issue3892@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Actually, I've decided to leave it alone.  The buildbots most recent
failure was:

test test_bsddb3 failed -- Traceback (most recent call last):
  File
"S:\buildbots\python\trunk.nelson-windows\build\lib\bsddb\test\test_replication.py",
line 315, in test01_basic_replication
    self.assertTrue(time.time()<timeout)
AssertionError

But I can't repro that - instead, I now see:

Traceback (most recent call last):
  File "o:\src\python-svn\lib\bsddb\test\test_lock.py", line 127, in
test03_lock_timeout
    self.assertTrue((end_time-start_time) >= 0.1)
AssertionError

So I go back to the windows buildbots and they are all green!!  So any
remaining issues appear truly transient and don't seem to be restricted
to a single place.  I can't think of an obvious improvement to make here.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Sat Sep 20 03:48:11 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 20 Sep 2008 01:48:11 +0000
Subject: [issue3913] compound_stmt syntax includes 'decorated'
In-Reply-To: <1221872639.14.0.855717413781.issue3913@psf.upfronthosting.co.za>
Message-ID: <48D4555D.2090907@gmail.com>


Bruce Frederiksen <dangyogi at gmail.com> added the comment:

But the real Grammar doesn't include decorators on funcdef and classdef, 
while the Language Reference document does.  So the 'decorated' option 
is not needed in the Language Reference (and, indeed, doesn't even seem 
to be defined there).

Benjamin Peterson wrote:
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> If you look at the real Grammar (in Grammar/Grammar), you will see that
> this decorated is used in the grammar.
>
> ----------
> nosy: +benjamin.peterson
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3913>
> _______________________________________
>
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3913>
_______________________________________

From report at bugs.python.org  Sat Sep 20 04:13:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Sep 2008 02:13:07 +0000
Subject: [issue3913] compound_stmt syntax includes 'decorated'
In-Reply-To: <1221872397.1.0.255492187185.issue3913@psf.upfronthosting.co.za>
Message-ID: <1221876787.77.0.858880655149.issue3913@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The language reference is merely a explanation of the the Grammar, so I
don't understand why you think it shouldn't be there. A 'decorated' node
contains a 'classdef' or 'fundef'.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3913>
_______________________________________

From report at bugs.python.org  Sat Sep 20 04:37:34 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Sep 2008 02:37:34 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221878254.12.0.141974964779.issue3891@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I changed this to a doc issue for 2.6/3.0 whenever.

I have two objections to adding "An empty deque evaluates as false". 
First, it implies (falsely) that it could be otherwise; since deque has
no __bool__ method, its __len__ method is used, so that bool(d) ==
(len(d)!=0).   Second, it misses better doc enhancements that might make
the statement I just made clearer and easier to find.

1. Ref manual Expressions Boolean Operations says
"In the context of Boolean operations, and also when expressions are
used by control flow statements, the following values are interpreted as
false: False, None, numeric zero of all types, and empty strings and
containers (including strings, tuples, lists, dictionaries, sets and
frozensets)."

For 3.0, I suggest replacing "and empty strings..." with
"empty strings and sequences (including strings, bytes, bytearrays,
tuples, lists, and Userlists and deques from the collections module),
and other empty containers (sets, frozensets, dictionaries, and
Userdicts and defaultdicts from the collections module)."
Anything else I forgot?  Adjust for 2.5/6.

The sentence after next "User-defined objects can customize their truth
value by providing a __bool__() method." should say '... __bool__ or
__len__ method.', with __len__ linked to object.__len__ just as __bool__
is linked to object.__bool__.

2. The LibRef entry for built-in function bool says simply "Convert a
value to a Boolean, using the standard truth testing procedure". 
Extended that with " described in the Language reference in the __bool__
and __len__ entries of the Special methods subsection and in the Boolean
operations subsection."

----------
assignee: rhettinger -> georg.brandl
components: +Documentation -Extension Modules, Library (Lib)
nosy: +georg.brandl, tjreedy
versions: +Python 2.6, Python 3.0 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Sat Sep 20 05:00:22 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 20 Sep 2008 03:00:22 +0000
Subject: [issue3913] compound_stmt syntax includes 'decorated'
In-Reply-To: <1221876787.77.0.858880655149.issue3913@psf.upfronthosting.co.za>
Message-ID: <48D46646.2010505@gmail.com>


Bruce Frederiksen <dangyogi at gmail.com> added the comment:

The grammar definitions in the Language Reference are _not_ just a 
straight copy of the Grammar.  They have been reworked.  (I don't know 
why, perhaps to make it easier to understand)?

So the Grammar defines funcdef and classdef _without_ decorators and 
then has a separate definition for decorated funcdefs and classdefs 
called 'decorated' that is another compound_stmt (along with funcdef and 
classdef).  (For Grammar, I'm looking at: 
http://docs.python.org/dev/3.0/reference/grammar.html).

The Language Reference defines both funcdef and classdef _with_ optional 
decorators, so the 'decorated' alternative for compound_stmt is no 
longer required and should be deleted.  The following links should take 
you straight to the funcdef and classdef definitions in the Language 
Reference:

http://docs.python.org/dev/3.0/reference/compound_stmts.html#grammar-token-funcdef
http://docs.python.org/dev/3.0/reference/compound_stmts.html#grammar-token-classdef

Now, I just also noticed that the Language Reference actually has two 
definitions of funcdef.  The second definition is 3 lines below the 
first one and fails to include either the optional decorators or the new 
["->" expression] option after the argument list.  Should I report this 
as another bug, or does this comment count.  This second definition 
should be deleted.

Also, the first definition of funcdef in the Language Reference has an 
extraneous '?' character after the ["->" expression] which should also 
be deleted.  Should I report this as a separate bug too, or leave it, as 
well, to this comment?  (Sorry for asking whether to report these too, I 
don't know how strict you guys are about keeping a record of everything).

There are many other places where the grammar defined in the Language 
Reference is not a mirror copy of the Grammar (but is still an 
equivalent grammar).  In fact, this seems to be the rule, rather than 
the exception.  If you are unaware of this, you should examine the 
grammar definitions in the Language Reference and compare them to the 
Grammar yourself; or ask whoever is in charge of the Language Reference 
document.  I don't know why this was done, I'm just trying to point out 
that the Language Reference document has some (minor) bugs in it that 
are very easily fixed.

Benjamin Peterson wrote:
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> The language reference is merely a explanation of the the Grammar, so I
> don't understand why you think it shouldn't be there. A 'decorated' node
> contains a 'classdef' or 'fundef'.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3913>
> _______________________________________
>
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3913>
_______________________________________

From report at bugs.python.org  Sat Sep 20 05:22:10 2008
From: report at bugs.python.org (Roy Smith)
Date: Sat, 20 Sep 2008 03:22:10 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221880930.19.0.864950178252.issue3891@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

I think you're missing the point.  Imagine you are somebody who doesn't know 
Python internals.  You're looking at the doc page for deque and ask yourself 
the question, "How do I tell if one of these is empty?".  There's no 
information ON THAT PAGE that answers that question.  Your explanation is all 
about "How do I compute the boolean value of a container?"  The logical gap 
is that you need to understand that to tell if it's empty, you should compute 
the boolean value.

You give the page on boolean operations as part of the answer, but you need 
to know to go look at that page in the first place.  I should be able to look 
at the page that describes a deque and find out everything I need to know 
about that class on that page.

Essentially, what you're saying is that deque inherits some behaviors from 
container, one of which being that if you convert a container to a bool, it 
is True iff the container is not empty.  So, there should be something on the 
deque page which points to that information.

Explicit is better than implicit :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Sat Sep 20 09:38:11 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Sat, 20 Sep 2008 07:38:11 +0000
Subject: [issue1688] Incorrectly displayed non ascii characters in prompt
	using "input()" - Python 3.0a2
In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>
Message-ID: <1221896291.78.0.835175547457.issue1688@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

While I am not sure about the status of this somewhat older issue, I 
just wanted to mention, that the behaviour remains the same in Python 
3.0rc1 (XPh SP3, Czech)

Python 3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input("???: ")
??????: ???
'???'
>>> print("???: ")
???:
>>>

Is the patch above supposed to have been committed, or are there yet 
another difficulties?
(Not that it is a huge problem (for me), as applications dealing with 
non ascii text probably would use a gui, rather than relying on a 
console, but it's a kind of surprising.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
_______________________________________

From report at bugs.python.org  Sat Sep 20 10:03:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Sep 2008 08:03:32 +0000
Subject: [issue3891] collections.deque should have empty() method
In-Reply-To: <1221686229.93.0.518355205894.issue3891@psf.upfronthosting.co.za>
Message-ID: <1221897812.21.0.409648589273.issue3891@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry Roy, I think you're way off base on this one.  There are standard
ways to test for an empty container "if c:" or "if len(c)" or "if len(c)
> 0".  This is Python 101. 

Closing this one as it has nothing to do specifically with
collections.deque() and is already covered in the Ref Manual.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3891>
_______________________________________

From report at bugs.python.org  Sat Sep 20 10:15:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Sep 2008 08:15:55 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221898555.8.0.119735822173.issue3905@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

There are also instances of set_daemon left in socketserver and
multiprocessing/dummy. How is that possible?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Sep 20 10:15:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Sep 2008 08:15:28 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221898528.44.0.665308195948.issue3905@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Benjamin, I think you're responsible.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Sep 20 10:59:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 20 Sep 2008 08:59:17 +0000
Subject: [issue1688] Incorrectly displayed non ascii characters in prompt
	using "input()" - Python 3.0a2
In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>
Message-ID: <1221901157.71.0.678262981696.issue1688@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +needs review
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
_______________________________________

From report at bugs.python.org  Sat Sep 20 12:46:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 20 Sep 2008 10:46:41 +0000
Subject: [issue1688] Incorrectly displayed non ascii characters in prompt
	using "input()" - Python 3.0a2
In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>
Message-ID: <1221907601.48.0.657499568321.issue1688@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Amaury, what further review of the patch do you desire? I had already
commented that I consider the patch correct, except that it might use
stdout_encoding instead.

Also, I wouldn't consider this a release blocker. It is somewhat
annoying that input produces moji-bake in certain cases (i.e. non-ASCII
characters in the prompt, and a non-UTF-8 terminal), but if the patch
wouldn't make it into 3.0, we can still fix it in 3.0.1.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
_______________________________________

From report at bugs.python.org  Sat Sep 20 14:53:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Sep 2008 12:53:41 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221915221.03.0.918927415658.issue3905@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The idle problem has already been fixed, and I got the socket server one
in r66520.

----------
assignee: benjamin.peterson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Sep 20 17:04:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 20 Sep 2008 15:04:34 +0000
Subject: [issue1688] Incorrectly displayed non ascii characters in prompt
	using "input()" - Python 3.0a2
In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>
Message-ID: <1221923074.09.0.309976404687.issue1688@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Given MvL's review, assuming it fixes the Czech problem, I'm all for
applying it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
_______________________________________

From report at bugs.python.org  Sat Sep 20 18:19:51 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 20 Sep 2008 16:19:51 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1221927591.08.0.358526166139.issue3884@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd like to appeal that decision. That the turtle module is implemented
in Tkinter is, well, an implementation detail. What matters to the end
user is the turtle API, which has little to do with Tkinter (at least,
the most high-level API doesn't).

I think it is a mistake to have the module in the tkinter package, hence
I marked this bug release-critical, and would like to ask that this is
reconsidered before rc2 (clearly, when 3.0 is released, this mistake
cannot be corrected easily anymore).

In considering this issue, please understand the target audience of the
turtle module: children that just learn programming. I completely agree
with Kirill (and also with Gregor Lingl, who complained about this also,
but didn't follow up). For these people, stability of documentation is
much more important than for trained programmers: when they get an
import error, they consider all kinds of problems (such as them having
mistyped things, or the computer being broken and the module being
missing); the real cause (arbitrary renaming) doesn't come to their mind
as the first thing.

Attached is a patch that has the necessary changes.

Guido, would you be willing to pronounce?

----------
assignee: brett.cannon -> gvanrossum
keywords: +patch
nosy: +glingl, gregorlingl, gvanrossum, loewis
priority:  -> release blocker
resolution: rejected -> 
status: closed -> open
Added file: http://bugs.python.org/file11529/turtle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Sat Sep 20 18:43:24 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 20 Sep 2008 16:43:24 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221929004.29.0.0190062918923.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

This patch is now based on Python 2.6rc2.

I've reduced the number of macros and used functions instead, provided
that it didn't cost much in terms of speed. In many cases it should be
faster than the current release, and at worst no slower. More speed
tests and tweaks needed.

BTW, the impression I got was that look-behind was fixed width because
the matching operations could only match forwards through the text, so
in order to look behind it had to step back through the text and then
match forwards. For simplicity and speed it insisted that it must be
able to determine the size of the step beforehand, hence fixed-width. My
addition was to add matching operations which worked matched backwards
and also reverse the order of the matching for look-behinds, an idea
which I got from a page on how it could be implemented in Perl 6!

Added file: http://bugs.python.org/file11530/regex_2.6rc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 20 19:53:39 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 20 Sep 2008 17:53:39 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1221933219.1.0.492410153707.issue3884@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Agreed. It's toplevel in 2.6. Let's keep it toplevel in 3.x.

----------
assignee: gvanrossum -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Sat Sep 20 20:12:48 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sat, 20 Sep 2008 18:12:48 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221934368.46.0.208501133507.issue3905@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

Just for information and from an end user perspective.

I have tried to replace the socketserver.py from the original 3.0rc1
distribution by the socketserver.py as proposed by Benjamin Peterson
(r66520).

Script difference (line 568):

        if self.daemon_threads:
            t.daemon = True
        t.start()

and 

        if self.daemon_threads:
            t.set_daemon(True)
        t.start()

Unfortunately, no luck, I'm still getting exactly the same error
messages, the msg box and the raised AttributeError:

AttributeError: 'Thread' object has no attribute 'set_daemon'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Sep 20 20:59:37 2008
From: report at bugs.python.org (Jason Etheridge)
Date: Sat, 20 Sep 2008 18:59:37 +0000
Subject: [issue3915] Broken link in 14.7 curses, Python Library Reference
In-Reply-To: <1221937177.94.0.347210678057.issue3915@psf.upfronthosting.co.za>
Message-ID: <1221937177.94.0.347210678057.issue3915@psf.upfronthosting.co.za>


New submission from Jason Etheridge <jasoneth at gmail.com>:

In http://docs.python.org/lib/module-curses.html, the link "Curses 
Programming with Python" is broken. It links to http://www.python.org/doc/howto/curses/curses.html, which no longer 
exists. I found the page externally at http://www.amk.ca/python/howto/curses/.

----------
assignee: georg.brandl
components: Documentation
messages: 73469
nosy: georg.brandl, jasoneth
severity: normal
status: open
title: Broken link in 14.7 curses, Python Library Reference
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3915>
_______________________________________

From report at bugs.python.org  Sat Sep 20 21:58:14 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 20 Sep 2008 19:58:14 +0000
Subject: [issue3911] ftplib.FTP.makeport() bug
In-Reply-To: <1221847682.44.0.529655554535.issue3911@psf.upfronthosting.co.za>
Message-ID: <1221940694.24.0.739288488485.issue3911@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> Would you like to contribute a patch?

Ok.
I started working on a patch which implements a dummy asyncore-based FTP
server including tests for all basic FTP() class methods.
I'll contribute a patch as soon as I'll wrote IPv6 tests.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3911>
_______________________________________

From report at bugs.python.org  Sat Sep 20 22:20:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 20 Sep 2008 20:20:22 +0000
Subject: [issue1688] Incorrectly displayed non ascii characters in prompt
	using "input()" - Python 3.0a2
In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>
Message-ID: <1221942022.97.0.250632929922.issue1688@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a new version of the patch: the PyString* functions were renamed
to PyBytes*, and it now uses stdout_encoding.

About the "release blocker" status: I agree it is not so important, I
just wanted to express my "it's been here for long, it's almost ready,
it would be a pity not to have it in the final 3.0" feelings.

----------
keywords: +patch
Added file: http://bugs.python.org/file11531/inputprompt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
_______________________________________

From report at bugs.python.org  Sat Sep 20 22:31:41 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 20 Sep 2008 20:31:41 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221942701.97.0.351823861247.issue3825@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


Removed file: http://bugs.python.org/file11530/regex_2.6rc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 20 22:32:41 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 20 Sep 2008 20:32:41 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1221942761.76.0.794549566856.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Bugfix.

Added file: http://bugs.python.org/file11532/regex_2.6rc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sat Sep 20 22:57:34 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 20 Sep 2008 20:57:34 +0000
Subject: [issue3916] layout of build directories for Windows not current
In-Reply-To: <1221944254.72.0.255027457089.issue3916@psf.upfronthosting.co.za>
Message-ID: <1221944254.72.0.255027457089.issue3916@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

In the "Using Python on Windows" document, the 
various directories listed for building Python 
on Windows are not current. The attached patch 
fixes the documentation.

Also included a small fix in the PBbuild/
readme.txt file.

----------
assignee: georg.brandl
components: Documentation
files: docwin.patch
keywords: patch
messages: 73473
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: layout of build directories for Windows not current
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11533/docwin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3916>
_______________________________________

From report at bugs.python.org  Sat Sep 20 23:21:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 20 Sep 2008 21:21:49 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1221945709.18.0.668588388093.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This patches corrects the bad printf, when the given filename is only
1-char long.

----------
keywords: +needs review
Added file: http://bugs.python.org/file11534/cygwin_badprintf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Sat Sep 20 23:28:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 20 Sep 2008 21:28:20 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1221946100.75.0.269039312807.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Since the bsddb module has been removed from py3k, the previous patch
addresses the last issue for this ticket.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Sun Sep 21 00:34:31 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 20 Sep 2008 22:34:31 +0000
Subject: [issue3912] unittest. assertAlmostEqual() documentation incomplete
In-Reply-To: <1221870165.22.0.917883186399.issue3912@psf.upfronthosting.co.za>
Message-ID: <1221950071.29.0.710543156048.issue3912@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This patch documents the missing default value.

----------
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file11535/unittest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3912>
_______________________________________

From report at bugs.python.org  Sun Sep 21 01:05:49 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 20 Sep 2008 23:05:49 +0000
Subject: [issue3852] kqueue.control requires 2 params while docs say
	max_events (the second) defaults to 0
In-Reply-To: <1221256371.42.0.0336253245305.issue3852@psf.upfronthosting.co.za>
Message-ID: <1221951949.58.0.748320157417.issue3852@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Attached a documentation patch, including the kqueue.control function 
docstring.

But I wonder if the code was incorrect instead - both the 
documentation and the function docstring specified a default value for 
max_events=0, and the corresponding variable was initialized to 0.
Perhaps the author meant to use PyArg_ParseTuple(args, "O|
iO:control",...) instead of the current "Oi|O:control"

----------
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file11536/select.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3852>
_______________________________________

From report at bugs.python.org  Sun Sep 21 01:41:56 2008
From: report at bugs.python.org (Kevin Watters)
Date: Sat, 20 Sep 2008 23:41:56 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221954117.0.0.691599023978.issue3905@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sun Sep 21 02:37:58 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sun, 21 Sep 2008 00:37:58 +0000
Subject: [issue3917] set_display definition allows empty '{' '}' in Language
	Definition
In-Reply-To: <1221957478.27.0.336258451859.issue3917@psf.upfronthosting.co.za>
Message-ID: <1221957478.27.0.336258451859.issue3917@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

The definition for set_display in the Language Definition allows for
empty curly braces by enclosing expression_list | comprehension in
brackets ('[', ']').  These brackets should be removed, as empty curly
braces are a dict_display.

http://docs.python.org/dev/3.0/reference/expressions.html#grammar-token-set_display

----------
assignee: georg.brandl
components: Documentation
messages: 73478
nosy: dangyogi, georg.brandl
severity: normal
status: open
title: set_display definition allows empty '{' '}' in Language Definition
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3917>
_______________________________________

From report at bugs.python.org  Sun Sep 21 05:20:20 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Sun, 21 Sep 2008 03:20:20 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1221967220.15.0.977669662191.issue3626@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

3.0rc1 together with the printf patch builds and installs.  Some quick
testing seems ok, but idle isn't working:

$ idle3.0
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.0/idlelib/run.py", line 76, in main
    sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'

IDLE appears briefly with a message:

Subprocess Startup Error
IDLE's subprocess didn't make connection.  Either IDLE can't start a
subprocess or personal firewall software is blocking the connection.
[OK]

Pushing OK causes idle3.0 to quit.  idle 2.5 works fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Sun Sep 21 05:36:55 2008
From: report at bugs.python.org (Frank Martinez)
Date: Sun, 21 Sep 2008 03:36:55 +0000
Subject: [issue3918] random.uniform suprisingly (good kind) does not work as
	documented
In-Reply-To: <1221968215.79.0.562348738395.issue3918@psf.upfronthosting.co.za>
Message-ID: <1221968215.79.0.562348738395.issue3918@psf.upfronthosting.co.za>


New submission from Frank Martinez <python.20.xuinkrbin at spamgourmet.com>:

The documentation for random.uniform states:
    uniform(a, b)
        Return a random real number N such that a <= N < b.
However when I test it out, We see:
    >>> import random as r
    >>> r.uniform(0,-1)
    -0.9815056608839331
    >>> r.uniform(0,-1)
    -0.37308132546878092
    >>> r.uniform(0,-1)
    -0.57090673820243609
    >>> r.uniform(-1,0)
    -0.80471374256455697
    >>> r.uniform(3,2)
    2.9202748927236488
Now, while /I/ actually find this behavior *extremely* useful (I don't 
need to verify I call with the arguments in the `correct' order.), I 
think either the behavior needs to change to match the documentation or 
(preferably), the documentation needs alteration to read, for example, 
additionally:
    If a > b, this function behaves as if it were called as uniform(b,a).
Again, for clarity, I vote for the documentation change.

----------
components: Library (Lib)
messages: 73480
nosy: xuinkrbin
severity: normal
status: open
title: random.uniform suprisingly (good kind) does not work as documented
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3918>
_______________________________________

From report at bugs.python.org  Sun Sep 21 06:14:03 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Sun, 21 Sep 2008 04:14:03 +0000
Subject: [issue3826] Self-reference in BaseHTTPRequestHandler descendants
	causes stuck connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1221970443.61.0.720243890547.issue3826@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

3.0rc1 still fails.
The diagnostic is correct, the connection should be closed after 
sending the response, but isn't.
The attached unittest reproduces the error without requiring a browser.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Sun Sep 21 07:16:59 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 21 Sep 2008 05:16:59 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1221974219.37.0.840462467992.issue3787@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Is this really meant to be for 3.1, or should this be a 3.0 blocker?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Sun Sep 21 08:58:38 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 21 Sep 2008 06:58:38 +0000
Subject: [issue3919] PySys_SetObject crashes after Py_NewInterpreter().
In-Reply-To: <1221980318.04.0.539220090744.issue3919@psf.upfronthosting.co.za>
Message-ID: <1221980318.04.0.539220090744.issue3919@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

Somewhere between Python 3.0a3 and Python 3.0b3, a call to PySys_SetObject() 
after having used Py_NewInterpreter() to create a sub interpreter causes a 
crash. This appears to be due to interp->sysdict being NULL after 
Py_NewInterpreter() called.

As illustration of problem, consider program for Python 2.X.

#include <Python.h>

int
main(int argc, char *argv[])
{
    Py_Initialize();
    PySys_SetObject("xxx", PyLong_FromLongLong(1));
    fprintf(stderr, "sysdict=%d\n", !!PyThreadState_Get()->interp->sysdict);
    fflush(stderr);
    PyRun_SimpleString("import sys\n"
                       "print >> sys.stderr, 'xxx =', sys.xxx\n");

    Py_NewInterpreter();
    fprintf(stderr, "sysdict=%d\n", !!PyThreadState_Get()->interp->sysdict);
    fflush(stderr);
    PySys_SetObject("yyy", PyLong_FromLongLong(2));
    PyRun_SimpleString("import sys\n"
                       "print >> sys.stderr, 'yyy =', sys.yyy\n");

    Py_Finalize();
    return 0;
}

This when run yields:

sysdict=1
xxx = 1
sysdict=1
yyy = 2

Now, for Python 3.0 variant of same program:

#include <Python.h>

int
main(int argc, char *argv[])
{
    Py_Initialize();
    fprintf(stderr, "sysdict=%d\n", !!PyThreadState_Get()->interp->sysdict);
    fflush(stderr);
    PySys_SetObject("xxx", PyLong_FromLongLong(1));
    PyRun_SimpleString("import sys\n"
                       "print('xxx =',sys.xxx, file=sys.stderr)\n");

    Py_NewInterpreter();
    fprintf(stderr, "sysdict=%d\n", !!PyThreadState_Get()->interp->sysdict);
    fflush(stderr);
    PySys_SetObject("yyy", PyLong_FromLongLong(2));
    PyRun_SimpleString("import sys\n"
                       "print('yyy =',sys.yyy, file=sys.stderr)\n");

    Py_Finalize();
    return 0;
}

I get for Python 3.0a3:

sysdict=1
xxx = 1
sysdict=1
object  : AttributeError("'module' object has no attribute 'stderr'",)
type    : AttributeError
refcount: 4
address : 0xf1180
lost sys.stderr

I am not concerned here about loss of sys.stderr, although that could be a 
separate issue for all I know.

The important bit here is that sysdict is set after Py_NewInterpreter().

In Python 3.0b3/3.0rc1 I instead get:

sysdict=1
xxx = 1
sysdict=0
Bus error

This is because PySys_SetObject() is presumably crashing because sysdict is 
not set in interp object.

I tried to ask about this on python-3000 Google group, but that message ended 
up in some moderation queue and has vanished. Thus quote part of that message 
below.

"""
>From what I can tell so far the problem is that 'interp->sysdict' is
NULL after calling Py_NewInterpreter() to create a secondary sub
interpreter.

Reading through code and using a debugger, at this point this seems to
be due to condition if code:

       sysmod = _PyImport_FindExtension("sys", "sys");
       if (bimod != NULL && sysmod != NULL) {
               interp->sysdict = PyModule_GetDict(sysmod);
               if (interp->sysdict == NULL)
                       goto handle_error;
               Py_INCREF(interp->sysdict);
               PySys_SetPath(Py_GetPath());
               PyDict_SetItemString(interp->sysdict, "modules",
                                    interp->modules);
               _PyImportHooks_Init();
               initmain();
               if (!Py_NoSiteFlag)
                       initsite();
       }

in Py_NewInterpreter() not executing due to
_PyImport_FindExtension("sys", "sys") returning NULL.

Down in _PyImport_FindExtension(), it appears that the reason it fails
is because of following returning with NULL.

       def = (PyModuleDef*)PyDict_GetItemString(extensions,
filename);

       .....

               if (def->m_base.m_init == NULL)
                       return NULL;

In other words, whatever m_base.m_init is meant to be is NULL when
perhaps it isn't meant to be.

(gdb) call ((PyModuleDef*)PyDict_GetItemString(extensions,"builtins"))-
>m_base.m_init
$9 = (PyObject *(*)()) 0
(gdb) call ((PyModuleDef*)PyDict_GetItemString(extensions,"sys"))-
>m_base.m_init
$10 = (PyObject *(*)()) 0

I am going to keep tracking through to try and work out why, but
posting this initial information in case this rings a bell with
anyone.
"""

Is this expected behaviour? Or, is it necessary now to perform some special 
initialisation after having called Py_NewInterpreter() to get builtins and 
sys modules setup?

This problem originally came up with mod_wsgi, which worked fine with Python 
3.0a3, but fails on more recent releases because of this.

I know sub interpreters may be seen as evil by some and the target of 
removal, but are they still meant to work for now at least?

----------
components: Interpreter Core
messages: 73483
nosy: grahamd
severity: normal
status: open
title: PySys_SetObject crashes after Py_NewInterpreter().
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3919>
_______________________________________

From report at bugs.python.org  Sun Sep 21 08:59:31 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 21 Sep 2008 06:59:31 +0000
Subject: [issue3919] PySys_SetObject crashes after Py_NewInterpreter().
In-Reply-To: <1221980318.04.0.539220090744.issue3919@psf.upfronthosting.co.za>
Message-ID: <1221980371.57.0.637863973256.issue3919@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Sorry, should also mention that this was on MacOS X 10.4 (Tiger).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3919>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:10:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:10:30 +0000
Subject: [issue3917] set_display definition allows empty '{' '}' in Language
	Definition
In-Reply-To: <1221957478.27.0.336258451859.issue3917@psf.upfronthosting.co.za>
Message-ID: <1221981030.83.0.264053229509.issue3917@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66522. Also removed the last two paragraphs of the set
display explanation which were pasted from genexps and made no sense,
and added a sentence about {} not constructing a set.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3917>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:15:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:15:08 +0000
Subject: [issue3852] kqueue.control requires 2 params while docs say
	max_events (the second) defaults to 0
In-Reply-To: <1221256371.42.0.0336253245305.issue3852@psf.upfronthosting.co.za>
Message-ID: <1221981308.43.0.752218385431.issue3852@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed patch in r66523. At least for now, code and docs are
consistent again.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3852>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:16:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:16:10 +0000
Subject: [issue3912] unittest. assertAlmostEqual() documentation incomplete
In-Reply-To: <1221870165.22.0.917883186399.issue3912@psf.upfronthosting.co.za>
Message-ID: <1221981370.92.0.794848534285.issue3912@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed in r66524.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3912>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:17:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:17:09 +0000
Subject: [issue3916] layout of build directories for Windows not current
In-Reply-To: <1221944254.72.0.255027457089.issue3916@psf.upfronthosting.co.za>
Message-ID: <1221981429.9.0.13411108979.issue3916@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed as r66525.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3916>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:17:36 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:17:36 +0000
Subject: [issue3915] Broken link in 14.7 curses, Python Library Reference
In-Reply-To: <1221937177.94.0.347210678057.issue3915@psf.upfronthosting.co.za>
Message-ID: <1221981456.33.0.971417247477.issue3915@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, this is already fixed in SVN and will be in the 2.6 docs coming
out soon.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3915>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:18:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:18:37 +0000
Subject: [issue3914] augop definition does not include "//="
In-Reply-To: <1221872629.07.0.183880310815.issue3914@psf.upfronthosting.co.za>
Message-ID: <1221981517.17.0.590265617317.issue3914@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66526.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3914>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:22:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:22:44 +0000
Subject: [issue3913] compound_stmt syntax includes 'decorated'
In-Reply-To: <1221872397.1.0.255492187185.issue3913@psf.upfronthosting.co.za>
Message-ID: <1221981764.27.0.875222844798.issue3913@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Bruce is right.

I fixed "decorated", the duplicate "funcdef" and the "?" in r66527 and
r66528.

Bruce, usually adding comments with more issues, especially if they are
so small, is fine; however, since they may be overlooked you're free to
open another bug after a time if no reaction happens.

----------
resolution: invalid -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3913>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:24:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:24:20 +0000
Subject: [issue3901] Slight readme.txt fix (VC9)
In-Reply-To: <1221756041.2.0.713379827172.issue3901@psf.upfronthosting.co.za>
Message-ID: <1221981860.01.0.713026823394.issue3901@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed r66529.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3901>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:29:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:29:45 +0000
Subject: [issue3889] Demo/parser/unparse.py
In-Reply-To: <1221654858.66.0.853855104786.issue3889@psf.upfronthosting.co.za>
Message-ID: <1221982185.93.0.441571650969.issue3889@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This was fixed some time ago on the trunk.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3889>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:32:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:32:16 +0000
Subject: [issue3897] collections
In-Reply-To: <1221725854.26.0.119924443633.issue3897@psf.upfronthosting.co.za>
Message-ID: <1221982336.26.0.220469348251.issue3897@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r66530.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3897>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:32:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 21 Sep 2008 07:32:33 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1221982353.76.0.440231917874.issue3884@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in r66531.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:34:51 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:34:51 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1221982491.48.0.697200946009.issue3905@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Jean-Michel, you'll need to apply the idlelib/run.py patch; replace

    sockthread.set_daemon(True)

with

    sockthread.daemon = True

around line 75.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.0 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:38:34 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:38:34 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1221982714.89.0.557450782036.issue3909@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Which version of Sphinx did you use to build the docs? The Python docs
currently need the unreleased SVN version (that will of course change
for the final release).

If you have a Sphinx release installed as a Python egg, it will cause
problems, even if you used the Makefile to checkout the latest from SVN.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:45:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 21 Sep 2008 07:45:48 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1221983148.11.0.0078661271109.issue3685@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Is there any problem with always computing the end of the string as "s +
wcslen(s)"? I feel that this is actually more readable than wcschr.

Here is a patch that does that. It doesn't change PC/getpathp.c, since
it's only used on Windows, where wcschr works correctly (AFAIK).

Henry, can you confirm that this patch still fixes the problem?

----------
keywords: +needs review
nosy: +loewis
Added file: http://bugs.python.org/file11537/wcslen.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:48:27 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:48:27 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221983307.08.0.394702157899.issue3879@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think the patch is okay; I guess you're processing the result of
getproxies() yourself and relying on "no" being a key?

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:52:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 21 Sep 2008 07:52:37 +0000
Subject: [issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
In-Reply-To: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>
Message-ID: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

msg71969 suggests that OpenBSD 4.4 still fails to build Python if
_XOPEN_SOURCE is defined.

Henry, can you please confirm that
a) the problem still is that select is unavailable if _POSIX_SOURCE is
defined, and
b) the attached patch fixes the problem (when run through autoconf)

The patch is for 2.6, but should be ported to 3.0 also.

----------
files: bsd.diff
keywords: patch
messages: 73500
nosy: henry.precheur, loewis
severity: normal
status: open
title: OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11538/bsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3920>
_______________________________________

From report at bugs.python.org  Sun Sep 21 09:58:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 07:58:16 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1221983896.65.0.911997455193.issue3884@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Docs done in r66534.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Sun Sep 21 10:03:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 08:03:28 +0000
Subject: [issue3918] random.uniform suprisingly (good kind) does not work as
	documented
In-Reply-To: <1221968215.79.0.562348738395.issue3918@psf.upfronthosting.co.za>
Message-ID: <1221984208.74.0.1015809306.issue3918@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Noted in r66535.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3918>
_______________________________________

From report at bugs.python.org  Sun Sep 21 10:08:36 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 21 Sep 2008 08:08:36 +0000
Subject: [issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
In-Reply-To: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>
Message-ID: <1221984516.91.0.759365645221.issue3920@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Looking at the code again, it might be that definition of _POSIX_SOURCE
is not harmful per se anymore, as long as _BSD_SOURCE is also defined.

Can you please also try the alternative bsd2.diff?

Added file: http://bugs.python.org/file11539/bsd2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3920>
_______________________________________

From report at bugs.python.org  Sun Sep 21 10:11:48 2008
From: report at bugs.python.org (Takafumi SHIDO)
Date: Sun, 21 Sep 2008 08:11:48 +0000
Subject: [issue3921] smtplib cannot sendmail over TLS
In-Reply-To: <1221984708.09.0.19052832877.issue3921@psf.upfronthosting.co.za>
Message-ID: <1221984708.09.0.19052832877.issue3921@psf.upfronthosting.co.za>


New submission from Takafumi SHIDO <takafumi at shido.info>:

when a SMTP object tries to send a mail through TLS, the smtp server 
replies retcode 502.

When a test code (sendmail_test.py) is executed on Python 3,
it stacks on sending mail while the test code works on Python 2.5.

Following is the result of the test.

The first half is the result on Python 2.5. 
A mail has been sent without any problem.

The second half is the result on Python 3.
Upto AUTH, it works fine.
But when it sends mail, the server replies retcode 502.
This is the message of failure:

send: 'mail FROM:<lambda.let at gmail.com> size=176\r\n'
reply: b'502 5.5.1 Unrecognized command. u8sm8612791tia.6\r\n'
 

====================== RESULT ============================
Z:\doc\monthly\08-09\py_book3\script\net>python mail2.py
send: 'ehlo [192.168.1.8]\r\n'
reply: '250-mx.google.com at your service, [124.41.68.137]\r\n'
reply: '250-SIZE 35651584\r\n'
reply: '250-8BITMIME\r\n'
reply: '250-STARTTLS\r\n'
reply: '250 ENHANCEDSTATUSCODES\r\n'
reply: retcode (250); Msg: mx.google.com at your service, [124.41.68.137]
SIZE 35651584
8BITMIME
STARTTLS
ENHANCEDSTATUSCODES
send: 'STARTTLS\r\n'
reply: '220 2.0.0 Ready to start TLS\r\n'
reply: retcode (220); Msg: 2.0.0 Ready to start TLS
send: 'ehlo [192.168.1.8]\r\n'
reply: '250-mx.google.com at your service, [124.41.68.137]\r\n'
reply: '250-SIZE 35651584\r\n'
reply: '250-8BITMIME\r\n'
reply: '250-AUTH LOGIN PLAIN\r\n'
reply: '250 ENHANCEDSTATUSCODES\r\n'
reply: retcode (250); Msg: mx.google.com at your service, [124.41.68.137]
SIZE 35651584
8BITMIME
AUTH LOGIN PLAIN
ENHANCEDSTATUSCODES
send: 'AUTH PLAIN AGxhbWJkYS5sZXRAZ21haWwuY29tAGNoaWtha29zMDA=\r\n'
reply: '235 2.7.0 Accepted\r\n'
reply: retcode (235); Msg: 2.7.0 Accepted
send: 'mail FROM:<lambda.let at gmail.com> size=176\r\n'
reply: '250 2.1.0 OK\r\n'
reply: retcode (250); Msg: 2.1.0 OK
send: 'rcpt TO:<takafumi at shido.info>\r\n'
reply: '250 2.1.5 OK\r\n'
reply: retcode (250); Msg: 2.1.5 OK
send: 'data\r\n'
reply: '354 Go ahead\r\n'
reply: retcode (354); Msg: Go ahead
data: (354, 'Go ahead')
send: 'MIME-Version: 1.0\r\nContent-Type: text/plain;
charset="us-ascii"\r\nCon
ent-Transfer-Encoding: 7bit\r\nFrom: lambda.let at gmail.com\r\nTo:
takafumi at shido
info\r\nSubject: test\r\n\r\nThis is a test.\r\n.\r\n'
reply: '250 2.0.0 OK 1221982163 22sm8756554tim.10\r\n'
reply: retcode (250); Msg: 2.0.0 OK 1221982163 22sm8756554tim.10
data: (250, '2.0.0 OK 1221982163 22sm8756554tim.10')
send: 'quit\r\n'
reply: '221 2.0.0 mx.google.com closing connection 22sm8756554tim.10\r\n'
reply: retcode (221); Msg: 2.0.0 mx.google.com closing connection
22sm8756554ti
.10

Z:\doc\monthly\08-09\py_book3\script\net>py3 mail2.py

Z:\doc\monthly\08-09\py_book3\script\net>c:\python30\python.exe mail2.py

send: 'ehlo [192.168.1.8]\r\n'
reply: b'250-mx.google.com at your service, [124.41.68.137]\r\n'
reply: b'250-SIZE 35651584\r\n'
reply: b'250-8BITMIME\r\n'
reply: b'250-STARTTLS\r\n'
reply: b'250 ENHANCEDSTATUSCODES\r\n'
reply: retcode (250); Msg: b'mx.google.com at your service,
[124.41.68.137]\nSI
E 35651584\n8BITMIME\nSTARTTLS\nENHANCEDSTATUSCODES'
send: 'STARTTLS\r\n'
reply: b'220 2.0.0 Ready to start TLS\r\n'
reply: retcode (220); Msg: b'2.0.0 Ready to start TLS'
send: 'ehlo [192.168.1.8]\r\n'
reply: b'250-mx.google.com at your service, [124.41.68.137]\r\n'
reply: b'250-SIZE 35651584\r\n'
reply: b'250-8BITMIME\r\n'
reply: b'250-AUTH LOGIN PLAIN\r\n'
reply: b'250 ENHANCEDSTATUSCODES\r\n'
reply: retcode (250); Msg: b'mx.google.com at your service,
[124.41.68.137]\nSI
E 35651584\n8BITMIME\nAUTH LOGIN PLAIN\nENHANCEDSTATUSCODES'
send: 'AUTH PLAIN AGxhbWJkYS5sZXRAZ21haWwuY29tAGNoaWtha29zMDA=\n\r\n'
reply: b'235 2.7.0 Accepted\r\n'
reply: retcode (235); Msg: b'2.7.0 Accepted'
send: 'mail FROM:<lambda.let at gmail.com> size=176\r\n'
reply: b'502 5.5.1 Unrecognized command. u8sm8612791tia.6\r\n'
reply: retcode (502); Msg: b'5.5.1 Unrecognized command. u8sm8612791tia.6'
send: 'rset\r\n'
reply: b'250 2.1.0 OK\r\n'
reply: retcode (250); Msg: b'2.1.0 OK'
Traceback (most recent call last):
  File "sendmail_test.py", line 43, in <module>

  File "sendmail_test.py", line 35, in send_mail

  File "c:\python30\lib\smtplib.py", line 701, in sendmail
    raise SMTPSenderRefused(code, resp, from_addr)
smtplib.SMTPSenderRefused: (502, b'5.5.1 Unrecognized command.
u8sm8612791tia.6
, 'lambda.let at gmail.com')

Z:\doc\monthly\08-09\py_book3\script\net>

==================== Test Code (sendmail_test.py) =============

#! python

''' send mail using Python 2.5 and 3'''

import smtplib
from email.mime.text import MIMEText
from email.header import Header


def make_mime_text(mail_from, mail_to, subject, body):
    '''create MIMEText'''

    msg = MIMEText(body, 'plain', 'ascii')
    msg['From'] = Header(mail_from, 'ascii')
    msg['To'] = Header(mail_to,  'ascii')
    msg['Subject'] = Header(subject, 'ascii')
    return msg

def send_mail(server, mail_from, mail_to, msg, use_tls=False, user='',
passwd='', ):
    '''sendmail, if use_tls=True, use TLS'''

    sender = smtplib.SMTP(server, (587 if use_tls else 25))
    sender.set_debuglevel(1)
    
    if use_tls:
        sender.ehlo()
        sender.starttls()
        sender.ehlo()
        sender.login(user, passwd)
        
    sender.sendmail(mail_from, mail_to, msg.as_string())
    sender.quit()


if __name__ =='__main__':
    ME = 'lambda.let at gmail.com'
    TK = 'takafumi at shido.info'
    send_mail('smtp.gmail.com', ME, (TK,), \
      make_mime_text(ME, TK, "test", "This is a test."), True, ME,
'********')

----------
components: Library (Lib)
files: sendmail_test.py
messages: 73504
nosy: shidot
severity: normal
status: open
title: smtplib cannot sendmail over TLS
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11540/sendmail_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3921>
_______________________________________

From report at bugs.python.org  Sun Sep 21 10:40:43 2008
From: report at bugs.python.org (vila)
Date: Sun, 21 Sep 2008 08:40:43 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1221986443.35.0.711165003414.issue3879@psf.upfronthosting.co.za>


vila <v.ladeuil+bugs-python at free.fr> added the comment:

Georg Brandl:
> I guess you're processing the result of
> getproxies() yourself and relying on "no" being a key?

Indeed. Thanks for approving this.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Sun Sep 21 11:51:19 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 21 Sep 2008 09:51:19 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1221990679.04.0.467192359816.issue3659@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Damn. I uploaded a patch to this issue a few days ago for review.
Apparently, it didn't work?! I'll recreate it again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Sun Sep 21 12:02:09 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 21 Sep 2008 10:02:09 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1221991329.06.0.0962349830171.issue3659@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Attached patch corrects the issue. Could you please review it?

----------
status: open -> pending
Added file: http://bugs.python.org/file11541/py3_sqlite3_str_subclass.dif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Sun Sep 21 12:02:49 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 21 Sep 2008 10:02:49 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1221991369.54.0.624580567704.issue3659@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
keywords: +easy, needs review, patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Sun Sep 21 12:03:57 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 21 Sep 2008 10:03:57 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1221991437.4.0.0139862878748.issue3659@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Sun Sep 21 12:09:48 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sun, 21 Sep 2008 10:09:48 +0000
Subject: [issue3922] 3.0rc1 missing tk lib in sys.path?
In-Reply-To: <1221991788.31.0.575741048418.issue3922@psf.upfronthosting.co.za>
Message-ID: <1221991788.31.0.575741048418.issue3922@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

3.0rc1: When toying and attempting to import the scrolledtext module, I
noticed the tkinter library path is no more by default included in the
sys.path.

Unfortunate omission or new Python 3.0 design?

C:\Python30>python
Python 3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500 32 bit
(Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> for e in sys.path: print(e)
...

C:\Python30\python30.zip
C:\Python30\DLLs
C:\Python30\lib
C:\Python30\lib\plat-win
C:\Python30
C:\Python30\lib\site-packages
>>>


C:\Python26>python
Python 2.6rc2 (r26rc2:66507, Sep 18 2008, 14:27:33) [MSC v.1500 32 bit
(Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> for e in sys.path: print e
...

C:\Python26\python26.zip
C:\Python26\DLLs
C:\Python26\lib
C:\Python26\lib\plat-win
C:\Python26\lib\lib-tk <<<<<<<<<<<<<<<<<<<<<<<<<
C:\Python26
C:\Python26\lib\site-packages
>>>

----------
components: Library (Lib)
messages: 73508
nosy: jmfauth
severity: normal
status: open
title: 3.0rc1 missing tk lib in sys.path?
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3922>
_______________________________________

From report at bugs.python.org  Sun Sep 21 13:24:07 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 21 Sep 2008 11:24:07 +0000
Subject: [issue3838] test_tarfile error on cygwin (Directory not empty)
In-Reply-To: <1221155992.48.0.592399874075.issue3838@psf.upfronthosting.co.za>
Message-ID: <1221996247.65.0.898620659673.issue3838@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

The patch is okay. Go ahead.

BTW, I've never used Cygwin before, is it always that slow? 10 minutes
for a configure script on a recent machine is a real pain.

----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3838>
_______________________________________

From report at bugs.python.org  Sun Sep 21 13:57:32 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 11:57:32 +0000
Subject: [issue3838] test_tarfile error on cygwin (Directory not empty)
In-Reply-To: <1221155992.48.0.592399874075.issue3838@psf.upfronthosting.co.za>
Message-ID: <1221998252.84.0.378063422828.issue3838@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in trunk(r66539) and py3k(r66540).

>BTW, I've never used Cygwin before, is it always that slow? 10 minutes
for a configure script on a recent machine is a real pain.

Yes, that's really painful. On my box, I can eat dinner and take a bath
while configure & make. :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3838>
_______________________________________

From report at bugs.python.org  Sun Sep 21 13:58:49 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 21 Sep 2008 11:58:49 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1221998329.17.0.0778675707253.issue3262@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Sun Sep 21 13:59:05 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 11:59:05 +0000
Subject: [issue3838] test_tarfile error on cygwin (Directory not empty)
In-Reply-To: <1221155992.48.0.592399874075.issue3838@psf.upfronthosting.co.za>
Message-ID: <1221998345.42.0.787507538136.issue3838@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords:  -needs review
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3838>
_______________________________________

From report at bugs.python.org  Sun Sep 21 14:00:01 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 21 Sep 2008 12:00:01 +0000
Subject: [issue3654] Duplicated test name in regex test script
In-Reply-To: <1219523298.64.0.249650635001.issue3654@psf.upfronthosting.co.za>
Message-ID: <1221998401.34.0.520934478021.issue3654@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3654>
_______________________________________

From report at bugs.python.org  Sun Sep 21 14:00:33 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 21 Sep 2008 12:00:33 +0000
Subject: [issue516762] have a way to search backwards for re
Message-ID: <1221998433.04.0.704339127417.issue516762@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue516762>
_______________________________________

From report at bugs.python.org  Sun Sep 21 14:24:56 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 12:24:56 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1221999896.77.0.579171013295.issue1706863@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>AttributeError: 'NoneType' object has no attribute 'rfind'

Fixing this error is not difficult. I think attached patch is enough.

But still cygwin user who wants to use sqlite3 module won't be happy.
find_library() supports static lib, shared lib, and dylib but ".dll.a"
seems to be windows specific import library. Probably disutils itself
need to be modified. (And probably it's too late for RC phase :-()

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file11542/fix_sqlite3_setup_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Sun Sep 21 18:16:25 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sun, 21 Sep 2008 16:16:25 +0000
Subject: [issue3923] 'genexpr_for' in definition of 'call' in Language
	Reference.
In-Reply-To: <1222013785.56.0.0641485389769.issue3923@psf.upfronthosting.co.za>
Message-ID: <1222013785.56.0.0641485389769.issue3923@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

The definition of 'call' in the Language Reference refers to
'genexpr_for' which doesn't exist.  Either 'genexpr_for' should be
changed to 'comp_for' or 'expression genexpr_for' should be changed to
'comprehension'.  See the following:

http://docs.python.org/dev/3.0/reference/expressions.html#grammar-token-call
http://docs.python.org/dev/3.0/reference/expressions.html#grammar-token-comprehension

I also did not see any description if what happens if you use the
comprehension option (though I was scanning the text quickly and could
have missed it).

----------
assignee: georg.brandl
components: Documentation
messages: 73513
nosy: dangyogi, georg.brandl
severity: normal
status: open
title: 'genexpr_for' in definition of 'call' in Language Reference.
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3923>
_______________________________________

From report at bugs.python.org  Sun Sep 21 18:14:49 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sun, 21 Sep 2008 16:14:49 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222013689.86.0.794681747215.issue2384@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

Python 3.0rc1

If the lines are now displayed correctly, I think there is still a
numbering issue, a +1 offset.

Python 2.5.2

# -*- coding: cp1252 -*-      <<<< line 1, first line

s = 'abc'
import dummy
s = 'def'

---

>pythonw -u "testpy2.py"
Traceback (most recent call last):
  File "testpy2.py", line 4, in <module>
    import dummy
ImportError: No module named dummy
>Exit code: 1


Python 3.0rc1

# -*- coding: cp1252 -*-

s = 'abc'
import dummy
s = 'def'

---

>c:\python30\pythonw -u "testpy3.py"
Traceback (most recent call last):
  File "testpy3.py", line 5, in <module>
    s = 'def'
ImportError: No module named dummy
>Exit code: 1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Sun Sep 21 18:47:55 2008
From: report at bugs.python.org (Todd Whiteman)
Date: Sun, 21 Sep 2008 16:47:55 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1222015675.44.0.00877279525336.issue3905@psf.upfronthosting.co.za>


Todd Whiteman <twhitema at yahoo.com.au> added the comment:

Uh, the Idle bug reported by Jean-Michel is a completely different bug
(please see the first three messages of this report).

Please re-open this bug, as the subprocess issue I have reported is
still outstanding.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sun Sep 21 19:00:31 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 17:00:31 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1222016431.9.0.220075796501.issue3905@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sun Sep 21 19:03:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Sep 2008 17:03:39 +0000
Subject: [issue3923] 'genexpr_for' in definition of 'call' in Language
	Reference.
In-Reply-To: <1222013785.56.0.0641485389769.issue3923@psf.upfronthosting.co.za>
Message-ID: <1222016619.98.0.178534525974.issue3923@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r66541.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3923>
_______________________________________

From report at bugs.python.org  Sun Sep 21 19:24:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 21 Sep 2008 17:24:12 +0000
Subject: [issue3922] 3.0rc1 missing tk lib in sys.path?
In-Reply-To: <1221991788.31.0.575741048418.issue3922@psf.upfronthosting.co.za>
Message-ID: <1222017852.37.0.222985662073.issue3922@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is intentional. tkinter now lives directly in the lib directory
(and is a package).

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3922>
_______________________________________

From report at bugs.python.org  Sun Sep 21 20:12:02 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sun, 21 Sep 2008 18:12:02 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1222020722.47.0.889197131113.issue3905@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

> Georg Brandl

Thanks, patch applied on w2k+sp4 box, swiss french, Python 3.0rc1.
IDLE is working fine.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sun Sep 21 20:30:25 2008
From: report at bugs.python.org (Denis)
Date: Sun, 21 Sep 2008 18:30:25 +0000
Subject: [issue3924] cookielib chokes on non-integer cookie version,
	should ignore it instead
In-Reply-To: <1222021824.75.0.209543556591.issue3924@psf.upfronthosting.co.za>
Message-ID: <1222021824.75.0.209543556591.issue3924@psf.upfronthosting.co.za>


New submission from Denis <f.pybugs at altudov.com>:

PROBLEM:

Some sites (e.g. https://itunesconnect.apple.com) sends cookies where
version is "1" instead of 1. Cookielib chokes on it so none of the
cookies work after that.

PROBLEM CODE:
    def _cookie_from_cookie_tuple(self, tup, request):
...
        name, value, standard, rest = tup
...
        version = standard.get("version", None)
        if version is not None: version = int(version) << CRASH HERE!!!



WORKAROUND:

use my own cookie jar, e.g.:

class MyCookieJar(CookieJar):
    def _cookie_from_cookie_tuple(self, tup, request):
        name, value, standard, rest = tup
        standard["version"]= None
        CookieJar._cookie_from_cookie_tuple(self, tup, request)

REAL FIX:
do not assume that version is int, keep it as string if it does not
parse as int:

CRASH STACK:

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/cookielib.py:1577:
UserWarning: cookielib bug!
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/cookielib.py",
line 1575, in make_cookies
    parse_ns_headers(ns_hdrs), request)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/cookielib.py",
line 1532, in _cookies_from_attrs_set
    cookie = self._cookie_from_cookie_tuple(tup, request)
  File
"/Users/denis/Documents/svn2/tson/main/sales/src/download_sales.py",
line 28, in _cookie_from_cookie_tuple
    CookieJar._cookie_from_cookie_tuple(self, tup, request)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/cookielib.py",
line 1451, in _cookie_from_cookie_tuple
    if version is not None: version = int(version)
ValueError: invalid literal for int() with base 10: '"1"'

  _warn_unhandled_exception()

----------
components: None
messages: 73518
nosy: DenNukem
severity: normal
status: open
title: cookielib chokes on non-integer cookie version, should ignore it instead
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3924>
_______________________________________

From report at bugs.python.org  Sun Sep 21 21:19:14 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Sep 2008 19:19:14 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1222024754.98.0.0882173248927.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The IDLE problem is already corrected: see issue3628.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Sun Sep 21 21:28:27 2008
From: report at bugs.python.org (Yaakov (Cygwin Ports))
Date: Sun, 21 Sep 2008 19:28:27 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1222025307.02.0.867847693375.issue3626@psf.upfronthosting.co.za>


Yaakov (Cygwin Ports) <yselkowitz at users.sourceforge.net> added the comment:

> The IDLE problem is already corrected: see issue3628.

In that case, then I think this can be closed; if I encounter any
further issues after rc2, I'll open a new bug.

Thank you for all your help.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Sun Sep 21 21:30:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Sep 2008 19:30:24 +0000
Subject: [issue3919] PySys_SetObject crashes after Py_NewInterpreter().
In-Reply-To: <1221980318.04.0.539220090744.issue3919@psf.upfronthosting.co.za>
Message-ID: <1222025424.43.0.954225745996.issue3919@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This seems a duplicate of issue3723.

----------
nosy: +amaury.forgeotdarc
superseder:  -> Py_NewInterpreter does not work

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3919>
_______________________________________

From report at bugs.python.org  Sun Sep 21 21:34:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Sep 2008 19:34:01 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1222025641.83.0.364334264138.issue3626@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> I think this can be closed

Well, after the proposed patch "cygwin_badprintf.patch" is reviewed and 
applied...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Sun Sep 21 21:42:19 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 21 Sep 2008 19:42:19 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1222026139.51.0.513316933911.issue3262@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I wonder whether it could be put into Python 3 where certain breaks in
backwards compatibility are to be expected.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Sun Sep 21 21:52:32 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 21 Sep 2008 19:52:32 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222026752.23.0.486594677139.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Fixed the matching of word boundaries when searching and matching in
substrings.

Added file: http://bugs.python.org/file11543/regex_2.6rc2+1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:06:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 20:06:10 +0000
Subject: [issue3919] PySys_SetObject crashes after Py_NewInterpreter().
In-Reply-To: <1221980318.04.0.539220090744.issue3919@psf.upfronthosting.co.za>
Message-ID: <1222027570.68.0.95047543405.issue3919@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3919>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:06:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 20:06:30 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222027590.35.0.178230528775.issue3723@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:13:08 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 20:13:08 +0000
Subject: [issue3925] test_distutils fails on cygwin
In-Reply-To: <1222027988.35.0.687868329699.issue3925@psf.upfronthosting.co.za>
Message-ID: <1222027988.35.0.687868329699.issue3925@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently msvc build ignores shutil.rmtree error, this workaround is
needed for cygwin too.

======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/WhiteRabbit/python-dev/trunk/Lib/distutils/tests/test_build_ext.py
", line 66, in tearDown
    shutil.rmtree(self.tmp_dir, False if os.name != "nt" else True)
  File "/home/WhiteRabbit/python-dev/trunk/Lib/shutil.py", line 221, in
rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "/home/WhiteRabbit/python-dev/trunk/Lib/shutil.py", line 219, in
rmtree
    os.remove(fullname)
OSError: [Errno 13] Permission denied:
'/cygdrive/c/DOCUME~1/WHITER~1/LOCALS~1/T
emp/pythontest_YRSZAn/xx.dll'

----------
components: Tests
files: test_distutils.patch
keywords: easy, needs review, patch
messages: 73525
nosy: ocean-city
severity: normal
status: open
title: test_distutils fails on cygwin
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11544/test_distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3925>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:28:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 20:28:49 +0000
Subject: [issue3925] test_distutils fails on cygwin
In-Reply-To: <1222027988.35.0.687868329699.issue3925@psf.upfronthosting.co.za>
Message-ID: <1222028929.95.0.486107819378.issue3925@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Go ahead.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3925>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:29:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 20:29:23 +0000
Subject: [issue3925] test_distutils fails on cygwin
In-Reply-To: <1222027988.35.0.687868329699.issue3925@psf.upfronthosting.co.za>
Message-ID: <1222028963.03.0.661286589383.issue3925@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3925>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:33:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 20:33:00 +0000
Subject: [issue1688] Incorrectly displayed non ascii characters in prompt
	using "input()" - Python 3.0a2
In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>
Message-ID: <1222029180.88.0.59509929214.issue1688@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm ok with this patch.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:37:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 20:37:55 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1222029475.92.0.573934363673.issue3659@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think the patch looks good.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Sun Sep 21 22:54:04 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 20:54:04 +0000
Subject: [issue3925] test_distutils fails on cygwin
In-Reply-To: <1222027988.35.0.687868329699.issue3925@psf.upfronthosting.co.za>
Message-ID: <1222030444.6.0.979667785233.issue3925@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66542(trunk) and r66543(py3k).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3925>
_______________________________________

From report at bugs.python.org  Sun Sep 21 23:04:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Sep 2008 21:04:00 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222031040.83.0.631420095774.issue3723@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I applied the patch to PC/config.c, but this did not change anything.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Sun Sep 21 23:16:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 21:16:54 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222031814.33.0.786576008285.issue3723@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Interesting, here it lets import.c's init_builtin reinitalize modules...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Sun Sep 21 23:28:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 21:28:19 +0000
Subject: [issue3879] 2.6 regression in urllib.getproxies_environment
In-Reply-To: <1221568637.31.0.774442487005.issue3879@psf.upfronthosting.co.za>
Message-ID: <1222032499.36.0.763151883275.issue3879@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66544.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3879>
_______________________________________

From report at bugs.python.org  Sun Sep 21 23:37:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Sep 2008 21:37:57 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
	non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1222033077.84.0.305118915414.issue3705@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Today I learned something: wchar_t can be 2 or 4 bytes, PyUNICODE can be 
2 or 4 bytes, and all combinations are possible.
My error was to use PyUnicode_FromUnicode on a wchar_t*; PyUnicode_FromWideChar is the obvious function to use.

Attached a new patch (command_unicode_2.patch) for review.

----------
keywords: +needs review
priority: high -> critical
Added file: http://bugs.python.org/file11545/command_unicode_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Sun Sep 21 23:44:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 21:44:35 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222033475.78.0.508672993973.issue3187@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a potential patch for listdir. It emits a UnicodeWarning (or
should that be a BytesWarning?) and skips the file when decoding fails.
What would be the best way to test this?

Added file: http://bugs.python.org/file11546/listdir_bytes_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 22 00:05:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Sep 2008 22:05:40 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222034740.83.0.0991565008983.issue3187@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I did not test the patch, but I have some remarks about it:
- %r does not seem to be handled by PyUnicode_FromFormat; %R maybe?
- In this case, PyObject_Repr(v) is not necessary - and this will avoid 
a reference leak.
- Does the warning warn multiple times? IIRC the default behaviour is to 
warn once.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 22 00:11:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Sep 2008 22:11:32 +0000
Subject: [issue1688] Incorrectly displayed non ascii characters in prompt
	using "input()" - Python 3.0a2
In-Reply-To: <1198357772.97.0.682407228029.issue1688@psf.upfronthosting.co.za>
Message-ID: <1222035092.35.0.922948657841.issue1688@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r66545.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1688>
_______________________________________

From report at bugs.python.org  Mon Sep 22 00:15:45 2008
From: report at bugs.python.org (Henry Precheur)
Date: Sun, 21 Sep 2008 22:15:45 +0000
Subject: [issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
In-Reply-To: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>
Message-ID: <1222035345.59.0.781483411536.issue3920@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

The patch bsd2.diff seems to work. There was a little typo in it (a
missing @). (correction attached)

Added file: http://bugs.python.org/file11547/bsd3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3920>
_______________________________________

From report at bugs.python.org  Mon Sep 22 00:16:12 2008
From: report at bugs.python.org (Henry Precheur)
Date: Sun, 21 Sep 2008 22:16:12 +0000
Subject: [issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
In-Reply-To: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>
Message-ID: <1222035372.74.0.346807144837.issue3920@psf.upfronthosting.co.za>


Changes by Henry Precheur <henry at precheur.org>:


----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3920>
_______________________________________

From report at bugs.python.org  Mon Sep 22 00:27:52 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Sun, 21 Sep 2008 22:27:52 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1222036072.43.0.620122933124.issue3884@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Of course I highly appreciate this decision.

I'd like to point you to an urgent issue concerning turtle.py
which needs a decision and which I've just posted to Python-dev

Regards,
Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Mon Sep 22 01:03:45 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 23:03:45 +0000
Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character
	is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1222038225.84.0.76680771673.issue2382@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file9786/fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2382>
_______________________________________

From report at bugs.python.org  Mon Sep 22 01:04:34 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 23:04:34 +0000
Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character
	is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1222038274.09.0.611702159699.issue2382@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Patch revised.

----------
components: +Interpreter Core -None
Added file: http://bugs.python.org/file11548/py3k_adjust_cursor_at_syntax_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2382>
_______________________________________

From report at bugs.python.org  Mon Sep 22 01:44:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 23:44:28 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222040668.4.0.261350915127.issue3187@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Removed file: http://bugs.python.org/file11546/listdir_bytes_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 22 01:48:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 23:48:15 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222040895.95.0.314785346598.issue3187@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's two more patches. One is like the old one with Amaury's comments
observed. The other simply notes if there were decoding problems and
warns once at the end of the listdir call.

Making a warning happen more than once is tricky because it requires
messing with the warnings filter. This of course takes away some of the
user's control which is one of the main reasons for using the Python
warning system in the first place.

(I almost wish we could write another listdir that returned the names it
could decode and a list of those it couldn't.)

Added file: http://bugs.python.org/file11549/listdir_encoding_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 22 01:48:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 23:48:43 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222040923.04.0.916791900237.issue3187@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Removed file: http://bugs.python.org/file10719/oslistdir_string.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 22 01:48:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Sep 2008 23:48:36 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222040916.47.0.765867929281.issue3187@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file11550/warn_at_the_end.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 22 01:52:16 2008
From: report at bugs.python.org (Scott David Daniels)
Date: Sun, 21 Sep 2008 23:52:16 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>


New submission from Scott David Daniels <Scott.Daniels at Acm.Org>:

Idle doesn't accept the new improved warnings arguments, thus escalating
warnings to failures.  This is, I believe, the core reason that Idle was
failing on windows (warnings about deprecated set_daemon call escalated
to a failure).

Files affected: idlelib/PyShell.py and idlelib/run.py

On chasing this, it looks like the code in warnings.py is masking 
IOErrors a little too broadly, so we should probably also narrow the
exception handling in warnings.py

Patch coming, but not ready just yet.

----------
messages: 73541
nosy: scott_daniels
severity: normal
status: open
title: Idle doesn't obey the new improved warnings arguements
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:04:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 22 Sep 2008 00:04:22 +0000
Subject: [issue3927] dummy multiprocessing needs to use properties
In-Reply-To: <1222041862.6.0.169497195008.issue3927@psf.upfronthosting.co.za>
Message-ID: <1222041862.6.0.169497195008.issue3927@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

multiprocessing.dummy is still using some of the "get_name", "set_name"
variety names. These should change. The attached patch should handle the
problem.

----------
assignee: jnoller
components: Library (Lib)
files: kill_old_names.patch
keywords: patch
messages: 73542
nosy: benjamin.peterson, jnoller
priority: release blocker
severity: normal
status: open
title: dummy multiprocessing needs to use properties
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11551/kill_old_names.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3927>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:11:32 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Sep 2008 00:11:32 +0000
Subject: [issue821862] ftplib: Strict RFC 959 (telnet in command channel)
Message-ID: <1222042292.95.0.918789898382.issue821862@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/issue821862>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:15:55 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 00:15:55 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222042555.47.0.279113936702.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

regex_2.6rc2+2.diff is a bugfix for capture groups in look-behinds.

Added file: http://bugs.python.org/file11552/regex_2.6rc2+2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:23:05 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 00:23:05 +0000
Subject: [issue3678] Ignored LDFLAGS during linking libpython$(VERSION).so
In-Reply-To: <1219696089.59.0.174711225307.issue3678@psf.upfronthosting.co.za>
Message-ID: <1222042985.59.0.381825666859.issue3678@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

already merged in py3k.

committed to release25-maint in r66547.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3678>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:29:41 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 22 Sep 2008 00:29:41 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222043381.59.0.0913675992138.issue3824@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, the patch didn't work... I didn't understand Martin's word. And
nl_langinfo(CODESET) is useless on cygwin because it's always US-ASCII.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:42:20 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 00:42:20 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222044140.92.0.689053781309.issue3825@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


Removed file: http://bugs.python.org/file11552/regex_2.6rc2+2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:43:27 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 00:43:27 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222044207.63.0.797015104652.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Needed to correct regex_2.6rc2+2.diff.

Added file: http://bugs.python.org/file11553/regex_2.6rc2+2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:48:41 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 00:48:41 +0000
Subject: [issue3593] subprocess + stdout redirection + wait + svn= hang
In-Reply-To: <1219095028.86.0.31629994109.issue3593@psf.upfronthosting.co.za>
Message-ID: <1222044521.26.0.230864023994.issue3593@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This is not a subprocess bug.  the os's pipe buffer filled up so the
process never terminated to be noticed by wait.  see:

http://docs.python.org/dev/library/subprocess.html#subprocess.Popen.wait

use communicate() instead of wait().

----------
nosy: +gregory.p.smith
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3593>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:50:03 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 00:50:03 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222044603.88.0.0552703819672.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

regex_2.6rc2+3.diff adds reverse searching with the re.REVERSE/re.R and
"(?r)" flag.

This gives results such as:

>>> re.findall("(\w+)", "one two three")
['one', 'two', 'three']
>>> re.findall("(?r)(\w+)", "one two three")
['three', 'two', 'one']

See #516762.

Added file: http://bugs.python.org/file11554/regex_2.6rc2+3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:51:47 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 00:51:47 +0000
Subject: [issue516762] have a way to search backwards for re
Message-ID: <1222044707.32.0.494590272027.issue516762@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Implemented as part of #3825.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue516762>
_______________________________________

From report at bugs.python.org  Mon Sep 22 02:54:07 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 00:54:07 +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: <1222044847.12.0.386834765259.issue3392@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Mon Sep 22 03:00:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 22 Sep 2008 01:00:03 +0000
Subject: [issue516762] have a way to search backwards for re
Message-ID: <1222045203.36.0.554465751521.issue516762@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
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/issue516762>
_______________________________________

From report at bugs.python.org  Mon Sep 22 03:01:45 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 01:01:45 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1222045305.11.0.948946930644.issue3745@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

agreed.  most platforms should be using the openssl version, i will
update the non-openssl implementations to behave the same.

I don't think this is worth being a release blocker.  I'll do it for 3.0.1.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3745>
_______________________________________

From report at bugs.python.org  Mon Sep 22 03:05:28 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 01:05:28 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1222045528.98.0.826271163755.issue3826@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> critical
title: Self-reference in BaseHTTPRequestHandler descendants causes stuck connections -> BaseHTTPRequestHandler depends on GC to close connections

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Mon Sep 22 03:18:50 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 01:18:50 +0000
Subject: [issue3066] FD leak in urllib2
In-Reply-To: <1213009389.23.0.132424094421.issue3066@psf.upfronthosting.co.za>
Message-ID: <1222046330.56.0.429509745385.issue3066@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3066>
_______________________________________

From report at bugs.python.org  Mon Sep 22 03:21:44 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 01:21:44 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1222046504.09.0.220120374622.issue3631@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Mon Sep 22 03:22:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 01:22:00 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1222046520.34.0.245467947652.issue3709@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Buffering up header IO and sending it all at once is always a good thing
to do.  A patch and unit test would be greatly appreciated.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
priority:  -> normal
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Mon Sep 22 03:23:24 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 22 Sep 2008 01:23:24 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1222046604.83.0.180239903543.issue3566@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Mon Sep 22 04:22:00 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Sep 2008 02:22:00 +0000
Subject: [issue751758] ftplib.retrbinary fails when called from retrlines
	callback
Message-ID: <1222050120.57.0.375526307819.issue751758@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

In FTP every data channel is supposed to be used for a unique transfer
(RFC-1123, chapter 4.1.2.6) and every client should open only one data
connection at time. Actually there isn't any official RFC which
explicitly states my second sentence but the common practices for
servers receiving a PORT or PASV request while another transfer is in
progress usually are:

- processing the request when the transfer is finished
- creating a new data channel closing the old one
- returning a 4xx temporarily failure response code

IMHO it's your use case which, even if not "officially" declared
incorrect, is usually discouraged and hence should not be covered by
base ftplib module.


My2cents

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue751758>
_______________________________________

From report at bugs.python.org  Mon Sep 22 04:28:06 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Sep 2008 02:28:06 +0000
Subject: [issue1248] ftplib needs a rewrite to use bytes/buffers
In-Reply-To: <1191874324.3.0.017965594704.issue1248@psf.upfronthosting.co.za>
Message-ID: <1222050486.06.0.850521910924.issue1248@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Actually the 'r' flag is used against the control connection which is
not supposed to receive any "binary" data and in FTP.retrlines method
which is supposed to retrieve data in line mode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1248>
_______________________________________

From report at bugs.python.org  Mon Sep 22 05:07:46 2008
From: report at bugs.python.org (Hank Christian)
Date: Mon, 22 Sep 2008 03:07:46 +0000
Subject: [issue3841] IDLE: quirky behavior when displaying strings longer than
	4093 characters
In-Reply-To: <1221158494.97.0.26052991619.issue3841@psf.upfronthosting.co.za>
Message-ID: <1222052866.83.0.509355334464.issue3841@psf.upfronthosting.co.za>


Hank Christian <hank.christian at gmail.com> added the comment:

I am using Vista Ultimate, with Python 2.5. 
I did not have any problems running this code. The result was 4094.

----------
nosy: +hankchristian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3841>
_______________________________________

From report at bugs.python.org  Mon Sep 22 07:04:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 05:04:12 +0000
Subject: [issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
In-Reply-To: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>
Message-ID: <1222059852.79.0.18335877946.issue3920@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Hye-Shik, can you please review this patch?

----------
assignee:  -> hyeshik.chang
keywords: +needs review
nosy: +hyeshik.chang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3920>
_______________________________________

From report at bugs.python.org  Mon Sep 22 07:16:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 05:16:02 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222060562.7.0.337266388959.issue3824@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I didn't mean to suggest that a new codec is created; instead, mbstowcs
should be called directly in grpmodule.c.

By default, mbstowcs will use ASCII, so it is likely to fail - you would
need to call setlocale first.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Mon Sep 22 08:05:44 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Mon, 22 Sep 2008 06:05:44 +0000
Subject: [issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in
	switch
In-Reply-To: <1219594315.65.0.145921400813.issue3659@psf.upfronthosting.co.za>
Message-ID: <1222063544.22.0.438266313006.issue3659@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Thanks a lot, Benjamin!

Committed revision 66550.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3659>
_______________________________________

From report at bugs.python.org  Mon Sep 22 08:49:22 2008
From: report at bugs.python.org (Dominique Wahli)
Date: Mon, 22 Sep 2008 06:49:22 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222066162.65.0.367919320822.issue3872@psf.upfronthosting.co.za>


Dominique Wahli <dwahli at gmail.com> added the comment:

I hope this bug will have some attention before final 2.6

Work on Python 2.5.2 and not on 2.6rc1 and 2.6rc2

----------
title: Tix ComboBox error -> Python 2.6rc2: Tix ComboBox error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Mon Sep 22 09:28:39 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Mon, 22 Sep 2008 07:28:39 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1222068519.64.0.0930759983297.issue3909@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

Hi Georg,
whatever I am getting when I am doing a make latex in the Docs 
directory. The current version is 66550: "Sphinx v0.5, building latex".

I just redid it again and the error persists. But you say that one has 
to use unreleased SVN versions. So I have to wait another few days for 
a PDF version of the new documents.

Thanks a lot for your time,
Winfried - viele Gr??e nach M?nchen und viel Gl?ck in der Pyhsik :)

----------
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Mon Sep 22 10:18:35 2008
From: report at bugs.python.org (T.Morin)
Date: Mon, 22 Sep 2008 08:18:35 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>
Message-ID: <1222071515.22.0.572818963805.issue2574@psf.upfronthosting.co.za>


T.Morin <thomas-python at treizh.net> added the comment:

>
> Exercising the API fully requires an SSM capable multicast LAN.

... and it also requires a host IP stack implementing the API, which is
not yet (AFAIK) the case for Mac OS X, even very recent releases.

I think you will need a Windows or Linux box to successfully run a tests
that uses RFC3768 functions/consts.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2574>
_______________________________________

From report at bugs.python.org  Mon Sep 22 10:37:34 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Sep 2008 08:37:34 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222072654.11.0.512437654865.issue3872@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Tix is still at version 8.4 (tix84.dll) when tcl has been upgraded to
8.5 (tcl85.dll and tk85.dll)

The Tix project does not seem to be maintained any more.
I managed to recompile it against tcl85, but nothing changed.

Should we remove it from python, or try to update it?

----------
nosy: +amaury.forgeotdarc, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Mon Sep 22 11:38:54 2008
From: report at bugs.python.org (Erik Sandberg)
Date: Mon, 22 Sep 2008 09:38:54 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>


New submission from Erik Sandberg <sandberg at virtutech.com>:

When building Python on Solaris, I don't get the os.mknod function. This
seems to be a combination of two errors:
1. The definition of posix_mknod() in posixmodule.c is surrounded by:
#if defined(HAVE_MKNOD) && defined(HAVE_MAKEDEV)
It works fine if I remove the HAVE_MAKEDEV define.

2. The reason why HAVE_MAKEDEV doesn't work, is that the Python
configure script only looks for makedev in <sys/types.h>, while on
Solaris you need to include <sys/mkdev.h> as well.

cc -V gives:
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
uname -a gives:
SunOS zelda 5.9 Generic_117171-07 sun4us sparc FJSV,GPUZC-M

----------
components: Extension Modules
messages: 73562
nosy: sandberg
severity: normal
status: open
title: os.mknod missing on Solaris
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Sep 22 12:07:59 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 22 Sep 2008 10:07:59 +0000
Subject: [issue3929] Incorrect exception raising in dbm.open on non-existing DB
In-Reply-To: <1222078079.42.0.696848044955.issue3929@psf.upfronthosting.co.za>
Message-ID: <1222078079.42.0.696848044955.issue3929@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

Opening a dbm database which doesn't exist without a "c" or "n" flag
results in this exception:

>>> import dbm
>>> dbm.open("abc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/MP.shadow/hagenf/local/src/py3k/Lib/dbm/__init__.py", line
79, in open
    raise error("need 'c' or 'n' flag to open new db")
TypeError: 'tuple' object is not callable

"error" is a tuple of dbm's own exception class and IOError, but this
doesn't seem to make sense in the present code and Python 3.0. The
attached patch fixes the problem and adds a test for the correct
exception being raised.

----------
components: Library (Lib)
files: dbm.patch
keywords: patch
messages: 73563
nosy: hagen
severity: normal
status: open
title: Incorrect exception raising in dbm.open on non-existing DB
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11555/dbm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3929>
_______________________________________

From report at bugs.python.org  Mon Sep 22 13:19:15 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 22 Sep 2008 11:19:15 +0000
Subject: [issue3930] urllib.request.urlopen() different on Windows than Linux
In-Reply-To: <1222082355.39.0.877616271155.issue3930@psf.upfronthosting.co.za>
Message-ID: <1222082355.39.0.877616271155.issue3930@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

Py30rc1

On Windows the file object returned by urllib.request.urlopen() appears
to be in binary mode, so .read() returns a bytes object. But on Linux it
appears to be in text mode, so .read() returns a str object. It seeems
to me that the same type of file object should be returned on all
platforms, otherwise you have to test the platform and use str.encode()
or bytes.decode() depending on where the code is running.

----------
components: Library (Lib)
messages: 73565
nosy: mark
severity: normal
status: open
title: urllib.request.urlopen() different on Windows than Linux
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3930>
_______________________________________

From report at bugs.python.org  Mon Sep 22 13:14:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Sep 2008 11:14:24 +0000
Subject: [issue3929] Incorrect exception raising in dbm.open on non-existing DB
In-Reply-To: <1222078079.42.0.696848044955.issue3929@psf.upfronthosting.co.za>
Message-ID: <1222082064.27.0.737371325105.issue3929@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

dbm.error is documented as a tuple, and I'd prefer not to change this:
  http://docs.python.org/dev/3.0/library/dbm.html#dbm.error
Since it says that its first member is another dbm.error exception,
we could simply raise error[0](message)

Attached another patch, with the same test case.

----------
keywords: +needs review
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file11556/dbm-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3929>
_______________________________________

From report at bugs.python.org  Mon Sep 22 13:37:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Sep 2008 11:37:10 +0000
Subject: [issue3930] urllib.request.urlopen() different on Windows than Linux
In-Reply-To: <1222082355.39.0.877616271155.issue3930@psf.upfronthosting.co.za>
Message-ID: <1222083430.25.0.174006346659.issue3930@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I only get bytes on Linux. Do you have a test script?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3930>
_______________________________________

From report at bugs.python.org  Mon Sep 22 13:55:30 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Mon, 22 Sep 2008 11:55:30 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1222084530.63.0.347436061995.issue3262@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

I think Mike Coleman proposal of enabling this behaviour via flag is
probably best and IMHO we should consider it under these circumstances.
 Intuitively, I think you're interpretation of what re.split should do
under zero-width conditions is logical, and I almost think this should
be a 2-minor number transition ? la from __future__ import
zeroWidthRegexpSplit if we are to consider it as the long-term 'right
thing to do'.  3000 (3.0) seems a good place to also consider it for
true overhaul / reexamination, especially as we are writing 'upgrade'
scripts for many of the other Python features.  However, I would say
this, Guido has spoken and it may be too late for the pebbles to vote.

I would like to add this patch as a new item to the general Regexp
Enhancements thread of issue 2636 though, as I think it is an idea worth
considering when overhauling Regexp.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Mon Sep 22 14:00:56 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 22 Sep 2008 12:00:56 +0000
Subject: [issue3930] urllib.request.urlopen() different on Windows than Linux
In-Reply-To: <1222082355.39.0.877616271155.issue3930@psf.upfronthosting.co.za>
Message-ID: <1222084856.93.0.173428970598.issue3930@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

Sorry, I now can't reproduce it. I made a tiny test script and it worked
fine on both Windows and Linux. Now when I run the real test that works
fine too. So could you close/remove this "bug" for me please?

#!/usr/bin/env python3
import sys
import urllib.request
print(sys.version)
fh = urllib.request.urlopen("http://www.python.org/index.html")
data = fh.read()
fh.close()
print(type(data))

# output when run on Linux:
3.0rc1 (r30rc1:66499, Sep 18 2008, 17:45:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
<class 'bytes'>

# output when run on Windows:
3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500 32 bit (Intel)]
<class 'bytes'>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3930>
_______________________________________

From report at bugs.python.org  Mon Sep 22 14:06:30 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Mon, 22 Sep 2008 12:06:30 +0000
Subject: [issue3931] codecs.charmap_build is untested and undocumented
In-Reply-To: <1222085190.52.0.690275455212.issue3931@psf.upfronthosting.co.za>
Message-ID: <1222085190.52.0.690275455212.issue3931@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

Although it doesn't start with _ and is definitely necessary as codecs
call it.

----------
components: Library (Lib)
messages: 73569
nosy: fijal
severity: normal
status: open
title: codecs.charmap_build is untested and undocumented
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3931>
_______________________________________

From report at bugs.python.org  Mon Sep 22 14:18:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Sep 2008 12:18:55 +0000
Subject: [issue3930] urllib.request.urlopen() different on Windows than Linux
In-Reply-To: <1222082355.39.0.877616271155.issue3930@psf.upfronthosting.co.za>
Message-ID: <1222085935.69.0.247064205322.issue3930@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3930>
_______________________________________

From report at bugs.python.org  Mon Sep 22 14:24:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 22 Sep 2008 12:24:46 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222086286.56.0.576411224077.issue3824@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file11455/experimental_mbcstowcs_codec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Mon Sep 22 14:33:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Sep 2008 12:33:03 +0000
Subject: [issue3929] Incorrect exception raising in dbm.open on non-existing DB
In-Reply-To: <1222078079.42.0.696848044955.issue3929@psf.upfronthosting.co.za>
Message-ID: <1222086783.81.0.136064566171.issue3929@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Amaury's patch looks good.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3929>
_______________________________________

From report at bugs.python.org  Mon Sep 22 14:33:10 2008
From: report at bugs.python.org (yanne)
Date: Mon, 22 Sep 2008 12:33:10 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>


New submission from yanne <jth at ri.fi>:

It seems that HTMLParser.feed throws an exception whenever an attribute
name contains both quotation mark '&' and non-ascii characters.

Running the attached test file with Python 2.5 succeeds, but with Python
2.6, the result is:

C:\Python26>python.exe test.py
Without & in attribute
OK
With & in attribute
Traceback (most recent call last):
  File "test.py", line 18, in <module>
    HP().feed(s)
  File "C:\Python26\lib\HTMLParser.py", line 108, in feed
    self.goahead(0)
  File "C:\Python26\lib\HTMLParser.py", line 148, in goahead
    k = self.parse_starttag(i)
  File "C:\Python26\lib\HTMLParser.py", line 249, in parse_starttag
    attrvalue = self.unescape(attrvalue)
  File "C:\Python26\lib\HTMLParser.py", line 386, in unescape
    return re.sub(r"&(#?[xX]?(?:[0-9a-fA-F]+|\w{1,8}));",
replaceEntities, s)
  File "C:\Python26\lib\re.py", line 150, in sub
    return _compile(pattern, 0).sub(repl, string, count)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0:
ordinal
not in range(128)

I am running:

Python 2.6rc2 (r26rc2:66507, Sep 18 2008, 14:27:33) [MSC v.1500 32 bit
(Intel)] on win32

----------
components: Library (Lib)
files: test.py
messages: 73571
nosy: yanne
severity: normal
status: open
title: HTMLParser cannot handle '&' and non-ascii characters in attribute names
versions: Python 2.6
Added file: http://bugs.python.org/file11557/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Mon Sep 22 14:43:58 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 22 Sep 2008 12:43:58 +0000
Subject: [issue3933] presence of .pythonstartup.py causes __main__.__file__ to
	be set incorrectly
In-Reply-To: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>
Message-ID: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

exarkun at charm:~$ ls  .pythonstartup.py
.pythonstartup.py
exarkun at charm:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> __file__
'/home/exarkun/.pythonstartup.py'
>>> 
exarkun at charm:~$ mv .pythonstartup.py .not-pythonstartup.py
exarkun at charm:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> __file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '__file__' is not defined
>>>

----------
components: Library (Lib)
messages: 73572
nosy: exarkun
severity: normal
status: open
title: presence of .pythonstartup.py causes __main__.__file__ to be set incorrectly
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3933>
_______________________________________

From report at bugs.python.org  Mon Sep 22 15:04:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Sep 2008 13:04:32 +0000
Subject: [issue3933] presence of .pythonstartup.py causes __main__.__file__ to
	be set incorrectly
In-Reply-To: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>
Message-ID: <1222088672.27.0.194220855381.issue3933@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Someone took the time machine and corrected this 18 months ago: r54189
is included in the 2.6 version.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3933>
_______________________________________

From report at bugs.python.org  Mon Sep 22 15:12:05 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 22 Sep 2008 13:12:05 +0000
Subject: [issue3933] presence of .pythonstartup.py causes __main__.__file__ to
	be set incorrectly
In-Reply-To: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>
Message-ID: <1222089125.44.0.968448292884.issue3933@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Why wasn't it backported to 2.5?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3933>
_______________________________________

From report at bugs.python.org  Mon Sep 22 15:13:36 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 22 Sep 2008 13:13:36 +0000
Subject: [issue3927] dummy multiprocessing needs to use properties
In-Reply-To: <1222041862.6.0.169497195008.issue3927@psf.upfronthosting.co.za>
Message-ID: <1222089216.29.0.194719351414.issue3927@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

The patch looks fine to me Ben, if you want to apply it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3927>
_______________________________________

From report at bugs.python.org  Mon Sep 22 15:41:56 2008
From: report at bugs.python.org (Kirill Simonov)
Date: Mon, 22 Sep 2008 13:41:56 +0000
Subject: [issue3884] turtle in the tkinter package?
In-Reply-To: <1221599171.66.0.226018210692.issue3884@psf.upfronthosting.co.za>
Message-ID: <1222090916.1.0.552232757059.issue3884@psf.upfronthosting.co.za>


Kirill Simonov <xi at gamma.dn.ua> added the comment:

Thank you for the fix, I really appeciate it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3884>
_______________________________________

From report at bugs.python.org  Mon Sep 22 15:48:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Sep 2008 13:48:20 +0000
Subject: [issue3933] presence of .pythonstartup.py causes __main__.__file__ to
	be set incorrectly
In-Reply-To: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>
Message-ID: <1222091300.83.0.000318654872777.issue3933@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I was not there, but the usual rules state that a backport is not
allowed to break working code, even if it relies on undocumented
features or side-effects.

Here, PyRun_SimpleFileExFlags changed its behaviour: it now deletes
__main__.__file__ and some applications may have used this attribute in
some way.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3933>
_______________________________________

From report at bugs.python.org  Mon Sep 22 15:57:17 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 22 Sep 2008 13:57:17 +0000
Subject: [issue3933] presence of .pythonstartup.py causes __main__.__file__ to
	be set incorrectly
In-Reply-To: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>
Message-ID: <1222091837.07.0.663751311398.issue3933@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Any buggy behavior might be relied on by applications.  Taken to the
extreme, you can never have a bug-fix release of Python.

__file__ from PYTHONSTARTUP breaks the warnings module.  It would be
difficult for an application to rely on __main__.__file__ being set,
since $PYTHONSTARTUP is only read in interactive mode - when it's a
human using Python, not a program.  Of course another process could run
Python interactively in a child process and then rely on __file__, sure.
 But why is that valid?  It's not like __file__ *means* something there
- it's just the value of PYTHONSTARTUP.

But I guess I don't really care anymore.  I understand why warnings are
being reported incorrectly now, so I doubt this affects /me/ anymore. 
It seems like it'd be better to reduce confusion for other people too,
but that's not up to me.

Thanks for pointing out where it was fixed in 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3933>
_______________________________________

From report at bugs.python.org  Mon Sep 22 16:07:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Sep 2008 14:07:33 +0000
Subject: [issue3933] presence of .pythonstartup.py causes __main__.__file__ to
	be set incorrectly
In-Reply-To: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>
Message-ID: <1222092453.97.0.602984667416.issue3933@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I was thinking about an application that embeds an interpreter, and
calls PyRun_SimpleFile(). There are many ways to use python...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3933>
_______________________________________

From report at bugs.python.org  Mon Sep 22 16:49:13 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 22 Sep 2008 14:49:13 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222094953.62.0.586992543706.issue3824@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'm not cygwin user, but cygwin seems not to support multibyte function.
Following program outputs 5 on VC6 as expected, but 10 on cygwin. 
Hmm...

#include <stdio.h>
#include <stdlib.h>
#include <locale.h>

int main(int argc, char* argv[])
{
	const char s[] = "?????";
	size_t len;
	wchar_t *buf;

	setlocale(LC_ALL, "");

	len = strlen(s); /* 10 */

	buf = (wchar_t*)malloc((len+1)*sizeof(wchar_t));

	len = mbstowcs(buf, s, len+1);

	printf("--------> %d\n", len); /* should be 5 */

	return 0;
}

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Mon Sep 22 16:51:22 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 22 Sep 2008 14:51:22 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1222095082.43.0.892217303391.issue3926@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The first part was already mentioned in issue3391, but not closing this
in favor of the second part of your message.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Mon Sep 22 16:52:45 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 22 Sep 2008 14:52:45 +0000
Subject: [issue3868] patch for review: OS/2 EMX port fixes for 2.6
In-Reply-To: <1221395971.68.0.568143419044.issue3868@psf.upfronthosting.co.za>
Message-ID: <1222095165.93.0.649091209567.issue3868@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

Committed in revs 66552, 66553 and 66554.

I've blocked r66554 from py3k as other changes are needed for OS/2 (r66555)
I've merged r66552 and r66553 into py3k as they apply cleanly (r66556).

Thanks for the review Amaury.

----------
assignee:  -> aimacintyre
priority:  -> normal
resolution:  -> accepted
status: open -> pending
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3868>
_______________________________________

From report at bugs.python.org  Mon Sep 22 18:03:14 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 16:03:14 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222099394.22.0.32952005158.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

regex_2.6rc2+4.diff fixes the ordering of the capture groups for reverse
searching.

Added file: http://bugs.python.org/file11558/regex_2.6rc2+4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 22 18:03:30 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 16:03:30 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222099410.06.0.632369815387.issue3825@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


Removed file: http://bugs.python.org/file11558/regex_2.6rc2+4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 22 18:04:46 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 16:04:46 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222099486.54.0.156713713475.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Correction of regex_2.6rc2+4.diff. (Aargh!)

Added file: http://bugs.python.org/file11559/regex_2.6rc2+4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Mon Sep 22 18:34:05 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Sep 2008 16:34:05 +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: <1222101245.36.0.183544146865.issue3392@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand the problem. If you open a lot of files, the open() 
loop will stop an exception (IOError: too many open files), and so 
subprocess is not used.

If I open <limit>-1 files, subprocess._get_handles() will fail on 
os.pipe().

If I open <limit>-4 files, the script doesn't fail.

I'm using Linux. Here is my script:
---
# open <limit>-4 files
import subprocess
files = []
while 1:
    try:
        newfile = open("/etc/passwd")
    except IOError, err:
        print "ERR: %s" % err
        break
    files.append(newfile)

# use -3 to get an error
for file in files[-4:]:
    print "close"
    file.close()

# success
subprocess.Popen(["date"], stdout=subprocess.PIPE).communicate()
---

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Mon Sep 22 18:44:24 2008
From: report at bugs.python.org (=?utf-8?q?Mattias_Engdeg=C3=A5rd?=)
Date: Mon, 22 Sep 2008 16:44:24 +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: <1222101864.42.0.971309040992.issue3392@psf.upfronthosting.co.za>


Mattias Engdeg?rd <yorick at users.sourceforge.net> added the comment:

As the comment in the original bug report said, you need to raise the
file descriptor limit to something well above 2000 before running the
test case.

Needless to say, you may need to do that part as root in case that would
exceed your hard RLIMIT_NOFILE limit.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Mon Sep 22 19:08:53 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Sep 2008 17:08:53 +0000
Subject: [issue3001] RLock's are SLOW
In-Reply-To: <1212074891.45.0.23606216758.issue3001@psf.upfronthosting.co.za>
Message-ID: <1222103333.4.0.904712770088.issue3001@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11172/rlock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3001>
_______________________________________

From report at bugs.python.org  Mon Sep 22 20:18:15 2008
From: report at bugs.python.org (robwolfe)
Date: Mon, 22 Sep 2008 18:18:15 +0000
Subject: [issue3934] sphinx - building muppy docs fails on Linux
In-Reply-To: <1222107495.4.0.954300379659.issue3934@psf.upfronthosting.co.za>
Message-ID: <1222107495.4.0.954300379659.issue3934@psf.upfronthosting.co.za>


New submission from robwolfe <rw at smsnet.pl>:

I've tried to build muppy (http://packages.python.org/muppy/)
documentation on:
$ python2.5 -c "import sys; print sys.version"
2.5 (release25-maint, Dec  9 2006, 14:35:53)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)]

with Sphinx (version 0.4.2) and got this error:

$ make doctest mkdir -p build/doctest
sphinx-build -b doctest -d build/doctrees   source build/doctest
Sphinx v0.4.2, building doctest
trying to load pickled env... not found
building [doctest]: targets for 15 source files that are out of date
updating environment: 15 added, 0 changed, 0 removed
reading... changes copyright detailed_toc glossary index intro
library/library library/muppy library/refbrowser Exception occurred:
  File
"/usr/lib/python2.5/site-packages/Sphinx-0.4.2-py2.5.egg/sphinx/ext/autodoc.py",
line 313, in generate_rst
    if not mod_cls:
UnboundLocalError: local variable 'mod_cls' referenced before assignment
The full traceback has been saved in /tmp/sphinx-err-XRu3ZJ.log, if you
want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sphinx-dev at googlegroups.com. Thanks!
make: *** [doctest] B??d 1

The simple patch I've attached helped of course.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: autodoc.patch
keywords: patch
messages: 73587
nosy: georg.brandl, robwolfe
severity: normal
status: open
title: sphinx - building muppy docs fails on Linux
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file11560/autodoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3934>
_______________________________________

From report at bugs.python.org  Mon Sep 22 20:50:57 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Sep 2008 18:50:57 +0000
Subject: [issue433031] SRE: x++ isn't supported
Message-ID: <1222109457.11.0.854885828315.issue433031@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Implemented in #2636 and #3825.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433031>
_______________________________________

From report at bugs.python.org  Mon Sep 22 20:54:44 2008
From: report at bugs.python.org (jason kirtland)
Date: Mon, 22 Sep 2008 18:54:44 +0000
Subject: [issue3935] bisect insort C implementation ignores methods on list
	subclasses
In-Reply-To: <1222109684.93.0.997656752515.issue3935@psf.upfronthosting.co.za>
Message-ID: <1222109684.93.0.997656752515.issue3935@psf.upfronthosting.co.za>


New submission from jason kirtland <jek at discorporate.us>:

The C implementation (only) of bisect does not invoke list subclass
methods when insorting.  Code like this will not trigger the assert:

  class Boom(list):
     def insert(self, index, item):
         assert False

  bisect.insort(Boom(), 123)

object-derived classes are OK.

----------
components: Library (Lib)
files: test.py
messages: 73589
nosy: jek
severity: normal
status: open
title: bisect insort C implementation ignores methods on list subclasses
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file11561/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3935>
_______________________________________

From report at bugs.python.org  Mon Sep 22 21:43:06 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 22 Sep 2008 19:43:06 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1222112586.4.0.0178444650475.issue3666@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Removed file: http://bugs.python.org/file11517/atexit.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Mon Sep 22 21:45:20 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 22 Sep 2008 19:45:20 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1222112720.78.0.373604883985.issue3666@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I've taken this ticket.  Can someone please review and give
it a thumbs up or thumbs down?

----------
assignee:  -> skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Mon Sep 22 22:11:29 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Sep 2008 20:11:29 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1222114289.21.0.232871059301.issue3666@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

*thumbs up*

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Mon Sep 22 22:40:01 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Sep 2008 20:40:01 +0000
Subject: [issue3262] re.split doesn't split with zero-width regex
In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za>
Message-ID: <1222116001.01.0.965300369244.issue3262@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The problem with doing this per 3.0 is that it's impossible to write a
conversion script.

I'm okay with adding a flag to enable this behavior though.  Please open
a new bug with a new patch, preferably one that applies cleanly to the
trunk, and a separate patch for the py3k branch unless the trunk patch
merges cleanly.  There should also be unittests and documentation.  The
patches should be marked for Python 2.7 and 3.1 -- it's way too late to
get this into 2.6 and 3.0.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3262>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:02:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 21:02:43 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222117363.69.0.435426848444.issue3872@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Dominique, unless you contribute a fix yourself, no fix might get
included in 2.6.

I still would leave Tix "in" 2.6, unless it can be shown that all Tix
widgets are broken.

I don't think it's a problem that the Tix version is 8.4 - there is no
inherent need for Tix to have the same version number as Tcl or Tk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:03:04 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Sep 2008 21:03:04 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1222117384.46.0.109168162544.issue3885@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Patch comments:
- the test suite section of the diff appears to have a number of changes
that are unrelated to this issue
- the purpose of the new do_not_close flag (i.e. avoiding the crash)
could use a comment at the point where it is referenced in the code
- aren't all those dummy=DB_close_internal(*) + Py_XDECREF calls also in
need of the PyErr_Clear() treatment?
- globally clearing *any* error unconditionally is typically a bad idea.
If there are certain 'expected' errors (such as the No Server error
Victor was triggering or other BSDDB errors) then those can be cleared
silently, but for other errors something should at least be written to
stderr to indicate that an error was ignored because it couldn't be
propagated back to the eval loop (and possibly even for the BSDDB errors).

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:04:21 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 21:04:21 +0000
Subject: [issue3928] os.mknod missing on Solaris
In-Reply-To: <1222076334.46.0.231050042066.issue3928@psf.upfronthosting.co.za>
Message-ID: <1222117461.07.0.326329590642.issue3928@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It would be best if you could contribute a patch to fix this. The source
of configure is configure.in; you need autoconf to generate configure
from it.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3928>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:14:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 22 Sep 2008 21:14:10 +0000
Subject: [issue3927] dummy multiprocessing needs to use properties
In-Reply-To: <1222041862.6.0.169497195008.issue3927@psf.upfronthosting.co.za>
Message-ID: <1222118050.43.0.448851262057.issue3927@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66557.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3927>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:14:11 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 21:14:11 +0000
Subject: [issue3933] presence of .pythonstartup.py causes __main__.__file__ to
	be set incorrectly
In-Reply-To: <1222087438.11.0.964536433748.issue3933@psf.upfronthosting.co.za>
Message-ID: <1222118051.23.0.740069971701.issue3933@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Jean-Paul, to find out why the specific patch was not backported, you
would have to ask the original committer (which happens to be Georg
Brandl). If you want to ask that question through the tracker, it's best
to add him to the nosy list, so that he can actually see that he is
being asked a question.

My guess is as good as everybody else's: most likely, he didn't have the
time to backport, or didn't consider it important enough.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3933>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:18:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 21:18:15 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222118295.92.0.322640436043.issue3824@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In this case, I think there is nothing we can do. Perhaps it is useful
to put a comment into the test, pointing out that this is likely to
break on Cygwin, and refer to this issue.

I don't see that as a problem: it's just a test that fails, and only on
some systems (i.e. when you have non-ASCII characters in the group
file). People running into the problem should first resolve the
underlying problem in Cygwin, and, when Cygwin actually works correctly,
come back to fixing this issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:19:24 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 21:19:24 +0000
Subject: [issue3934] sphinx - building muppy docs fails on Linux
In-Reply-To: <1222107495.4.0.954300379659.issue3934@psf.upfronthosting.co.za>
Message-ID: <1222118364.65.0.86069421925.issue3934@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +schuppenies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3934>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:31:50 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Sep 2008 21:31:50 +0000
Subject: [issue433031] SRE: x++ isn't supported
Message-ID: <1222119110.51.0.950873155813.issue433031@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing this one then.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> Regexp 2.7 (modifications to current re 2.2.2)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433031>
_______________________________________

From report at bugs.python.org  Mon Sep 22 23:52:22 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Sep 2008 21:52:22 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Copied from c.l.p post by F. Lundh
I have no idea if this has implications for warnings in 2.6
------------------------

>  >>> from sympy.mpmath import specfun
>  >>>
>
> So what could be suppressing the warning?
[about 'as' becoming a keyword, when assigned to]

a bug in Python 2.5, it seems:

> more f1.py
as = 1
as = 2
as = 3
> python f1.py
f1.py:1: Warning: 'as' will become a reserved keyword in Python 2.6
f1.py:2: Warning: 'as' will become a reserved keyword in Python 2.6
f1.py:3: Warning: 'as' will become a reserved keyword in Python 2.6

> more f2.py
as = 1
import os
as = 3
> python f2.py
f2.py:1: Warning: 'as' will become a reserved keyword in Python 2.6

A quick look in parsetok.c reveals that it sets a "handling_import" flag
when it stumbles upon an "import" statement, a flag that's later used to
suppress the warning message.  The bug is that the flag isn't reset
until the parser sees an ENDMARKER token (end of file), instead of when
it sees the next NEWLINE token.

(if someone wants to submit this to bugs.python.org, be my guest)

----------
components: Interpreter Core
messages: 73600
nosy: tjreedy
severity: normal
status: open
title: Faulty suppression of 'as' keyword warning
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Tue Sep 23 00:13:32 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 22 Sep 2008 22:13:32 +0000
Subject: [issue3937] platform.dist(): detect Linux distribution version in a
	robust, standard way
In-Reply-To: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>
Message-ID: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

platform.dist() returns ('debian', 'lenny/sid', '') on my Ubuntu 8.04
Hardy system.  Investigating shows that there are a few techniques in
platform.py to parse the version-number-files of different Linux
distributions.  This patch adds a command to try executing "lsb_release"
first of all.  lsb_release is the standard way to do this, originally
published in 2001:

http://refspecs.freestandards.org/LSB_1.0.0/gLSB/lsbrelease.html

and currently standardized here:

http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html

If invoking "lsb_release" results in exit code 0 and some non-empty,
non-all-whitespace string on stdout, then dist() returns that.  Else,
dist falls back to the old (current) hacks.

There is a drawback to this: invoking three successive subprocesses
takes a bit of time.  Hopefully nobody needs to invoke platform.dist()
in a time-critical moment...

With this patch, platform.dist() return:
('Ubuntu', '8.04', 'hardy')

Oh, this patch also updates the docstring of dist() to explain what is
meant by "distribution", "version", and "id".

----------
components: Library (Lib)
files: dist.patch.txt
messages: 73601
nosy: zooko
severity: normal
status: open
title: platform.dist(): detect Linux distribution version in a robust, standard way
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11562/dist.patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3937>
_______________________________________

From report at bugs.python.org  Tue Sep 23 00:18:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 22 Sep 2008 22:18:59 +0000
Subject: [issue3937] platform.dist(): detect Linux distribution version in a
	robust, standard way
In-Reply-To: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>
Message-ID: <1222121939.21.0.722085831943.issue3937@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> lemburg
nosy: +lemburg
priority:  -> normal
versions: +Python 2.7, Python 3.1 -Python 2.4, Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3937>
_______________________________________

From report at bugs.python.org  Tue Sep 23 00:20:57 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Mon, 22 Sep 2008 22:20:57 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1222122057.71.0.880611908616.issue3885@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Nick:

1. Yes, the code actually patches an unrelated regression too
(DB.verify() crashes). I added the testcase, since the testsuite didn't
exercise "DB.verify()" and so the bug was lurking there for months. It
is solved now, and the testcase is there to protect us in the future.

I can split the patch, if demanded, nevertheless.

2. About commenting "do_not_close" use, I agree. Done. Now the code says:

"""
        /*
        ** "do_not_close" is used to dispose all related objects in the
        ** tree, without actually releasing the "root" object.
        ** This is done, for example, because function calls like
        ** "DB.verify()" implicitly close the underlying handle. So
        ** the handle doesn't need to be closed, but related objects
        ** must be cleaned up.
        */
"""

Similarly in "DBSequence.remove()".

I'm actually thinking about splitting "*_close_internal()" functions in
"release related objects"+"object close". I don't like the
"do_not_close" flag. But that would be a post-2.6.0 change that I'm
still considering.

3. About "dummy=DB_close_internal(*) + Py_XDECREF", the crashes are
related to raising exceptions *while* deallocating objects. These are
solved with this patch.

Other "dummy=DB_close_internal(*) + Py_XDECREF" uses need be improved,
but they do not crash the library, and the changes are a bit extensive
for a post RC code. They are in my TO DO list, but I think they can be
left out of Python 2.6.0. See my previous post.

4. I agree with you. The problem is related to cleaning a
partially/incorrectly initialized object. Ideally the error should be
raised in the object constructor. Nevertheless in this case the RPC
initialization involves several functions that must be called in
sequence: object created as "RPC enabled"+specifying the details of
remote RPC server. If the handle is disposed before the second step, it
can be safely deallocated without showing any spurious error. In this
concrete example, I don't think the user needs to know about the
"phantom" error.

If you don't agree, please tell to me. Would be a few "fprintf()" enough?.

Thanks for your time, Nick.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Tue Sep 23 00:45:02 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Sep 2008 22:45:02 +0000
Subject: [issue3938] Clearing globals; interpreter -- IDLE difference
In-Reply-To: <1222123502.26.0.150284389082.issue3938@psf.upfronthosting.co.za>
Message-ID: <1222123502.26.0.150284389082.issue3938@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Interpreter:
>>> globals()
{'__builtins__': <module 'builtins' (built-in)>, '__name__': '__main__',
'__doc__': None, '__package__': None}
>>> globals().clear()
>>> globals()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'globals' is not defined

Though not what one would usually want, .clear() clears all.  One now
has a bare interpreter with import disabled ('__import__' not found).

IDLE:
>>> globals().clear()
>>> __name__
'builtins'
>>> globals()
{'__builtins__': {'bytearray': <class 'bytearray'>,...

Module builtins has become the main module. Assignments are added to the
__builtins__ dict.  I am not sure if this is intended or a bug, but if
IDLE is trying to 'recover' from the 'disabling' of the main module, I
think 'Restart Shell ^F6' would be better.

----------
components: IDLE
messages: 73603
nosy: tjreedy
severity: normal
status: open
title: Clearing globals; interpreter -- IDLE difference
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3938>
_______________________________________

From report at bugs.python.org  Tue Sep 23 00:45:49 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 22 Sep 2008 22:45:49 +0000
Subject: [issue3937] platform.dist(): detect Linux distribution version in a
	robust, standard way
In-Reply-To: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>
Message-ID: <1222123549.26.0.315432773058.issue3937@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Here's a new version of this patch which differs only in having slightly
more correct documentation.

Added file: http://bugs.python.org/file11563/dist.patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3937>
_______________________________________

From report at bugs.python.org  Tue Sep 23 00:56:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 22 Sep 2008 22:56:00 +0000
Subject: [issue3938] Clearing globals; interpreter -- IDLE difference
In-Reply-To: <1222123502.26.0.150284389082.issue3938@psf.upfronthosting.co.za>
Message-ID: <1222124160.77.0.8872383382.issue3938@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3938>
_______________________________________

From report at bugs.python.org  Tue Sep 23 01:42:23 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Sep 2008 23:42:23 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

ftplib module is currently lacking a test suite which actually connects
to a FTP server and uses the FTP class methods and facilities.
Bug #3911, discovered just a bunch of weeks before the stable release of
Python 3.0, is an example of how much a test suite is necessary.
As demanded by Benjamin Peterson in #3911, I started working on test
suite which implements an asyncore-based dummy FTP server which sends
fixed response codes that I used to test all the relevant FTP class methods.
Tests for the IPv6 module facilities are also included.
Although not that useful (IMHO) I didn't remove the old tests about
timeouts.

Tested against Python 2.6-RC2 on Windows XP SP3, Linux 2.6.20 and
FreeBSD 7.0.

----------
files: test_ftplib.patch
keywords: patch
messages: 73605
nosy: benjamin.peterson, facundobatista, giampaolo.rodola, gvanrossum
severity: normal
status: open
title: Patch to implement a real ftplib test suite
versions: Python 2.7
Added file: http://bugs.python.org/file11564/test_ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Tue Sep 23 01:44:58 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Sep 2008 23:44:58 +0000
Subject: [issue3911] ftplib.FTP.makeport() bug
In-Reply-To: <1221847682.44.0.529655554535.issue3911@psf.upfronthosting.co.za>
Message-ID: <1222127098.05.0.978391009877.issue3911@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

> Would you like to contribute a patch?

Done in issue #3939.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3911>
_______________________________________

From report at bugs.python.org  Tue Sep 23 02:16:18 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 00:16:18 +0000
Subject: [issue3940] turtle.py - minor bugfixes
In-Reply-To: <1222128977.85.0.461974495418.issue3940@psf.upfronthosting.co.za>
Message-ID: <1222128977.85.0.461974495418.issue3940@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

Thorough testing revealesd the following bugs in turtle.py (Python 2.6):

1) Around lines 359 and 379: There's a name conflict with a methodname
of the parentclass Frame: _root. The bugfix consists in renaming this
attribute, which occurs only twice

2) Around line 732: Turtles with image-shapes do not recognize user
coordinates. This is fixed in  TurtleScreenBase method _drawimage by
introducing the corresponding scaling factors

3) Around line 3570: Calling the __init__ - Method of the Screen-class
(which uses the Borg idiom) destroys graphics and Turtles on the Screen.
This is an undesired behaviour. The fix brings the behaviour of Screen
in accordance with the Python 3.0 version.

4) Around line 3612: Screen.setup() needs a final update() call in order
to ensure, that immediately following calls of window_width() or
window_height() return correct values.

Moreover there is a correction of the version number and date

Bugfixes are attached in turtle.py.diff

Regards,
Gregor

----------
components: Library (Lib)
files: turtle.py.diff
keywords: patch
messages: 73607
nosy: gregorlingl
severity: normal
status: open
title: turtle.py - minor bugfixes
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11565/turtle.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3940>
_______________________________________

From report at bugs.python.org  Tue Sep 23 02:20:43 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 00:20:43 +0000
Subject: [issue3940] turtle.py - minor bugfixes
In-Reply-To: <1222128977.85.0.461974495418.issue3940@psf.upfronthosting.co.za>
Message-ID: <1222129243.96.0.767921977079.issue3940@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

The bugfix for bug 3) described above makes necessary the insertion of a
line in turtleDemo.py (around line 96)

Again I've attached the corresponding diff file

Added file: http://bugs.python.org/file11566/turtleDemo.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3940>
_______________________________________

From report at bugs.python.org  Tue Sep 23 02:32:05 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 00:32:05 +0000
Subject: [issue3941] Help in IDLE doesn't work correctly
In-Reply-To: <1222129925.92.0.876996277522.issue3941@psf.upfronthosting.co.za>
Message-ID: <1222129925.92.0.876996277522.issue3941@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

>From IDLE either pressing F1 or choosing the menu Help-Python Docs
should open a Help-Window with the docs of the current version. (This
works well for instance in Python 2.5.2) The docs file normally resides
on the local computer in the Doc directory (at least under Windows)

With 2.6rc2 under Windows pressing F1 only opens a Browser with the url
http://www.python.org/doc/current/ which leads to the 2.5.2 documentation.  

It should be linked to the python26.chm file in the Doc directory

Regards,
Gregor

----------
components: IDLE
messages: 73609
nosy: gregorlingl
severity: normal
status: open
title: Help in IDLE doesn't work correctly
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3941>
_______________________________________

From report at bugs.python.org  Tue Sep 23 02:53:18 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 23 Sep 2008 00:53:18 +0000
Subject: [issue3666] atexit.register with bad input segfaults on exit
In-Reply-To: <1219610352.03.0.944854344602.issue3666@psf.upfronthosting.co.za>
Message-ID: <1222131198.21.0.843504923904.issue3666@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Checked in as revision 66562.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3666>
_______________________________________

From report at bugs.python.org  Tue Sep 23 03:26:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Sep 2008 01:26:35 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222133195.63.0.62503658426.issue3939@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Awesome! I'll look at this soon.

----------
assignee:  -> benjamin.peterson
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Tue Sep 23 03:53:26 2008
From: report at bugs.python.org (Martin Meredith)
Date: Tue, 23 Sep 2008 01:53:26 +0000
Subject: [issue3942] Usability issue from not being able to use defined start
	and end code block markers
In-Reply-To: <1222134806.54.0.118615870136.issue3942@psf.upfronthosting.co.za>
Message-ID: <1222134806.54.0.118615870136.issue3942@psf.upfronthosting.co.za>


New submission from Martin Meredith <mez at ubuntu.com>:

Recently, a blind user posted on Stack Overflow asking whether there was
something that would allow them to use braces within python.

They have a point, with only tabs being show in the editor, it can be
very confusing for a blind user using a braille output, or a screen
reader to be able to tell exactly where in a code block they are. 

Specific Code Block Markers would allow them to understand this in a
more definate manner.

The question can be found at 

http://stackoverflow.com/questions/118643

Along with some suggestions.

It would be nice if this issue could be resolved in some manner. I
understand obviously, that the fact that python doesn't use braces etc
is why people like it, but the fact that this causes issues so that
python is barely usable by unsighted persons is something that I think
should be addressed.

----------
components: Interpreter Core
messages: 73612
nosy: Mez
severity: normal
status: open
title: Usability issue from not being able to use defined start and end code block markers
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3942>
_______________________________________

From report at bugs.python.org  Tue Sep 23 04:55:48 2008
From: report at bugs.python.org (Robert Yodlowski)
Date: Tue, 23 Sep 2008 02:55:48 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>


New submission from Robert Yodlowski <rbtyod at gmail.com>:

I installed 3.0rc1 on a Win XP 2.4Gzh system with all current updates
with no problems. Cmd line Python and docs work fine. 

Tried to start IDLE but got error message: "IDLE's subprocess didn't
make connection. Either IDLE can't start subprocess or personal firewall
is blocking." 

I turned off my firewall but got the same error message. IDLE works fine
in Python 2.5 and 2.6 on this same machine. Tried change to
idlelib\run.py suggested in bug report #3905 but it had no effect.

...Bob

----------
components: IDLE
messages: 73613
nosy: rbtyod
severity: normal
status: open
title: IDLE won't start in 3.0rc1 "Subprocess didn't make connection...."
type: crash
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Tue Sep 23 06:32:12 2008
From: report at bugs.python.org (Senthil)
Date: Tue, 23 Sep 2008 04:32:12 +0000
Subject: [issue3942] Usability issue from not being able to use defined start
	and end code block markers
In-Reply-To: <1222134806.54.0.118615870136.issue3942@psf.upfronthosting.co.za>
Message-ID: <1222144332.75.0.623180636328.issue3942@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Hello Mez, I don't think this will be implemented in the language. There
have discussions on supporting braces (as accessibility mechanism)
before, but it is not generally agreed upon.

I would like to point to you the discussion between Guido and T.V.Raman
at c.l.p here: http://tinyurl.com/clpdiscussion  You might find
something that would be actually be helpful to blind users, emacsspeak
with python mode extension. Also in the stackoverflow discussion, I
found people pointing to wrapper utilities like pyBraces. That should be
helpful too, but Python wont be changing to support braces.

This report can be closed.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3942>
_______________________________________

From report at bugs.python.org  Tue Sep 23 07:21:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 23 Sep 2008 05:21:33 +0000
Subject: [issue3940] turtle.py - minor bugfixes
In-Reply-To: <1222128977.85.0.461974495418.issue3940@psf.upfronthosting.co.za>
Message-ID: <1222147293.4.0.276244507505.issue3940@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please submit separate patches for unrelated issues. As a whole, the
patch is unacceptable because of that.

Please don't add comments to the code that describe what has changed, or
what was before. Only describe what is. Specifically, don't say
"renamed:...".

Also, for each issue, it would be good if you could provide a short test
case that demonstrates the bug that gets fixed with the patch.

----------
nosy: +loewis
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3940>
_______________________________________

From report at bugs.python.org  Tue Sep 23 07:23:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 23 Sep 2008 05:23:35 +0000
Subject: [issue3941] Help in IDLE should open the chm file
In-Reply-To: <1222129925.92.0.876996277522.issue3941@psf.upfronthosting.co.za>
Message-ID: <1222147415.71.0.355638447682.issue3941@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Notice that the chm file is available on Windows only. So in general,
opening the online documentation might be the right thing to do.

----------
nosy: +loewis
title: Help in IDLE doesn't work correctly -> Help in IDLE should open the chm file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3941>
_______________________________________

From report at bugs.python.org  Tue Sep 23 07:26:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 23 Sep 2008 05:26:04 +0000
Subject: [issue3941] Help in IDLE should open the chm file
In-Reply-To: <1222129925.92.0.876996277522.issue3941@psf.upfronthosting.co.za>
Message-ID: <1222147564.62.0.354173768257.issue3941@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Kurt, even if using online documentation is necessary, I think the URL
is not quite right - it should rather be a version-dependent URL, IMO.

----------
assignee:  -> kbk
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3941>
_______________________________________

From report at bugs.python.org  Tue Sep 23 09:03:34 2008
From: report at bugs.python.org (Dominique Wahli)
Date: Tue, 23 Sep 2008 07:03:34 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222153414.01.0.759261997858.issue3872@psf.upfronthosting.co.za>


Dominique Wahli <dwahli at gmail.com> added the comment:

Sorry Martin but I couldn't help to fix this issue.

A quick check of Tix widgets show the same issue with:
CheckList
HList
ListNoteBook
DirList
DirTree
DirSelectDialog
DirSelectBox
ExFileSelectBox
FileSelectBox

That's a lot of things so maybe it's time to remove Tix package from
core Python.
If not, Tix documentation in Python help need a big red comment in the
beginning of the page.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Tue Sep 23 09:32:05 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 23 Sep 2008 07:32:05 +0000
Subject: [issue3934] sphinx - building muppy docs fails on Linux
In-Reply-To: <1222107495.4.0.954300379659.issue3934@psf.upfronthosting.co.za>
Message-ID: <1222155125.17.0.103445865409.issue3934@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

This was fixed in r65489 (see issue3498). Using the current Sphinx trunk
(http://svn.python.org/projects/doctools/trunk/sphinx) works for me.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3934>
_______________________________________

From report at bugs.python.org  Tue Sep 23 10:19:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Sep 2008 08:19:47 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222157987.91.0.774130450169.issue3943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It is probably already corrected in svn.

Can you please try from a command prompt:

> cd <path_to_python3.0rc1>
> python Lib/idlelib/idle.py

Does this display some error message?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Tue Sep 23 10:23:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Sep 2008 08:23:52 +0000
Subject: [issue3554] ctypes.wstring_at and string_at call Python API without
	the GIL
In-Reply-To: <1218731992.24.0.0258351695719.issue3554@psf.upfronthosting.co.za>
Message-ID: <1222158232.74.0.424731216583.issue3554@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Reference to the SVN:
- trunk: rev65681
- release25-maint branch: rev65858

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3554>
_______________________________________

From report at bugs.python.org  Tue Sep 23 11:23:32 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Tue, 23 Sep 2008 09:23:32 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222161812.87.0.997865869527.issue3943@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

I think the problem is fixed.
See issue 3905.

----------
nosy: +jmfauth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Tue Sep 23 11:31:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Sep 2008 09:31:47 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222162307.61.0.456758767249.issue3943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But #3905 is not yet fixed, furthermore the OP already tried the
correction suggested there.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Tue Sep 23 12:25:59 2008
From: report at bugs.python.org (Pernici Mario)
Date: Tue, 23 Sep 2008 10:25:59 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>


New submission from Pernici Mario <pernici at users.sourceforge.net>:

In this patch x_mul(a, b) uses fewer bit operations for a != b,
asymptotically half of them.
On the three computers I tried the speed-up is around 5% for size=4
and it increases up to 45-60% just below the Karatsuba cutoff,
then it decreases a bit after this cutoff (on one computer the speed-up
is only 16% after KARATSUBA_CUTOFF=70, but raising the cutoff to 140,
for which with the current code the multiplication is also faster,
the speed-up is 45%).

----------
files: longobject_diff
messages: 73624
nosy: pernici
severity: normal
status: open
title: faster long multiplication
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file11567/longobject_diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Tue Sep 23 13:49:34 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 23 Sep 2008 11:49:34 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222170574.07.0.733048518036.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I've had a chance to do some testing and it _is_ related to the itimer
tests (in test_wait4).

This is with r66550:

$ ./python -E -tt ./Lib/test/regrtest.py -l -v test_wait4 test_signal
test_wait4
test_wait (test.test_wait4.Wait4Test) ... ok

----------------------------------------------------------------------
Ran 1 test in 5.007s

OK
test_signal
test_getsignal (test.test_signal.BasicSignalTests) ... ok
test_out_of_range_signal_number_raises_error
(test.test_signal.BasicSignalTests) ... ok
test_setting_signal_handler_to_none_raises_error
(test.test_signal.BasicSignalTests) ... ok
test_main (test.test_signal.InterProcessSignalTests) ... FAIL
test_wakeup_fd_during (test.test_signal.WakeupSignalTests) ... ok
test_wakeup_fd_early (test.test_signal.WakeupSignalTests) ... ok
test_siginterrupt_off (test.test_signal.SiginterruptTest) ... ok
test_siginterrupt_on (test.test_signal.SiginterruptTest) ... ok
test_without_siginterrupt (test.test_signal.SiginterruptTest) ... ok
test_itimer_exc (test.test_signal.ItimerTest) ... ok
test_itimer_prof (test.test_signal.ItimerTest) ...

Running only test_signal:
$ ./python -E -tt ./Lib/test/regrtest.py -l -v test_signal
test_signal
test_getsignal (test.test_signal.BasicSignalTests) ... ok
test_out_of_range_signal_number_raises_error
(test.test_signal.BasicSignalTests)
 ... ok
test_setting_signal_handler_to_none_raises_error
(test.test_signal.BasicSignalTe
sts) ... ok
test_main (test.test_signal.InterProcessSignalTests) ... ok
test_wakeup_fd_during (test.test_signal.WakeupSignalTests) ... ok
test_wakeup_fd_early (test.test_signal.WakeupSignalTests) ... ok
test_siginterrupt_off (test.test_signal.SiginterruptTest) ... ok
test_siginterrupt_on (test.test_signal.SiginterruptTest) ... ok
test_without_siginterrupt (test.test_signal.SiginterruptTest) ... ok
test_itimer_exc (test.test_signal.ItimerTest) ... ok
test_itimer_prof (test.test_signal.ItimerTest) ... ('SIGPROF handler
invoked', (
27, <frame object at 0x83c860c>))
ok
test_itimer_real (test.test_signal.ItimerTest) ...
call pause()...
('SIGALRM handler invoked', (14, <frame object at 0x83c8c0c>))
ok
test_itimer_virtual (test.test_signal.ItimerTest) ... ('SIGVTALRM
handler invoke
d', (26, <frame object at 0x83c920c>))
('SIGVTALRM handler invoked', (26, <frame object at 0x83c920c>))
('SIGVTALRM handler invoked', (26, <frame object at 0x83c920c>))
last SIGVTALRM handler call
('SIGVTALRM handler invoked', (26, <frame object at 0x83c920c>))
ok

----------------------------------------------------------------------
Ran 13 tests in 6.534s

OK
1 test OK.

Noting the interprocess signal test failure, I tried deactivating it and
the itimer tests still go off into the never never (using all available
CPU cycles too).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 13:53:33 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 23 Sep 2008 11:53:33 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222170813.38.0.98755630564.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

Oops - the itimer tests are in test_signal, not test_wait4.

test_wait4 just triggers the problems in test_signal (both the itimer
problems and the interprocess signal test failure).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:03:07 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 23 Sep 2008 12:03:07 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222171387.58.0.539443033455.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

After perusing test_wait4, I tried substituting test_fork1 for
test_wait4 and got the same behaviour from test_signal.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:07:05 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Sep 2008 12:07:05 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1222171625.47.0.35078106718.issue3885@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

All of those explanations sound fair to me - with those questions
answered, the patch looks good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:39:57 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 23 Sep 2008 12:39:57 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222173597.23.0.674894785698.issue3547@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Make this a release blocker so hopefully someone will review it.

----------
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:40:07 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 23 Sep 2008 12:40:07 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222173607.13.0.751055849053.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I compiled the C test case from issue 2240:

$ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -o test_2240
test_2240.c

{lifted as many gcc options off the standard Python compile as possible}

$ ldd test_2240
test_2240:
        libpthread.so.2 => /lib/libpthread.so.2 (0x2807a000)
        libc.so.6 => /lib/libc.so.6 (0x2809f000)

$ ./test_2240
0
1 0
deactive ITIMER_PROF

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:41:51 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Sep 2008 12:41:51 +0000
Subject: [issue3935] bisect insort C implementation ignores methods on list
	subclasses
In-Reply-To: <1222109684.93.0.997656752515.issue3935@psf.upfronthosting.co.za>
Message-ID: <1222173711.7.0.924102124974.issue3935@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/issue3935>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:48:21 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 23 Sep 2008 12:48:21 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222174101.24.0.215453090501.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

Spelunking with test_fork1, it seems that the interprocess signal test
failure is due to the HUP signal not being delivered from the subprocess
to the parent (line 99 of test_signal.py: self.assertTrue(self.a_called).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:48:08 2008
From: report at bugs.python.org (Scott David Daniels)
Date: Tue, 23 Sep 2008 12:48:08 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222095082.43.0.892217303391.issue3926@psf.upfronthosting.co.za>
Message-ID: <48D8E810.5@Acm.Org>


Scott David Daniels <Scott.Daniels at Acm.Org> added the comment:

I found that patch, but it confuses showwarning and formatwarning 
parameter changes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Tue Sep 23 14:57:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Sep 2008 12:57:48 +0000
Subject: [issue3942] Usability issue from not being able to use defined start
	and end code block markers
In-Reply-To: <1222134806.54.0.118615870136.issue3942@psf.upfronthosting.co.za>
Message-ID: <1222174668.78.0.110138600895.issue3942@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3942>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:04:01 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 23 Sep 2008 13:04:01 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222175041.13.0.692809874082.issue3864@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

When you say "interprocess signal test" do you actually mean ItimerTest
? Because I don't see the former failing, and the later hangs because
signals are not being delivered to it (SIGVTALRM neither SIGPROF).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:19:20 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 23 Sep 2008 13:19:20 +0000
Subject: [issue3690] sys.getsizeof wrong for Py3k bool objects
In-Reply-To: <1219783923.07.0.717830637968.issue3690@psf.upfronthosting.co.za>
Message-ID: <1222175960.64.0.647922799148.issue3690@psf.upfronthosting.co.za>


Robert Schuppenies <robert.schuppenies at gmail.com> added the comment:

Attached is a patch which takes the preallocation of small_ints into
account. What do you think?

Added file: http://bugs.python.org/file11568/smallints_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3690>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:19:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Sep 2008 13:19:56 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222175996.66.0.588579126302.issue3939@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Giampaolo, my review comments are on Rietveld:
http://codereview.appspot.com/5698

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:27:16 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 23 Sep 2008 13:27:16 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222176436.89.0.842367131818.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

>From the problematic test run log:

...
test_main (test.test_signal.InterProcessSignalTests) ... FAIL
...

I should be using the full name, sorry.

This failure seems unrelated to the itimer problem though (which is in
itimer_test_prof).  If I deactivate it, the itimer tests still goes into
the never never.

Both however are reliably triggered by running test_fork1 or test_wait4
(which uses the same machinery as test_fork1) before test_signal.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:31:44 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 23 Sep 2008 13:31:44 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222176704.14.0.207654123618.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I should be more specific:
itimer_test_prof (test.test_signal.ItimerTest) appears to go into an
infinite loop when run after test_fork1 or test_wait4 have been run.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:33:22 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 23 Sep 2008 13:33:22 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222176802.22.0.458962880346.issue3864@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Last time I checked many more would cause ItimerTest to not run
properly, these were: test_asynchat, test_asyncore, test_decimal,
text_docxmlrpc, test_ftplib, test_logging, test_poplib, test_queue,
test_smtplib, test_socket and all these tests had in common the
threading.Event usage.

It is possible that I missed other tests, but what I concluded is that
freebsd, threads, and itimer doesn't work together :/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:42:37 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 13:42:37 +0000
Subject: [issue3945] compile error in _fileio.c (cygwin)
In-Reply-To: <1222177357.1.0.250609712045.issue3945@psf.upfronthosting.co.za>
Message-ID: <1222177357.1.0.250609712045.issue3945@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently, fails to build trunk on cygwin.

gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -
I/home/WhiteRabbit/python-dev/trunk/./Include -I. -IInclude -I./Include
-I/home/
WhiteRabbit/python-dev/trunk/Include
-I/home/WhiteRabbit/python-dev/trunk -c /ho
me/WhiteRabbit/python-dev/trunk/Modules/_fileio.c -o
build/temp.cygwin-1.5.25-i6
86-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_fileio.o
/home/WhiteRabbit/python-dev/trunk/Modules/_fileio.c:834: error:
initializer ele
ment is not constant
/home/WhiteRabbit/python-dev/trunk/Modules/_fileio.c:834: error: (near
initializ
ation for `PyFileIO_Type.ob_type')


To fix this, attached patch is needed. Or, like py3k, using following
Py_???_HEAD_INIT (surrounded with bracket) might fix this issue in trunk.

#define PyObject_HEAD_INIT(type)	\
	{ _PyObject_EXTRA_INIT		\
	1, type },

#define PyVarObject_HEAD_INIT(type, size)	\
	{ PyObject_HEAD_INIT(type) size },

----------
components: Build
files: _fileio.patch
keywords: easy, needs review, patch
messages: 73639
nosy: ocean-city
severity: normal
status: open
title: compile error in _fileio.c (cygwin)
versions: Python 2.6
Added file: http://bugs.python.org/file11569/_fileio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3945>
_______________________________________

From report at bugs.python.org  Tue Sep 23 15:55:58 2008
From: report at bugs.python.org (Roger Upole)
Date: Tue, 23 Sep 2008 13:55:58 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>
Message-ID: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

Sample code:
	PyObject *b=PyBytes_FromString("eh ?????");
	PyObject *mv=PyMemoryView_FromObject(b);
	PyObject_CheckReadBuffer(mv);

>From following the chain of calls in PyObject_CheckReadBuffer,
a few things are unclear.

It calls bf_getbuffer with a NULL Py_Buffer pointer, although the PEP
explicitely states that is should never be NULL.

PyBuffer_FillInfo immediately returns success if the view pointer is
NULL.  I'm guessing this is to just determine if the operation could be
completed, but it returns before any checks are done.

It then attempts to release a hardcoded NULL Py_buffer pointer
which of course crashes.

----------
messages: 73640
nosy: rupole
severity: normal
status: open
title: PyObject_CheckReadBuffer crashes on memoryview object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Tue Sep 23 16:12:28 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 23 Sep 2008 14:12:28 +0000
Subject: [issue3937] platform.dist(): detect Linux distribution version in a
	robust, standard way
In-Reply-To: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>
Message-ID: <1222179148.06.0.973401008323.issue3937@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

Please take a look at #1322 for some discussion on this topic.

----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3937>
_______________________________________

From report at bugs.python.org  Tue Sep 23 16:34:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Sep 2008 14:34:46 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>
Message-ID: <1222180486.14.0.772575449873.issue3946@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

And the following statement crashes the interpreter:

>>> compile(memoryview(b"text"), "name", "exec")

----------
nosy: +amaury.forgeotdarc
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Tue Sep 23 17:10:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Sep 2008 15:10:15 +0000
Subject: [issue3945] compile error in _fileio.c (cygwin)
In-Reply-To: <1222177357.1.0.250609712045.issue3945@psf.upfronthosting.co.za>
Message-ID: <1222182615.62.0.352415963015.issue3945@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is OK, even if the second half is not necessary:
PyType_Ready() takes care of the ob_type field.

Adding brackets in the macro would be wrong: the object layout is
different between 2.6 and 3.0.
3.0 does not have this problem because _fileio.c is built-in and linked
with the core interpreter (2.6 leaves it in an extension module).

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3945>
_______________________________________

From report at bugs.python.org  Tue Sep 23 17:20:58 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Sep 2008 15:20:58 +0000
Subject: [issue2486] Decimal slowdown in 3.0 due to str/unicode changes
In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za>
Message-ID: <1222183258.86.0.508225786392.issue2486@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> So I would suggest either a new directory in the sandbox, or re-using
> Facundo's original directory (which includes the telco benchmark)

Makes sense---thanks for the suggestion!

But since it seems I don't have any open ssh ports it looks like I'll 
just have to post a tarball for now.  The module is written to work with 
Python 3.x, on the basis that it's probably easier to backport to 2.x 
later than to try to maintain two separate versions.

On Unix, untar, edit the top line of the Makefile to point to a Python 
3.0 executable, and do

./configure && make

"make test" runs the decimal test-suite.

Added file: http://bugs.python.org/file11570/deccoeff.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2486>
_______________________________________

From report at bugs.python.org  Tue Sep 23 17:26:42 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 15:26:42 +0000
Subject: [issue3945] compile error in _fileio.c (cygwin)
In-Reply-To: <1222177357.1.0.250609712045.issue3945@psf.upfronthosting.co.za>
Message-ID: <1222183602.96.0.0183410004597.issue3945@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>The patch is OK, even if the second half is not necessary:
>PyType_Ready() takes care of the ob_type field.

Oh, OK.

>Adding brackets in the macro would be wrong: the object layout is
>different between 2.6 and 3.0.

I Undarstand.

How about the attached patch?

Added file: http://bugs.python.org/file11571/_fileio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3945>
_______________________________________

From report at bugs.python.org  Tue Sep 23 17:30:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Sep 2008 15:30:04 +0000
Subject: [issue3945] compile error in _fileio.c (cygwin)
In-Reply-To: <1222177357.1.0.250609712045.issue3945@psf.upfronthosting.co.za>
Message-ID: <1222183804.08.0.953787043941.issue3945@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

OK, please apply!

----------
keywords:  -needs review
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3945>
_______________________________________

From report at bugs.python.org  Tue Sep 23 18:12:15 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 16:12:15 +0000
Subject: [issue3945] compile error in _fileio.c (cygwin)
In-Reply-To: <1222177357.1.0.250609712045.issue3945@psf.upfronthosting.co.za>
Message-ID: <1222186335.64.0.665940171139.issue3945@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thanks, fixed in r66566(trunk).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3945>
_______________________________________

From report at bugs.python.org  Tue Sep 23 18:44:39 2008
From: report at bugs.python.org (Steve Lianoglou)
Date: Tue, 23 Sep 2008 16:44:39 +0000
Subject: [issue1168055] Add current dir when running try_run test program
Message-ID: <1222188279.52.0.811703324652.issue1168055@psf.upfronthosting.co.za>


Steve Lianoglou <slianoglou at gmail.com> added the comment:

Sorry to bring up an old issue, but I just got bit by this when trying
to install a python package.

The `config` command was used to ensure that a certain function was
included in the math.h on my cpu before compiling the resulting c binary
and python wrapper for it.

I had to chase down the problem and basically re-figure out what Michiel
did in his patch on my system[1] and override the `try_run` method in
the setup.py file.

I didn't bother checking the issue tracker assuming distutils is used so
widely (and is old enough) that the bug couldn't be in distutiles
itself, but must be something I'm doing wrong in my end ... oh well.

Anyway, could we somehow try to fix this bug to mitigate some lost time
and frustration?

Michiel's patch seems reasonable enough to me since it looks to be the
least surgery-intensive way (I'm not sure where Phillip would like to
put the os.path.abspath() call) to fix the bug for the majority of the
time when someone would be bitten by it.

Regardless of whether or not the code is well documented, it's still
there and usable in distutils (w/o any warnings against its use), so it
would make sense to me that we at least have it work as its intended to.

[1] My path was slightly different than the submitted patch. Where
Michiel has:

command = os.path.join(os.curdir, exe)

I have:

command = os.path.join(os.getcwd(), exe)

all in all, you get the same effect

----------
nosy: +lianos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1168055>
_______________________________________

From report at bugs.python.org  Tue Sep 23 18:55:48 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 16:55:48 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I'm not sure this is python's bug or cygwin's bug, thread enabled python
crashes thread related tests on cygwin. (ex: test_exit on test_sys.py,
test_threading.py etc)

After some investigation, I found following workaround solves this crash.

Index: Modules/_ssl.c
===================================================================
--- Modules/_ssl.c      (revision 66562)
+++ Modules/_ssl.c      (working copy)
@@ -1580,7 +1580,7 @@

        /* Init OpenSSL */
        SSL_load_error_strings();
-#ifdef WITH_THREAD
+#if defined(WITH_THREAD) && !defined(__CYGWIN__)
        /* note that this will start threading if not already started */
        if (!_setup_ssl_threads()) {
                return;

So I applied following patch. (after reverted above workaround)


Index: Modules/_ssl.c
===================================================================
--- Modules/_ssl.c      (revision 66562)
+++ Modules/_ssl.c      (working copy)
@@ -1517,6 +1517,8 @@
           lock. They can be useful for debugging.
        */

+        printf("-------> %d (%u) %s %d: %ul\n", n, mode & CRYPTO_LOCK,
file, line, PyThread_get_thread_ident());
+
        if ((_ssl_locks == NULL) ||
            (n < 0) || ((unsigned)n >= _ssl_locks_count))
                return;

And this is result.

-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 16 (1) ssl_ciph.c 273: 6684680l
-------> 16 (0) ssl_ciph.c 276: 6684680l
-------> 16 (1) ssl_ciph.c 277: 6684680l
-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 16 (0) ssl_ciph.c 308: 6684680l
    started worker thread
    trying nonsensical thread id
    waiting for worker thread to get started
    verifying worker hasn't exited
    attempting to raise asynch exception in worker
    waiting for worker to say it caught the exception
-------> 1 (1) err.c 418: 7282896l
    all OK -- joining worker
-------> 1 (1) err.c 418: 7282896l
   6020 [unknown (0x650)] python 1156 _cygtls::handle_exceptions: Error
while du
mping state (probably corrupted stack)
Illegal instruction (core dumped)


Thread 7282896l tries to lock same object twice. I'm not familiar with
OpenSSL nor Python Thread, so I cannot fix this.

# Can callback function for CRYPTO_set_locking_callback() be called like
this? How does PyThread_allocate_lock behave in this situation? I don't
know.

I used OpenSSL0.9.8h installed via cygwin setup.

----------
files: a.py
messages: 73649
nosy: ocean-city
severity: normal
status: open
title: configure --with-threads on cygwin => crash on thread related tests
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file11572/a.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Tue Sep 23 18:57:59 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 16:57:59 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222189079.76.0.616441751135.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

releast25-maint is fine probably because CRYPTO_set_locking_callback()
is not used in Modules/_ssl.c. I don't try configure --with-threads on
py3k, but probably same on trunk.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Tue Sep 23 19:16:00 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 23 Sep 2008 17:16:00 +0000
Subject: [issue3937] platform.dist(): detect Linux distribution version in a
	robust, standard way
In-Reply-To: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>
Message-ID: <1222190160.19.0.0360147540162.issue3937@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Here is an updated version of my patch which tries parsing
/etc/lsb-release first and only if that fails tries executing
lsb_release.  The reason is that executing lsb_release in a subprocess
takes half-a-second on my high-performance Athlon64 Ubuntu workstation,
and also that some installations have /etc/lsb-release but not
lsb_release.  See the docstring for more details about why to do it this
way and exactly what it does.

Added file: http://bugs.python.org/file11573/dist.patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3937>
_______________________________________

From report at bugs.python.org  Tue Sep 23 19:16:54 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 17:16:54 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222190214.47.0.789591572656.issue1706863@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Tue Sep 23 19:36:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 23 Sep 2008 17:36:31 +0000
Subject: [issue3937] platform.dist(): detect Linux distribution version in a
	robust, standard way
In-Reply-To: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>
Message-ID: <1222191391.87.0.134857767312.issue3937@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
dependencies: +platform.dist() has unpredictable result under Linux
keywords: +patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3937>
_______________________________________

From report at bugs.python.org  Tue Sep 23 19:36:38 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 23 Sep 2008 17:36:38 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222191398.91.0.745441027639.issue1322@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
dependencies: +platform.dist(): detect Linux distribution version in a robust, standard way

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 19:39:45 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 23 Sep 2008 17:39:45 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222191585.57.0.704694067255.issue1322@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Please see also #3937 for a patch which first tries to parse
"/etc/lsb-release", then tries to execute "lsb_release", then falls back
to the old behavior of platform.dist().  (Note that parsing the file
named /etc/lsb-release is not guaranteed to work by the Linux Standard
Base spec, but that executing "lsb_release" is.  On the other hand, the
former currently seems to work on more Debian/Ubuntu installations than
the latter does, and invoking lsb_release in a subprocess takes
significantly more time.)

Please see the links to the Linux Standard Base specifications which I
posted in #3937.  (The specification was originally published in 2001,
so most of the Linux systems that future versions of Python will be
deployed on were developed long after that specification was written.)

My patch, in #3937, is against the python-release25-maint branch.  I
tested the patch locally and it worked, and then I wrote a patch for my
project -- allmydata.org "Tahoe" -- which does something similar:

http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py?rev=2976

I committed that change to Tahoe, and it was automatically tested on
eleven different systems by our buildbot:

http://allmydata.org/buildbot/waterfall

The resulting distribution-identification can be seen in the logs of
those tests.  For any machine on the waterfall, click on the "test.log"
hyperlink and search in text for "tahoe versions:".  For example, here
is the one for our Debian etch machine -- "debian", "4.0":

http://allmydata.org/buildbot/builders/etch/builds/1205/steps/test/logs/test.log

here is the one for the Ubuntu dapper machine -- "Ubuntu", "6.06":

http://allmydata.org/buildbot/builders/dapper/builds/1773/steps/test/logs/test.log

and here is the result for my Ubuntu hardy workstation -- "Ubuntu", "8.04":

http://allmydata.org/buildbot/builders/zooko%20yukyuk%20hardy/builds/216/steps/test/logs/test.log

----------
nosy: +zooko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 20:10:25 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Sep 2008 18:10:25 +0000
Subject: [issue3937] platform.dist(): detect Linux distribution version in a
	robust, standard way
In-Reply-To: <1222121612.35.0.920527697852.issue3937@psf.upfronthosting.co.za>
Message-ID: <1222193425.91.0.571918215716.issue3937@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

As explained in #1322. platform.dist() has been superseded by
platform.linux_distribution().

Please check what platform.linux_distribution() returns on your platform
using Python 2.6rc2.

I'm closing this ticket since it's basically a duplicate of #1322.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3937>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:13:21 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 23 Sep 2008 19:13:21 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222197201.49.0.796941058069.issue1706863@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

The search for *dll.a is described in paragraph "direct linking to a
dll" here: http://sourceware.org/binutils/docs/ld/WIN32.html

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:16:22 2008
From: report at bugs.python.org (Koen van de Sande)
Date: Tue, 23 Sep 2008 19:16:22 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222197382.13.0.671885850619.issue3936@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

I was wondering why I didn't have any warnings in my code in 2.5, when 
it started failing with errors on import in 2.6. Now I know.

----------
nosy: +koen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:19:39 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Sep 2008 19:19:39 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222197579.47.0.876206826937.issue1322@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Zooko, I think the main reason for the parser in platform.py to fail on
Ubuntu is that Ubuntu doesn't ship with a /etc/ubuntu-release file and
instead uses the optional override parameters in /etc/lsb-release to
setup the distribution values.

E.g. on my Ubuntu box it has these lines:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

I guess we'll need to add a special parser for lsb-release files which
then gets tried *after* having tried the /etc/<distro>-release files
(this is how the lsb_release command works as well) and overrides any
settings found in the <distro>-release file.

If that doesn't work either, the function will need to fallback to
_dist_try_harder().

There's no need to start a subprocess for running lsb_release. 

Please also note that the subprocess module is not available in Python
2.1, so it's not an option anyway (platform.py defines it's own popen()
helper which should be used instead).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:27:51 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 23 Sep 2008 19:27:51 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1222198071.78.0.757307982048.issue3885@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Thanks. Committed as r66568.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:34:01 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 23 Sep 2008 19:34:01 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222198441.48.0.875313840938.issue3824@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

What is test result if the environment variable LANG is set to C ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:38:20 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 23 Sep 2008 19:38:20 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222198700.72.0.995245083788.issue1322@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Okay, per MAL's request over on #3937, I tried
platform.get_linux_distribution() on the current svn trunk (which I
assume is the version that is about to become python 2.6).  It gave the
same not-so-great answer as platform.dist() used to: ('debian',
'lenny/sid', '').  I then ported my patch to trunk (attached), and it
gave the answer I wanted: ('Ubuntu', '8.04', 'hardy').

Note that technique of parsing /etc/lsb-release or invoking lsb_release
is more standard and generic and easier to maintain than the current
technique of trying a series of specific file parses for specific
"supported" distributions.  For example, if some new Linux distribution
is invented, or if this is tried on a distribution that isn't in the
supported list (has anyone tried this on Foresight Linux yet?), then my
technique has a good chance of working on that distribution, where the
current technique has a higher chance of accidentally mis-identifying it
as some other distribution, for example the way that the current trunk
mis-identifies Ubuntu 8.04 as Debian lenny/sid.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:39:01 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 23 Sep 2008 19:39:01 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222198741.53.0.873813940381.issue1322@psf.upfronthosting.co.za>


Changes by Zooko O'Whielacronx <zooko at zooko.com>:


Added file: http://bugs.python.org/file11574/dist.patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:49:04 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 23 Sep 2008 19:49:04 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222199344.59.0.624095734142.issue1322@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

MAL:  why do you say it is better to look for
/etc/$supportedplatform-release files first instead of looking for
/etc/lsb-release first?

I do not know if /etc/lsb-release is suitably generic -- I've tried it
only on a few platforms.  I do know that executing lsb_release is
suitably generic since it is standard, but I prefer not to try it first
since it imposes about half-a-second delay.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 21:56:02 2008
From: report at bugs.python.org (Jason Tishler)
Date: Tue, 23 Sep 2008 19:56:02 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222199762.53.0.202010072409.issue1706863@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

The Cygwin build issue was worked around by releasing a sqlite3 
package that contains a static library too. However, this causes the 
Python _sqlite module to be statically linked against sqlite3 even 
though a shared library version is available.

The following patch enables Cygwin to leverage off on the ".dylib" 
functionality added (AFAICT) for Mac OS X.  After the patch is applied,
the _sqlite module is linked against the shared sqlite3 library 
instead of the static one.

Is the patch acceptable? Or, can someone think of a better approach?

Added file: http://bugs.python.org/file11575/unixccompiler.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Tue Sep 23 22:05:24 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Sep 2008 20:05:24 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1222199344.59.0.624095734142.issue1322@psf.upfronthosting.co.za>
Message-ID: <48D94C01.5010800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-09-23 21:49, Zooko O'Whielacronx wrote:
> Zooko O'Whielacronx <zooko at zooko.com> added the comment:
> 
> MAL:  why do you say it is better to look for
> /etc/$supportedplatform-release files first instead of looking for
> /etc/lsb-release first?

Because that's exactly what lsb_release does as well. The data
in /etc/lsb-release can only override data already parsed from
the /etc/<distro>-release file.

> I do not know if /etc/lsb-release is suitably generic -- I've tried it
> only on a few platforms.  I do know that executing lsb_release is
> suitably generic since it is standard, but I prefer not to try it first
> since it imposes about half-a-second delay.

lsb_release is standard on LSB compliant Linuxes, but the much
older /etc/<distro>-release file approach is still valid and in
wide use.

E.g. on SuSE, /etc/lsb-release doesn't contain any usable
distribution information. On Fedora, that file doesn't exist at
all.

It's better to follow the approach taken by lsb_release and then
add calling lsb_release as one of the methods taken by
_dist_try_harder() (using platform.popen()) should the parsers
fail.

This avoids spawning a process in most cases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 22:19:11 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 23 Sep 2008 20:19:11 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222201151.41.0.531980345458.issue1322@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

> Because that's exactly what lsb_release does as well.

You must know something about common lsb_release implementations that I
don't.  As far as I saw in the LSB documentation, it is required to
print out information in a certain format, but how it is implemented is
totally up to the distribution in question.

You give examples of SuSE and Fedora as not having /etc/lsb-release
files, and I'm sure you are right, but I happen to know that both of
them have compliant lsb_release executables (and that they have had for
many releases).  So, the patch that I've submitted will definitely work
correctly for those two distributions, although it will pay the price of
having to spawn a subprocess and then wait for the lsb_release
executable to do its work (however it does it).

However, presumably your SuSE- and Fedora- specific techniques will give
correct answers on those platforms faster than the generic lsb_release
would.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 22:26:19 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 23 Sep 2008 20:26:19 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222201579.68.0.972971444878.issue1706863@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I think that modification has to be in cygwinccompiler. It is specific
for   win32 binutils and impact both - cygwin and mingw.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Tue Sep 23 22:34:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Sep 2008 20:34:38 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222202078.94.0.483415184484.issue1706863@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

+1 for adding 
   dylib_lib_extension = ".dll.a"
to the CygwinCCompiler class.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Tue Sep 23 22:38:53 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Sep 2008 20:38:53 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1222201151.41.0.531980345458.issue1322@psf.upfronthosting.co.za>
Message-ID: <48D953DA.3060600@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-09-23 22:19, Zooko O'Whielacronx wrote:
> Zooko O'Whielacronx <zooko at zooko.com> added the comment:
> 
>> Because that's exactly what lsb_release does as well.

I have to correct that: lsb_release will only look at the other
release files in case it doesn't already enough information from
the lsb-release file.

> You must know something about common lsb_release implementations that I
> don't.  As far as I saw in the LSB documentation, it is required to
> print out information in a certain format, but how it is implemented is
> totally up to the distribution in question.

Just do a "man lsb_release" or look at the lsb_release shell script.

> You give examples of SuSE and Fedora as not having /etc/lsb-release
> files,

Fedora doesn't have that file, so lsb_release has to read the results
from /etc/fedora-release. SuSE does, but doesn't override
the default set in /etc/SuSE-release.

> and I'm sure you are right, but I happen to know that both of
> them have compliant lsb_release executables (and that they have had for
> many releases).  So, the patch that I've submitted will definitely work
> correctly for those two distributions, although it will pay the price of
> having to spawn a subprocess and then wait for the lsb_release
> executable to do its work (however it does it).
> 
> However, presumably your SuSE- and Fedora- specific techniques will give
> correct answers on those platforms faster than the generic lsb_release
> would.

Yep and the same is true for all other _supported_dists. I always try
to avoid spawning external processes whenever I can.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Sep 23 22:59:29 2008
From: report at bugs.python.org (Shish)
Date: Tue, 23 Sep 2008 20:59:29 +0000
Subject: [issue3948] readline steals sigwinch
In-Reply-To: <1222203569.91.0.225970694441.issue3948@psf.upfronthosting.co.za>
Message-ID: <1222203569.91.0.225970694441.issue3948@psf.upfronthosting.co.za>


New submission from Shish <shish+python at shishnet.org>:

I have an app which wants to use a mostly curses interface with some 
parts readline, however, doing so much as "import readline" causes 
readline to claim ownership of sigwinch, thus breaking the ability of 
the app to resize.

Worse, it seems to claim it at the C level -- doing signal.getsignal
(signal.SIGWINCH) returns SIG_DFL, so I can't see anything I can do at 
the python level to manually set the signals to be handled in the way I 
want :-/

I would think it best to set the handler at the start (for 
compatability, and because the vast majority of apps will expect it 
that way), but set it via python's signal module, so that app writers 
can take the signal handler and call it in their own way (In my case, I 
want the app to listen for the signal, and the app's handler will call 
readline's and curses's handlers in turn)

----------
components: Extension Modules
messages: 73667
nosy: shish
severity: normal
status: open
title: readline steals sigwinch
type: behavior
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3948>
_______________________________________

From report at bugs.python.org  Tue Sep 23 23:18:28 2008
From: report at bugs.python.org (Shish)
Date: Tue, 23 Sep 2008 21:18:28 +0000
Subject: [issue3949] curses' sigwinch handler isn't visible from python
In-Reply-To: <1222204708.76.0.512730295083.issue3949@psf.upfronthosting.co.za>
Message-ID: <1222204708.76.0.512730295083.issue3949@psf.upfronthosting.co.za>


New submission from Shish <shish+python at shishnet.org>:

after the first initscr() sigwinch is handled as expected, but then my 
app needs to ignore sigwinch, leave curses to view the output from 
something, come back into curses, and start listening for sigwinch 
again. The signal(SIGWINCH, SIG_IGN) call doesn't return the old, 
working signal handler; it returns 0 -- thus trying to re-set the 
signal handler doesn't work.

(The reason for ignoring the signal is that if the window is resized 
while the external app is running, python's wait() is interrupted)

Having the handler visible from python would also make curses play 
nicer with readline, as the app could mediate signal handling (see 
issue #3948)

----------
components: Extension Modules
messages: 73668
nosy: shish
severity: normal
status: open
title: curses' sigwinch handler isn't visible from python
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3949>
_______________________________________

From report at bugs.python.org  Tue Sep 23 23:29:51 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 23 Sep 2008 21:29:51 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1222205391.12.0.573032236365.issue3885@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
resolution:  -> fixed
status: open -> closed
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Tue Sep 23 23:35:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Sep 2008 21:35:39 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>
Message-ID: <1222205739.2.0.992411212399.issue3946@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching patch and test.

----------
keywords: +needs review, patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file11576/no_null_view.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Tue Sep 23 23:49:05 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Sep 2008 21:49:05 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1222206545.9.0.229673131668.issue3885@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, thanks. My initial bug is closed and my fuzzer is unable to find 
new ones ;-) Great job.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:22:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Sep 2008 22:22:26 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222208546.97.0.182980158659.issue3936@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching patch and test.

----------
keywords: +needs review, patch
nosy: +benjamin.peterson
priority:  -> high
Added file: http://bugs.python.org/file11577/fix_warning_after_import.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:24:14 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Tue, 23 Sep 2008 22:24:14 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1221599389.8.0.12271871478.issue3885@psf.upfronthosting.co.za>
Message-ID: <1222208654.01.0.595077949995.issue3885@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Would be nice to use that fuzzer myself. Details, please :).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:26:18 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 22:26:18 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

In the first line of TurtleScreenBase._drawimage() there are to
scalefactors missing. This leads to the annoying fact, that the drawings
and the movement of a turtle which has an image shape differ.

This is shown in the short script
_drawimage_bug_fix-test.py
which I'll submit immediately. (You have to have huhn.gif in the same
directory as the script.)

After applying the bugfix submitted in 
_drawimage_patch.diff
this annoying behaviour goes away.

It is really an ambarassing and easy to fix bug.
Regards, Gregor

----------
files: _drawimage-patch.diff
keywords: patch
messages: 73673
nosy: gregorlingl, loewis
severity: normal
status: open
title: turtle.py: bug in TurtleScreenBase._drawimage
Added file: http://bugs.python.org/file11578/_drawimage-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:27:30 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 22:27:30 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1222208850.83.0.0458250876235.issue3950@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


----------
type:  -> behavior
versions: +Python 2.6
Added file: http://bugs.python.org/file11579/_drawimage_bug_fix_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:28:25 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 22:28:25 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1222208905.78.0.889863254275.issue3950@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Added file: http://bugs.python.org/file11580/huhn.gif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:35:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 22:35:33 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1222209333.72.0.337045135128.issue2445@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

# I found this infomation via "svn blame"

According to issue403947, cygwin once used CygwinCCompiler, and problem
was there, swiched to UnixCCompier. (r19674)

If this issue is not solved yet, maybe it's not good to go back to
CygwinCCompiler. (maybe)

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2445>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:39:57 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 22:39:57 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222209597.79.0.193880074837.issue1706863@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Python is not using CCygwinCCompiler to build itself on cygwin. See
issue2445.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:47:23 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Sep 2008 22:47:23 +0000
Subject: [issue3885] errors on _bsddb creation and dealloc
In-Reply-To: <1222208654.01.0.595077949995.issue3885@psf.upfronthosting.co.za>
Message-ID: <200809240047.27275.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Would be nice to use that fuzzer myself. Details, please :).

It's not the best place to explain it, so I will try explain shortly:
* install fusil 1.0: use mandriva/debian packages, or use sources
* (create fusil user group)
* run "sudo fusil-python --module=_bsddb"

The best way is to use the trunk version (without installation)!
----
cd <your fusil home>
svn co http://python-ptrace.hachoir.org/svn/trunk python-ptrace
svn co http://fusil.hachoir.org/svn/trunk fusil
export PYTHONPATH=$PWD/python-ptrace/ptrace:$PWD/fusil:$PYTHONPATH
sudo <your python interpreter> ./fusil/fuzzer/fusil-python --module=_bsddb
----
(refer to python-ptrace/INSTALL and fusil/INSTALL)

You have to run the fuzzer as root to be able to run child processes as the 
fusil user. Never run fusil as root or it will kill you(r computer)!

See also http://fusil.hachoir.org/trac/wiki/Contact

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3885>
_______________________________________

From report at bugs.python.org  Wed Sep 24 00:58:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Sep 2008 22:58:57 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1222210737.28.0.489321417796.issue3950@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Go ahead and apply it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Wed Sep 24 01:05:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 23 Sep 2008 23:05:41 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222211141.75.0.0568974214044.issue3187@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's another patch. It simply propagates the UnicodeDecodeErrors. I
like this because it avoids silent ignoring problem, and people can get
bytes if they want by passing in a bytes path.

Added file: http://bugs.python.org/file11581/raise_decoding_errors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Wed Sep 24 01:49:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Sep 2008 23:49:25 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222213765.9.0.431629995816.issue3936@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I would be more comfortable if "started = 1" was also executed in the 
NEWLINE case. I'm not sure to understand the exact use of its value.

And do you think if it's possible to add the type==SEMICOLON case?
This would properly show the warning for:
    import sys; as = 3    # on the same line

There are still some far-fetched constructs that do not warn, like:
    import sys as as
but they are probably not worth the trouble.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:01:30 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 24 Sep 2008 00:01:30 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222214490.71.0.948413064737.issue3187@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hmm... much of the os.path machinery (and os.walk) probably doesn't work
with bytes, and neither do fnmatch.py and glob.py, I expect.  Plus
io.open() refuses bytes for the filename, even though _fileio accepts
them.  The latter should be fixed regardless, and one of the attachments
here has a fix IIRC.

Gotta run, sorry.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:04:50 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 24 Sep 2008 00:04:50 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222214690.93.0.708035633794.issue3824@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> What is test result if the environment variable LANG is set to C ?

There is no change.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:15:07 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 24 Sep 2008 00:15:07 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222215307.94.0.64114354271.issue3939@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Patch modified after the remarks discussed with Benjamin is in attachment.

Added file: http://bugs.python.org/file11582/test_ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:29:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 00:29:18 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In rev 56476, martin.v.loewis enabled Py_USING_MEMORY_DEBUGGER by 
default in an huge commit:
   PEP 3123: Provide forward compatibility with Python 3.0, 
   while keeping backwards compatibility. Add Py_Refcnt, 
   Py_Type, Py_Size, and PyVarObject_HEAD_INIT.

I guess that's an error, and that Py_USING_MEMORY_DEBUGGER should be 
disabled by default.

Proposition to avoid such bug in future: create a configure option, 
like --with-memory-debugger. See for example my patch to configure.in 
(you will need to run autoconf && autoheader).

----------
files: configure-memory-debugger.patch
keywords: patch
messages: 73683
nosy: haypo
severity: normal
status: open
title: Disable Py_USING_MEMORY_DEBUGGER!
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11583/configure-memory-debugger.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:36:28 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 00:36:28 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222216588.44.0.284051741847.issue3951@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file11584/obmalloc-no-debug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:37:30 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 00:37:30 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222216650.1.0.760767026434.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Patch regex_2.6rc2+5.diff adds scoped and 'negative' flags for (?i),
(?m) and (?s). The other flags remain unchanged in behaviour.

See #433024, #433027 and #433028.

Added file: http://bugs.python.org/file11585/regex_2.6rc2+5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:38:24 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 00:38:24 +0000
Subject: [issue433024] SRE: (?flag) isn't properly scoped
Message-ID: <1222216704.75.0.0945496839717.issue433024@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Implemenetd in #3825.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433024>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:39:03 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 00:39:03 +0000
Subject: [issue433027] SRE: (?-flag) is not supported.
Message-ID: <1222216743.45.0.63514164299.issue433027@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Implemented in #3825.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433027>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:39:26 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 00:39:26 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1222216766.92.0.8974266048.issue433028@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Implemented in #3825.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433028>
_______________________________________

From report at bugs.python.org  Wed Sep 24 02:41:02 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 00:41:02 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222216862.45.0.703089407155.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Guido compiled my patches here: http://codereview.appspot.com/3055

My patches allows bytes for fnmatch.filter(), glob.glob1(), 
os.path.join() and open().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Wed Sep 24 03:22:08 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 01:22:08 +0000
Subject: [issue3952] _lsprof: clear() should call flush_unmatched()
In-Reply-To: <1222219328.76.0.602702790572.issue3952@psf.upfronthosting.co.za>
Message-ID: <1222219328.76.0.602702790572.issue3952@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Example to reproduce the bug (using Python trunk):
---
from gc import collect
import _lsprof

def callMethod(obj):
    obj.clear()
    collect()

obj = _lsprof.Profiler()
obj.enable()
callMethod(obj)
obj.enable()

del obj
collect()
---

The problem is that the profiler is still running when exiting 
callMethod() and so it tries to use callMethod context which was 
free'd just before by profiler_clear().

----------
files: _lsprof_clear.patch
keywords: patch
messages: 73689
nosy: haypo
severity: normal
status: open
title: _lsprof: clear() should call flush_unmatched()
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11586/_lsprof_clear.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3952>
_______________________________________

From report at bugs.python.org  Wed Sep 24 04:20:23 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 02:20:23 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222222823.54.0.282851662996.issue3825@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Patch regex_2.6rc2+6.diff is a bugfix.

Added file: http://bugs.python.org/file11587/regex_2.6rc2+6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Wed Sep 24 05:07:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Sep 2008 03:07:21 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222225641.92.0.948172715574.issue3951@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Wed Sep 24 06:35:23 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 24 Sep 2008 04:35:23 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222230923.49.0.135737779788.issue3951@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You are right that this was by mistake; here is a patch to revert that
mistake (revert.diff).

I'm marking the issue release-critical because of thsi patch; the other
patches (for adding a new configure option) clearly can't go into 2.6,
and might need to be deferred to 2.7.

----------
keywords: +needs review
priority:  -> release blocker
Added file: http://bugs.python.org/file11588/revert.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:02:05 2008
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Wed, 24 Sep 2008 09:02:05 +0000
Subject: [issue3953] __cmp__ still documented in 3.0rc1?
In-Reply-To: <1222246925.0.0.181564278939.issue3953@psf.upfronthosting.co.za>
Message-ID: <1222246925.0.0.181564278939.issue3953@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i? <hniksic at gmail.com>:

__cmp__ is apparently still documented at
http://docs.python.org/dev/3.0/reference/datamodel.html#object.__cmp__ .
 If it is going away for 3.0, it should be removed from the
documentation as well.

----------
assignee: georg.brandl
components: Documentation
messages: 73692
nosy: georg.brandl, hniksic
severity: normal
status: open
title: __cmp__ still documented in 3.0rc1?
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3953>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:13:49 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 09:13:49 +0000
Subject: [issue3953] __cmp__ still documented in 3.0rc1?
In-Reply-To: <1222246925.0.0.181564278939.issue3953@psf.upfronthosting.co.za>
Message-ID: <1222247629.71.0.73006920063.issue3953@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks! Removed this and a few more references in r66577.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3953>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:19:20 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Sep 2008 09:19:20 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222247960.75.0.83074528772.issue3944@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just to be clear:  this patch halves the number of shifts and masks, 
asymptotically;  it doesn't affect the number of adds and multiplies 
(except for saving a few additions to zero by setting the initial carry 
intelligently).  Is that correct?  It's quite surprising that the bit 
operations have such a large effect on the running time.

Perhaps this is an argument for considering changing PyLong_SHIFT to 16 
(or better, 32, since surely almost every compiler provides uint64_t or 
equivalent these days)?  Though that would be quite an involved task.

While I believe the idea is sound, the patch isn't quite correct---it's 
got some assertions that won't always hold.  For example, with the 
patch, in a debug build of Python, I get:

>>> a = b = 2**30-1
[36413 refs]
>>> a*b
Assertion failed: (carry <= PyLong_MASK), function x_mul, file 
Objects/longobject.c, line 2228.
Abort trap

I'm fairly sure that the assert(carry <= PyLong_MASK) doesn't matter, 
and that the assertion at the end of the main outer loop (assert(carry 
>> PyLong_SHIFT) == 0)) should still hold.  But some more comments and 
analysis in the code would be good.  For example, if carry >= 
PyLong_MASK the the comment that 2*MASK + 2*MASK*MASK is contained in a 
twodigit isn't so useful.  How big can carry get?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:20:49 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Sep 2008 09:20:49 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222248049.37.0.506443066093.issue3944@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/issue3944>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:28:31 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Sep 2008 09:28:31 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222248511.99.0.226103997891.issue1706863@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

If Jason patch resolve issue may I ask cygwincompiler.py to be modified
too just in case if as result of issue2445 is decided to switch back ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:52:50 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Sep 2008 09:52:50 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1222249970.09.0.42801790455.issue2445@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

May be check for compiler.compiler_type (from sysconfig.py ) has to be
replaced with a check for descendant classes of UnixCCompiler, i.e. to
include mingw32 too ?

Also CygwinCCompiler __init__ has to be reviewed too. As example :
-------------
        # Hard-code GCC because that's what this is all about.
        # XXX optimization, warnings etc. should be customizable.
        self.set_executables(compiler='gcc -mcygwin -O -Wall',
        .....
-------------
May override in unexpected way settings from customize_compiler.

I thin that proposed modification in sysconfig.py with removing(or
replacing)  of self.set_executables from CygwinCCompiler __init__  will
help me for issue3871 (cross building python for mingw32 with distutils). 

As example I will remove a hack in the setup.py:
-----------------------
@@ -196,8 +196,26 @@
         if compiler is not None:
             (ccshared,cflags) =
sysconfig.get_config_vars('CCSHARED','CFLAGS')
             args['compiler_so'] = compiler + ' ' + ccshared + ' ' + cflags
+
+        # FIXME: Is next correct ?
+        # To link modules we need LDSHARED passed to setup.py otherwise
+        # distutils will use linker from build system if cross-compiling.
+        linker_so = os.environ.get('LDSHARED')
+        if linker_so is not None:
+            args['linker_so'] = linker_so
+
         self.compiler.set_executables(**args)
-----------------------
Thanks to Hirokazu who point me, in an another thread, that cygwin build
don't use CygwinCCompiler.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2445>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:55:04 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 09:55:04 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222250104.07.0.205943568985.issue3951@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@loewis: your patch (revert.diff) includes a change in configure.in 
about OpenBSD !?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Wed Sep 24 11:55:35 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Sep 2008 09:55:35 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1222250135.2.0.0265256416813.issue3451@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch, Mario!  I'll give a look when I get the chance.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3451>
_______________________________________

From report at bugs.python.org  Wed Sep 24 12:01:07 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Sep 2008 10:01:07 +0000
Subject: [issue3871] cross building python for mingw32 with distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1222250467.51.0.775891379809.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

For the protocol: issue2445 impact proposed patch.
Also I finish the tests and I will upload soon new patch - I the current
patch (  	 rpetrov, 2008-09-15 02:08) "Modules/selectmodule.c" isn't
ported and this prevent socked and related modules to work.
Also I understand the one of the reasons python 2.6x to be linked with
msvcr90 - many of bugs related to math functions are fixed in this
version of runtime.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Sep 24 12:02:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 10:02:33 +0000
Subject: [issue3954] _hotshot: invalid error control in logreader()
In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>
Message-ID: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Using Fusil the fuzzer, I found a "minor" bug in _hotshot module: it 
doesn't check correctly the errors in hotshot_logreader(). On error, 
an exception is raised (eg. by eof_error()) but the result is a 
pointer to a new allocated object instead of NULL.

Here is a patch to delete the new created object (using Py_DECREF) and 
return NULL. It uses an ugly goto, but goto is sometimes useful to 
avoid code duplication on error handling (eg. see Linux source code).

Example to reproduce the bug:
---
import _hotshot, gc
_hotshot.logreader(".")
gc.collect()
---

----------
components: Library (Lib)
files: _hotshot_logreader.patch
keywords: patch
messages: 73700
nosy: haypo
severity: normal
status: open
title: _hotshot: invalid error control in logreader()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file11589/_hotshot_logreader.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3954>
_______________________________________

From report at bugs.python.org  Wed Sep 24 12:10:08 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 10:10:08 +0000
Subject: [issue3954] _hotshot: invalid error control in logreader()
In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>
Message-ID: <1222251008.15.0.72692852093.issue3954@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, my previous patch always raise an error even on valid file :-p

Here is a new patch with *an unit test* (yeah!).

Added file: http://bugs.python.org/file11590/_hotshot_logreader2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3954>
_______________________________________

From report at bugs.python.org  Wed Sep 24 12:10:13 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 10:10:13 +0000
Subject: [issue3954] _hotshot: invalid error control in logreader()
In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>
Message-ID: <1222251013.31.0.00278420468483.issue3954@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11589/_hotshot_logreader.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3954>
_______________________________________

From report at bugs.python.org  Wed Sep 24 12:14:52 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Sep 2008 10:14:52 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1222251292.7.0.427432926204.issue2445@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

P.S. : about: static_lib_extension = ".dll.a" - it is suffix for import
library  and "unixccompiler.py.diff" patch from issue1706863 propose 
dylib_lib_extension = ".dll.a" .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2445>
_______________________________________

From report at bugs.python.org  Wed Sep 24 12:24:22 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Sep 2008 10:24:22 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1222251862.58.0.997194843069.issue2445@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I forgot  an another issue in CygwinCCompiler __init__:
if gcc isn't version "2.91.57" then method will set dll_libraries to
result of get_msvcr(), but the result may be is None. In this case link
method fail on the line libraries.extend(self.dll_libraries).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2445>
_______________________________________

From report at bugs.python.org  Wed Sep 24 13:13:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Sep 2008 11:13:19 +0000
Subject: [issue3954] _hotshot: invalid error control in logreader()
In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>
Message-ID: <1222254799.58.0.289456967526.issue3954@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is good to me. 
gotos are perfectly allowed for this purpose.

(to python committers: Should this kind of "minor" issues be fixed after
2.6rc2? This could as well wait until 2.6.1)

----------
nosy: +amaury.forgeotdarc
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3954>
_______________________________________

From report at bugs.python.org  Wed Sep 24 13:28:31 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 11:28:31 +0000
Subject: [issue433024] SRE: (?flag) isn't properly scoped
Message-ID: <1222255711.8.0.159886660671.issue433024@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433024>
_______________________________________

From report at bugs.python.org  Wed Sep 24 13:28:42 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 11:28:42 +0000
Subject: [issue433027] SRE: (?-flag) is not supported.
Message-ID: <1222255722.09.0.943352534816.issue433027@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433027>
_______________________________________

From report at bugs.python.org  Wed Sep 24 13:28:50 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 11:28:50 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1222255730.21.0.573980158103.issue433028@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433028>
_______________________________________

From report at bugs.python.org  Wed Sep 24 13:33:01 2008
From: report at bugs.python.org (Jason Tishler)
Date: Wed, 24 Sep 2008 11:33:01 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222255981.32.0.773631312817.issue1706863@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

Hirokazu Yamamoto wrote:
> Python is not using CCygwinCCompiler to build itself on cygwin.

Which I why my patch modifies UnixCCompiler instead of 
CCygwinCCompiler.  FWIW, my patch leverages the already existing 
Cygwin specific code in UnixCCompiler.

So, is my patch acceptable?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Wed Sep 24 13:54:10 2008
From: report at bugs.python.org (Jason Tishler)
Date: Wed, 24 Sep 2008 11:54:10 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1222257250.53.0.776806759012.issue2445@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

I don't think the patch, cygwin-smaller.diff, is correct. The value of 
static_lib_extension needs to remain ".a". Otherwise, shared 
extensions attempting to build against a library that only offers a 
static version will fail to link.

AFAICT, Cygwin needs a concept that is not currently supported by 
distutils -- the ability to specify a shared library *link* extension 
(i.e., ".dll.a") which is different from the shared library extension 
(i.e., ".dll"). On Unix they are the same (e.g., ".so"), but on Cygwin 
they are different because of how Windows handles DLLs -- import 
library versus DLL.

----------
nosy: +jlt63

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2445>
_______________________________________

From report at bugs.python.org  Wed Sep 24 14:06:43 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 12:06:43 +0000
Subject: [issue3825] Major reworking of Python 2.5.2 re module
In-Reply-To: <1220994473.73.0.878276412191.issue3825@psf.upfronthosting.co.za>
Message-ID: <1222258003.91.0.933460988332.issue3825@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Matthew,

I am really happy that you are making such progress on your engine, but
can I PLEASE ask you to slow down for a moment?  We have a lot of issues
already listed in issue 2636 that is a catch-all for any Python 2.7
Regexp improvements, including your new engine, and I have been working
frantically to try and document all the changes YOU are making here into
the general Regexp 2.7 modification thread and setting up development
trees in my Bazaar VCS repository for your work.

There is also a recommended process for patching which makes it easier
for the moderators to accept your patches which is to provide
dis-entangled functionality and letting each improvement stand on its
own two feet.  In other words, let your engine stand ONLY on it's 2x
speed improvements.  We already have an implementation of Atomic
Grouping / Possessive Qualifiers in issue 2636 but you have a version of
your engine with both.  We have no such 'feature-only' implementation
for Variable-Length Look-Behind, for a Reverse flag, for Positionally
Dependent modifier flags or modifier negation flags, as well as the
zero-width Regular Expression split feature, though you and I completely
agree these would all be great things to have!  The more features you
add to your engine as an all-or-nothing proposition, the less likely the
moderators are going to be to adapt it because it's harder for them to
examine the merits of each individual piece.  That is why issue 2636 is
broken up into items (currently 1 - 18, with your proposals bringing
that up toward 22) and where alternate, combined features are provided
if implementing 1 features would affect the implementation of another.

Please understand that I personally have no problem with you redesigning
large swaths of the Python Regular Expression engine.  I would
personally, like to see one of the design goals of any new engine not
only be speed but better source comments because my main beef with the
current engine is that it took me a month to understand and part of my
redesign in issue 2636 9-1 was to add copious comments to the engine so
that future developers would understand what was going on and be able to
pick up from my work.  I am not proposing we use my 9-1 engine because
it is 8% slower than the current engine and I don't intend to propose
anything slower.  But it would be nice if you could add lots of comments
to your engine so that others could help develop features against it. 
None the less, I will fully support your engine if it does indeed
perform substantially and measurably faster and am happy to see all the
Regexp issues you are finding are finally being implemented, all be it
entangled with your engine.  But let's return to the fundamentals of
what you propose IN THIS THREAD, which simply to propose a new Regexp
Engine which is 2x faster than the existing engine (Which I have
allocated item 9-2 in the issue 2636 thread).  I am not trying to put
more work on your hands -- in fact, what I am trying to do is get us to
co-operate on a better python Regexp Engine so that I can help you to
achieve your goals.  Please read issue 2636 and join the discussion
there; feel free to add any new items you feel are missing from my
existing list.  And remember, each new feature needs tests and
documentation changes.  I have been doing each for any feature I
undertake and would be happy to share those skills with you.  

Let's work together to see your engine be the new model, okay?

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3825>
_______________________________________

From report at bugs.python.org  Wed Sep 24 14:23:14 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 24 Sep 2008 12:23:14 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1222258994.64.0.341129042248.issue1759169@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Sorry I didn't get back to this ticket, MvL.

Recently someone trying to build the Tahoe distributed filesystem on
Solaris had a problem:

http://allmydata.org/pipermail/tahoe-dev/2008-September/000789.html

They had built Python 2.5 themselves from source.

It turned out to be this issue:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6395191

Which is that g++ on Solaris fails when _XOPEN_SOURCE_EXTENDED is defined.

This reminded me of this ticket, so here I am again.

So, here is the port of Python to Solaris that is maintained by the
Solaris engineers:

http://src.opensolaris.org/source/xref/jds/spec-files/trunk/SUNWPython.spec

It contains the following stanza:

    146 # These #define's break the build with gcc and cause problems when
    147 # building c99 compliant python modules
    148 perl -pi -e 's/^(#define _POSIX_C_SOURCE.*)/\/* $1 *\//' pyconfig.h
    149 perl -pi -e 's/^(#define _XOPEN_SOURCE.*)/\/* $1 *\//' pyconfig.h
    150 perl -pi -e 's/^(#define _XOPEN_SOURCE_EXTENDED.*)/\/* $1 *\//'
pyconfig.h

This shows that the Python that comes with Solaris has, for a long time
now, had these #define's stripped out of the pyconfig.h.  Why?  Well, I
asked the Solaris engineers about it on IRC, and they were very nice and
helpful, and they said, if I am remembering correctly, that Solaris
doesn't use these #define's in the way that we Python people think.

#defining _XOPEN_SOURCE_EXTENDED on Solaris is *not* understood by the
Solaris runtime as a request for XPG4v2 (UNIX98) features to be
supported, but more as a declaration that the code we are compiling was
written for XPG4v2.  So, for example, this disables C99, because after
all C99 wasn't available in XPG4v2.  It also apparently breaks g++, but
that is by accident rather than design.  In any case, the Solaris
engineers assured me that rather than figuring out which unixy features
are turned on by which #defines, we should instead #define
__EXTENSIONS__ and then assume all the features we can eat.

Whether this is true in general remains to be seen, but apparently
_POSIX_C_SOURCE, _XOPEN_SOURCE, and _XOPEN_SOURCE_EXTENDED, at least,
are proven to be unnecessary on Solaris by the fact that the version of
Python that has been shipping with Solaris for who knows how long has
them stripped out.

Therefore, I propose to apply my patch so that we do not turn on
_XOPEN_SOURCE but we do turn on __EXTENSIONS__, when building for Solaris.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Wed Sep 24 14:00:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Sep 2008 12:00:47 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222257647.34.0.460201367742.issue3824@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Doesn't getgrgid() return the untranslated content of /etc/group?
Then the encoding of this file is relevant.

On cygwin, "mkgroup -l" is often (exclusively?) used to generate this
/etc/group, extracting the user definitions from the Windows settings.
Its source code
http://www.google.com/codesearch?q=file:mkgroup.c+package:cygwin-1.5
shows that it uses MBCS to encode strings.

Maybe we should start considering cygwin as a posix platform with win32
features; but I am not sure to like this idea.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Wed Sep 24 14:38:22 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 24 Sep 2008 12:38:22 +0000
Subject: [issue3955] maybe doctest doesn't understand unicode_literals?
In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za>
Message-ID: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

# This program works fine with Python 2.5 and 2.6:
def f():
    """
    >>> f()
    'xyz'
    """
    return "xyz"

if __name__ == "__main__":
    import doctest
    doctest.testmod()


But if you put the statement "from __future__ import unicode_literals"
at the start then it fails:
File "/tmp/test.py", line 5, in __main__.f
Failed example:
    f()
Expected:
    'xyz'
Got:
    u'xyz'

I don't know if it is a bug or a feature but I didn't see any mention of
it in the bugs or docs so thought I'd mention it.

----------
components: Library (Lib)
messages: 73710
nosy: mark
severity: normal
status: open
title: maybe doctest doesn't understand unicode_literals?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3955>
_______________________________________

From report at bugs.python.org  Wed Sep 24 14:58:36 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 12:58:36 +0000
Subject: [issue3511] Incorrect charset range handling with ignore case flag?
In-Reply-To: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>
Message-ID: <1222261116.18.0.875160111346.issue3511@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3511>
_______________________________________

From report at bugs.python.org  Wed Sep 24 15:15:04 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 13:15:04 +0000
Subject: [issue3511] Incorrect charset range handling with ignore case flag?
In-Reply-To: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>
Message-ID: <1222262104.35.0.651075836206.issue3511@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

I think this is even more complicated when you consider that
localization my be an issue.  Consider "?": is this grammatically before
 "A" or after "a"?  From a character set point of view, it is typically
after "a" but when Locale is taken into account, all that is done is
there is a change to relative ordering, so ? appears somewhere before A
and B.  But when this is done, does that mean that [9-?] is going to
cover ALL uppercase and ALL lowercase and ALL characters with ord from
91 to 96 and 123 to 127 and all kinds of other UNICODE symbols?  And how
will this effect case-insensitivity.

In a sense, I think it may only be safe to say that character class
ranges are ONLY appropriate over Alphabetic character ranges or numeric
character ranges, since the order of the ASCII symbols between 0 and 47,
56 and 64, 91 adn 96 and 123 and 127, though well-defined, are none the
less implementation dependent.  When we bring UNICODE into this, things
get even more befuddled with some Latin characters in Latin-1, some in
Latin-2, Cyrillic, Hebrew, Arabic, Chinese, Japanese and Korean
character sets just to name a few of the most common!  And how does a
total ordering of characters apply to them?

In the end, I think it's just dangerous to define character group ranges
that span the gap BETWEEN numbers and alphabetics.  Instead, I think a
better solution is simply to implement Emacs / Perl style named
character classes as in issue 2636 sub-item 8.

I do agree this is a problem, but as I see it, the solution may not be
that simple, especially in a UNICODE world.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3511>
_______________________________________

From report at bugs.python.org  Wed Sep 24 15:42:58 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Sep 2008 13:42:58 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

There is a bug in Screen.__init__() (The Screen class uses the Borg
idiom to simulate a Singleton).

This bug is demonstrated best interactively from IDLE (using the -n
switch) like this:

>>> from turtle import Screen, Turtle
>>> t = Turtle()
>>> t.fd(100)     # idea: let's have a yellow background, so we need
                  # *the* screen
>>> s = Screen()  # the drawing vanishes
>>> s.turtles()
[]

This is undesired behaviour. Instead the Screen() call should leave the
drawings an the turtles untouched and return the already existing
Screen. So the call of turtles() would result in something like:

>>> s.turtles()
[<turtle.Turtle object at 0x01490330>]

This is accomplished by the patch described in the attached file turtle.diff

Of course sequences of commands like those shown in the interactive
session above do not occur in well designed scripts, but they may well
occur during sessions of students in interactive classroom use. 

Two more important notes:

(1) This patch is already done in turtle.py for Python 3.0. So in 2.6 it
would ensure that Turtles and the Screen show identical behaviour in
both versions.

(2) This patch makes necessary one other patch in turtleDemo.py - in the
Demo directory - which is shown in the attached turtleDemo.diff 
turtleDemo.py is not a normal turtle application but a GUI - utility
designed to run a series of 'normal' turtle - apps conforming to some
simple rules (These apps in most cases use a Screen()). So when
switching from one to another demo script within turtleDemo one wants to
reinitialize the Canvas - what is just the contrary of what one wants
normally as explained above. This is accomplished by this patch of
turtleDemo.py. (This patch is also already done for Python 3.0)

----------
files: turtle.diff
keywords: patch
messages: 73712
nosy: benjamin.peterson, gregorlingl, loewis
severity: normal
status: open
title: turtle.py - bug in Screen.__init__()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11591/turtle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Wed Sep 24 15:45:51 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Sep 2008 13:45:51 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222263951.41.0.504549650951.issue3956@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Do the patch of turtleDemo.py if and only if the patch of turtle.py is
accepted.

Added file: http://bugs.python.org/file11592/turtleDemo.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Wed Sep 24 16:28:03 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 14:28:03 +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: <1222266483.98.0.265085104749.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Comparing item 2 and item 3, I think that item 3 is the Pythonic choice
and item 2 is a bad idea.

Item 4: back-references in the pattern are like \1 and (?P=name), not
\g<1> or \g<name>, and in the replacement string are like \g<1> and
\g<name>, not \1 (or  (?P=name)). I'd like to suggest that
back-references in the pattern also include \g<1> and \g<name> and
\g<-1> for relative back-references. Interestingly, Perl names groups
with (?<name>...) whereas Python uses (?P<name>...). A permissible
alternative?

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:01:03 2008
From: report at bugs.python.org (David Naylor)
Date: Wed, 24 Sep 2008 15:01:03 +0000
Subject: [issue3957] [contextlib] Reverse order of locking
In-Reply-To: <1222268463.82.0.912581539287.issue3957@psf.upfronthosting.co.za>
Message-ID: <1222268463.82.0.912581539287.issue3957@psf.upfronthosting.co.za>


New submission from David Naylor <naylor.b.david at gmail.com>:

Overview:
Add a generator that will revert the order applied to a with 
statement.  

Motivation:
Often with threaded applications one needs to do a certain task 
outside of a lock but while inside a greater block of code protected 
by a lock.  

e.g:
with lock:
  BLOCK1
  lock.release()
  try:
    BLOCK2
  finally:
    lock.acquire()
  BLOCK3

but with an inverter for a with statement it becomes:

with lock:
  BLOCK1
  with invert(lock):
    BLOCK2
  BLOCK3

[Of course there are many other possible uses for this...]

Implementation:
def invert(thing):
  thing.__exit__(None, None, None)
  yield thing
  thing.__enter__()

Issues:
Normal exception handling will not take place (however for locks and 
the like this is not an issue)

----------
components: Library (Lib)
messages: 73715
nosy: DragonSA
severity: normal
status: open
title: [contextlib] Reverse order of locking
type: feature request
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3957>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:03:26 2008
From: report at bugs.python.org (David Naylor)
Date: Wed, 24 Sep 2008 15:03:26 +0000
Subject: [issue3957] [contextlib] Reverse order of locking
In-Reply-To: <1222268463.82.0.912581539287.issue3957@psf.upfronthosting.co.za>
Message-ID: <1222268606.24.0.721070699601.issue3957@psf.upfronthosting.co.za>


David Naylor <naylor.b.david at gmail.com> added the comment:

Apologies, obviously the invert function should be preceded by an 
@contextmanager to become:

@contextmanager
def invert(thing):
  thing.__exit__(None, None, None)
  yield thing
  thing.__enter__()

[Although there may be a better way of doing this, perhaps as a 
class?]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3957>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:09:29 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 15:09:29 +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: <1222268969.85.0.355275025915.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Thanks for weighing in Matthew!

Yeah, I do get some flack for item 2 because originally item 3 wasn't
supposed to cover named groups but on investigation it made sense that
it should.  I still prefer 2 over-all but the nice thing about them
being separate items is that we can accept 2 or 3 or both or neither,
and for the most part development for the first phase of 2 is complete
though there is still IMHO the issue of UNICODE name groups (visa-vi
item 14) and the name collision problem which I propose fixing with an
Attribute / re.A flag.  So, I think it may end up that we could support
both 3 by default and 2 via a flag or maybe 3 and 2 both but with 2 as
is, with name collisions hidden (i.e. if you have r'(?P<string>...)' as
your capture group, typing m.string will still give you the original
comparison string, as per the current python documentation) but have
collision-checking via the Attribute flag so that with
r'(?A)(?P<string>...)' would not compile because string is a reserved word.

Your interpretation of 4 matches mine, though, and I would definitely
suggest using Perl's \g<-n> notation for relative back-references, but
further, I was thinking, if not part of 4, part of the catch-all item 11
to add support for Perl's (?<name>...) as a synonym for Python's
(?P<name>...) and Perl's \k<name> for Python's (?P=name) notation.  The
evolution of Perl's name group is actually interesting.  Years ago,
Guido had a conversation with Larry Wall about using the (?P...) capture
sequence for python-specific Regular Expression blocks.  So Python went
ahead and implemented named capture groups.  Years later, the Perl folks
thought named capture groups were a neat idea and adapted them in the
(?<...>...) form because Python had restricted the (?P...) notation to
themselves so they couldn't use our even if they wanted to.  Now,
though, with Perl adapting (?<...>...), I think it inevitable that Java
and even C++ may see this as the defacto standard.  So I 100% agree, we
should consider supporting (?<name>...) in the parser.

Oh, and as I suggested in Issue 3825, I have these new item proposals:

Item 18: Add a re.REVERSE, re.R (?r) flag for reversing the direction of
the String Evaluation against a given Regular Expression pattern. See
issue 516762, as implemented in Issue 3825.

Item 19: Make various in-line flags positionally dependant, for example
(?i) makes the pattern before this case-sensitive but after it
case-insensitive. See Issue 433024, as implemented in Issue 3825.

Item 20: All the negation of in-line flags to cancel their effect in
conditionally flagged expressions for example (?-i). See Issue 433027,
as implemented in Issue 3825.

Item 21: Allow for scoped flagged expressions, i.e. (?i:...), where the
flag(s) is applied to the expression within the parenthesis. See Issue
433028, as implemented in Issue 3825.

Item 22: Zero-width regular expression split: when splitting via a
regular expression of Zero-length, this should return an expression
equivalent to splitting at each character boundary, with a null string
at the beginning and end representing the space before the first and
after the last character. See issue 3262.

Item 23: Character class ranges over case-insensitive matches, i.e. does
"(?i)[9-A]" contain '_' , whose ord is greater than the ord of 'A' and
less than the ord of 'a'. See issue 5311.

And I shall create a bazaar repository for your current development line
with the unfortunately unwieldy name of
lp:~timehorse/python/issue2636-01+09-02+17+18+19+20+21 as that would,
AFAICT, cover all the items you've fixed in your latest patch.

Anyway, great work Matthew and I look forward to working with you on
Regexp 2.7 as you do great work!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:17:23 2008
From: report at bugs.python.org (dominik.holler)
Date: Wed, 24 Sep 2008 15:17:23 +0000
Subject: [issue3958] strage default value behaviour
In-Reply-To: <1222269443.26.0.580926056272.issue3958@psf.upfronthosting.co.za>
Message-ID: <1222269443.26.0.580926056272.issue3958@psf.upfronthosting.co.za>


New submission from dominik.holler <dominik.holler at gmx.net>:

The behaviour is changing, if I toogle comment lines 10 + 11.


Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on
win32

----------
components: None
files: test.py
messages: 73718
nosy: dominik.holler
severity: normal
status: open
title: strage default value behaviour
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file11593/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3958>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:17:45 2008
From: report at bugs.python.org (dominik.holler)
Date: Wed, 24 Sep 2008 15:17:45 +0000
Subject: [issue3958] strage default value behaviour
In-Reply-To: <1222269443.26.0.580926056272.issue3958@psf.upfronthosting.co.za>
Message-ID: <1222269465.92.0.0422682294509.issue3958@psf.upfronthosting.co.za>


Changes by dominik.holler <dominik.holler at gmx.net>:


Added file: http://bugs.python.org/file11594/index.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3958>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:37:46 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 15:37:46 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222270666.97.0.905770967863.issue1647489@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

This also affects re.findall().

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:47:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Sep 2008 15:47:56 +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: <1222271276.95.0.3500313281.issue1856@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The threads don't have to be daemons: sys.exit() calls Py_Finalize()
without waiting for non-daemons threads.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:57:55 2008
From: report at bugs.python.org (Pernici Mario)
Date: Wed, 24 Sep 2008 15:57:55 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222271875.08.0.260151907482.issue3944@psf.upfronthosting.co.za>


Pernici Mario <pernici at users.sourceforge.net> added the comment:

Yes, I think that the speed-up is due to reducing the number of 
shifts and masks.

Changing PyLong_SHIFT to 16 would be complicated; for instance in 
v_iadd() carry could not be a digit of 16 bits anymore; writing code
specific for 64 bit machines would surely improve performance;
maybe with PyLong_SHIFT=30 few changes to the code would be needed?

I did not modify the case a = b.

I changed the documentation, which was wrong,
adding detailed bounds on carry
in the various steps to check that it does not overflow.
I corrected the wrong assertion (carry <= PyLong_MASK).

----------
keywords: +patch
Added file: http://bugs.python.org/file11595/longobject1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:58:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Sep 2008 15:58:27 +0000
Subject: [issue3958] strage default value behaviour
In-Reply-To: <1222269443.26.0.580926056272.issue3958@psf.upfronthosting.co.za>
Message-ID: <1222271907.75.0.631265896588.issue3958@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Your script is subject to the "shared default value" syndrome, explained
here:
http://www.python.org/doc/faq/general/#why-are-default-values-shared-between-objects

As indicated in the FAQ, your function could be rewritten like this:

def getElementsByAttrib(self, value, AName="ID-REF", list=None):
  if list is None:
      list = []
  ...

to have a less surprising behavior.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3958>
_______________________________________

From report at bugs.python.org  Wed Sep 24 17:48:50 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 15:48:50 +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: <1222271330.73.0.928185617085.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Regarding item 22: there's also #1647489 ("zero-length match confuses
re.finditer()").

This had me stumped for a while, but I might have a solution. I'll see
whether it'll fix item 22 too.

I wasn't planning on doing any more major changes on my branch, just
tweaking and commenting and seeing whether I've missed any tricks in the
speed stakes. Half the task is finding out what's achievable, and how!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:23:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 16:23:19 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1222273399.67.0.258215375027.issue3950@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Gregor doesn't have commit rights. Patch looks OK, would you apply it
please, Ben?

----------
assignee:  -> benjamin.peterson
nosy: +georg.brandl
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:24:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 16:24:30 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222273470.61.0.593306349067.issue3956@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks ok, like the 3.0 code. Benjamin, please review and commit.

----------
assignee:  -> benjamin.peterson
nosy: +georg.brandl
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:25:51 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 16:25:51 +0000
Subject: [issue3954] _hotshot: invalid error control in logreader()
In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>
Message-ID: <1222273551.84.0.92583893217.issue3954@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks fine. Since it is minor, why not commit it now?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3954>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:26:46 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 16:26:46 +0000
Subject: [issue3954] _hotshot: invalid error control in logreader()
In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>
Message-ID: <1222273606.79.0.66514511571.issue3954@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@georg: give me a svn access and i will commit it ;-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3954>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:29:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 16:29:11 +0000
Subject: [issue3955] maybe doctest doesn't understand unicode_literals?
In-Reply-To: <1222259902.44.0.148184723221.issue3955@psf.upfronthosting.co.za>
Message-ID: <1222273751.13.0.103708708469.issue3955@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It certainly isn't a feature. I don't immediately see how to fix it,
though. unicode_literals doesn't change the repr() of unicode objects
(it obviously can't, since that change would not be module-local).

Let's try to get a comment from Uncle Timmy...

----------
assignee:  -> tim_one
nosy: +georg.brandl, tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3955>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:30:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 16:30:10 +0000
Subject: [issue3954] _hotshot: invalid error control in logreader()
In-Reply-To: <1222250553.13.0.674938017839.issue3954@psf.upfronthosting.co.za>
Message-ID: <1222273810.7.0.166430868729.issue3954@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Regardless of the smiley, I certainly wouldn't object if you requested
permissions on python-dev...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3954>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:33:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 16:33: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: <1222274015.69.0.559648121675.issue2636@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Though I can't look at the code at this time, I just want to express how
good it feels that you both are doing these great things for regular
expressions in Python! Especially atomic grouping is something I've
often wished for when writing lexers for Pygments... Keep up the good work!

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:45:11 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 24 Sep 2008 16:45:11 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1222274711.19.0.363263423471.issue3824@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>Doesn't getgrgid() return the untranslated content of /etc/group?
>Then the encoding of this file is relevant.

Yes, /etc/group contains "??" as gr_name in MBCS,?"??" means
"nothing"?and I can print it with puts() in grpmodule.c, so it
shouldn't be translated.

>Maybe we should start considering cygwin as a posix platform with win32
>features; but I am not sure to like this idea.

Me neigher.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Wed Sep 24 18:56:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 16:56:22 +0000
Subject: [issue3428] httplib.HTTPMessage undocumented
In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za>
Message-ID: <1222275382.34.0.666540474499.issue3428@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
components: +Documentation -Documentation tools (Sphinx)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3428>
_______________________________________

From report at bugs.python.org  Wed Sep 24 19:09:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 17:09:58 +0000
Subject: [issue3875] provide a "cmem" role
In-Reply-To: <1221519147.92.0.0786016698466.issue3875@psf.upfronthosting.co.za>
Message-ID: <1222276198.89.0.631493323651.issue3875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added in r66606.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3875>
_______________________________________

From report at bugs.python.org  Wed Sep 24 19:10:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 17:10:14 +0000
Subject: [issue3875] provide a "cmem" role
In-Reply-To: <1221519147.92.0.0786016698466.issue3875@psf.upfronthosting.co.za>
Message-ID: <1222276214.47.0.159895463492.issue3875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

(It's called "cmember").

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3875>
_______________________________________

From report at bugs.python.org  Wed Sep 24 19:16:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 17:16:25 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1222276585.08.0.781015107655.issue3909@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, I can't really tell what may cause the "Too many }" error. Can you
try and play around with sphinx.sty, commenting out stuff, to find where
it comes from?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Wed Sep 24 19:30:38 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Wed, 24 Sep 2008 17:30:38 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222277438.3.0.659553640907.issue3547@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

Looks fine to me, except for the comment in the test suite.  Should

+        # MS compilers do NOT combine c_short and c_int into
+        # one field, gcc doesn't.

perhaps be

+        # MS compilers do NOT combine c_short and c_int into
+        # one field, gcc do.

?

Is using explicit tests for MSVC vs. GCC a good idea, btw?  What about 
other compilers?  Can the test be changed to accept either value?

----------
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Wed Sep 24 19:36:15 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 24 Sep 2008 17:36:15 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222277775.01.0.919360028984.issue3547@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Looks reasonable, though I'm no ctypes maven.  Trivial little nit:
In the comment just before the start of CField_FromDesc it says,
in part:

 * Expects the size, index and offset for the current field in *psize and
 * *poffset, stores the total size so far in *psize, the offset for the next

Note that it identifies three values (size, index, offset) as stored
in two locations (*psize and *poffset).  Seems like some sort of
mismatch to me.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Wed Sep 24 19:35:57 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 17:35:57 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222277757.38.0.0909957850629.issue1647489@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Wed Sep 24 19:59:57 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 17:59:57 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222279197.41.0.576879603811.issue1647489@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

What should:

    [m.groups() for m in re.finditer(r'(^z*)|(^q*)|(\w+)', 'abc')]

return? Should the second group also yield a zero-width match before the
third group is tried? I think it probably should. Does Perl?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:00:28 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 24 Sep 2008 18:00:28 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1222277438.3.0.659553640907.issue3547@psf.upfronthosting.co.za>
Message-ID: <48DA803A.4010901@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

Fredrik Lundh schrieb:
> Looks fine to me, except for the comment in the test suite.  Should
> 
> +        # MS compilers do NOT combine c_short and c_int into
> +        # one field, gcc doesn't.
> 
> perhaps be
> 
> +        # MS compilers do NOT combine c_short and c_int into
> +        # one field, gcc do.

Sure.  But isn't this correct (or better) english, instead?

                            ^^^^

> Is using explicit tests for MSVC vs. GCC a good idea, btw?  What about 
> other compilers?  Can the test be changed to accept either value?

Well, MSVC and GCC are the only compilers that I use (and that are tested
on the buildbots, afaik).  If a cygwin compiled Python, for example, fails
this test then of course the test must be changed.

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:01:32 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 24 Sep 2008 18:01:32 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1222277775.01.0.919360028984.issue3547@psf.upfronthosting.co.za>
Message-ID: <48DA807B.3000807@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

Skip Montanaro schrieb:
> Looks reasonable, though I'm no ctypes maven.  Trivial little nit:
> In the comment just before the start of CField_FromDesc it says,
> in part:
> 
>  * Expects the size, index and offset for the current field in *psize and
>  * *poffset, stores the total size so far in *psize, the offset for the next
> 
> Note that it identifies three values (size, index, offset) as stored
> in two locations (*psize and *poffset).  Seems like some sort of
> mismatch to me.

Unfortunately this is not the only comment that is out of date in the
ctypes sources.  I wanted to touch as little code as possible in this patch.

Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:02:55 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Wed, 24 Sep 2008 18:02:55 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222279375.92.0.126355012914.issue3547@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

^^^^

"Do" should be "does", right.  Not enough coffee today :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:14:28 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 18:14:28 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222280068.08.0.678182227323.issue1647489@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Hmmm.  This strikes me as a bug, beyond the realm of Issue 3262.  The
two items may be related, but the dropping of the 'a' seems like
unexpected behaviour that I doubt any current code is expecting to
occur.  Clearly, what is going on is that the Engine starts scanning at
the 'a', finds the Zero-Width match and, having found a match,
increments its pointer within the input string, thus skipping the 'a'
when it matches 'bc'.

If it is indeed a bug, I think this should be considered for inclusion
in Python 2.6 rather than being part of the new Engine Design in Issue
3626.  I think the solution would simply be to not increment the ptr
(which points to the input string) when findall / finditer encounters a
Zero-Width match.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:21:05 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 18:21:05 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222280465.83.0.657044709537.issue1647489@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Never mind inclusion in 2.6 as no-one has repeated this bug in re-world
examples yet so it's going to have to wait for the Regexp 2.7 engine in
issue 2636.

----------
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:21:23 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 24 Sep 2008 18:21:23 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222280483.68.0.694499934737.issue3951@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file11588/revert.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:22:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 24 Sep 2008 18:22:28 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222280548.42.0.831265977383.issue3951@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Sorry about that - let me retry.

Added file: http://bugs.python.org/file11596/revert.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:23:18 2008
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 24 Sep 2008 18:23:18 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1222280598.85.0.653118930621.issue1322@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Well, for what it is worth I've updated the custom "detect linux
distribution" code in Tahoe yet again.  The current version first tries
to parse /etc/lsb-version (fast, gives a good answer on Ubuntu, and
hopefully at least semi-standardized), then invokes platform.dist()
(fast, customized, but gives a bad answer on Ubuntu), and then if
platform.dist() returns an empty distribution or empty release (which
I'm not sure if that is even possible), it invokes lsb_release -a in a
subprocess (slow, totally standardized).

Here's the patch:

http://allmydata.org/trac/tahoe/changeset/2981

Running it on the Tahoe buildbot shows that we currently have the
followings kinds of buildslaves:

http://allmydata.org/buildbot/waterfall?show_events=true

Linux-Ubuntu_6.06-i686-32bit, Linux-Ubuntu_6.10-i686-32bit,
Linux-Ubuntu_7.10-i686-32bit, SunOS-5.11-i86pc-i386-32bit,
Linux-Ubuntu_7.04-i686-32bit, Linux-debian_4.0-i686-32bit,
Linux-Ubuntu_8.04-i686-32bit, Darwin-9.4.0-i386-32bit,
Linux-Ubuntu_8.04-x86_64-64bit, Windows-XP-5.1.2600-SP2,
CYGWIN_NT-5.1-1.5.25-0.156-4-2-i686-32bit-WindowsPE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:33:09 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 18:33:09 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222281189.05.0.713924310357.issue1647489@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Ah, I see the problem, if ptr is not incremented, then it will keep
matching the first expression, (^z*), so it would have to both 'skip'
the 'a' and NOT skip the 'a'.  Hmm.  You're right, Matthew, this is
pretty complicated.  Now, for your expression, Matthew,
r'(z*)|(^q*)|(\w+)', Perl gives:

"",undef,undef
undef,undef,"abc"
"",undef,undef

Meaning it doesn't even bother matching the ^q* since the ^z* matches
first.  This seems the logical behaviour and fits with the idea that a
Zero-Width match would both only match once and NOT consume any
characters.  An internal flag would just have to be created to tell the
2 find functions whether the current value of ptr would allow for a "No
Zero-Width Match" option on second go-around.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:33:11 2008
From: report at bugs.python.org (dominik.holler)
Date: Wed, 24 Sep 2008 18:33:11 +0000
Subject: [issue3958] strage default value behaviour
In-Reply-To: <1222269443.26.0.580926056272.issue3958@psf.upfronthosting.co.za>
Message-ID: <1222281191.11.0.158212731455.issue3958@psf.upfronthosting.co.za>


dominik.holler <dominik.holler at gmx.net> added the comment:

thx
sorry reporting this bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3958>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:42:15 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 24 Sep 2008 18:42:15 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222281735.29.0.58103238842.issue1706863@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>So, is my patch acceptable?

Umm, it works, but I'm not sure we can call import library as dylib...
If it's not problem, I think your patch is fine.

# I had considered attached patch "experimental_distutils.patch". It's
little adhoky, I'm not sure this patch is acceptable.

----------
components: +Distutils
Added file: http://bugs.python.org/file11597/experimental_distutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:45:14 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 24 Sep 2008 18:45:14 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1222257647.34.0.460201367742.issue3824@psf.upfronthosting.co.za>
Message-ID: <48DA89F9.8050707@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Doesn't getgrgid() return the untranslated content of /etc/group?
> Then the encoding of this file is relevant.

That certainly depends on the implementation of getgrgid. On some
systems, it uses NIS, LDAP, or a relational database in addition to
or instead of /etc/group.

I don't think POSIX specifies the charset of gr_name, except perhaps
implicitly by inheriting the notion of "execution character set" from
C, which proposes that all char* should have the same interpretation.
In POSIX, the character set comes from the locale.
The getgrid man page gives an example demonstrating that you are
supposed to be able to printf() gr_name using %s, which suggests that
it should have the locale's encoding.

In Cygwin, I have no doubt that the implementation literally copies
the encoding untranslated. I would claim this to be a bug in Cygwin.
A quality POSIX implementation would convert the /etc/group encoding
to the locale's encoding (just as it should when fetching the data
from LDAP).

> Maybe we should start considering cygwin as a posix platform with win32
> features; but I am not sure to like this idea.

If it is desired that we support this specific implementation aspect, we
can certainly special-case Cygwin in getgrgid. However, I would prefer
if this issue was discussed with the Cygwin people first, suggesting
that it might be a Cygwin bug (one that it certainly shares with many
other POSIX implementations - people just don't use non-ASCII characters
in /etc/group).

If Cygwin ever changes its implementation in that respect, we would need
to have a way for telling which specific implementation is being used.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3824>
_______________________________________

From report at bugs.python.org  Wed Sep 24 20:59:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 24 Sep 2008 18:59:15 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222282755.52.0.237846008565.issue3956@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm opposed to this patch. As a design principle, any class should
always call its base class' __init__, unless that is known to be empty.

With this patch, the base __init__ call becomes conditional, which hints
at a design bug of the entire class hierarchy.

I don't quite understand *what* the problem is. If Screen is intended to
be a singleton, then the right fix would be to make Screen a function,
which maintains a singleton reference, and Screen be renamed to _Screen.

The fact that the same design bug already exists in 3.0 doesn't mean it
should be backported to 2.6.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Wed Sep 24 21:07:32 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 24 Sep 2008 19:07:32 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222283252.06.0.324199260305.issue3956@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a follow-up, I also don't understand the two if blocks in
Screen.__init__: if there is meant to be a single Screen instance
anyway, why have _root, _canvas, and _title as class variables, whereas
everything else is in (shared) instance variables?

How could _root be initialized, and _canvas not (or vice versa)?

And why is Turtle._screen being set to the last Screen instance being
created (even under this patch), whereas all other initialization is
keyed to the creation of the first Screen instance?

This code could surely use some comments.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Wed Sep 24 21:42:21 2008
From: report at bugs.python.org (Robert Yodlowski)
Date: Wed, 24 Sep 2008 19:42:21 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222285341.93.0.204153653672.issue3943@psf.upfronthosting.co.za>


Robert Yodlowski <rbtyod at gmail.com> added the comment:

Amaury, I did as you suggested - running idle.py directly both from a
command line and by clicking on it and the results were the same. Each
time, I got the same error message window as before. In addition,
several seconds before the error window came up I got the following
traceback in the command window:

C:\Python30>python Lib/idlelib/idle.py
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python30\lib\idlelib\run.py", line 76, in main
    sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'

I hope this helps.
...Bob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Wed Sep 24 21:45:59 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 24 Sep 2008 19:45:59 +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: <1222285558.49.0.700245534736.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Good catch on issue 1647489 Matthew; it looks like this is where that
bug fix will end up going.  But, I am unsure if the solution for this
issue is going to be the same as for 3262.  I think the solution here is
to add an internal flag that will keep track of whether the current
character had previously participated in a Zero-Width match and thus not
allow any subsequent zero-width matches associated beyond the first, and
at the same time not consuming any characters in a Zero-width match.

Thus, I have allocated this fix as Item 24, but it may be later merged
with 22 if the solutions turn out to be more or less the same, likely
via a 22+24 thread.  The main difference, though, as I see it, is that
the change in 24 may be considered a bug where the general consensus of
22 is that it is more of a feature request and given Guido's acceptance
of a flag-based approach, I suggest we allocate re.ZEROWIDTH, re.Z and
(?z) flags to turn on the behaviour you and I expect, but still think
that be best as a 2.7 / 3.1 solution.  I would also like to add a from
__futurue__ import ZeroWidthRegularExpressions or some such to make this
the default behaviour so that by version 3.2 it may indeed be considered
the default.

Anyway, I've allocated all the new items in the launchpad repository so
feel free to go to http://www.bazaar-vcs.org/ and install Bazaar for
windows so you can download any of the individual item development
threads and try them out for yourself.  Also, please consider setting up
a free launchpad account of your very own so that I can perhaps create a
group that would allow us to better share development.

Thanks again Matthew for all your greatly appreciated contributions!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Sep 24 22:52:30 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 24 Sep 2008 20:52:30 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1222289550.1.0.338297748838.issue3781@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The 3.0 forward port of r66386 still needs a once over before being
committed (there were enough differences that I don't think the review
of the 2.6 version is enough to cover the 3.0 version as well).

Once that is done, then this issue can be closed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Wed Sep 24 22:58:00 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Sep 2008 20:58:00 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222289880.6.0.343243100015.issue1706863@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

About experimental_distutils.patch - extra changes that has to go in a
specific compiler class. As example platform can be any but compiler
gcc(mingw) that produce executables for windows host platform. In this
case search has to include suffix .dll.a.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Wed Sep 24 23:14:14 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 21:14:14 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222290854.17.0.901142226175.issue1647489@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

What about r'(^z*)|(q*)|(\w+)'? I could imagine that the first group
could match only at the start of the string, but if the second group
doesn't have that restriction then it could match the second time, and
only after that could the third match, if you see what I mean. (The
previous example had (^q*) so it couldn't match because the first group
has already matched at the start of the string and we've already
advanced beyond that, even though by no characters!)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Thu Sep 25 00:07:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Sep 2008 22:07:54 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222294074.27.0.417978908793.issue3951@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Looks good to me.

----------
keywords:  -needs review
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Thu Sep 25 00:13:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Sep 2008 22:13:58 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1222294438.46.0.915813562934.issue3950@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Done in r66614.

Georg, according to http://python.org/dev/committers and r64063, Gregor
does have commit access.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Thu Sep 25 00:14:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Sep 2008 22:14:40 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1222294480.91.0.338823772271.issue3950@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

My apologies then.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Thu Sep 25 00:15:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Sep 2008 22:15:55 +0000
Subject: [issue3957] [contextlib] Reverse order of locking
In-Reply-To: <1222268463.82.0.912581539287.issue3957@psf.upfronthosting.co.za>
Message-ID: <1222294555.22.0.651418084508.issue3957@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This doesn't sound like such a good idea. In the example you gave, it is
trivial and easier to use two separate with statements than three!

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3957>
_______________________________________

From report at bugs.python.org  Thu Sep 25 00:54:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Sep 2008 22:54:37 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1222296877.49.0.937550369625.issue3886@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Got 3.0 in r66615. Somebody should really test it, though.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Thu Sep 25 01:14:10 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 24 Sep 2008 23:14:10 +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: <1222298050.73.0.172554962966.issue3959@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Google just released ipaddr.py, a module that knows how to manipulate IP
addresses (both IPv4 and IPv6).

I have nothing to do with this module, but I suggest considering it for
inclusion in the standard library.

It fills a gap for address manipulations that will become more important
to fill as IPv6 becomes more widespread.

----------
messages: 73761
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Add Google's ipaddr.py to the stdlib
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 01:15:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Sep 2008 23:15:41 +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: <1222298141.15.0.818882658349.issue3959@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Where can we find this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 01:15:58 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 24 Sep 2008 23:15:58 +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: <1222298158.87.0.212090619833.issue3959@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

It would help if I added a link to the Google release:

http://code.google.com/p/ipaddr-py/

Description:

"

An IPv4/IPv6 manipulation library in Python.

This library is used to create/poke/manipulate IPv4 and IPv6 addresses
and prefixes.

"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 01:16:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Sep 2008 23:16:48 +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: <1222298208.56.0.904235425617.issue3959@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Almost time machine. :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 01:34:12 2008
From: report at bugs.python.org (Matthew Smart)
Date: Wed, 24 Sep 2008 23:34:12 +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: <1222299252.26.0.162583325627.issue3959@psf.upfronthosting.co.za>


Changes by Matthew Smart <mattsmart at gmail.com>:


----------
nosy: +mattsmart

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 01:34:20 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Sep 2008 23:34:20 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222299260.46.0.203229046821.issue1647489@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

FYI, I posted msg73737 after finding that the fix for the original case
was really very simple, but then thought about whether it would behave
as expected when there were more zero-width matches, hence the later posts.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Thu Sep 25 01:43:41 2008
From: report at bugs.python.org (Michael Shields)
Date: Wed, 24 Sep 2008 23:43:41 +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: <1222299821.86.0.537625147722.issue3959@psf.upfronthosting.co.za>


Changes by Michael Shields <shields at msrl.com>:


----------
nosy: +shields

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 02:06:33 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 00:06:33 +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: <1222301193.93.0.635305677622.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

I've moved all the development branches to the ~pythonregexp2.7 team so 
that we can work collaboratively.  You just need to install Bazaar, join 
www.launchpad.net, upload your public SSH key and then request to be added 
to the pythonregexp2.7 team.  At that point, you can check out any code 
via:

bzr co lp:~pythonregexp2.7/python/issue2636-*

This should make co-operative development easier.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 02:29:18 2008
From: report at bugs.python.org (pmoody)
Date: Thu, 25 Sep 2008 00:29: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: <1222302558.6.0.199902021582.issue3959@psf.upfronthosting.co.za>


Changes by pmoody <python at hda3.com>:


----------
nosy: +pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 03:37:14 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Thu, 25 Sep 2008 01:37:14 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1222306634.92.0.36706635934.issue3826@psf.upfronthosting.co.za>


Changes by Rafael Zanella <rafael.zanella at yahoo.com.br>:


----------
nosy: +zanella

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Thu Sep 25 04:15:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 25 Sep 2008 02:15:46 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222308946.8.0.446806445837.issue3936@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

You're right; I should put it within the started block. Actually, no
import cases are currently handled by the warning to avoid conflicting
with "import foo as bar". This isn't really an issue, though because
using the module name "as.attribute" will give a warning.

If we were going to do this again, I would implement the warning in AST
generation, but it's far too late for that.

Added file: http://bugs.python.org/file11598/after_review.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Thu Sep 25 06:07:32 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 25 Sep 2008 04:07:32 +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: <1222315652.14.0.446266803484.issue3959@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see a list of owners in the code (although it's difficult to infer
real names or email addresses from that list). I think we should not
include the code without their explicit approval.

The question will then always be: what is the official master copy of
the code? The one in Python, or the one on Google code? Whose
responsibility would it be to keep those synchronized, and incorporate
changes from one copy into the other?

I would prefer if the copy in Python (say, 2.7) becomes the master copy,
and the copy on Google code eventually disappears (when interest in
older Python versions has died).

I would object to a mere fork of the code (i.e. where one of the regular
Python committers incorporates, from time to time, the changes that
Google made)

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 06:16:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 25 Sep 2008 04:16:01 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222316161.01.0.826641001615.issue3951@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed as r66616 and r66617

----------
assignee: loewis -> 
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Thu Sep 25 07:53:59 2008
From: report at bugs.python.org (pmoody)
Date: Thu, 25 Sep 2008 05:53:59 +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: <1222322039.96.0.056580921671.issue3959@psf.upfronthosting.co.za>


pmoody <python at hda3.com> added the comment:

as one of the owners listed in the code.google.com project (same name),
and the original author, you certainly have my approval for inclusion in
python.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 09:08:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 07:08:39 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222326519.74.0.168850766055.issue3943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did you *really* follow the suggested change proposed in #3905 ?
http://bugs.python.org/msg73496

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Thu Sep 25 09:46:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 07:46:23 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222328783.01.0.0832908072707.issue3936@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Patch is good to me.

Actually 2.5 is not in "Release Candidate" stage, do we really need
formal review?

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Thu Sep 25 10:44:33 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 25 Sep 2008 08:44:33 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222332273.45.0.354075177502.issue3944@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the updated patch!  Looks good, on a quick scan.

(One comment typo I noticed: there's a line
BASE - 3 = 2*MASK - 1
presumably this should be 2*BASE - 3 on the LHS.)

Just out of interest, is it possible to go further, and combine 4
partial multiplications at once instead of 2?  Or does the extra
bookkeeping involved make it not worth it?

I think it's important to make sure that any changes to longobject.c
don't slow down operations on small integers (where "small" means "less
than 2**32") noticeably.

Re: possible changes to PyLong_SHIFT

Yes, changing PyLong_SHIFT to 16 (or 32) would be complicated, and would
involve almost a complete rewrite of longobject.c, together with much
else...  It wasn't really a serious suggestion, but it probably would
provide a speedup.  The code in GMP gives some idea how things might work.

Changing PyLong_SHIFT to 30 doesn't seem like a totally ridiculous idea,
though.  One problem is that there's no 64-bit integer type (for
twodigits) in *standard* C89;  so since Python is only allowed to assume
C89 there would have to be some fallback code for those (very few,
surely) platforms that didn't have a 64-bit integer type available.

On 64-bit machines one could presumably go further, and have
PyLong_SHIFT be 60 (or 62, or 63 --- but those break the assumption
in long_pow that the PyLong_SHIFT is a multiple of 5).  This would
depend on the compiler providing a 128-bit type for twodigits (like
__uint128_t on gcc/x86-64).  Probably not worth it, especially if it
ends up slowing down operations on everyday small integers.

Any of these changes is also going to affect a good few other parts of
the codebase (e.g. marshal, pickle?, struct?, floatobject.c, ...).  It
shouldn't be difficult to find most of the files affected (just look to
see which files include longintrepr.h), but I have a suspicion there are
a couple of other places that just assume PyLong_SHIFT is 15).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Thu Sep 25 11:39:51 2008
From: report at bugs.python.org (romkyns)
Date: Thu, 25 Sep 2008 09:39:51 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1222335591.18.0.90121313084.issue3826@psf.upfronthosting.co.za>


romkyns <ws.python at starkov.name> added the comment:

So the GC behaviour in this case is such that Python 3.0 can't collect
the object whereas Python 2.6 can. Is this known / expected or should
this be recorded in a separate issue?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Thu Sep 25 12:50:14 2008
From: report at bugs.python.org (Erno Kuusela)
Date: Thu, 25 Sep 2008 10:50:14 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1222339814.01.0.290403724908.issue3783@psf.upfronthosting.co.za>


Erno Kuusela <erno+pybugs at iki.fi> added the comment:

I'm looking for a bsddb-shelve replacement (because of we bsddb
corruption problems), and decided to give this a try. Don't overlook
the free locking you get from sqlite when evaluating this for inclusion!

A small bug:

>>> from sq_dict import shelve
>>> shelve('zz', 'c')[42] = 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "sq_dict.py", line 144, in __setitem__
    key = self._check_key(key)
  File "sq_dict.py", line 287, in _check_key
    (", ".join(i.__name__ for i in self._allowed_keys), type(key)))
NameError: global name 'self' is not defined

----------
nosy: +erno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 25 13:39:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Sep 2008 11:39:43 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>
Message-ID: <1222342783.9.0.316319517411.issue3946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The test would be better in test_memoryview rather than in test_builtin.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Thu Sep 25 13:51:42 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 11:51:42 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1222343502.14.0.299847177005.issue3826@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The garbage collector does collect unreachable objects.

What happens is that with python 2, the socket is explicitly closed by
the HTTPServer, whereas with python 3, the explicit close() does not
work, and the socket is ultimately closed when the request has finished
and all objects are disposed.

The cause is in the socket.makefile() function: since python3, the
underlying socket uses a reference count, so that:
    s = <a connected socket>
    f = s.makefile()
    s.close()
does not close the socket! adding f.close() is not enough. A "del f" is
necessary to really close the underlying socket.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Thu Sep 25 13:52:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 25 Sep 2008 11:52:39 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222328783.01.0.0832908072707.issue3936@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809250452i4a869c2ap2b4aaff12ab2e228@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Thu, Sep 25, 2008 at 2:46 AM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Patch is good to me.
>
> Actually 2.5 is not in "Release Candidate" stage, do we really need
> formal review?

Well, it certainly can't hurt. :)
>
> ----------
> keywords:  -needs review
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3936>
> _______________________________________
>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Thu Sep 25 13:52:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 25 Sep 2008 11:52:56 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222343576.32.0.926561009544.issue3936@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Thu Sep 25 13:56:40 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Sep 2008 11:56:40 +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: <1222343800.96.0.194838732179.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Just out of interest, is there any plan to include #1160 while we're at it?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 13:57:55 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 11:57:55 +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: <1222343875.47.0.822776103888.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

I've enumerated the current list of Item Numbers at the official
Launchpad page for this issue:

https://launchpad.net/~pythonregexp2.7

There you will find links to each development branch associated with
each item, where a broader description of each issue may be found.

I will no longer enumerate the entire list here as it has grown too long
to keep repeating; please consult that web page for the most up-to-date
list of items we will try to tackle in the Python Regexp 2.7 update.

Also, anyone wanting to join the development team who already has a
Launchpad account can just go to the Python Regexp 2.7 web site above
and request to join.  You will need Bazaar to check out, pull or branch
code from the repository, which is available at www.bazaar-vcs.org.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:01:57 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 12:01:57 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1222344117.82.0.288422993433.issue1160@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:19:02 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 12:19:02 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1222345142.41.0.615630232371.issue1160@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

It seems that changing the size type of the Regular Expression Byte-code
is a nice quick-fix, even though it doubles the size of a pattern.  It
may have the added benefit that most machine architectures available
today are at least partially, if not fully, 32-bit oriented so that
retrieving op codes may in fact be faster if we make this change.  OTOH,
it implies something interesting IMHO with the repeat count limits we
currently have.  Repeat counts can be explicitly set up to 65534 times
because 65535, being the largest number you can express in a 16-bit
unsigned integer, is currently reserved to mean Infinite.  It seems to
me this is a great opportunity to set that limit to (unsigned long)-1,
since that repeat count is incredibly large.

OTOH, if size is an issue, we could change the way sizes are expressed
in the Regexp Op Codes (typically in skip counts) to be 15-bit, with the
Most Significant Bit being reserved for 'extended' expressions.  In this
way, a value of 0xFFFFFFFF could be expressed as:

0xFFFF 0xFFFF 0x0003

Of course, parsing number in this form is a pain, to say the least, and
unlike in Python, the C-library would not play nicely if someone tried
to express a number that could not fit into what the architecture
defined an int to be.  Plus, there is the problem of how you express
Infinite with this scheme.  The advantage though would be we don't have
to change the op-code size and these 'extended' counts would be very
rare indeed.

Over all, I'm more of an Occam's Razor fan in that the simplest solution
is probably the best: just change the op-code size to unsigned long
(which, on SOME architectures would actually make it 64-bits!) and
define the 'Infinite' constant as (unsigned long)-1.  Mind you, I prefer
defining the constant in Python, not C, and it would be hard for Python
to determine that particular value being that Python is meant to be 'the
same' regardless of the underlying architecture, but that's another issue.

Anyway, as 2.6 is in Beta, this will have to wait for Python 2.7 / 3.1,
and so I will add an item to Issue 2636 with respect to it.

----------
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:23:26 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 12:23:26 +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: <1222345406.89.0.995799467191.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Good catch, Matthew, and if you spot any other outstanding Regular
Expression issues feel free to mention them here.

I'll give issue 1160 an item number of 25 and think all we need to do
here is change SRE_CODE to be typedefed to an unsigned long and change
the repeat count constants (which would be easier if we assume item 10:
shared constants).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:28:43 2008
From: report at bugs.python.org (djc)
Date: Thu, 25 Sep 2008 12:28:43 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222345723.6.0.339507210336.issue3723@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:41:48 2008
From: report at bugs.python.org (Ronny Haryanto)
Date: Thu, 25 Sep 2008 12:41:48 +0000
Subject: [issue3960] Section permalink html anchors are wrong
In-Reply-To: <1222346508.67.0.745864435926.issue3960@psf.upfronthosting.co.za>
Message-ID: <1222346508.67.0.745864435926.issue3960@psf.upfronthosting.co.za>


New submission from Ronny Haryanto <ronny at haryan.to>:

With sphinx svn version 66617, generated html docs have invalid html 
anchors: <a class="headerlink" href="#blah"> instead of <a 
class="headerlink" name="blah">.

Affected file: sphinx/htmlwriter.py, lines 71 and 373.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 73783
nosy: georg.brandl, ronny
severity: normal
status: open
title: Section permalink html anchors are wrong
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3960>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:44:55 2008
From: report at bugs.python.org (Ronny Haryanto)
Date: Thu, 25 Sep 2008 12:44:55 +0000
Subject: [issue3960] Section permalink html anchors are wrong
In-Reply-To: <1222346508.67.0.745864435926.issue3960@psf.upfronthosting.co.za>
Message-ID: <1222346695.61.0.366378619247.issue3960@psf.upfronthosting.co.za>


Ronny Haryanto <ronny at haryan.to> added the comment:

Sorry, forgot to mention that this happened to the generated Django html 
documentations (django svn r9084), if it makes any difference.

After fixing the two lines (as I mentioned), all named link works again.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3960>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:54:10 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Thu, 25 Sep 2008 12:54:10 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1222347250.42.0.509772476322.issue3892@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Oracle guys are studying this issue. I will keep you informed.

This issue is not a release blocker, in any case. See rational in msg73370.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Thu Sep 25 14:56:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 25 Sep 2008 12:56:05 +0000
Subject: [issue3960] Section permalink html anchors are wrong
In-Reply-To: <1222346508.67.0.745864435926.issue3960@psf.upfronthosting.co.za>
Message-ID: <1222347365.84.0.43283754809.issue3960@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Actually this is all right. The generated HTML looks like this:
<span id="blah"></span><h3>Blah<a class="headerlink" href="#blah"
title="Permalink to this headline">?</a></h3>

So the id is in the span tag, not the a tag. The link generated for the
? is a convenience so that you can right-click and say "copy link
location" if you want to have a URL pointing to that heading.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3960>
_______________________________________

From report at bugs.python.org  Thu Sep 25 15:04:50 2008
From: report at bugs.python.org (Jason Tishler)
Date: Thu, 25 Sep 2008 13:04:50 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222347890.3.0.814160607054.issue1706863@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

Hirokazu Yamamoto wrote:
> Umm, it works, but I'm not sure we can call import library as
> dylib...

Agreed.

> I had considered attached patch "experimental_distutils.patch".
> It's little adhoky, I'm not sure this patch is acceptable.

The new functionality is very similar to what I suggested in 
issue2445. Although it would be better to put Cygwin specific behavior 
in CygwinCCompiler, I think the changes would have be more invasive if 
you did.

I prefer your approach to mine. Can we get consensus and move forward?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Thu Sep 25 15:06:51 2008
From: report at bugs.python.org (Richard)
Date: Thu, 25 Sep 2008 13:06:51 +0000
Subject: [issue3961] Arrows key do not browse in the IDLE
In-Reply-To: <1222348011.21.0.891596482298.issue3961@psf.upfronthosting.co.za>
Message-ID: <1222348011.21.0.891596482298.issue3961@psf.upfronthosting.co.za>


New submission from Richard <poggi.ricky at hotmail.it>:

I open python3.0 (rc1) IDLE from command line and it works fine, but
when i press the arrows key they writes: ^[[A ^[[B ^[[C ^[[D
also pagUP and pagDOWN writes: ^[[5~ ^[[6~
so I'm not able to browse the history and the all things with arrows key.

More Info:

my OS is Ubuntu 8.04 upgrade from 7.10

It's the first time that I have an issue with keyboard

I have look for my international settings of keyboard but I don't note
nothing of relevant. (my country is Italy-Europe)

I have installed as main python 2.5 with I have no problem (works perfect)

I made a standard alt-installation
./configure
make
make test   # 1error with urllib2 and some skip (see attach txt)
sudo make altinstall

I have no other kind of problems with python3.0rc1

Is there someone has an idea??

 -- Richard (excuse my English)

----------
components: IDLE
files: maketestpython30_log.txt
messages: 73788
nosy: italian-boy
severity: normal
status: open
title: Arrows key do not browse in the IDLE
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11599/maketestpython30_log.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3961>
_______________________________________

From report at bugs.python.org  Thu Sep 25 15:08:17 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 13:08:17 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222348097.51.0.94697607419.issue1647489@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Perl gives this result for your new expression:

"",undef,undef
undef,undef,"abc"
undef,"",undef

I think it has to do with not thinking of a string as a sequence of
characters, but as a sequence of characters separated by null-space. 
Null-space is can be captured, but ONLY if it is part of a zero-width
match, and once captured, it can no longer be captured by another
zero-width expression.  This is in keeping which what I see as Perl's
behaviour, namely that the (q*) group never participates in the first
match because, initially the (^z*) captures it.  OTOH, when it gets to
the null-space AFTER the 'abc' capture, the (^z*) cannot participate
because it has a "at-beginning" restriction.  The evaluator then moves
on to the (q*), which has no such restriction and this time it matches,
consuming the final null-space.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Thu Sep 25 15:35:49 2008
From: report at bugs.python.org (Chris)
Date: Thu, 25 Sep 2008 13:35:49 +0000
Subject: [issue3962] single architecture framework build fails on OS X 10.5
In-Reply-To: <1222349749.71.0.779692324968.issue3962@psf.upfronthosting.co.za>
Message-ID: <1222349749.71.0.779692324968.issue3962@psf.upfronthosting.co.za>


New submission from Chris <christopher.e.kees at usace.army.mil>:

Hi,

Our group ended  up needing a non-universal x86_64 framework build 
because we had  trouble building some modules with the non-framework 
build. We had  to modify the makefile in two places to get it to work. 
First we fixed a place where configure generates '-arch_only i386'. That 
fixes the the build phase. Then we got rid of some install targets that  
were trying to pull  in Carbon code. 

The first problem seems like it could easily be fixed by somebody who 
understands the configure script. 

I'm not sure what's going on with the second problem. Is --disable-
toolbox-glue not being handled  correctly when the install target is 
generated? It seems like the build phase is skipping the Carbon 
dependent extension modules correctly but install is trying to pull in 
modules that  depend on those disabled modules. FYI, here's what  were 
doing:

./configure --prefix=${HOME} --with-cxx-main='/usr/bin/mpicxx -arch 
x86_64'\  --enable-framework=${HOME} --disable-toolbox-glue 
CC='/usr/bin/mpicc -arch \ x86_64' CXX='/usr/bin/mpicxx -arch x86_64' 
LDFLAGS='-framework Accelerate \ -arch x86_64'

Edit Makefile to replace  -arch_only i386 with -arch_only x86_64 and 
remove frameworkinstallmaclib and frameworkinstallapps from the 
altinstall: target.
 
diff Makefile Makefile~
457c457
<              -lSystem -lSystemStubs -arch_only x86_64 -install_name 
$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK) -
compatibility_version $(VERSION) -current_version $(VERSION) ;\
---
>              -lSystem -lSystemStubs -arch_only i386 -install_name 
$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK) -
compatibility_version $(VERSION) -current_version $(VERSION) ;\
741c741
<                 sharedinstall oldsharedinstall 
frameworkaltinstallunixtools
---
>                 sharedinstall oldsharedinstall frameworkinstallmaclib 
frameworkinstallapps frameworkaltinstallunixtools

Here is the svn info
Path: .
URL: http://svn.python.org/projects/python/trunk
Repository Root: http://svn.python.org/projects
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 66613
Node Kind: directory
Schedule: normal
Last Changed Author: thomas.heller
Last Changed Rev: 66611
Last Changed Date: 2008-09-24 13:26:05 -0500 (Wed, 24 Sep 2008)

----------
components: Macintosh
messages: 73790
nosy: cekees
severity: normal
status: open
title: single architecture framework build fails on OS X 10.5
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3962>
_______________________________________

From report at bugs.python.org  Thu Sep 25 15:43:29 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Sep 2008 13:43:29 +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: <1222350209.25.0.506826297577.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

For reference, these are all the regex-related issues that I've found
(including this one!):

id       : activity : title
#2636    : 25/09/08 : Regexp 2.7 (modifications to current re 2.2.2)
#1160    : 25/09/08 : Medium size regexp crashes python
#1647489 : 24/09/08 : zero-length match confuses re.finditer()
#3511    : 24/09/08 : Incorrect charset range handling with ignore case
flag?
#3825    : 24/09/08 : Major reworking of Python 2.5.2 re module
#433028  : 24/09/08 : SRE: (?flag:...) is not supported
#433027  : 24/09/08 : SRE: (?-flag) is not supported.
#433024  : 24/09/08 : SRE: (?flag) isn't properly scoped
#3262    : 22/09/08 : re.split doesn't split with zero-width regex
#3299    : 17/09/08 : invalid object destruction in re.finditer()
#3665    : 24/08/08 : Support \u and \U escapes in regexes
#3482    : 15/08/08 : re.split, re.sub and re.subn should support flags
#1519638 : 11/07/08 : Unmatched Group issue - workaround
#1662581 : 09/07/08 : the re module can perform poorly: O(2**n) versus
O(n**2)
#3255    : 02/07/08 : [proposal] alternative for re.sub
#2650    : 28/06/08 : re.escape should not escape underscore
#433030  : 17/06/08 : SRE: Atomic Grouping (?>...) is not supported
#1721518 : 24/04/08 : Small case which hangs
#1693050 : 24/04/08 : \w not helpful for non-Roman scripts
#2537    : 24/04/08 : re.compile(r'((x|y+)*)*') should fail
#1633953 : 23/02/08 : re.compile("(.*$){1,4}", re.MULTILINE) fails
#1282    : 06/01/08 : re module needs to support bytes / memoryview well
#814253  : 11/09/07 : Grouprefs in lookbehind assertions
#214033  : 10/09/07 : re incompatibility in sre
#1708652 : 01/05/07 : Exact matching
#694374  : 28/06/03 : Recursive regular expressions
#433029  : 14/06/01 : SRE: posix classes aren't supported

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 15:56:57 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Sep 2008 13:56:57 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222351017.54.0.853240864364.issue1647489@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I have to report that the fix appears to be successful:

>>> print [m.groups() for m in re.finditer(r'(^z*)|(\w+)', 'abc')]
[('', None), (None, 'abc')]
>>> print re.findall(r"(^z*)|(\w+)", "abc")
[('', ''), ('', 'abc')]
>>> print [m.groups() for m in re.finditer(r"(^z*)|(q*)|(\w+)", "abc")]
[('', None, None), (None, None, 'abc'), (None, '', None)]
>>> print re.findall(r"(^z*)|(q*)|(\w+)", "abc")
[('', '', ''), ('', '', 'abc'), ('', '', '')]

The patch is regex_2.6rc2+7.diff.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Thu Sep 25 16:08:26 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 25 Sep 2008 14:08:26 +0000
Subject: [issue3959] Add Google's ipaddr.py to the stdlib
In-Reply-To: <1222315652.14.0.446266803484.issue3959@psf.upfronthosting.co.za>
Message-ID: <ca471dc20809250705k6fba3d88gecc617afb2b3af67@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Wed, Sep 24, 2008 at 9:07 PM, Martin v. L?wis <report at bugs.python.org> wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> I see a list of owners in the code (although it's difficult to infer
> real names or email addresses from that list). I think we should not
> include the code without their explicit approval.

I know they *want* this to happen, no worries on this front.

> The question will then always be: what is the official master copy of
> the code? The one in Python, or the one on Google code? Whose
> responsibility would it be to keep those synchronized, and incorporate
> changes from one copy into the other?
>
> I would prefer if the copy in Python (say, 2.7) becomes the master copy,
> and the copy on Google code eventually disappears (when interest in
> older Python versions has died).

I'm in favor of this, and I believe the authors at Google are too --
it was written out of necessity, and once integrated, the need for a
separate Google copy will go away.

> I would object to a mere fork of the code (i.e. where one of the regular
> Python committers incorporates, from time to time, the changes that
> Google made)

Agreed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Thu Sep 25 16:18:09 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 14:18: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: <1222352289.9.0.522218272478.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Hmmm.  Well, some of those are already covered:

#2636    : self
#1160    : Item 25
#1647489 : Item 24
#3511    : Item 23
#3825    : Item 9-2
#433028  : Item 21
#433027  : Item 20
#433024  : Item 19
#3262    : Item 22
#3299    : TBD
#3665    : TBD
#3482    : TBD
#1519638 : TBD
#1662581 : TBD
#3255    : TBD
#2650    : TBD
#433030  : Item 1
#1721518 : TBD
#1693050 : TBD
#2537    : TBD
#1633953 : TBD
#1282    : TBD
#814253  : TBD (but I think you implemented this, didn't you Matthew?)
#214033  : TBD
#1708652 : TBD
#694374  : TBD
#433029  : Item 8

I'll have to get nosy and go over the rest of these to see if any of
them have already been solved, like the duplicate test case issue from a
while ago, but someone forgot to close them.  I'm thinking specifically
the '\u' escape sequence one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 17:10:21 2008
From: report at bugs.python.org (Erik Sandberg)
Date: Thu, 25 Sep 2008 15:10:21 +0000
Subject: [issue3963] Problems when calling exec from a function
In-Reply-To: <1222355421.74.0.537715062608.issue3963@psf.upfronthosting.co.za>
Message-ID: <1222355421.74.0.537715062608.issue3963@psf.upfronthosting.co.za>


New submission from Erik Sandberg <sandberg at virtutech.com>:

When an exec statement called from a function f defines a top-level
function g, the body of g cannot access the top-level symbols defined by
the exec statement (which also happen to be the local variables of f).
Example:

x = 2
def f():
    exec "x = 1\ndef b(): return x"
    print b()
f()

An unqualified guess is that the mix of being top-level and being a
local variable, makes the symbol end up somewhere between locals() and
globals(). Example:

The problem causes real-life problems when I want to create a wrapper
function around execfile() to handle certain exceptions.

----------
components: Interpreter Core
messages: 73795
nosy: sandberg
severity: normal
status: open
title: Problems when calling exec from a function
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3963>
_______________________________________

From report at bugs.python.org  Thu Sep 25 17:30:48 2008
From: report at bugs.python.org (=?utf-8?q?Christian_H=C3=B6ltje?=)
Date: Thu, 25 Sep 2008 15:30:48 +0000
Subject: [issue3964] quiet the freeze makefile
In-Reply-To: <1222356648.66.0.370920569039.issue3964@psf.upfronthosting.co.za>
Message-ID: <1222356648.66.0.370920569039.issue3964@psf.upfronthosting.co.za>


New submission from Christian H?ltje <docwhat at gerf.org>:

The make process for building a freeze'd python script is a little
noisy.  This patch makes quieter unless someone adds "VERBOSE=1" to the
make invocation.

----------
components: Demos and Tools
files: freeze.quiet.patch
keywords: patch
messages: 73796
nosy: docwhat
severity: normal
status: open
title: quiet the freeze makefile
type: feature request
Added file: http://bugs.python.org/file11600/freeze.quiet.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3964>
_______________________________________

From report at bugs.python.org  Thu Sep 25 17:56:21 2008
From: report at bugs.python.org (Geoff Gilmour-Taylor)
Date: Thu, 25 Sep 2008 15:56:21 +0000
Subject: [issue3965] 2.6rc2 crashes when trying to open unicode filename with
	unprintables
In-Reply-To: <1222358181.85.0.131055408857.issue3965@psf.upfronthosting.co.za>
Message-ID: <1222358181.85.0.131055408857.issue3965@psf.upfronthosting.co.za>


New submission from Geoff Gilmour-Taylor <geoff.gilmour-taylor at cnib.ca>:

In 2.6rc2, when I try to open a file with a unicode filename with a tab
in it, Python crashes on Win2000 and WinXP.  Bytestrings raise an
IOError as expected.  I'm using the Windows ia32 binaries.

C:\>c:\python26\python
Python 2.6rc2 (r26rc2:66507, Sep 18 2008, 14:27:33) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('c:\temp\temp.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: invalid filename: c:   emp     emp.txt or mode: r
>>> f = open(u'c:\temp\temp.txt')
[[Crash happens here.]]
C:\>

I also get crashes for other unprintables \a \b \f \n \r \v \x03 and so on.

I'm not getting this on 2.5.2 or 3.0rc1.

----------
components: Windows
files: unicodecoredump.txt
messages: 73797
nosy: giltay
severity: normal
status: open
title: 2.6rc2 crashes when trying to open unicode filename with unprintables
versions: Python 2.6
Added file: http://bugs.python.org/file11601/unicodecoredump.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3965>
_______________________________________

From report at bugs.python.org  Thu Sep 25 17:57:46 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Sep 2008 15:57:46 +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: <1222358266.43.0.681072634065.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

#814253 is part of the fix for variable-width lookbehind.

BTW, I've just tried a second time to register with Launchpad, but still
no reply. :-(

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 18:10:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 16:10:52 +0000
Subject: [issue3963] Problems when calling exec from a function
In-Reply-To: <1222355421.74.0.537715062608.issue3963@psf.upfronthosting.co.za>
Message-ID: <1222359052.66.0.732773364867.issue3963@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Right. Nested scopes only work for statically compiled code; inside an
'exec' block, non-local variables are global.

In your case, I suggest to specify the context in which the code has to
execute:

x = 2
def f():
    g = globals().copy()
    exec "x = 1\ndef b(): return x" in g
    print eval("b()", g)

This prints 1, as you want it, and can still access names defined
outside the f() function. And this gives you more control on the symbols
available to the executed code.
Python does something very similar when it loads a module.

I don't think that this behaviour can ever change. Tentatively closing
as "won't fix".

----------
nosy: +amaury.forgeotdarc
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3963>
_______________________________________

From report at bugs.python.org  Thu Sep 25 18:26:05 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 25 Sep 2008 16:26:05 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1222359965.53.0.590261010778.issue3783@psf.upfronthosting.co.za>


Changes by Josiah Carlson <josiahcarlson at users.sourceforge.net>:


Removed file: http://bugs.python.org/file11472/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 25 18:27:39 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 25 Sep 2008 16:27:39 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1222360059.05.0.714035457797.issue3783@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Thank you for the report (fixed in the newly attached version) :) .

Added file: http://bugs.python.org/file11602/sq_dict.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Thu Sep 25 18:32:50 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 16:32:50 +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: <1222360370.44.0.0949660112255.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Yes, I see in you rc2+2 diff it was added into that.  I will have to
allocate a new number for that fix though, as technically it's a
different feature than variable-length look-behind.

For now I'm having a hard time merging your diffs in with my code base.
 Lots and lots of conflicts, alas.

BTW, what UID did you try to register under at Launchpad?  Maybe I can
see if it's registered but just forgetting to send you e-mail.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 18:50:11 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 25 Sep 2008 16:50:11 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222361411.87.0.361924671217.issue3547@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

test_mixed_4 fail on:
Python 2.6rc2+ (trunk:66617M, Sep 25 2008, 16:32:44) 
[GCC 3.4.5 (mingw special)] on win32
Type "help", "copyright", "credits" or "license" for more information.

sizeof(X) return 12.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Thu Sep 25 19:01:12 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Sep 2008 17:01:12 +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: <1222362072.15.0.0292377088333.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Tried bazaar at mrabarnett.plus.com twice, no reply. Succeeded with
mrabarnett at freeuk.com.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 19:26:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 17:26:47 +0000
Subject: [issue3965] 2.6rc2 crashes when trying to open unicode filename with
	unprintables
In-Reply-To: <1222358181.85.0.131055408857.issue3965@psf.upfronthosting.co.za>
Message-ID: <1222363607.81.0.103317669585.issue3965@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Confirmed here. This also happens on Windows when the mode is invalid:
    open(u"foobar", "rr")

Here is a patch, please review.

The problem does not affect py3k because open() is used in place of
fopen(), and the mode string is parsed differently.

----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
priority:  -> release blocker
Added file: http://bugs.python.org/file11603/invalid_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3965>
_______________________________________

From report at bugs.python.org  Thu Sep 25 19:36:08 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 17:36:08 +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: <1222364168.3.0.499161950152.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Thanks Matthew.  You are now part of the pythonregexp2.7 team.  I want
to handle integrating Branch 01+09-02+17 myself for now and the other
branches will need to be renamed because I need to add Item 26: Capture
Groups in Look-Behind expressions, which would mean the order of your
patches are:

01+09-02+17:

regex_2.6rc2.diff
regex_2.6rc2+1.diff

01+09-02+17+26:

regex_2.6rc2+2.diff

01+09-02+17+18+26:

regex_2.6rc2+3.diff
regex_2.6rc2+4.diff

01+09-02+17+18+19+20+21+26:

regex_2.6rc2+5
regex_2.6rc2+6

It is my intention, therefore, to check a version of each of these
patches in to their corresponding repository, sequentially, starting
with 0, which is what I am working on now.

I am worried about a straight copy to each thread though, as there are
some basic cleanups provided through the core issue2636 patch, the item
1 patch and the item 9 patch.  The best way to see what these changes
are is to download
http://bugs.python.org/file10645/issue2636-patches.tar.bz2 and look at
the issue2636-01+09.patch file or, by typing the following into bazaar:

bzr diff --old lp:~pythonregexp2.7/python/base --new
lp:~pythonregexp2.7/python/issue2636+01+09

Which is more up-to-date than my June patches -- I really need to
regenerate those!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Sep 25 19:54:15 2008
From: report at bugs.python.org (Robert Yodlowski)
Date: Thu, 25 Sep 2008 17:54:15 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222365255.57.0.441098304912.issue3943@psf.upfronthosting.co.za>


Robert Yodlowski <rbtyod at gmail.com> added the comment:

Amaury, my stupid! I must have forgotten to delete the run.pyc file
before trying out the modified run.py as suggested in #3905 . It all
works now and IDLE starts up just fine.

Sorry and, thanks for the help.

...Bob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Thu Sep 25 20:35:50 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 25 Sep 2008 18:35:50 +0000
Subject: [issue3966] Win32ErrorTests from test_os.py
In-Reply-To: <1222367750.46.0.164641457334.issue3966@psf.upfronthosting.co.za>
Message-ID: <1222367750.46.0.164641457334.issue3966@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

test method       - call os.method
test_mkdir(self)  - os.chdir
test_access(self) - os.utime
test_chmod(self)  - os.utime

Is the test correct ?

----------
messages: 73807
nosy: rpetrov
severity: normal
status: open
title: Win32ErrorTests from test_os.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3966>
_______________________________________

From report at bugs.python.org  Thu Sep 25 21:12:55 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 25 Sep 2008 19:12:55 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222369975.86.0.802829693669.issue3547@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Does the following patch fix the test failure with MingW?

<patch>
Index: cfield.c
===================================================================
--- cfield.c	(revision 66611)
+++ cfield.c	(working copy)
@@ -65,10 +65,10 @@
 	}
 	if (bitsize /* this is a bitfield request */
 	    && *pfield_size /* we have a bitfield open */
-#if defined(MS_WIN32) && !defined(__MINGW32__)
-	    && dict->size * 8 == *pfield_size /* MSVC */
+#if defined(MS_WIN32)
+	    && dict->size * 8 == *pfield_size /* Windows */
 #else
-	    && dict->size * 8 <= *pfield_size /* GCC, MINGW */
+	    && dict->size * 8 <= *pfield_size /* GCC */
 #endif
 	    && (*pbitofs + bitsize) <= *pfield_size) {
 		/* continue bit field */
<end patch>

Also, can you please post the output of the following code snippet?

<test script>
from ctypes import *

class X(Structure):
    _fields_ = [("a", c_short, 4),
                ("b", c_short, 4),
                ("c", c_int, 24),
                ("d", c_short, 4),
                ("e", c_short, 4),
                ("f", c_int, 24)]

print X.a
print X.b
print X.c
print X.d
print X.e
print X.f
<end test script>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Thu Sep 25 21:20:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 19:20:28 +0000
Subject: [issue3943] IDLE won't start in 3.0rc1 "Subprocess didn't make
	connection...."
In-Reply-To: <1222138548.32.0.537221831059.issue3943@psf.upfronthosting.co.za>
Message-ID: <1222370428.62.0.970287870486.issue3943@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3943>
_______________________________________

From report at bugs.python.org  Thu Sep 25 21:22:07 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 25 Sep 2008 19:22:07 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1222370527.47.0.154234135587.issue1647489@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Matthew, I'll try to merge all your diffs with the current repository
over the weekend.  Having done the first, I know where code differs
between your implementation, mine and the base, so I can apply your
patch, and then a patch that restores my changes so the rest of the
merges should be easy!  :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_______________________________________

From report at bugs.python.org  Thu Sep 25 22:30:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 25 Sep 2008 20:30:26 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222342783.9.0.316319517411.issue3946@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809251330v2fc0529ei2ae1c954a2156fbe@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Thu, Sep 25, 2008 at 6:39 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> The test would be better in test_memoryview rather than in test_builtin.

I disagree. The test I added is really about compile, and its failure
was really just a side effect of the buffer bug.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Thu Sep 25 22:34:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 25 Sep 2008 20:34:00 +0000
Subject: [issue3965] 2.6rc2 crashes when trying to open unicode filename with
	unprintables
In-Reply-To: <1222358181.85.0.131055408857.issue3965@psf.upfronthosting.co.za>
Message-ID: <1222374840.49.0.536663656236.issue3965@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think it is somewhat surprising that the file name shows up at the end
in the traceback. Instead of getting

IOError: [Errno 22] invalid filename or mode 'w': '/dos/foo\n'

it might be better if it said

IOError: [Errno 22] invalid mode ('w') or filename: '/dos/foo\n'

Otherwise, the patch looks fine.

----------
assignee:  -> amaury.forgeotdarc
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3965>
_______________________________________

From report at bugs.python.org  Thu Sep 25 22:38:49 2008
From: report at bugs.python.org (Joseph Rothrock)
Date: Thu, 25 Sep 2008 20:38:49 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1222375129.06.0.580696123054.issue858809@psf.upfronthosting.co.za>


Joseph Rothrock <rothrock at rothrock.org> added the comment:

Hi,

This problem still exists in 2.5.2. Setting the libdir argument doesn't
correctly set LIBDIR in the Makefile.


[rothrock at su1 Python-2.5.2]$ ./configure --prefix=/home/y
--libdir=/home/y/lib64

...

[rothrock at su1 Python-2.5.2]$ cat Makefile | grep LIBDIR=
LIBDIR=		$(exec_prefix)/lib

----------
nosy: +rothrock
versions: +Python 2.5 -Python 2.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Thu Sep 25 22:46:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 25 Sep 2008 20:46:42 +0000
Subject: [issue3936] Faulty suppression of 'as' keyword warning
In-Reply-To: <1222120341.98.0.209140784414.issue3936@psf.upfronthosting.co.za>
Message-ID: <1222375602.03.0.107007251356.issue3936@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66618.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3936>
_______________________________________

From report at bugs.python.org  Thu Sep 25 22:55:04 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 20:55:04 +0000
Subject: [issue3965] 2.6rc2 crashes when trying to open unicode filename with
	unprintables
In-Reply-To: <1222358181.85.0.131055408857.issue3965@psf.upfronthosting.co.za>
Message-ID: <1222376104.0.0.623421601456.issue3965@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied patch in r66620, with the suggested change in the error message.

----------
keywords:  -needs review
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3965>
_______________________________________

From report at bugs.python.org  Thu Sep 25 22:55:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 20:55:47 +0000
Subject: [issue3965] 2.6rc2 crashes when trying to open unicode filename with
	unprintables
In-Reply-To: <1222358181.85.0.131055408857.issue3965@psf.upfronthosting.co.za>
Message-ID: <1222376147.4.0.914727695887.issue3965@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

And, thanks a lot reporting this!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3965>
_______________________________________

From report at bugs.python.org  Thu Sep 25 23:05:03 2008
From: report at bugs.python.org (Geoff Gilmour-Taylor)
Date: Thu, 25 Sep 2008 21:05:03 +0000
Subject: [issue3965] 2.6rc2 crashes when trying to open unicode filename with
	unprintables
In-Reply-To: <1222358181.85.0.131055408857.issue3965@psf.upfronthosting.co.za>
Message-ID: <1222376703.36.0.252793868636.issue3965@psf.upfronthosting.co.za>


Geoff Gilmour-Taylor <geoff.gilmour-taylor at cnib.ca> added the comment:

Cheers.  First bug I've found in 5 years of Python.  (Or, 5 years in and
I still keep forgetting to use raw strings for Windows paths.  :)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3965>
_______________________________________

From report at bugs.python.org  Thu Sep 25 23:39:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Sep 2008 21:39:33 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>
Message-ID: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

bytes_count() doesn't check start maximum value: _adjust_indices()
should check that start is smaller than len (smaller or egal? len or
len-1?). Example:

>>> b = bytearray(3)
>>> b.count("x", 1491491034, 0)

start=1491491034 should be replaced by 3 (or 2 or 4? I don't know
bytearray enough).

----------
components: Interpreter Core
messages: 73817
nosy: haypo
severity: normal
status: open
title: bytearray().count()
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Thu Sep 25 23:47:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 21:47:13 +0000
Subject: [issue3963] Problems when calling exec from a function
In-Reply-To: <1222355421.74.0.537715062608.issue3963@psf.upfronthosting.co.za>
Message-ID: <1222379233.81.0.851274313045.issue3963@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

See also:

http://docs.python.org/dev/reference/executionmodel.html#interaction-
with-dynamic-features

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3963>
_______________________________________

From report at bugs.python.org  Fri Sep 26 00:29:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 22:29:21 +0000
Subject: [issue3929] Incorrect exception raising in dbm.open on non-existing DB
In-Reply-To: <1222078079.42.0.696848044955.issue3929@psf.upfronthosting.co.za>
Message-ID: <1222381761.95.0.321036847154.issue3929@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did you know that...
with python 2.x, "raise (x,y,z)" is equivalent to "raise x"!
I could not find this in the documentation.

Committed the patch to py3k as r66622.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3929>
_______________________________________

From report at bugs.python.org  Fri Sep 26 00:43:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Sep 2008 22:43:18 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>
Message-ID: <1222382598.38.0.155666676209.issue3967@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is there a problem, a potential crash?
looking at the code, I could not find any: in fastsearch, the "if (w < 
0)" will quickly exit the function, without reading the contents of the 
array.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Fri Sep 26 00:58:31 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Sep 2008 22:58:31 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222382598.38.0.155666676209.issue3967@psf.upfronthosting.co.za>
Message-ID: <48DC178D.7010001@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a trace of Valgrind:

 >>> b=bytearray(2)
 >>> b.count("xxxx", 3493403, 0)
0
 >>> b.count("xxxx", 23131230123012010231023, 0)
==13650== Invalid read of size 1
==13650==    at 0x812718A: fastsearch (fastsearch.h:67)
==13650==    by 0x81272CB: stringlib_count (count.h:22)
==13650==    by 0x8128611: bytes_count (bytearrayobject.c:1198)
==13650==    by 0x81376B6: PyCFunction_Call (methodobject.c:81)
==13650==    by 0x80D913D: call_function (ceval.c:3679)
==13650==    by 0x80D603A: PyEval_EvalFrameEx (ceval.c:2370)
==13650==    by 0x80D7891: PyEval_EvalCodeEx (ceval.c:2942)
==13650==    by 0x80D0A8F: PyEval_EvalCode (ceval.c:515)
==13650==    by 0x80FB4FE: run_mod (pythonrun.c:1330)
==13650==    by 0x80FA166: PyRun_InteractiveOneFlags (pythonrun.c:836)
==13650==    by 0x80F9EEA: PyRun_InteractiveLoopFlags (pythonrun.c:756)
==13650==    by 0x80F9DAC: PyRun_AnyFileExFlags (pythonrun.c:725)
==13650==  Address 0x8444553a is not stack'd, malloc'd or (recently) free'd
==13650==
==13650== Process terminating with default action of signal 11 (SIGSEGV)

Trace of gdb:
0x0812718a in fastsearch (s=0x89b9fcaf <Address 0x89b9fcaf out of 
bounds>, n=-2147483647,
    p=0xb7b54274 "xxxx", m=4, mode=0) at Objects/stringlib/fastsearch.h:67
67              if (s[i+m-1] == p[m-1]) {
(gdb) where
#0  0x0812718a in fastsearch (s=0x89b9fcaf <Address 0x89b9fcaf out of 
bounds>, n=-2147483647,
    p=0xb7b54274 "xxxx", m=4, mode=0) at Objects/stringlib/fastsearch.h:67
#1  0x081272cc in stringlib_count (str=0x89b9fcaf <Address 0x89b9fcaf 
out of bounds>,
    str_len=-2147483647, sub=0xb7b54274 "xxxx", sub_len=4) at 
Objects/stringlib/count.h:22
#2  0x08128612 in bytes_count (self=0xb7d025f0, args=0xb7b5075c)
    at Objects/bytearrayobject.c:1198
(gdb) print w
$1 = 2147483645
(gdb) print m
$2 = 4

Oh, look at stringlib_count (..., str_len=-2147483647, ..., sub_len=4): 
str_len is negative.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Fri Sep 26 01:07:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Sep 2008 23:07:21 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1afaf6160809251330v2fc0529ei2ae1c954a2156fbe@mail.gmail.com>
Message-ID: <1222384038.6478.18.camel@fsol>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I disagree. The test I added is really about compile, and its failure
> was really just a side effect of the buffer bug.

Well, I won't fight over it, but it's really meant to check an aspect of
memoryview behaviour - otherwise why would it be part of your patch ? -,
and as such it should be in test_memoryview (and if it's meant to check
compile() then it should be in some hypothetical test_compile :-)).

In general I find it annoying that many tests are dumped into "generic"
test files like test_builtin, rather than in the test file appropriate
for the functionality being tested.

That said, I haven't looked at the rest of the patch yet, sorry! (back
from holidays)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Fri Sep 26 01:34:48 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 25 Sep 2008 23:34:48 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222385688.89.0.172399497004.issue3956@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

First of all I'd like to point you at a posting which I posted to
Python-dev on August 18th, where I addressed this issue in full detail. 

http://mail.python.org/pipermail/python-dev/2008-August/081846.html

I hoped to provoke a clarifying discussion but I have to complain, that
I didn't succeed with this probably because many people were on vacation
at this time.

The only substantial reply I got was by Vern Ceder, a turtle graphics
veteran who contributed a lot to the old turtle module. He wrote:

Gregor,

I don't feel authoritative on the correctness/appropriateness of the 
implementation, but I do agree completely that behavior b, 
or what you have in the 3.0 version, is vastly preferable.

Cheers,
Vern 

The design decision to use a singleton is of interest only for
interactive use. (A well designed Script uses at most one Screen() call
at the beginning. So that is no issue.)

I'll demonstrate here in a short interactive session (which you can
reproduce using IDLE with the -n switch as usual), why the solution
Martin proposes doesn't meet the requirements I tried to accomplish with
my code. This session 'simulates' a student curiously playing around and
experimenting with *the* Screen():

>>> from turtle import Screen, Turtle
>>> class YellowScreen(Screen):
	def __init__(self):
		Screen.__init__(self)
		self.bgcolor("yellow")

		
>>> s = YellowScreen()
>>> t = Turtle()
>>> for i in range(10):
	t.fd(50)
	t.lt(36)

	
>>> s1 = Screen()
>>> s1.bgcolor("pink")
>>> s = YellowScreen()
>>> s1.bgcolor()
'yellow'
>>> s1.turtles()
[<turtle.Turtle object at 0x01490450>]
>>> class TextScreen(Screen):
	def __init__(self):
		Screen.__init__(self)
		self. writer = Turtle(visible=False)
		self.writer.pu()
	def writeAt(self, x, y, txt):
		self.writer.goto(x,y)
		self.writer.write(txt)

		
>>> s = TextScreen()
>>> s.writeAt(0, -200, "Read me ...")
>>> s.turtles()
[<turtle.Turtle object at 0x01490450>, <turtle.Turtle object at 0x014902B0>]
>>> s.writer
<turtle.Turtle object at 0x014902B0>
>>> class RedScreen(Screen):
	def __init__(self):
		Screen .__init__(self)
		self.bgcolor(1, 0.5, 0.5)

		
>>> u = RedScreen()
>>> u.writeAt(0,200, "Read me too....")    # should fail!
Traceback (most recent call last):
  File "<pyshell#21>", line 1, in <module>
    u.writeAt(0,200, "Read me too....")
AttributeError: 'RedScreen' object has no attribute 'writeAt'
>>> u = TextScreen()
>>> u.writeAt(0,200, "Read me too....")
>>> u.turtles()  # at this point for the first time occurs an 
                 # unfavorable consequence of what Martin called a
                 # 'design bug', namely a turtle in the turtles() list 
                 # which is not used any more.
[<turtle.Turtle object at 0x01490450>, <turtle.Turtle object at
0x014902B0>, <turtle.Turtle object at 0x014C2D10>]
>>> u.writer
<turtle.Turtle object at 0x014C2D10>
>>> s.writer
<turtle.Turtle object at 0x014C2D10>
    #  We want a fresh screen ...
>>> s.clear()
>>> s.turtles()
[]

So there occurres this and possibly some more somewhat weird elements, 
presumably a result of using the Singleton pattern which is especially
controversial in combination with inheritance. Nevertheless I decisively
propose to accept this behaviour in order to be able do things like the
ones demonstrated above. Morover I also consider it to be a benefit to
use spezialized and/or reusable screens derived from the Screen() class
in scripts, what would not be possible with a Screen()-function
returning *the* single _Screen() object. (All this meant in the context
of teaching and learning OOP).

Now for the additional questions of Martin:

Yes, the second if statement is superfluous. It looks like to be a
remain from Pen.__init__ from the old turtle module, where - in contrast
- it was not superfluous. My fault. It could be removed, but it doesn't
do harm. (The overwhelming part of the module is *re*written but it
still contains (in this case regrettably) quite some traces of the old
module.) And also the assignement of self to Turtle._screen in the last
line could be put into the if-statement-body. But somehow I seem to have
felt that a conditionally empty body of __init__() looks dangerous - or
at least not nice. More seriously taken, the Borg idiom ensures the
creation of new instances (with different id), sharing state and
behaviour and I somehow felt it to be better to have the last created
instance in Turtle._screen (whereas in fact this is of no importance).

My preliminary conclusion: as I'm not a professional programmer but a
teacher I can't judge the importance of observing the design 
principle mentioned by Martin. (I know the principle, I normally observe
it and consider it's non observation in the Screen class to be well
founded) But if you think, that there is no way around and it has to be
observed strictly, one had to leave everything as is and find a
better solution (with the desired behaviour) for 2.6.1. Otherwise,
having done a lot of work with the Screen class and having not
observed any unexpected behaviour (let alone crashes) when using it
I'd pragmatically still much prefer the solution which is implemented in
3.0 Even then the search for a better solution may be indicated.

Anyway I'd like to express my hope that this controversial
implementation of the last element in the class hierarchy for a very
special purpose is *not* a hint at a design bug of the entire class
hierarchy.

Regards, Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Fri Sep 26 01:36:24 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 25 Sep 2008 23:36:24 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222385784.26.0.536813472236.issue3547@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Yes this extra define was the problem.
Instead hint /* Windows */ what about /* MSVC, GCC(with -mms-bitfields) */ ?

The option -mms-bitfields is available for GCC compiler on mingw and
cygwin targets.


About test_bitfields.py:
- comment in test_mixed_4: if GCC compiler has option -mms-bitfields it
will produce code compatible with MSVC. May be comment has to include
this information. 

- may be method test_mixed_1 need similar comment as test_mixed_4, but
even without comment is fine with me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Fri Sep 26 01:39:34 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 25 Sep 2008 23:39:34 +0000
Subject: [issue3968] fill() and end_fill() do not work correctly
In-Reply-To: <1222385974.61.0.090450366613.issue3968@psf.upfronthosting.co.za>
Message-ID: <1222385974.61.0.090450366613.issue3968@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

fill() and end_fill() do not work as expected. As a user 
on the tutor list wrote:

For a while now I've had trouble with end_fill(). Sometimes I can use
it to fill a figure such as a square, triangle or rectangle, but
sometimes not.

This is due to a missing update() call in the RawPen.fill() method

A patch is attached

Regards, Gregor

----------
components: Tkinter
files: 2.5turtle_fillpatch.diff
keywords: patch
messages: 73825
nosy: gregorlingl
severity: normal
status: open
title: fill() and end_fill() do not work correctly
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11604/2.5turtle_fillpatch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3968>
_______________________________________

From report at bugs.python.org  Fri Sep 26 01:42:37 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 25 Sep 2008 23:42:37 +0000
Subject: [issue3969] turtle.py - setup() doesn't work correctly
In-Reply-To: <1222386157.49.0.477269156724.issue3969@psf.upfronthosting.co.za>
Message-ID: <1222386157.49.0.477269156724.issue3969@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

setup() doesn't work correctly: startx argument is not recognized
This is due to a typo in the setup() function

A patch is attached.

Regards, Gregor

----------
components: Tkinter
files: 2.5turtle_setup_patch.diff
keywords: patch
messages: 73826
nosy: gregorlingl
severity: normal
status: open
title: turtle.py - setup() doesn't work correctly
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11605/2.5turtle_setup_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3969>
_______________________________________

From report at bugs.python.org  Fri Sep 26 01:43:57 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Thu, 25 Sep 2008 23:43:57 +0000
Subject: [issue3968] turtle.py: fill() and end_fill() do not work correctly
In-Reply-To: <1222385974.61.0.090450366613.issue3968@psf.upfronthosting.co.za>
Message-ID: <1222386237.88.0.662643579088.issue3968@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


----------
title: fill() and end_fill() do not work correctly -> turtle.py: fill() and end_fill() do not work correctly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3968>
_______________________________________

From report at bugs.python.org  Fri Sep 26 01:59:06 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Sep 2008 23:59:06 +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: <1222387146.24.0.668634145859.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've been completely unable to get Bazaar to work with Launchpad:
authentication errors and bzrlib.errors.TooManyConcurrentRequests.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Sep 26 02:02:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 00:02:29 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>
Message-ID: <1222387349.09.0.838117867831.issue3967@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ah, big numbers that overflow: even if 'start' is (silently) capped to  
sys.maxint-1,    len(b)-start-len("xx")   will wrap and yield a positive 
number...

The find/rfind/index/rindex methods have the same problem.

Attached a patch and unit tests, needs review.

----------
keywords: +needs review, patch
priority:  -> release blocker
Added file: http://bugs.python.org/file11606/string_count.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Fri Sep 26 02:07:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 00:07:02 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>
Message-ID: <1222387622.89.0.254798781465.issue3967@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

All versions are involved.

Even 2.4 has surprises:
>>> "aa".count("", sys.maxint, 0)
-2147483646

----------
versions: +Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Fri Sep 26 02:52:32 2008
From: report at bugs.python.org (Ron Longo)
Date: Fri, 26 Sep 2008 00:52:32 +0000
Subject: [issue3970] Tix Tree widget no longer instantiable.
In-Reply-To: <1222390352.08.0.770035062007.issue3970@psf.upfronthosting.co.za>
Message-ID: <1222390352.08.0.770035062007.issue3970@psf.upfronthosting.co.za>


New submission from Ron Longo <ron.longo at cox.net>:

The following code works in Python 2.5 but not in Python 2.6:  I've 
tested on Windows XP and Windows Vista.

from Tix import *
root = Tk()
t = Tree( root )

In Python 2.6 the following exception is thrown while trying to execute 
the last statement above:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python26\lib\lib-tk\Tix.py", line 1519, in __init__
    ['options'], cnf, kw)
  File "C:\Python26\lib\lib-tk\Tix.py", line 307, in __init__
    self.tk.call(widgetName, self._w, *extra)
_tkinter.TclError: unknown color name "{#c3c3c3}"

----------
components: Tkinter
messages: 73830
nosy: ronLongo
severity: normal
status: open
title: Tix Tree widget no longer instantiable.
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3970>
_______________________________________

From report at bugs.python.org  Fri Sep 26 05:06:46 2008
From: report at bugs.python.org (Ronny Haryanto)
Date: Fri, 26 Sep 2008 03:06:46 +0000
Subject: [issue3960] Section permalink html anchors are wrong
In-Reply-To: <1222346508.67.0.745864435926.issue3960@psf.upfronthosting.co.za>
Message-ID: <1222398406.51.0.646103916894.issue3960@psf.upfronthosting.co.za>


Ronny Haryanto <ronny at haryan.to> added the comment:

I should have mentioned that this breaks in-document links, e.g. clicking 
on <a href="#blah">blah</a> will not bring you to <span 
id="blah"></span><a href="#blah">...</a>.

My point is that the attribute should be "name" instead of "href".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3960>
_______________________________________

From report at bugs.python.org  Fri Sep 26 05:25:08 2008
From: report at bugs.python.org (Ronny Haryanto)
Date: Fri, 26 Sep 2008 03:25:08 +0000
Subject: [issue3960] Section permalink html anchors are wrong
In-Reply-To: <1222346508.67.0.745864435926.issue3960@psf.upfronthosting.co.za>
Message-ID: <1222399508.46.0.126209295895.issue3960@psf.upfronthosting.co.za>


Ronny Haryanto <ronny at haryan.to> added the comment:

Sorry, Georg, I just realized what you meant. You're right. But would it 
be possible to add "name" *in addition to* "href" so that clicking on in-
document links (e.g. in Table of Contents) would still work? Thanks.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3960>
_______________________________________

From report at bugs.python.org  Fri Sep 26 07:55:54 2008
From: report at bugs.python.org (Erik Sandberg)
Date: Fri, 26 Sep 2008 05:55:54 +0000
Subject: [issue3963] Problems when calling exec from a function
In-Reply-To: <1222355421.74.0.537715062608.issue3963@psf.upfronthosting.co.za>
Message-ID: <1222408554.18.0.552794669782.issue3963@psf.upfronthosting.co.za>


Erik Sandberg <sandberg at virtutech.com> added the comment:

Thanks! Passing an explicit global namespace solves the problem and is
something I wanted to do anyways, when I think about it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3963>
_______________________________________

From report at bugs.python.org  Fri Sep 26 07:57:45 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 26 Sep 2008 05:57:45 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1220995272.13.0.856073925349.issue3826@psf.upfronthosting.co.za>
Message-ID: <1222408665.97.0.977158411533.issue3826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The whole socket._io_refs thing looks like a real design flaw.  What is
its actual intended purpose?

When close is called on the socket object itself, the socket MSUT be
closed.  Why is our API otherwise?

Its up to the programming to ensure that no other references to that
socket wrapped in whatever layers will be used after that, if they are
they'll eventually get errors when an IO occurs.


I think this behavior started with this change:

------------------------------------------------------------------------
r56714 | jeremy.hylton | 2007-08-03 13:40:09 -0700 (Fri, 03 Aug 2007) |
21 lines

Make sure socket.close() doesn't interfere with socket.makefile().

If a makefile()-generated object is open and its parent socket is
closed, the parent socket should remain open until the child is
closed, too.  The code to support this is moderately complex and
requires one extra slots in the socket object.

This change fixes httplib so that several urllib2net test cases pass
again.

Add SocketCloser class to socket.py, which encapsulates the
refcounting logic for sockets after makefile() has been called.

Move SocketIO class from io module to socket module.  It's only use is
to implement the raw I/O methods on top of a socket to support
makefile().

Add unittests to test_socket to cover various patterns of close and
makefile.

...............
later modified by this (still the same effect):
...............

------------------------------------------------------------------------
r58970 | guido.van.rossum | 2007-11-14 14:32:02 -0800 (Wed, 14 Nov 2007)
| 6 lines

Patch 1439 by Bill Janssen.  I think this will work.
Tested on Windows by Christian Heimes.
I changed the code slightly, renaming decref_socketios() to
_decref_socketios(), and moving it closer to the close() method
that it calls.  Hopefully Bill can now submit his SSL port to 3.0.

----------
nosy: +gvanrossum, jhylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Fri Sep 26 09:01:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 07:01:11 +0000
Subject: [issue3970] Tix Tree widget no longer instantiable.
In-Reply-To: <1222390352.08.0.770035062007.issue3970@psf.upfronthosting.co.za>
Message-ID: <1222412471.24.0.191673557682.issue3970@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Duplicate of issue3872. Tix seems really broken with tcl8.5...

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python 2.6rc2: Tix ComboBox error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3970>
_______________________________________

From report at bugs.python.org  Fri Sep 26 09:01:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 07:01:21 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222412481.37.0.089595855253.issue3872@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Fri Sep 26 09:15:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Sep 2008 07:15:14 +0000
Subject: [issue3969] turtle.py - setup() doesn't work correctly
In-Reply-To: <1222386157.49.0.477269156724.issue3969@psf.upfronthosting.co.za>
Message-ID: <1222413314.21.0.232392486867.issue3969@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed as r66626 (2.5 branch only).

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3969>
_______________________________________

From report at bugs.python.org  Fri Sep 26 09:17:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Sep 2008 07:17:11 +0000
Subject: [issue3968] turtle.py: fill() and end_fill() do not work correctly
In-Reply-To: <1222385974.61.0.090450366613.issue3968@psf.upfronthosting.co.za>
Message-ID: <1222413431.15.0.573223985284.issue3968@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r66627 (2.5 branch only).

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3968>
_______________________________________

From report at bugs.python.org  Fri Sep 26 10:31:19 2008
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 26 Sep 2008 08:31:19 +0000
Subject: [issue3929] Incorrect exception raising in dbm.open on non-existing DB
In-Reply-To: <1222078079.42.0.696848044955.issue3929@psf.upfronthosting.co.za>
Message-ID: <1222417879.64.0.978111480466.issue3929@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

I didn't know until I had googled this:

http://mail.python.org/pipermail/python-3000/2007-March/005916.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3929>
_______________________________________

From report at bugs.python.org  Fri Sep 26 11:23:33 2008
From: report at bugs.python.org (netcaf)
Date: Fri, 26 Sep 2008 09:23:33 +0000
Subject: [issue3971] s_push: parser stack overflow MemoryError
In-Reply-To: <1222421013.17.0.704872075163.issue3971@psf.upfronthosting.co.za>
Message-ID: <1222421013.17.0.704872075163.issue3971@psf.upfronthosting.co.za>


New submission from netcaf <kanchy at gmail.com>:

t =
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((0x280000))+(0x80000)-1)/(0x80000))*(0x80000))
+ 0x280000))+(0x10000)-1)/(0x10000))*(0x10000))+((0x10000*31
))))+(0x1000)-1)/(0x1000))*(0x1000)))+(16)-1)/(16))*(16)) +
0x100000))+(512)-1)/(512))*(512)) + 0xBF4000))+(8)-1)/(8))*(8)) +
0x200000) + 0x524000L)+(0x1000)-1)/(0x1000))*(0x1000)))+(3*253)) +
0))+(0x1000)-1)/(0x1000))*(0x1000)) +
0))+(0x1000)-1)/(0x1000))*(0x1000))+0x2B0000L))+(0x1000)-1)/(0x1000))*(0x1000))+0x4000)
+ 0))+(0x1000)-1)/(0x1000))*(0x1000))+0x600000L) +
0))+(0x1000)-1)/(0x1000))*(0x1000))+0x4000) +
0))+(0x1000)-1)/(0x1000))*(0x1000))+0x900000U) +
0))+(0x1000)-1)/(0x1000))*(0x1000)))+(0x2000)) +
0)+(0x1000)-1)/(0x1000))*(0x1000)) +
0x800L)+(0x1000)-1)/(0x1000))*(0x1000))+0x600000L)+0))+(0x1000)-1)/(0x1000))*(0x1000))+(((((((((((((
( (((((1920L) <= (1920L)) * (1920L) + ((1920L) < (1920L)) * (1920L))
))&0xFFF0)+16) + (0) )* (1088L + (0)) * 2)+(64L)-1)/(64L))*(64L))) >=
((((((( ( ((((1680L) <= (1920L)) * (1680L) + ((1920L) < (1680L)) *
(1920L)))&0xFFF0)+16) + (0))* (((1050L) <= (1080)) * (1050L) + ((1080) <
(1050L)) * (1080)) * 3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( (((((1920L)
<= (1920L)) * (1920L) + ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) +
(0) )* (1088L + (0)) * 2)+(64L)-1)/(64L))*(64L))) + (((((((( (
((((1680L) <= (1920L)) * (1680L) + ((1920L) < (1680L)) *
(1920L)))&0xFFF0)+16) + (0))* (((1050L) <= (1080)) * (1050L) + ((1080) <
(1050L)) * (1080)) * 3)+(64L)-1)/(64L))*(64L))) > ((((((( ( (((((1920L)
<= (1920L)) * (1920L) + ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) +
(0) )* (1088L + (0)) * 2)+(64L)-1)/(64L))*(64L)))) * ((((((( (
((((1680L) <= (1920L)) * (1680L) + ((1920L) < (1680L)) *
(1920L)))&0xFFF0)+16) + (0))* (((1050L) <= (1080)) * (1050L) + ((1080) <
(1050L)) * (1080)) * 3)+(64L)-1)/(64L))*(64L))))) >= (((((((((( (
((((1920L) <= (1920L)) * (1920L) + ((1920L) < (1920L)) *
(1920L)))&0xFFF0)+16) + (0) )* (1088L + (0)) *
3)+(64L)-1)/(64L))*(64L))) >= ((((((( ( ((((720L) <= (1920L)) * (720L) +
((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L + (0)) *
3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((1920L) <= (1920L)) * (1920L)
+ ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L + (0)) *
3)+(64L)-1)/(64L))*(64L))) + (((((((( ( ((((720L) <= (1920L)) * (720L) +
((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L + (0)) *
3)+(64L)-1)/(64L))*(64L))) > ((((((( ( ((((1920L) <= (1920L)) * (1920L)
+ ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L + (0)) *
3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((720L) <= (1920L)) * (720L) +
((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L + (0)) *
3)+(64L)-1)/(64L))*(64L)))))) * (((((((((( ( (((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) + (0) )* (1088L
+ (0)) * 2)+(64L)-1)/(64L))*(64L))) >= ((((((( ( ((((1680L) <= (1920L))
* (1680L) + ((1920L) < (1680L)) * (1920L)))&0xFFF0)+16) + (0))*
(((1050L) <= (1080)) * (1050L) + ((1080) < (1050L)) * (1080)) *
3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( (((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) + (0) )* (1088L
+ (0)) * 2)+(64L)-1)/(64L))*(64L))) + (((((((( ( ((((1680L) <= (1920L))
* (1680L) + ((1920L) < (1680L)) * (1920L)))&0xFFF0)+16) + (0))*
(((1050L) <= (1080)) * (1050L) + ((1080) < (1050L)) * (1080)) *
3)+(64L)-1)/(64L))*(64L))) > ((((((( ( (((((1920L) <= (1920L)) * (1920L)
+ ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) + (0) )* (1088L + (0)) *
2)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((1680L) <= (1920L)) * (1680L)
+ ((1920L) < (1680L)) * (1920L)))&0xFFF0)+16) + (0))* (((1050L) <=
(1080)) * (1050L) + ((1080) < (1050L)) * (1080)) *
3)+(64L)-1)/(64L))*(64L))))) + ((((((((((( ( ((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L +
(0)) * 3)+(64L)-1)/(64L))*(64L))) >= ((((((( ( ((((720L) <= (1920L)) *
(720L) + ((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L +
(0)) * 3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L +
(0)) * 3)+(64L)-1)/(64L))*(64L))) + (((((((( ( ((((720L) <= (1920L)) *
(720L) + ((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L +
(0)) * 3)+(64L)-1)/(64L))*(64L))) > ((((((( ( ((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L +
(0)) * 3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((720L) <= (1920L)) *
(720L) + ((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L +
(0)) * 3)+(64L)-1)/(64L))*(64L))))) > (((((((((( ( (((((1920L) <=
(1920L)) * (1920L) + ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) + (0)
)* (1088L + (0)) * 2)+(64L)-1)/(64L))*(64L))) >= ((((((( ( ((((1680L) <=
(1920L)) * (1680L) + ((1920L) < (1680L)) * (1920L)))&0xFFF0)+16) + (0))*
(((1050L) <= (1080)) * (1050L) + ((1080) < (1050L)) * (1080)) *
3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( (((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) + (0) )* (1088L
+ (0)) * 2)+(64L)-1)/(64L))*(64L))) + (((((((( ( ((((1680L) <= (1920L))
* (1680L) + ((1920L) < (1680L)) * (1920L)))&0xFFF0)+16) + (0))*
(((1050L) <= (1080)) * (1050L) + ((1080) < (1050L)) * (1080)) *
3)+(64L)-1)/(64L))*(64L))) > ((((((( ( (((((1920L) <= (1920L)) * (1920L)
+ ((1920L) < (1920L)) * (1920L)) ))&0xFFF0)+16) + (0) )* (1088L + (0)) *
2)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((1680L) <= (1920L)) * (1680L)
+ ((1920L) < (1680L)) * (1920L)))&0xFFF0)+16) + (0))* (((1050L) <=
(1080)) * (1050L) + ((1080) < (1050L)) * (1080)) *
3)+(64L)-1)/(64L))*(64L)))))) * (((((((((( ( ((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L +
(0)) * 3)+(64L)-1)/(64L))*(64L))) >= ((((((( ( ((((720L) <= (1920L)) *
(720L) + ((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L +
(0)) * 3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L +
(0)) * 3)+(64L)-1)/(64L))*(64L))) + (((((((( ( ((((720L) <= (1920L)) *
(720L) + ((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L +
(0)) * 3)+(64L)-1)/(64L))*(64L))) > ((((((( ( ((((1920L) <= (1920L)) *
(1920L) + ((1920L) < (1920L)) * (1920L)))&0xFFF0)+16) + (0) )* (1088L +
(0)) * 3)+(64L)-1)/(64L))*(64L)))) * ((((((( ( ((((720L) <= (1920L)) *
(720L) + ((1920L) < (720L)) * (1920L)))&0xFFF0)+16) + (0)) * (576L +
(0)) * 3)+(64L)-1)/(64L))*(64L)))))) * 2)) +
0)+0x80)+0))+(8)-1)/(8))*(8)))+0x3600)+0))+(8)-1)/(8))*(8)))+0x400))+(8)-1)/(8))*(8))
+ 0)+(0x0))+(0x0))+(4096)-1)/(4096))*(4096)) +
0x1000)+(0x1000)-1)/(0x1000))*(0x1000)) +
0x1000)+(0x1000)-1)/(0x1000))*(0x1000))

----------
messages: 73839
nosy: netcaf
severity: normal
status: open
title: s_push: parser stack overflow MemoryError
type: resource usage
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3971>
_______________________________________

From report at bugs.python.org  Fri Sep 26 11:58:52 2008
From: report at bugs.python.org (Eldon Ziegler)
Date: Fri, 26 Sep 2008 09:58:52 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>


New submission from Eldon Ziegler <eldonz at atlanticdb.com>:

I updated httplib.py, python 2.4, to be able to bind to a specific IP
address when connecting to a remote site.

  conn = httplib.HTTPConnection('82.94.237.218', 80)

will connect to '82.94.237.218' using one of the local IP addresses. For
example, if a machine has an primary IP address and an alias such as

eth0    192.168.1.10
eth0:1  192.168.1.11

the outbound connection might use either eth0 or eth0:1. I'm not sure
how it picks now. I added a bind option both for http and https so we
can direct the connection through one or the other. For example,

  conn = httplib.HTTPConnection('82.94.237.218', 80, None, None, None,
'192.168.1.10')

would make sure it used 192.168.1.10 not 192.168.1.11.

I ran into this on a server that is contacted by an external legacy
server which requires a reverse connection over the same IP address that
the original connection came in on.

----------
components: Library (Lib)
files: httplib2.4.diff
keywords: patch
messages: 73840
nosy: eldonz at atlanticdb.com
severity: normal
status: open
title: Add Option to Bind to a Local IP Address in httplib.py
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11607/httplib2.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3972>
_______________________________________

From report at bugs.python.org  Fri Sep 26 12:52:11 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 10:52:11 +0000
Subject: [issue3973] Invalid line number in Exception traceback with header #
	-*- coding: xxx -*-
In-Reply-To: <1222426331.79.0.411203479625.issue3973@psf.upfronthosting.co.za>
Message-ID: <1222426331.79.0.411203479625.issue3973@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Short example:
---
# -*- coding: ASCII -*-
raise Exception("line 2")
---

Result:
----
Traceback (most recent call last):
  File "plop.py", line 3, in <module>

Exception: line 2
----

The problem is around newtracebackobject() which calls 
PyCode_Addr2Line(). It maybe a bug is frame->co_lnotab generation.

This bus is specified to python3 (trunk).

----------
messages: 73841
nosy: haypo
severity: normal
status: open
title: Invalid line number in Exception traceback with header # -*- coding: xxx -*-
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3973>
_______________________________________

From report at bugs.python.org  Fri Sep 26 13:49:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Sep 2008 11:49:46 +0000
Subject: [issue3973] Invalid line number in Exception traceback with header #
	-*- coding: xxx -*-
In-Reply-To: <1222426331.79.0.411203479625.issue3973@psf.upfronthosting.co.za>
Message-ID: <1222429786.23.0.0352715826455.issue3973@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like a duplicate of #2384. Do you confirm?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3973>
_______________________________________

From report at bugs.python.org  Fri Sep 26 13:52:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Sep 2008 11:52:29 +0000
Subject: [issue3973] Invalid line number in Exception traceback with header #
	-*- coding: xxx -*-
In-Reply-To: <1222426331.79.0.411203479625.issue3973@psf.upfronthosting.co.za>
Message-ID: <1222429949.13.0.678714091045.issue3973@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> [Py3k] line number is wrong after encoding declaration

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3973>
_______________________________________

From report at bugs.python.org  Fri Sep 26 13:52:39 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Sep 2008 11:52:39 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222429959.03.0.217074763588.issue2384@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 13:53:02 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Sep 2008 11:53:02 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222429982.53.0.464826295716.issue2384@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

#3973 is a duplicate.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 14:01:54 2008
From: report at bugs.python.org (Jens Kadenbach)
Date: Fri, 26 Sep 2008 12:01:54 +0000
Subject: [issue3974] collections.namedtuple uses exec to create new classes
In-Reply-To: <1222430514.93.0.950826754089.issue3974@psf.upfronthosting.co.za>
Message-ID: <1222430514.93.0.950826754089.issue3974@psf.upfronthosting.co.za>


New submission from Jens Kadenbach <j.kadenbach at gmx.de>:

Rewrite of the namedtuple implementation to avoid the use of exec for
class generation.? The new code uses a custom class dictionary and the
builtin type to create new classes dynamically.

----------
components: Library (Lib)
files: new_namedtuples.diff
keywords: patch
messages: 73844
nosy: audax
severity: normal
status: open
title: collections.namedtuple uses exec to create new classes
versions: Python 2.6
Added file: http://bugs.python.org/file11608/new_namedtuples.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3974>
_______________________________________

From report at bugs.python.org  Fri Sep 26 14:06:49 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Sep 2008 12:06:49 +0000
Subject: [issue3974] collections.namedtuple uses exec to create new classes
In-Reply-To: <1222430514.93.0.950826754089.issue3974@psf.upfronthosting.co.za>
Message-ID: <1222430809.48.0.939535611026.issue3974@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
priority:  -> normal
type:  -> feature request
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3974>
_______________________________________

From report at bugs.python.org  Fri Sep 26 14:21:43 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 12:21:43 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222431703.53.0.278814832087.issue2384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

By setting lineto to 1 (as proposed ocean-city), ASCII tests (test1 
and test2, see below) works correctly. This change doesn't impact 
utf-8/iso-8859-1 charset (it's special case).

--- test1 ---
# coding: ASCII
raise Exception("here")
-------------

--- test2 ---
# useless at line 1
# coding: ASCII
raise Exception("here")
-------------

I don't know how to test a UTF-16 file. Can someone write a testcase?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 14:51:42 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 12:51:42 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222433502.74.0.46409081711.issue2384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ocean-city testcase is invalid: it uses subprocess.call() which 
returns the exit code, not the Python error line number! Here is a 
better testcase using subprocess.Popen() checking the line number but 
also the display line. It tests ASCII, UTF-8 and GBK charsets. Using 
GBK charset, you get the bug described by ocean-city (problem with 
multibyte charset). My testcase takes also care of script with # 
coding at the second line.

Added file: http://bugs.python.org/file11609/test_traceback-gbk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 15:06:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 13:06:59 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222434419.55.0.0575970598905.issue2384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, about the empty line error using a multibyte charset, the issue 
is different. PyTraceBack_Print() calls _Py_DisplaySourceLine() which 
doesn't take care of the charset.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 15:11:23 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 26 Sep 2008 13:11:23 +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: <1222434683.5.0.301382417717.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Matthew,

Did you upload a public SSH key to your Launchpad account?

You're on MS Windows, right?  I can try and do an install on an MS
Windows XP box or 2 I have lying around and see how that works, but we
should try and solve this vexing thing I've noticed about Windows
development, which is that Windows cannot understand Unix-style file
permissions, and so when I check out Python on Windows and then check it
back in, I've noticed that EVERY python and C file is "changed" by
virtue of its permissions having changed.  I would hope there's some way
to tell Bazaar to ignore 'permissions' changes because I know our edits
really have nothing to do with that.

Anyway, I'll try a few things visa-vi Windows to see if I get a similar
problem; there's also the https://answers.launchpad.net/bazaar forum
where you can post your Bazaar issues and see if the community can help.
 Search previous questions or click the "Ask a question" button and type
your subject.  Launchpad's UI is even smart enough to scan your question
title for similar ones so you may be able to find a solution right away
that way.  I use the Launchpad Answers section all the time and have
found it usually is a great way of getting help.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Sep 26 16:18:19 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Sep 2008 14:18:19 +0000
Subject: [issue3826] BaseHTTPRequestHandler depends on GC to close connections
In-Reply-To: <1222408665.97.0.977158411533.issue3826@psf.upfronthosting.co.za>
Message-ID: <ca471dc20809260718k49257f56tb433ce1736bdc598@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Thu, Sep 25, 2008 at 10:57 PM, Gregory P. Smith
<report at bugs.python.org> wrote:
> The whole socket._io_refs thing looks like a real design flaw.  What is
> its actual intended purpose?

The original purpose was to support the original semantics of the
.makefile() method on Windows which doesn't have dup() (or at least
didn't have it when this hack was first invented, many years ago). We
almost got rid of it for Py3k, but then we realized that the same
issue (sort of) exists for ssl, and that's why it's still there and
used everywhere, not just on Windows.

> When close is called on the socket object itself, the socket MSUT be
> closed.  Why is our API otherwise?

See above -- the underlying connection must remain open until the
stream created with .makefile() is also closed. (These are the
original dup-based semantics.)

Why do you say MUST? Is there an Internet standard that requires this?

> Its up to the programming to ensure that no other references to that
> socket wrapped in whatever layers will be used after that, if they are
> they'll eventually get errors when an IO occurs.

No, the .makefile() API always promised that the connection remained
open until you closed (or lost) the stream.

> I think this behavior started with this change:
>
> ------------------------------------------------------------------------
> r56714 | jeremy.hylton | 2007-08-03 13:40:09 -0700 (Fri, 03 Aug 2007) |
> 21 lines
>
> Make sure socket.close() doesn't interfere with socket.makefile().

No, it's much, much older than that. That change was probably just a
refactoring -- it's been refactored a number of times.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3826>
_______________________________________

From report at bugs.python.org  Fri Sep 26 16:39:28 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 14:39:28 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222439968.44.0.63514130227.issue3872@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

May this info help?
http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2008-02/msg01363.html

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Fri Sep 26 17:12:29 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 15:12:29 +0000
Subject: [issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header
In-Reply-To: <1222441949.55.0.46817952378.issue3975@psf.upfronthosting.co.za>
Message-ID: <1222441949.55.0.46817952378.issue3975@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyTraceBack_Print() doesn't take care of the "# coding: xxx" header of 
a Python script. It calls _Py_DisplaySourceLine() which opens the file 
as a byte stream (and not an unicode characters stream). Because of 
this problem, the traceback maybe truncated or invalid. Example (write 
it into a file and execute the file):
----
from sys import executable
from os import execvpe
filename = "pouet.py"
out = open(filename, "wb")
out.write(b"""# -*- coding: GBK -*-
print("--asc\xA1\xA7i--")
raise Exception("--asc\xA1\xA7i--")""")
out.close()
execvpe(executable, [executable, filename], None)
----

This issue depends on issue2384 (line number).

Note: Python 2.6 may also has the problem but it doesn't parse "# 
coding: GBK". So it's a different problem (issue?).

----------
messages: 73851
nosy: haypo
severity: normal
status: open
title: PyTraceBack_Print() doesn't respect # coding: xxx header
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3975>
_______________________________________

From report at bugs.python.org  Fri Sep 26 17:13:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 15:13:52 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222442032.61.0.666179985071.issue2384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch fixing this issue: it's quite the same that ocean-city 
patch, but I prefer to patch lineno only if set_readline() succeed.

About the truncated traceback for multibyte charset: see the new 
issue3975.

Added file: http://bugs.python.org/file11610/tokenizer-coding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 17:16:20 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 26 Sep 2008 15:16:20 +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: <1222442180.18.0.717863213857.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I have it working finally!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Sep 26 17:43:47 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 26 Sep 2008 15:43:47 +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: <1222443827.48.0.414156042383.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Great, Matthew!!

Now, I'm still in the process of setting up branches related to your
work; generally they should be created from a core and set of features
implemented for example:

To get from Version 2 to Version 3 of your Engine, I had to first check
out lp:~pythonregexp2.7/python/issue2636-01+09-02+17 and then "push" it
back onto launchpad as
lp:~pythonregexp2.7/python/issue2636-01+09-02+17+26.  This way the
check-in logs become coherent.

So, please hold off on checking your code in until I have your current
patch-set checked in, which I should finish by today; I also need to
rename some of the projects based on the fact that you also implemented
item 26 in most of your patches.  Actually, I keep a general To-Do list
of what I am up to on the
https://code.launchpad.net/~pythonregexp2.7/python/issue2636 whiteboard,
which you can also edit, if you want to see what I'm up to.  But I'll
try to have that list complete by today, fingers crossed!  In the mean
time, would you mind seeing if you are getting the file permissions
issue by doing a checkout or pull or branch and then calling "bzr stat"
to see if this caused Bazaar to add your entire project for checkin
because the permissions changed.  Thanks and congratulations again!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:00:54 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 26 Sep 2008 16:00:54 +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: <1222444854.81.0.268854004134.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I did a search on the permissions problem:
https://answers.launchpad.net/bzr/+question/34332.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:07:58 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Fri, 26 Sep 2008 16:07:58 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1222445278.51.0.995683863785.issue3909@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

I had a go at commenting stuff in sphinx.sty, but every change produced
another error message. In the end I concluded that the best thing is to
leave sphinx.sty untouched, despite the fact that the index is always
missing. Since I do not understand the magic of tex (or pdflatex), I
better leave it to the expert(s) to figure out how one generates perfect
PDF documentation.  Sorry for that.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:11:42 2008
From: report at bugs.python.org (Fredrik Johansson)
Date: Fri, 26 Sep 2008 16:11:42 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222445502.91.0.798795918842.issue3944@psf.upfronthosting.co.za>


Changes by Fredrik Johansson <fredrik.johansson at gmail.com>:


----------
nosy: +fredrikj

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:11:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 16:11:50 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222445510.68.0.756947452259.issue2384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh! My patch breaks "python -m". The problem is maybe no in the token 
parser but... somewhere else?
--- test.py ---
# coding: ASCII
raise Exception("line 2")
# try again!
---------------

Python 3.0 trunk unpatched:
---
$ ./python test.py
Traceback (most recent call last):
  File "test.py", line 3, in <module>

$ ./python -m test
Traceback (most recent call last):
  File "/home/haypo/prog/py3k/Lib/runpy.py", line 121, in 
_run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/haypo/prog/py3k/Lib/runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "/home/haypo/prog/py3k/test.py", line 2, in <module>
    raise Exception("line 2")
Exception: line 2
---

Python 3.0 trunk + tokenizer-coding.patch:
---
marge$ ./python test.py
Traceback (most recent call last):
  File "test.py", line 2, in <module>
    raise Exception("line 2")
Exception: line 2

Traceback (most recent call last):
  File "/home/haypo/prog/py3k/Lib/runpy.py", line 121, in 
_run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/haypo/prog/py3k/Lib/runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "/home/haypo/prog/py3k/test.py", line 1, in <module>
    # coding: ASCII
Exception: line 2
---

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:15:00 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 26 Sep 2008 16:15:00 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

I've run into a case where pprint isn't able to print out a particular 
data structure, and have distilled it down to a simple example:

import pprint

class A:
    pass

pprint.pprint({A(): 1, A(): 2})

Which throws this exception:

Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py", line 272, in _safe_repr
    items = sorted(items)
TypeError: unorderable types: A() < A()

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "foo.py", line 6, in <module>
    pprint.pprint({A(): 1, A(): 2})
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py", line 55, in pprint
    printer.pprint(object)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py", line 106, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py", line 129, in _format
    rep = self._repr(object, context, level - 1)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py", line 216, in _repr
    self._depth, level)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py", line 228, in format
    return _safe_repr(object, context, maxlevels, level)
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3
.0/pprint.py", line 277, in _safe_repr
    items = sorted(items, key=sortkey)
TypeError: unorderable types: A() < A()


This is happening because of this block of code:

        try:
            items = sorted(items)
        except TypeError:
            def sortkey(item):
                key, value = item
                return str(type(key)), key, value
            items = sorted(items, key=sortkey)

The exception block is trying to sort the items again, but in this 
instance, it's still not orderable. Could we get _safe_repr to at least 
give up on sorting at this point? Or, we could try just falling back to 
sorting according to the class name, with:

        try:
            items = sorted(items)
        except TypeError:
            def sortkey(item):
                key, value = item
                return str(type(key)), key, value
            try:
                items = sorted(items, key=sortkey)
            except TypeError:
                def sortkey(item):
                    key, value = item
                    return str(type(key))

That would at least give some ordering to the output. Unfortunately, in 
this case it's a shame that we don't have the cmp function any more, 
because then we could just fall back to giving up on the ordering for 
just certain unorderable keys, but still have sorted output for 
orderable keys. I thought maybe we could test if the key and value have 
__lt__, but it looks like all classes now have that function, even if 
the user didn't implement it. In the long run though, I suppose the case 
where you have mixed types in a dict there's no sensible ordering 
anyway.

----------
components: Library (Lib)
messages: 73858
nosy: erickt
severity: normal
status: open
title: pprint._safe_repr is not general enough in one instance
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:26:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 16:26:52 +0000
Subject: [issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header
In-Reply-To: <1222441949.55.0.46817952378.issue3975@psf.upfronthosting.co.za>
Message-ID: <1222446412.69.0.774213600705.issue3975@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a new version of _Py_DisplaySourceLine() using 
PyTokenizer_FindEncoding() to read the coding header, and 
PyFile_FromFd() to create an "unicode-awake" file. The code could be 
optimized, but it least it displays correctly the file line ;-)

The code is based on the original _Py_DisplaySourceLine() and 
call_find_module() (import.c).

Notes:
* The code is young and new, it might be delayed until python 3.1
* Some functions may raise new exceptions (eg. MemoryError). I don't 
know how Python will react if an exception is raised during 
PyTraceBack_Print() ?
* The return code is 0 for success, but is it -1 or 1 for an error? It 
looks like error is "result != 0", so both -1 and 1 should be valid. I 
used -1.

----------
keywords: +patch
Added file: http://bugs.python.org/file11611/traceback_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3975>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:27:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Sep 2008 16:27:21 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1222446441.41.0.918512347427.issue3976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another solution would be to separate the dict items by key type, try to
sort each items list with separate fallback on onsorted. Then merge the
whole thing, ordered by key type name.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:27:52 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 16:27:52 +0000
Subject: [issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header
In-Reply-To: <1222441949.55.0.46817952378.issue3975@psf.upfronthosting.co.za>
Message-ID: <1222446472.8.0.776256039394.issue3975@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11611/traceback_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3975>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:28:11 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 26 Sep 2008 16:28:11 +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: <1222446491.2.0.456540428636.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Thanks, Matthew.  My reading of that Answer is that you should be okay
because you, I assume, installed the Windows-Native package rather than
the cygwin that I first tested.  I think the problem is specific to
Cygwin as well as the circumstances described in the article.  Still, it
should be quite easy to verify if you just check out python and then do
a stat, as this will show all files whose permissions have changed as
well as general changes.  Unfortunately, I am still working on setting
up those branches, but once I finish documenting each of the branches, I
should proceed more rapidly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:28:20 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 16:28:20 +0000
Subject: [issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header
In-Reply-To: <1222441949.55.0.46817952378.issue3975@psf.upfronthosting.co.za>
Message-ID: <1222446500.91.0.0172292414858.issue3975@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(oops, first patch included an useless whitespace change)

Added file: http://bugs.python.org/file11612/traceback_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3975>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:38:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Sep 2008 16:38:04 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>
Message-ID: <1222447084.19.0.134153848245.issue3946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The rest of the patch is fine with me (I assume you've run all the unit
tests :-)).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:45:54 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 26 Sep 2008 16:45:54 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1ef034530809260945s539ef046ne619db6244d0fc18@mail.gmail.com>


Erick Tryzelaar <idadesub at users.sourceforge.net> added the comment:

fyi, I found another case where pprint needs a "safe sort", this is
when you have a list that contains a dictionary. Anyway, Here's a
simple patch that creates a _safe_sorted function that implements the
fallback:

--- /opt/local/lib/python3.0/pprint.py	2008-09-26 09:35:21.000000000 -0700
+++ /tmp/pprint.py	2008-09-26 09:35:13.000000000 -0700
@@ -145,7 +145,7 @@
                 if length:
                     context[objid] = 1
                     indent = indent + self._indent_per_level
-                    items  = sorted(object.items())
+                    items  = _safe_sorted(object.items())
                     key, ent = items[0]
                     rep = self._repr(key, context, level)
                     write(rep)
@@ -267,14 +267,7 @@
         append = components.append
         level += 1
         saferepr = _safe_repr
-        items = object.items()
-        try:
-            items = sorted(items)
-        except TypeError:
-            def sortkey(item):
-                key, value = item
-                return str(type(key)), key, value
-            items = sorted(items, key=sortkey)
+        items = _safe_sorted(object.items())
         for k, v in items:
             krepr, kreadable, krecur = saferepr(k, context, maxlevels, level)
             vrepr, vreadable, vrecur = saferepr(v, context, maxlevels, level)
@@ -321,6 +314,20 @@
     rep = repr(object)
     return rep, (rep and not rep.startswith('<')), False

+def _safe_sorted(items):
+    try:
+        return sorted(items)
+    except TypeError:
+        def sortkey(item):
+            key, value = item
+            return str(type(key)), key, value
+        try:
+            return sorted(items, key=sortkey)
+        except TypeError:
+            def sortkey(item):
+                key, value = item
+                return str(type(key))
+            return sorted(items, key=sortkey)

 def _recursion(object):
     return ("<Recursion on %s with id=%s>"

One other thing to note is that I'm also aware that the yaml project
also has this problem, and they've got their own "safe_sorted"
function. It might be worthwhile formalizing this in a public function
in the api somewhere.

----------
nosy: +idadesub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Fri Sep 26 18:58:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 16:58:06 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222448286.38.0.947549637078.issue3872@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, the sample program works with Tix8.4.3.

The procedure to rebuild Tix was removed from PCBuild/readme.txt, and
the instructions in the 2.5 version are incomplete.  Here is what I did,
after several attempts:

- downloaded and extracted following file:
http://garr.dl.sourceforge.net/sourceforge/tix/Tix8.4.3-src.tar.gz

- created file win32/python.mak with the content:
TCL_MAJOR=8
TCL_MINOR=5
TCL_PATCH=2
INSTALL_DIR=..\..\tcltk
TOOLS32=$(VCINSTALLDIR)
MKDIR=md
RMDIR=rd
!include "makefile.vc"

- then "cd Tix8.4.3\win", and compile with:
nmake -f python.mak TK_DIR=..\..\tk-8.5.2.0 TCL_DIR=..\..\tcl-8.5.2.1
TK_TMPDIR=Release_VC8 TCL_TMPDIR=Release_VC8 install

What is the procedure to have this new version merged into the msi file?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:16:06 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 17:16:06 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1222449366.24.0.408929310883.issue3623@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is this something that needs to be backported to 2.6?

Hum, here is a part of my patch which can be applied to python 2.6. I 
don't know if it fixes real bugs, but the code looks better with the 
patch: PyErr_SetObject() and Py_DECREF() should not be called with 
NULL argument.

Added file: http://bugs.python.org/file11613/_json26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:32:56 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 26 Sep 2008 17:32:56 +0000
Subject: [issue3935] bisect insort C implementation ignores methods on list
	subclasses
In-Reply-To: <1222109684.93.0.997656752515.issue3935@psf.upfronthosting.co.za>
Message-ID: <1222450376.83.0.0313714219846.issue3935@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Actually it was an optimization. PyList_Insert() was used for list and
list-derived objects.

I've attached the patch which fix the issue and for me the new code
looks even cleaner than the original code.

----------
keywords: +patch
nosy: +hdima
Added file: http://bugs.python.org/file11614/bisect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3935>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:36:03 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 17:36:03 +0000
Subject: [issue3977] Check PyInt_AsSsize_t/PyLong_AsSsize_t error
In-Reply-To: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>
Message-ID: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyLong_Ssize_t() returns -1 and set an error (OverflowError) on
overflow, but some modules don't check this case. Here is a first patch
for BytesIO() and StringIO().

----------
components: Library (Lib)
files: py3k_bytes_stringio.patch
keywords: patch
messages: 73868
nosy: haypo
severity: normal
status: open
title: Check PyInt_AsSsize_t/PyLong_AsSsize_t error
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11615/py3k_bytes_stringio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3977>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:40:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 17:40:23 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1222450823.33.0.607523184025.issue3623@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

_json26.patch looks good, and is necessary, because the called python
function has more than one way to raise an exception (KeyboardInterrupt
at least...)

I would just add another minor change: this raise_errmsg() function
should be made static.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:43:35 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 17:43:35 +0000
Subject: [issue3977] Check PyInt_AsSsize_t/PyLong_AsSsize_t error
In-Reply-To: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>
Message-ID: <1222451015.29.0.178988621816.issue3977@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a fix for struct.pack_into().

Added file: http://bugs.python.org/file11616/py3k_struct.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3977>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:44:26 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 17:44:26 +0000
Subject: [issue3977] Check PyInt_AsSsize_t/PyLong_AsSsize_t error
In-Reply-To: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>
Message-ID: <1222451066.0.0.891226753891.issue3977@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fix _bytesio of Python 2.6.

Added file: http://bugs.python.org/file11617/py26_bytesio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3977>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:46:22 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 17:46:22 +0000
Subject: [issue3977] Check PyInt_AsSsize_t/PyLong_AsSsize_t error
In-Reply-To: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>
Message-ID: <1222451182.26.0.345863979601.issue3977@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

py3k_struct.patch can be ported to python trunk: so here is the fix for
python trunk (2.6).

Added file: http://bugs.python.org/file11618/py26_struct.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3977>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:52:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 17:52:36 +0000
Subject: [issue3935] bisect insort C implementation ignores methods on list
	subclasses
In-Reply-To: <1222109684.93.0.997656752515.issue3935@psf.upfronthosting.co.za>
Message-ID: <1222451556.08.0.619376192385.issue3935@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

We could keep the optimization for the standard case:
What about simply replacing PyList_Check with PyList_CheckExact?

- most usages use plain lists, and will even run slightly faster
- list-derived objects get the desired behaviour.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3935>
_______________________________________

From report at bugs.python.org  Fri Sep 26 19:58:38 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Fri, 26 Sep 2008 17:58:38 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1222451918.25.0.0100520450931.issue3909@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

I found at least one bug:

% Detect if we're using XeLaTeX
\IfFileExists{ifxetex.sty}{%
  \RequirePackage{ifxetex}
}{% not using xelatex
  \newif\ifxetex\xetexfalse         %(line 69)
}
should say:
  \newif\ifxetex\xetexfalse\fi

That makes it possible to run through without any serious errors.

However the index is still defective. Here are the relevant line from
"reference.log" (just as an example):

"""
Writing index file reference.idx
\modindexfile=\write6

...

No file reference.ind.
[99

] (reference.aux) )
"""
Something with your suffixes seems to be incorrect, but I cannot find
it. I guess you are using a built-in macro, but you're not obeying the
filename specifications correctly. Otherwise the index should be included. 

The generated PDF looks far better, but still lacks a proper footer. The
current footer is just "Contents" (at least for reference.pdf,
documenting.pdf, extending.pdf file).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Fri Sep 26 20:04:38 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 26 Sep 2008 18:04:38 +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: <1222452278.58.0.69724742143.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Phew!  Okay, all you patches have been applied as I said in a previous
message, and you should now be able to check out
lp:~pythonregexp2.7/python/issue2636+01+09-02+17+18+19+20+21+24+26 where
you can then apply your latest known patch (rc2+7) to add a fix for the
findall / finditer bug.

However, please review my changes to:

a) lp:~pythonregexp2.7/python/issue2636-01+09-02+17
b) lp:~pythonregexp2.7/python/issue2636-01+09-02+17+26
c) lp:~pythonregexp2.7/python/issue2636-01+09-02+17+18+26
d) lp:~pythonregexp2.7/python/issue2636-01+09-02+17+18+19+20+21+26

To make sure my mergers are what your code snapshots should be.  I did
get one conflict with patch 5 IIRC where a reverse attribute was added
to the SRE_STATE struct, and get a weird grouping error when running the
tests for (a) and (b), which I think is a typo; a compile error
regarding the afore mentioned missing reverse attribute from patch 3 or
4 in (c) and the SRE_FLAG_REVERSE seems to have been lost in (d) for
some reason.

Also, if you feel like tackling any other issues, whether they have
numbers or not, and implementing them in your current development line,
please let me know so I can get all the documentation and development
branches set up.  Thanks and good luck!

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Sep 26 20:09:34 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 26 Sep 2008 18:09:34 +0000
Subject: [issue433029] SRE: posix classes aren't supported
Message-ID: <1222452574.0.0.868301631508.issue433029@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

To clarify, you mean named character sets as found in Perl and Emacs,
which are normally written, for example, like '[:ALPHANUM:]', right?  We
are working on that as Item 8 of Issue 2636: Regexp 2.7.  If not, please
clarify so I nknow what needs to be added.  Thanks!

----------
nosy: +timehorse
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433029>
_______________________________________

From report at bugs.python.org  Fri Sep 26 20:59:31 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 26 Sep 2008 18:59:31 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222455571.18.0.158204067573.issue3547@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Ok, here is an additional patch bitfields-mingw.patch.
It fixes the problem reported by rpetrov, and updates the comments.

Please review again ;-).

The previous patch bitfields-3.patch has already been applied.

Added file: http://bugs.python.org/file11619/bitfields-mingw.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Fri Sep 26 20:59:44 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 26 Sep 2008 18:59:44 +0000
Subject: [issue3290] python-config --cflags includes irrelevant flags
In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za>
Message-ID: <1222455584.21.0.310810033692.issue3290@psf.upfronthosting.co.za>


Erick Tryzelaar <idadesub at users.sourceforge.net> added the comment:

fyi, on the mac with gcc-4.2, distutils is erroring out because of the "-
Wno-long-double" it is getting from "python-config --cflags", as it's no 
longer accepted as an argument. Fortunately this can be worked around by 
doing "CC=gcc-4.0 python setup.py".

----------
nosy: +erickt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3290>
_______________________________________

From report at bugs.python.org  Fri Sep 26 21:11:11 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 19:11:11 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222456271.93.0.671774987704.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>Thread 7282896l tries to lock same object twice.
This was not cause of problem. I saw crash after one lock on another thread.

I could create the C code to reproduce crash. (reproduce.zip)
But strangely, I couldn't crash main.exe if it was built with
http://www.openssl.org/source/openssl-0.9.8h.tar.gz (same version)

I compiled openssl with "config -dCygwin" and "make". (I needed to fix
one broken link in Include dir though)

Added file: http://bugs.python.org/file11620/reproduce.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Fri Sep 26 21:23:39 2008
From: report at bugs.python.org (James Athey)
Date: Fri, 26 Sep 2008 19:23:39 +0000
Subject: [issue3978] ZipFileExt.read() can be incredibly slow
In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za>
Message-ID: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za>


New submission from James Athey <james.athey at gmail.com>:

I've created a patch that improves the decompression performance of
zipfile.py by up to two orders of magnitude.

In ZipFileExt.read(), decompressed bytes waiting to be read() sit in a
string buffer, self.readbuffer.  When a piece of that string is read,
the string is split in two, with the first piece being returned, and the
second piece becoming the new self.readbuffer.  Each of these two pieces
must be allocated space and have their contents copied into them.  When
the length of the readbuffer far exceeds the number of bytes requested,
allocating space for the two substrings and copying in their contents
becomes very expensive.

The attached zeroes.zip demonstrates a worst-case scenario for this
problem.  It contains one 100 MiB file filled with zeroes.  This file
compresses to just 100 KiB, however, because it is so repetitive.  This
repetitive data means that the zlib decompressor returns many MiBs of
uncompressed data when fed just 64 KiB of compressed data.  Each call to
read() requests only 16 KiB, so each call must reallocate and copy many
MiBs.

The attached patch makes the read buffer a StringIO instead of a string.
  Each call to the decompressor creates a new StringIO buffer.  Reading
from the StringIO does not create a new string for the unread data. 
When the buffer has been exhausted, a new StringIO is created with the
next batch of uncompressed bytes.

The patch also fixes the behavior of zipfile.py when called as a script
with the -e flag.  Before, to extract a file, it decompressed the entire
file to memory, and then wrote the entire file to disk.  This behavior
is undesirable if the decompressed file is even remotely large.  Now, it
uses ZipFile.extractall(), which correctly streams the decompressed data
to disk.

unzip vs. Python's zipfile.py vs. patched zipfile.py:

$ time unzip -e zeroes.zip
Archive:  zeroes.zip
  inflating: zeroes_unzip/zeroes

real    0m0.707s
user    0m0.463s
sys     0m0.244s

$ time python zipfileold.py -e zeroes.zip zeroes_old

real    3m42.012s
user    0m57.670s
sys     2m43.510s

$ time python zipfile.py -e zeroes.zip zeroes_patched

real    0m0.986s
user    0m0.409s
sys     0m0.490s

In this test, the patched version is 246x faster than the unpatched
version, and is not far off the pace of the C version.

Incidentally, this patch also improves performance when the data is not
repetitive.  I tested a ZIP containing a single compressed file filled
with random data, created by running
$ dd if=/dev/urandom of=random bs=1024 count=1024
$ zip random.zip random
This archive demonstrates the opposite scenario - where compression has
next to no impact on file size, and the read buffer will never be
dramatically larger than the amount of data fed to the zlib decompressor.

$ time python zipfileold.py -e random.zip random_old

real    0m0.063s
user    0m0.053s
sys     0m0.010s

$ time python zipfile.py -e random.zip random_patched

real    0m0.059s
user    0m0.047s
sys     0m0.012s

----------
components: Extension Modules
files: zipfile_read_perf.patch
keywords: patch
messages: 73880
nosy: lightstruk
severity: normal
status: open
title: ZipFileExt.read() can be incredibly slow
type: performance
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11621/zipfile_read_perf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3978>
_______________________________________

From report at bugs.python.org  Fri Sep 26 21:24:27 2008
From: report at bugs.python.org (James Athey)
Date: Fri, 26 Sep 2008 19:24:27 +0000
Subject: [issue3978] ZipFileExt.read() can be incredibly slow
In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za>
Message-ID: <1222457067.7.0.487557104692.issue3978@psf.upfronthosting.co.za>


Changes by James Athey <james.athey at gmail.com>:


Added file: http://bugs.python.org/file11622/zeroes.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3978>
_______________________________________

From report at bugs.python.org  Fri Sep 26 21:48:35 2008
From: report at bugs.python.org (Dmitry Vasiliev)
Date: Fri, 26 Sep 2008 19:48:35 +0000
Subject: [issue3935] bisect insort C implementation ignores methods on list
	subclasses
In-Reply-To: <1222109684.93.0.997656752515.issue3935@psf.upfronthosting.co.za>
Message-ID: <1222458515.82.0.721591226604.issue3935@psf.upfronthosting.co.za>


Dmitry Vasiliev <dima at hlabs.spb.ru> added the comment:

Good idea! Don't know why I didn't use it in the very first version. :-)

New patch attached.

Added file: http://bugs.python.org/file11623/bisect2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3935>
_______________________________________

From report at bugs.python.org  Fri Sep 26 21:55:54 2008
From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=)
Date: Fri, 26 Sep 2008 19:55:54 +0000
Subject: [issue3979] Doctest failing when it should pass
In-Reply-To: <1222458954.88.0.967715209802.issue3979@psf.upfronthosting.co.za>
Message-ID: <1222458954.88.0.967715209802.issue3979@psf.upfronthosting.co.za>


New submission from J. Pablo Fern?ndez <pupeno at pupeno.com>:

The attached file contains a function and two tests for it which are
essentially the same. One is a doctest and the other is a TestCase. The
doctest fails and I believe it shouldn't.

Here's what I get:

$ python failingdoctest.py 
**********************************************************************
File "../../provizora/failingdoctest.py", line 8, in __main__._to_xsistemo
Failed example:
    _to_xsistemo(u"????????????")
Expected:
    'CxcxGxgxHxhxJxjxSxsxUxux'
Got:
   
"u'\\xc4\\x88\\xc4\\x89\\xc4\\x9c\\xc4\\x9d\\xc4\\xa4\\xc4\\xa5\\xc4\\xb4\\xc4\\xb5\\xc5\\x9c\\xc5\\x9d\\xc5\\xac\\xc5\\xad'"
**********************************************************************
1 items had failures:
   1 of   1 in __main__._to_xsistemo
***Test Failed*** 1 failures.
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK


Thank you.

----------
components: Library (Lib)
files: failingdoctest.py
messages: 73882
nosy: pupeno
severity: normal
status: open
title: Doctest failing when it should pass
versions: Python 2.5
Added file: http://bugs.python.org/file11624/failingdoctest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3979>
_______________________________________

From report at bugs.python.org  Fri Sep 26 22:24:45 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 20:24:45 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222460685.93.0.836917120052.issue2384@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Victor, this is fp_setreadl's problem, so if put "tok->lineno = -1"
anywhere, it should be in fp_setreadl(), I think.

	r = set_readline(tok, cs);
	if (r) {
		/* 1 */
		tok->encoding = cs;
		tok->decoding_state = STATE_NORMAL;

At /* 1 */, set_readline could be buf_setreadl(), and fp_setreadl is
called elsewhere.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 22:29:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Sep 2008 20:29:35 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1222460975.93.0.884106296429.issue3909@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If that solves the problem, that is very curious indeed. There must not
be a \fi after \newif; its syntax is

\newif\ifname\default

Later it can be used as \ifname ... \fi.

What TeX distribution and version of tex/latex are you using?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Fri Sep 26 22:32:42 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 20:32:42 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222461162.58.0.41274257572.issue1706863@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

>extra changes that has to go in a
>specific compiler class. As example platform can be any but compiler
>gcc(mingw) that produce executables for windows host platform.

You are right. It should be. My patch is just one choice when switching
back to CygwinCCompiler is difficult. (Anyway I don't understand well
why CygwinCCompiler was abandoned)

>it would be better to put Cygwin specific behavior 
>in CygwinCCompiler, I think the changes would have be more invasive if 
>you did.

Agreed.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Fri Sep 26 22:59:38 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 20:59:38 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222462778.98.0.0910944732692.issue3947@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

So it is a "Vendor OS problem", python is not involved.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:01:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 26 Sep 2008 21:01:34 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1222448286.38.0.947549637078.issue3872@psf.upfronthosting.co.za>
Message-ID: <48DD4DAA.7020201@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What is the procedure to have this new version merged into the msi file?

The version of Tix being used is the one in the Subversion externals
directory. See the subversion log for a complete list of changes; most
specifically, win/python9.mak is used to compile it. See
PCbuild/build_tkinter.py for a build procedure that might work.

There is no persistent (svn-commitable) procedure to get a newer Tix
version into the MSI file; I need to replace the Tix version that I
currently have on my disk with a newer one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:08:17 2008
From: report at bugs.python.org (Alan Gardner)
Date: Fri, 26 Sep 2008 21:08:17 +0000
Subject: [issue3980] win32file.GetCommState incorrect handling of DCB
In-Reply-To: <1222463297.39.0.178398084348.issue3980@psf.upfronthosting.co.za>
Message-ID: <1222463297.39.0.178398084348.issue3980@psf.upfronthosting.co.za>


New submission from Alan Gardner <agardner at whoi.edu>:

I believe I have found a bug in win32file.GetCommState and
win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5,
running an older version of pywin32, as well as the current (212)
version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper
for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python
after having that port open in Procomm (an old, no longer supported
terminal program).  I have only seen it happen with a particular brand
of USB to serial converters (Edgeport, made by Digi).  In these
conditions the python script will hang at the win32file.SetCommState()
command, usually timing out after 5-30 seconds, and quitting with no
error message.

After having done some probing I think I basically understand the
problem, and have a workaround, but I lack the know-how to fix it where
it should be fixed, in win32file.  When Procomm opens the port, it sets
XoffLim to 16128 and the XonLim to 15872.  When my script (actually,
serialwin32.py from pyserial) tries to open the port it first reads the
DCB with GetCommState(), changes baud rate, etc in the local PyDCB
object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or
XonLim >4096.  For example, if I try to execute

DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then
that DCB is passed to SetCommState, the script hangs for several seconds
before exiting without opening the port and with no error message.  For
example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling
SetCommState, then it works fine.  For example, after having opened and
closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have
incorporated this fix into serialwin32.py which is working for me now,
but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does
to the PyDCB to make it cause SetCommState to fail so dramatically.  I
also don't understand why I only see this problem with the Edgeport USB
converters, and not with several other USB converters or hardware serial
ports.  Maybe someone with a more intimate understanding of Python and
Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

----------
components: Extension Modules, Windows
messages: 73888
nosy: jiaailun
severity: normal
status: open
title: win32file.GetCommState incorrect handling of DCB
type: crash
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3980>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:20:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 21:20:14 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222464014.88.0.11142512789.issue2384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@ocean-city: Oops, sorry. Using your patch (set lineno in
fp_setreadl()), it works on both cases ("python test.py" or "python -m
test").

The new patch includes your fix for tokenizer.c and a new version of the
testcase.

Added file: http://bugs.python.org/file11625/tokenizer-coding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:24:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Sep 2008 21:24:53 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>
Message-ID: <1222464293.12.0.404270371915.issue3946@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm actually having a hard time trying to get memoryview to use
PyObject_CheckReadBuffer. Eventually, test should be written in C, but
for now are you ok with the compile test?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:34:05 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 26 Sep 2008 21:34:05 +0000
Subject: [issue3980] win32file.GetCommState incorrect handling of DCB
In-Reply-To: <1222463297.39.0.178398084348.issue3980@psf.upfronthosting.co.za>
Message-ID: <1222464845.19.0.0554488773665.issue3980@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is the bug tracker for the Python Core project. Please report
problems with win32file to the Python-Win32 project
(http://sourceforge.net/projects/pywin32)

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed
versions: +3rd party -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3980>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:40:30 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 26 Sep 2008 21:40:30 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222465230.62.0.542748412286.issue3547@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Flag start only with one minus: -mms-bitfields
Fine with me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:43:35 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 26 Sep 2008 21:43:35 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222465415.41.0.2536095131.issue1706863@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

no objections

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:48:33 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Sep 2008 21:48:33 +0000
Subject: [issue3979] Doctest failing when it should pass
In-Reply-To: <1222458954.88.0.967715209802.issue3979@psf.upfronthosting.co.za>
Message-ID: <1222465713.85.0.6504698985.issue3979@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You need to make your docstring a unicode string. Then both tests work
for me.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3979>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:49:06 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 21:49:06 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222465746.9.0.922869317747.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I noticed another bit. If main.exe is linked to libssl.dll.a and
libcrypto.dll.a it will crash, but linked to libssl.a and libcrypto.a it
won't crash. (I renamed *.dll.a temporary)

I'll try to build http://www.openssl.org/source/openssl-0.9.8h.tar.gz
with shared mode if possible.

>So it is a "Vendor OS problem", python is not involved.

Yes, possibly. Because other platform is not crashing on buildbot.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:49:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Sep 2008 21:49:40 +0000
Subject: [issue3946] PyObject_CheckReadBuffer crashes on memoryview object
In-Reply-To: <1222178158.76.0.378001331035.issue3946@psf.upfronthosting.co.za>
Message-ID: <1222465780.59.0.831034588792.issue3946@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66630.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3946>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:54:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Sep 2008 21:54:47 +0000
Subject: [issue3971] s_push: parser stack overflow MemoryError
In-Reply-To: <1222421013.17.0.704872075163.issue3971@psf.upfronthosting.co.za>
Message-ID: <1222466087.64.0.0649149212654.issue3971@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This really abuse of the parser. If you really need this, you can bump
MAXSTACK in Parser/parser.h to a higher number.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3971>
_______________________________________

From report at bugs.python.org  Fri Sep 26 23:57:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Sep 2008 21:57:32 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>
Message-ID: <1222466252.72.0.578525042854.issue3967@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I think the patch is good.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:17:25 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:17:25 +0000
Subject: [issue3664] Pickler.dump from a badly initialized Pickler segfaults
In-Reply-To: <1219609595.23.0.140986466622.issue3664@psf.upfronthosting.co.za>
Message-ID: <1222467445.18.0.454870524313.issue3664@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3664>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:17:43 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:17:43 +0000
Subject: [issue3661] sys.call_tracing segfaults
In-Reply-To: <1219606145.44.0.504923400807.issue3661@psf.upfronthosting.co.za>
Message-ID: <1222467463.45.0.152705657697.issue3661@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3661>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:17:59 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Fri, 26 Sep 2008 22:17:59 +0000
Subject: [issue3909] Building PDF documentation from tex files
In-Reply-To: <1221842807.23.0.726390591277.issue3909@psf.upfronthosting.co.za>
Message-ID: <1222467479.1.0.376975766248.issue3909@psf.upfronthosting.co.za>


Winfried Plappert <Winfried.Plappert at gmx.de> added the comment:

I just tested it under Linux/Ubuntu and it is the same behaviour as
described earlier: fix line 69 in sphinx.sty and it works. My pdflatex
version on Windows (MiKTeX) has been mentioned in my first entry and the
version for Ubuntu is (TeX-live):

pdfTeX 3.1415926-1.40.9-2.2 (Web2C 7.5.7)
kpathsea version 3.5.7
Copyright 2008 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
Kpathsea is copyright 2008 Karl Berry and Olaf Weber.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
Kpathsea written by Karl Berry, Olaf Weber, and others.
Compiled with libpng 1.2.29; using libpng 1.2.29
Compiled with zlib 1.2.3; using zlib 1.2.3
Compiled with xpdf version 3.02pl2

I include all reference.* files (apart from reference.tex) in zipped format.

Added file: http://bugs.python.org/file11626/reference.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3909>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:18:07 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:18:07 +0000
Subject: [issue1210] imaplib does not run under Python 3
In-Reply-To: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
Message-ID: <1222467487.08.0.991933082615.issue1210@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:18:23 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:18:23 +0000
Subject: [issue3775] Update RELNOTES file
In-Reply-To: <1220536018.76.0.0823799232176.issue3775@psf.upfronthosting.co.za>
Message-ID: <1222467503.43.0.280095904602.issue3775@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3775>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:18:34 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:18:34 +0000
Subject: [issue3574] compile() cannot decode Latin-1 source encodings
In-Reply-To: <1218933580.53.0.0614369271998.issue3574@psf.upfronthosting.co.za>
Message-ID: <1222467514.8.0.400556699148.issue3574@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3574>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:18:51 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:18:51 +0000
Subject: [issue1717] Get rid of more refercenes to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <1222467531.11.0.796350839756.issue1717@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:19:04 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:19:04 +0000
Subject: [issue3799] Byte/string inconsistencies between different dbm modules
In-Reply-To: <1220738372.55.0.492476136204.issue3799@psf.upfronthosting.co.za>
Message-ID: <1222467544.68.0.777957739328.issue3799@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3799>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:19:23 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:19:23 +0000
Subject: [issue3787] Make PyInstanceMethod_Type available or remove it
In-Reply-To: <1220640720.16.0.546689222531.issue3787@psf.upfronthosting.co.za>
Message-ID: <1222467563.81.0.533229639551.issue3787@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3787>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:19:38 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:19:38 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1222467578.3.0.0728116339631.issue3685@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:19:53 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:19:53 +0000
Subject: [issue3626] python3.0 interpreter on Cygwin ignores all arguments
In-Reply-To: <1219293362.56.0.98048679745.issue3626@psf.upfronthosting.co.za>
Message-ID: <1222467593.19.0.0990482873318.issue3626@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3626>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:20:09 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:20:09 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222467609.59.0.953021016332.issue3187@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:20:23 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:20:23 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1222467623.81.0.386257868608.issue3781@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:20:37 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:20:37 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1222467637.38.0.0642876545203.issue3886@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:20:51 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:20:51 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1222467651.37.0.312627541099.issue3623@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:21:04 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 26 Sep 2008 22:21:04 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222467664.36.0.906263367476.issue3723@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:25:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Sep 2008 22:25:32 +0000
Subject: [issue3886] Integer overflow in _hashopenssl.c (CVE-2008-2316)
In-Reply-To: <1221613334.0.0.249004634041.issue3886@psf.upfronthosting.co.za>
Message-ID: <1222467932.62.0.384671403502.issue3886@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm going to close this because 2.5, 2.6, and 3.0 have been patched.
Gregory, if you're concerned about 2.4, I think you should make a
different issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3886>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:27:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 22:27:24 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222468044.62.0.634172977678.issue3947@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think I have a beginning of an explanation:
libssl.dll implements a DllMain function, whose DLL_THREAD_DETACH event 
calls ERR_remove_state. 
At this time, the (posix) thread function has already exited; 
pthread::exit() was already called the pthread object has been deleted.

And the same (win32) thread will call sem_wait()... and maybe access 
freed resources.

Linking against the static library does not have this problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:38:36 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 26 Sep 2008 22:38:36 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1222468716.34.0.533392603049.issue3299@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:45:09 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 22:45:09 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>
Message-ID: <1222469109.1.0.297487090435.issue3967@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in Python trunk, rev66631, by amaury.forgeotdarc.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Sat Sep 27 00:49:59 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 22:49:59 +0000
Subject: [issue3967] bytearray().count()
In-Reply-To: <1222378773.15.0.652876026067.issue3967@psf.upfronthosting.co.za>
Message-ID: <1222469399.3.0.724591529053.issue3967@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed in trunk: r66631, in release25-maint: r66632 and py3k: r66633.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3967>
_______________________________________

From report at bugs.python.org  Sat Sep 27 01:04:39 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 23:04:39 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222470279.03.0.992973518628.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for great explanation! Probably you are right... I'll look
into the code.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Sat Sep 27 01:36:56 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 23:36:56 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222472216.07.0.0506597070411.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Maybe I can fix this openssl bug with pthread_cleanup_push, but this is
openssl bug, we cannot fix it directly.

I propose to commit workaround in msg73649 for 2.6 release.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Sat Sep 27 01:37:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Sep 2008 23:37:33 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1222472253.48.0.0822208682672.issue3892@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Sat Sep 27 01:52:50 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Sep 2008 23:52:50 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222473170.34.0.673690084255.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

And after openssl will be fixed, change it to

#if defined(WITH_THREAD) && !(defined(__CYGWIN__) &&
OPENSSL_VERSION_NUMBER < ???)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Sat Sep 27 01:58:42 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 23:58:42 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222473522.47.0.630809299143.issue3872@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I join two patches:

- the first applies to the "official" tix-8.4.3 source tree, and 
modifies the makefiles: adapt to new naming scheme for tcl/tk files and 
directories, embed manifest file...

- the other updates build_tkinter.py to build tcl-8.5.2.1, tk-8.5.2.0 
and tix-8.4.3. More options were needed. Tested on win32 with vs9 
express, Release & Debug modes.

At the end of the day, the given test_combotix.py passes (and displays a 
combobox in a small window!)

----------
keywords: +patch
Added file: http://bugs.python.org/file11627/tix843.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Sat Sep 27 01:59:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Sep 2008 23:59:44 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222473584.41.0.897403615227.issue3872@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Added file: http://bugs.python.org/file11628/build_tkinter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Sat Sep 27 02:05:05 2008
From: report at bugs.python.org (Simon Cross)
Date: Sat, 27 Sep 2008 00:05:05 +0000
Subject: [issue3932] HTMLParser cannot handle '&' and non-ascii characters in
	attribute names
In-Reply-To: <1222086790.7.0.800001604957.issue3932@psf.upfronthosting.co.za>
Message-ID: <1222473905.31.0.0477163115872.issue3932@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

I can't reproduce this on current trunk (r66633, 27 Sep 2008). I checked
sys.getdefaultencoding() but that returned 'ascii' as expected and I
even tried language Python with "LANG=C ./python" but that didn't fail
either. Perhaps this has been fixed? It looks like it might originally
have been a problem in the re module from the traceback.

----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3932>
_______________________________________

From report at bugs.python.org  Sat Sep 27 02:47:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 00:47:29 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222476449.76.0.103882147516.issue3187@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. Here's another possibility. It adds another optional parameter to
listdir. If False, bytes strings can be returned. Otherwise, the
UnicodeDecodeError is reraised.

Added file: http://bugs.python.org/file11629/force_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 02:48:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 00:48:16 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222476496.2.0.601009555276.issue3187@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Removed file: http://bugs.python.org/file11629/force_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 02:48:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 00:48:24 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222476504.7.0.250563128047.issue3187@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file11630/force_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 03:15:46 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 27 Sep 2008 01:15:46 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1222476449.76.0.103882147516.issue3187@psf.upfronthosting.co.za>
Message-ID: <ca471dc20809261815k3127415fs9412df81e8716801@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Fri, Sep 26, 2008 at 5:47 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
> Ok. Here's another possibility. It adds another optional parameter to
> listdir. If False, bytes strings can be returned. Otherwise, the
> UnicodeDecodeError is reraised.

I don't see the advantage over the existing rule bytes in -> bytes out...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 03:23:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 01:23:01 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222478581.3.0.29523959876.issue3187@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Does that mean that the right thing to do is raise decoding errors when
unicode is given and fix the path modules so they can use bytes?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 03:38:00 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 27 Sep 2008 01:38:00 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1222479480.35.0.450042285328.issue3892@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I need some MS Windows user able to replicate this issue locally (not in
the buildbot). Oracle people need to do some test and I would like to
avoid to mess with builtbots.

Please, help!.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Sat Sep 27 04:20:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 02:20:35 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222482034.98.0.612267108264.issue3939@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Excellent! Barry gave me permission to put this in 2.6, so I'll do so soon.

----------
versions: +Python 2.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Sat Sep 27 04:24:14 2008
From: report at bugs.python.org (Nick Edds)
Date: Sat, 27 Sep 2008 02:24:14 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za>
Message-ID: <1222482254.99.0.275762814977.issue3358@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

What do you think would be the best way to implement a test for this? To
test it, I ran it on a known file that caused the old recursive method
to fail, but I don't know if it makes sense to include that with the
tests. I could always write a test to verify that the iterative element
works, but as for testing the transition from recursive to iterative
when the recursion limit is exceeded, do you think that is something I
should do, and is there a better way than simply including the file that
I know causes the recursion limit to be exceeded?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Sat Sep 27 04:25:09 2008
From: report at bugs.python.org (Nick Edds)
Date: Sat, 27 Sep 2008 02:25:09 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1222482309.61.0.870337782653.issue2876@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

I have the functionality for this working, and will post it tomorrow
when I complete its test suite.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Sat Sep 27 04:36:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 02:36:00 +0000
Subject: [issue3358] 2to3 Iterative Wildcard Matching
In-Reply-To: <1222482254.99.0.275762814977.issue3358@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809261935wd04836ep18b7ec7d653559a2@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Fri, Sep 26, 2008 at 9:24 PM, Nick Edds <report at bugs.python.org> wrote:
>
> Nick Edds <nedds at uchicago.edu> added the comment:
>
> What do you think would be the best way to implement a test for this? To
> test it, I ran it on a known file that caused the old recursive method
> to fail, but I don't know if it makes sense to include that with the
> tests. I could always write a test to verify that the iterative element
> works, but as for testing the transition from recursive to iterative
> when the recursion limit is exceeded, do you think that is something I
> should do, and is there a better way than simply including the file that
> I know causes the recursion limit to be exceeded?

I recommend generating a deeply nested structure and/or using
sys.setrecursionlimit to make the recursion limit artificially low,
and testing that refactoring works as planned.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3358>
_______________________________________

From report at bugs.python.org  Sat Sep 27 04:50:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 02:50:26 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222483826.37.0.364210154795.issue3939@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Commited in r66634.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Sat Sep 27 04:51:30 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Sep 2008 02:51:30 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222483890.46.0.536317141973.issue3770@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looking at mp.synchronize, the whole module really does depend on a
working _multiprocessing.SemLock instance. If these platforms don't have
a native semaphore implementation, what is their basic inter-process
synchronisation primitive?

Once that is identified, then it should be possible to code either a C
or Python semaphore implementation based on that primitive.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Sat Sep 27 05:44:11 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 27 Sep 2008 03:44:11 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222487051.5.0.799960312053.issue3947@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

That workaround leaves unused function warning. This patch is revised patch.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11631/disable_setup_ssl_threads_on_cygwin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Sat Sep 27 10:53:21 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 27 Sep 2008 08:53:21 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails on Windows sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1222505601.61.0.778438747139.issue3892@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I reproduce the test failure very consistently, on both win2k and winXP, 
and may be of some help to test stuff.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Sat Sep 27 13:49:38 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Sep 2008 11:49:38 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222516178.08.0.407392126772.issue3187@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11189/filename.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 13:49:42 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Sep 2008 11:49:42 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222516182.11.0.170404194629.issue3187@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11210/invalid_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 14:38:50 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Sep 2008 12:38:50 +0000
Subject: [issue3978] ZipFileExt.read() can be incredibly slow
In-Reply-To: <1222457019.27.0.267576306603.issue3978@psf.upfronthosting.co.za>
Message-ID: <1222519130.57.0.984760561796.issue3978@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Very interesting, but it will have to wait for 2.7/3.1. 2.6 and 3.0 are
in the final phases of the release process.

----------
nosy: +pitrou
priority:  -> normal
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3978>
_______________________________________

From report at bugs.python.org  Sat Sep 27 15:21:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 27 Sep 2008 13:21:10 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1222521670.28.0.220737046018.issue3872@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. I have now integrated this patch into
externals/tix-8.4.3.1 (along with a patch to compile it for AMD64). Demo
installers including this code are available at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-2.6.14149.msi
http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-2.6.14149.amd64.msi

I'm skeptical about the build_tkinter patch. It seems fairly invasive,
so I'd rather defer it until after the release.

----------
priority: critical -> normal
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3872>
_______________________________________

From report at bugs.python.org  Sat Sep 27 15:54:28 2008
From: report at bugs.python.org (bahiminin)
Date: Sat, 27 Sep 2008 13:54:28 +0000
Subject: [issue3981] Python 3, IDLE does not start
In-Reply-To: <1222523668.6.0.778163110852.issue3981@psf.upfronthosting.co.za>
Message-ID: <1222523668.6.0.778163110852.issue3981@psf.upfronthosting.co.za>


New submission from bahiminin <art.wyse11 at gmail.com>:

I have Windows XP with Live OneCare as protection. Python 3 IDLE won't
start because of sub-process issues while Python 2.5.2 IDLE does start
without any problem.

----------
messages: 73923
nosy: dah
severity: normal
status: open
title: Python 3, IDLE does not start
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3981>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:20:42 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:20:42 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1222525242.78.0.901476711335.issue3665@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:23:14 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:23:14 +0000
Subject: [issue3482] re.split, re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1222525394.48.0.252184958433.issue3482@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:25:42 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:25:42 +0000
Subject: [issue3482] re.split, re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1222525542.15.0.260426238865.issue3482@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:26:26 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:26:26 +0000
Subject: [issue3299] invalid object destruction in re.finditer()
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1222525586.68.0.858720415825.issue3299@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:27:18 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:27:18 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1222525638.79.0.516993828161.issue3665@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:36:36 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:36:36 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1222526196.18.0.24345775989.issue1519638@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:39:08 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:39:08 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1222526348.39.0.726621101304.issue1519638@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:42:27 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 27 Sep 2008 14:42:27 +0000
Subject: [issue1662581] the re module can perform poorly: O(2**n) versus
	O(n**2)
Message-ID: <1222526547.19.0.62410630602.issue1662581@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662581>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:45:47 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sat, 27 Sep 2008 14:45:47 +0000
Subject: [issue433029] SRE: posix classes aren't supported
Message-ID: <1222526747.39.0.780229494885.issue433029@psf.upfronthosting.co.za>


Fredrik Lundh <effbot at users.sourceforge.net> added the comment:

Yes, this refers to the POSIX character classes as described here:

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html

(Ideally, there should be an (internal) API that lets you register class 
definitions from the Python level.)

Support for Unicode properties could perhaps be addressed at the same 
time:

http://unicode.org/unicode/reports/tr18/#Basic_Unicode_Support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433029>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:50:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Sep 2008 14:50:30 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222527030.64.0.263092685355.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

getcwd() fails with "NOT FOUNT" (not foun*d*?) if the current 
directory filename can't be converted to unicode (str type). Here is a 
patch to fallback to bytes if creation of the unicode failed.

Added file: http://bugs.python.org/file11632/getcwd_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 16:52:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Sep 2008 14:52:59 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222527179.19.0.480669350534.issue2384@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11610/tokenizer-coding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Sat Sep 27 17:12:06 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Sat, 27 Sep 2008 15:12:06 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222528326.7.0.602635776173.issue3187@psf.upfronthosting.co.za>


Dwayne Litzenberger <dlitz at dlitz.net> added the comment:

On Sat, Sep 27, 2008 at 01:15:46AM +0000, Guido van Rossum wrote:
> I don't see the advantage over the existing rule bytes in -> bytes out...

Guido,

I figure I should say something since I have some experience in this area.

I wrote some automatic backup software in Python 2 earlier this year.  It
had to work on ext3/Linux (where filenames are natively octet-strings) and
on NTFS/Win32 (where filenames are natively unicode-strings).  I had to be
ridiculously careful to always use unicode paths on Win32, and to always
use str paths on Linux, because otherwise Python would do the conversion
automatically---poorly.

It was particularly bad on Win32, where if you used os.listdir() with a
non-unicode path (Python 2.x str object) in a directory that contained
non-ascii filenames, Windows would invent filenames that looked similar but
couldn't actually be found when using open().  So, naive (Python 2) code
like this would break:

    for filename in os.listdir("."):
        f = open(filename, "rb")
        # ...

On Linux, it was bad too, since if you used unicode paths, the filenames
actually opened would depend on your LANG or LC_CTYPE or LC_ALL environment
variables, and those could vary from one system to another, or even from
one invocation of the program to another.

The simple fact of the matter is that pathnames on Linux are _not_ Unicode,
and pathnames on Windows are _not_ octet strings.  They're fundamentally
incompatible types that can only be reconciled when you make assumptions
(e.g. specifying a character encoding) that allow you to convert from one
to the other.

Ideally, io.open(), os.listdir(), os.path.*, etc. would accept _only_
pathnames in their native format, and it would be the job of a wrapper to
provide a portable-but-less-robust interface on top of that.  Perhaps the
built-in functions would use the wrapper (with reasonable defaults), but
the native-only interface should be there for module-writers who want
robust pathname handling.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sat Sep 27 17:21:56 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Sep 2008 15:21:56 +0000
Subject: [issue2832] Line numbers reported by extract_stack are offset by the
	#-*- encoding line
In-Reply-To: <1210567925.19.0.359554733284.issue2832@psf.upfronthosting.co.za>
Message-ID: <1222528916.13.0.518076923952.issue2832@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This bug is a duplicate of the issue 2384: I tried your example with 
the patch tokenizer-coding-2.patch and your bug is fixed:
 * first example (no coding): this is line 3
 * second example (with coding): this is line 4

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2832>
_______________________________________

From report at bugs.python.org  Sat Sep 27 17:27:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Sep 2008 15:27:30 +0000
Subject: [issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header
In-Reply-To: <1222441949.55.0.46817952378.issue3975@psf.upfronthosting.co.za>
Message-ID: <1222529250.78.0.149487215152.issue3975@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, my first version introduces a regression: if file open fails, 
the traceback printing was stopped. Here is a new version of my patch 
to support #coding: header in _Py_DisplaySourceLine(). It doesn't 
print the line of file open fails, but continue to display the end of 
the traceback.

But print still stops on PyFile_WriteObject() or PyFile_WriteString(). 
If PyFile fails, I guess that next print will also fails. (it's also 
the current behaviour of PyTraceBack_Print).

Example:
----
Python 3.0rc1+ (py3k:66643M, Sep 27 2008, 17:11:51)
>>> raise Exception('err')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Exception: err
----

The line is not displayed (why? no idea), but the exception 
("Exception: err") is still displayed.

Added file: http://bugs.python.org/file11633/traceback_unicode-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3975>
_______________________________________

From report at bugs.python.org  Sat Sep 27 17:31:13 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Sep 2008 15:31:13 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1222529473.32.0.0200919959855.issue2384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue 2832 is a duplicate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2384>
_______________________________________

From report at bugs.python.org  Sat Sep 27 17:32:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 15:32:44 +0000
Subject: [issue2832] Line numbers reported by extract_stack are offset by the
	#-*- encoding line
In-Reply-To: <1210567925.19.0.359554733284.issue2832@psf.upfronthosting.co.za>
Message-ID: <1222529564.38.0.750217232272.issue2832@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> [Py3k] line number is wrong after encoding declaration

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2832>
_______________________________________

From report at bugs.python.org  Sat Sep 27 17:38:03 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Sat, 27 Sep 2008 15:38:03 +0000
Subject: [issue3740] PEP 3121 --- module state is not nul-initalized as
	claimed in the PEP
In-Reply-To: <1220109289.56.0.0975805859845.issue3740@psf.upfronthosting.co.za>
Message-ID: <1222529883.24.0.523820363365.issue3740@psf.upfronthosting.co.za>


Paul Pogonyshev <pogonyshev at gmx.net> added the comment:

Ping.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3740>
_______________________________________

From report at bugs.python.org  Sat Sep 27 17:50:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 15:50:41 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

I just working on porting some networking code from 2.x to 3.x and it
heavily uses string formatting. Since bytes don't support any kind of
formatting, it's becoming tedious and inelegant to do it with "+". Can
.format be supported in bytes?

[I understand format is implemented with stringlib so shouldn't it be
fairly easy to implement?]

----------
components: Interpreter Core
messages: 73931
nosy: benjamin.peterson, eric.smith
priority: normal
severity: normal
status: open
title: support .format for bytes
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Sep 27 18:02:40 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Sep 2008 16:02:40 +0000
Subject: [issue3740] PEP 3121 --- module state is not nul-initalized as
	claimed in the PEP
In-Reply-To: <1220109289.56.0.0975805859845.issue3740@psf.upfronthosting.co.za>
Message-ID: <1222531360.15.0.344991946194.issue3740@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The state (md_state) is set to NULL in PyModule_New(name). However
PyModule_Create(mod) allocates memory iff the module size (m_size) isn't 0.

----------
components: +Documentation
nosy: +christian.heimes
priority:  -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3740>
_______________________________________

From report at bugs.python.org  Sat Sep 27 18:27:31 2008
From: report at bugs.python.org (Nick Edds)
Date: Sat, 27 Sep 2008 16:27:31 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1222532851.53.0.417111334605.issue2876@psf.upfronthosting.co.za>


Nick Edds <nedds at uchicago.edu> added the comment:

Here is a fixer and test suite for the UserDict. It doesn't do a very
good job handling imports with 'as' right now, but it's core
functionality appears to be working. If I get a chance I will improve
its handling of 'as' cases at some point in the future, but I think this
is an alright start. It passes all tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file11634/fix_userdict.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Sat Sep 27 19:33:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 27 Sep 2008 17:33:08 +0000
Subject: [issue3981] Python 3, IDLE does not start
In-Reply-To: <1222523668.6.0.778163110852.issue3981@psf.upfronthosting.co.za>
Message-ID: <1222536788.61.0.843027083396.issue3981@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please be more specific what precise version you have been trying?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3981>
_______________________________________

From report at bugs.python.org  Sat Sep 27 19:33:53 2008
From: report at bugs.python.org (Eric Smith)
Date: Sat, 27 Sep 2008 17:33:53 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1222536833.52.0.754775083849.issue3982@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Yes, it would be easy to add. Maybe bring this up on python-dev (or
python-3000) to get consensus?

Are we in feature freeze for 3.0?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Sep 27 19:35:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 17:35:11 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222536833.52.0.754775083849.issue3982@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809271035l2e5beaebm9913ee87d9d9a69c@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Sat, Sep 27, 2008 at 12:33 PM, Eric Smith <report at bugs.python.org> wrote:
>
> Eric Smith <eric at trueblade.com> added the comment:
>
> Yes, it would be easy to add. Maybe bring this up on python-dev (or
> python-3000) to get consensus?

Yes, that will have to be done.
>
> Are we in feature freeze for 3.0?

Unfortunately, yes.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Sep 27 19:35:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 27 Sep 2008 17:35:37 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1222536937.19.0.407489020675.issue3982@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm skeptical. What networking code specifically are you using, and what
specifically does it use string formatting for?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Sep 27 19:39:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 17:39:01 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222536937.19.0.407489020675.issue3982@psf.upfronthosting.co.za>
Message-ID: <1afaf6160809271039k1c57f03o5eff42a624425aec@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Sat, Sep 27, 2008 at 12:35 PM, Martin v. L?wis
<report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> I'm skeptical. What networking code specifically are you using, and what
> specifically does it use string formatting for?

I'm working on the tests for ftplib. [1] The dummy server uses string
formatting to build responses.

[1] http://svn.python.org/view/python/trunk/Lib/test/test_ftplib.py?view=markup

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Sep 27 20:42:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 27 Sep 2008 18:42:04 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1afaf6160809271039k1c57f03o5eff42a624425aec@mail.gmail.com>
Message-ID: <48DE7E78.5010605@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm working on the tests for ftplib. [1] The dummy server uses string
> formatting to build responses.

I see. I propose to add a method push_string, defined as

  def push_string(self, s):
      self.push(s.encode("ascii")

In FTP, the responses are, by definition, ASCII-encoded strings.
The proper way to generate them is to make a string, then encode it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat Sep 27 20:58:40 2008
From: report at bugs.python.org (bahiminin)
Date: Sat, 27 Sep 2008 18:58:40 +0000
Subject: [issue3981] Python 3, IDLE does not start
In-Reply-To: <1222536788.61.0.843027083396.issue3981@psf.upfronthosting.co.za>
Message-ID: <80a626f00809271158j25525e94s1159c4d7945f2b9d@mail.gmail.com>


bahiminin <art.wyse11 at gmail.com> added the comment:

The version of Python whose IDLE doesn't work have been installed using the
following installer package, Python-3.0rc1.msi, that I have downloaded from
your site. I have also installed another version with the Python-2.5.2.msi
installer. This one work fine with the only warning that the firewall may
prompt a warning because of calls made to some sub processes. Thanks.

On Sat, Sep 27, 2008 at 10:33 AM, Martin v. L?wis <report at bugs.python.org>wrote:

>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Can you please be more specific what precise version you have been trying?
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3981>
> _______________________________________
>

Added file: http://bugs.python.org/file11635/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3981>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080927/e6f44b8a/attachment.txt>

From report at bugs.python.org  Sun Sep 28 00:00:40 2008
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 27 Sep 2008 22:00:40 +0000
Subject: [issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
In-Reply-To: <1219733554.71.0.0422559715732.issue3685@psf.upfronthosting.co.za>
Message-ID: <1222552840.2.0.935816905428.issue3685@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

I just tested the patch and it fixes the problem.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3685>
_______________________________________

From report at bugs.python.org  Sun Sep 28 00:04:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 22:04:39 +0000
Subject: [issue3911] ftplib.FTP.makeport() bug
In-Reply-To: <1221847682.44.0.529655554535.issue3911@psf.upfronthosting.co.za>
Message-ID: <1222553079.89.0.405012128404.issue3911@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66656.

----------
priority:  -> release blocker
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3911>
_______________________________________

From report at bugs.python.org  Sun Sep 28 00:11:03 2008
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 27 Sep 2008 22:11:03 +0000
Subject: [issue1593035] readline problem on ia64-unknown-linux-gnu
Message-ID: <1222553463.18.0.918358128186.issue1593035@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

This problem was probably solved in issue #1204.

----------
nosy: +henry.precheur

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1593035>
_______________________________________

From report at bugs.python.org  Sun Sep 28 00:32:50 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 27 Sep 2008 22:32:50 +0000
Subject: [issue3457] Release notes for 2.6b2 call it an alpha release
In-Reply-To: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za>
Message-ID: <1222554770.04.0.847696569408.issue3457@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The web pages seem to have been updated to correctly describe 
the releases (now, they're release candidates).  Thanks for your report!

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3457>
_______________________________________

From report at bugs.python.org  Sun Sep 28 00:54:40 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 27 Sep 2008 22:54:40 +0000
Subject: [issue3510] Site-specific configuration hook documentation incorrect
In-Reply-To: <1218035166.89.0.646760261694.issue3510@psf.upfronthosting.co.za>
Message-ID: <1222556080.46.0.290029160539.issue3510@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Changed in rev. 66660 to use the X.Y form.  Thanks!

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3510>
_______________________________________

From report at bugs.python.org  Sun Sep 28 01:16:13 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 27 Sep 2008 23:16:13 +0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1222557373.79.0.326360791508.issue1706863@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_______________________________________

From report at bugs.python.org  Sun Sep 28 01:32:05 2008
From: report at bugs.python.org (Scott David Daniels)
Date: Sat, 27 Sep 2008 23:32:05 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1222558325.55.0.360976717184.issue3926@psf.upfronthosting.co.za>


Scott David Daniels <Scott.Daniels at Acm.Org> added the comment:

OK, Issues:
1) warnings.py 
    I/O errors in formatwarning will be masked and misinterpreted as
failures to write on stderr, and no output will be attempted.  

2) warnings.py
A line with of whitespace will be shown, rather than suppressed.

3) idlelib/PyShell.py 
idle_show_warning did not take new args to showwarning.
& a repeat of an error much like 1.

3) idlelib/PyShell.py
idle_format_warning did not take new arg to formatwarning.

4) idlelib/PyShell.py
extended_linecache_checkcache did not pass its arg along to 
orig_checkcache.  Had to rename the element in the loop to
avoid trashing the arg.

5) idlelib/run.py
idle_formatwarning_subproc must also follow the new protocol for 
formatwarning.

----------
components: +IDLE, Library (Lib)
Added file: http://bugs.python.org/file11636/diff_trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Sun Sep 28 01:33:42 2008
From: report at bugs.python.org (Scott David Daniels)
Date: Sat, 27 Sep 2008 23:33:42 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1222558422.26.0.102670999417.issue3926@psf.upfronthosting.co.za>


Scott David Daniels <Scott.Daniels at Acm.Org> added the comment:

Here is a test for the fixes provided.

Added file: http://bugs.python.org/file11637/test_idle_warnings.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Sun Sep 28 01:58:55 2008
From: report at bugs.python.org (Damien Miller)
Date: Sat, 27 Sep 2008 23:58:55 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1222483890.46.0.536317141973.issue3770@psf.upfronthosting.co.za>
Message-ID: <alpine.BSO.1.10.0809280955070.12305@fuyu.mindrot.org>


Damien Miller <djmdjm at users.sourceforge.net> added the comment:

For 2.6/3.0 it would probably be best to just disable the module
entirely on platforms that lack shareable semaphores (OpenBSD & FreeBSD
at least)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Sun Sep 28 01:59:47 2008
From: report at bugs.python.org (Asheesh Laroia)
Date: Sat, 27 Sep 2008 23:59:47 +0000
Subject: [issue1525919] email package quoted printable behaviour changed
Message-ID: <1222559987.04.0.137598102775.issue1525919@psf.upfronthosting.co.za>


Asheesh Laroia <python.bugs at asheesh.org> added the comment:

Another way to see this issue is that the email module double-encodes
when one attempts to use quoted-printable encoding.  This has to be
worked around by e.g. MoinMoin.

It's easy to get proper base64-encoded output of email.mime.text:

 	>>> mt = email.mime.text.MIMEText('Ta m?re', 'plain', 'utf-8')
 	>>> 'Content-Transfer-Encoding: base64' in mt.as_string()
 	True
 	>>> mt.as_string().split('\n')[-2]
 	'VGEgbcOocmU='

There we go, all nice and base64'd.

I can *not* figure out how to get quoted-printable-encoding.  I found 
http://docs.python.org/lib/module-email.encoders.html , so I thought
great - I'll just encode my MIMEText object:

 	>>> email.encoders.encode_quopri(mt)
 	>>> 'Content-Transfer-Encoding: quoted-printable' in mt.as_string()
 	True

Great!  Except it's actually double-encoded, and the headers admit to as
much.  You see here that, in addition to the quoted-printable header
just discovered, there is also a base64-related header, and the result
is not strictly QP encoding but QP(base64(payload)).

 	>>> 'Content-Transfer-Encoding: base64' in mt.as_string()
 	True
 	>>> mt.as_string().split('\n')[-2]
 	'VGEgbcOocmU=3D'

It should look like:

 	>>> quopri.encodestring('Ta m?re')
 	'Ta m=C3=A8re'

I raised this issue on the Baypiggies list
<http://mail.python.org/pipermail/baypiggies/2008-September/003983.html>, but
luckily I found this here bug.  This is with Python 2.5.2-0ubuntu1 from
Ubuntu 8.04.

 	paulproteus at alchemy:~ $ python --version
 	Python 2.5.2

If we can come to a decision as to how this *should* work, I could
contribute a patch and/or tests to fix it.  I could even perhaps write a
new section of the Python documentation of the email module explaining this.

----------
nosy: +paulproteus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1525919>
_______________________________________

From report at bugs.python.org  Sun Sep 28 02:01:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Sep 2008 00:01:05 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222560065.19.0.299043368185.issue3939@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Giampaolo, I'm seeing some failures on the buildbots like this:
http://python.org/dev/buildbot/stable/ia64%20Ubuntu%203.0/builds/612/step-test/0

Do you know where they are arising from?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Sun Sep 28 02:17:27 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 28 Sep 2008 00:17:27 +0000
Subject: [issue1579477] Use flush() before os.exevp()
Message-ID: <1222561047.55.0.784426005367.issue1579477@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

A paragraph has been added in rev. 66662, using
a modified version of your text.  Thanks for
your suggestion!

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1579477>
_______________________________________

From report at bugs.python.org  Sun Sep 28 02:26:31 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 28 Sep 2008 00:26:31 +0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1222561591.03.0.977229116072.issue2127@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

vdupras's test case now passes with Python 2.6; we should apply 
the patch to the test suite, though.  We could ask Barry if he wants to
apply it to 2.6rc, or adding the test can wait until 2.7.

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
_______________________________________

From report at bugs.python.org  Sun Sep 28 03:11:29 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 28 Sep 2008 01:11:29 +0000
Subject: [issue1415508] optparse enable_interspersed_args
	disable_interspersed_args
Message-ID: <1222564289.65.0.0924154540988.issue1415508@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Added to the documentation in rev. 66663; thanks for your
patch!

Barry, there's also a patch adding two docstrings 
to optparse.py.  Is it
OK to add docstrings at the rc level, or should I wait until
the trunk is re-opened for 2.7?  (Actually, I have a few unrelated
docstring changes?)

----------
nosy: +akuchling, barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1415508>
_______________________________________

From report at bugs.python.org  Sun Sep 28 03:17:18 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 28 Sep 2008 01:17:18 +0000
Subject: [issue1415508] optparse enable_interspersed_args
	disable_interspersed_args
Message-ID: <1222564638.97.0.754243354429.issue1415508@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: gward -> akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1415508>
_______________________________________

From report at bugs.python.org  Sun Sep 28 04:44:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 28 Sep 2008 02:44:45 +0000
Subject: [issue459007] Document sys.path on Windows
Message-ID: <1222569885.9.0.66069468085.issue459007@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I think this item doesn't need to be handled
by Mark.  There's a comment at the top of 
PC/getpathp.c giving the rules, so it's 
just a matter of editing the text and adding reST
markup.  But where in the docs should this material go?  using/windows.rst?

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue459007>
_______________________________________

From report at bugs.python.org  Sun Sep 28 04:52:01 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 28 Sep 2008 02:52:01 +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: <1222570321.13.0.591671645374.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I haven't yet found out how to turn on compression when getting the
branches, so I've only looked at
lp:~pythonregexp2.7/python/issue2636+01+09-02+17+18+19+20+21+24+26. I
did see that the SRE_FLAG_REVERSE flag was missing.

BTW, I ran re.findall(r"(?m)^(.*re\..+\\m)$", text) where text was 67MB
of emails. Python v2.5.2 took 2.4secs and the new version 5.6secs. Ouch!
I added 4 lines to _sre.c and tried again. 1.1secs. Nice! :-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Sep 28 08:46:16 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 28 Sep 2008 06:46:16 +0000
Subject: [issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
In-Reply-To: <1221392514.26.0.835541576459.issue3864@psf.upfronthosting.co.za>
Message-ID: <1222584376.73.0.869673019037.issue3864@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

The tests are passing on FreeBSD 7.0 (only checked amd64 at this point).

I came across a reference to an errata notice for FreeBSD 6.x which
appears pertinent:
http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc

As I read the above notice, the underlying issue is a FreeBSD bug which
will be fixed in FreeBSD 6.4 (expected to be released in the next couple
of months.

On this basis, I suggest closing this as "Won't fix".

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3864>
_______________________________________

From report at bugs.python.org  Sun Sep 28 08:48:07 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Sep 2008 06:48:07 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222584487.07.0.449004815945.issue3770@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Jesse, how much (if any) of the rest of the package will work without
the synchronize module? If it isn't a lot, then it may be a matter of
just making this a cleaner ImportError and an expected test suite skip
on OpenBSD and FreeBSD.

(Unfortunately, our OpenBSD and FreeBSD buildbots are so unreliable that
they don't get much attention when they go red - it looks to me like the
OpenBSD buildbot isn't even managing to build _multiprocessing at the
moment, because HAVE_SEM_OPEN is incorrectly set to 1).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Sun Sep 28 09:48:05 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 28 Sep 2008 07:48:05 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222588085.52.0.59889486235.issue3770@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I've done some more digging into this for the FreeBSD case.

FreeBSD 6.3 and 7.0 both have sem_open, and the man pages suggest it 
should be fully functional. (see
http://www.freebsd.org/cgi/man.cgi?query=sem_open&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html)
There is a caveat on the length of the name, which I think could trigger
if the counter variable passed into SEM_CREATE() is >9999.  But as that 
variable seems like it can only ever be 0 (not sure this is intended!)
this shouldn't happen as it stands.

If I change HAVE_SEM_OPEN to 1 in setup.py, the _multiprocessing module
builds, but test_multiprocessing provokes a core dump in both cases.
The backtrace (on 6.3 i386) looks like:
#0  0x2820ef17 in ksem_open () from /lib/libc.so.6
#1  0x2820592c in sem_open () from /lib/libc.so.6
#2  0x284494a0 in semlock_new (type=0x2844b380, args=0x836443c, kwds=0x0)
    at
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:439
#3  0x0809e710 in type_call (type=0x2844b380, args=0x836443c, kwds=0x0)
    at Objects/typeobject.c:731
#4  0x0806042a in PyObject_Call (func=0x2844b380, arg=0x836443c, kw=0x0)
    at Objects/abstract.c:2487
#5  0x080cc367 in PyEval_EvalFrameEx (f=0x84dd00c, throwflag=0)
    at Python/ceval.c:3890
#6  0x080cf9ac in PyEval_EvalCodeEx (co=0x8478800, globals=0x4e,
locals=0xa00,
    args=0x819b02c, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0,
    closure=0x0) at Python/ceval.c:2942
#7  0x08123f84 in function_call (func=0x8486ca4, arg=0x82e107c, kw=0x0)
    at Objects/funcobject.c:524
#8  0x0806042a in PyObject_Call (func=0x8486ca4, arg=0x82e107c, kw=0x0)
    at Objects/abstract.c:2487
#9  0x08069c15 in instancemethod_call (func=0x4e, arg=0x82e107c, kw=0x0)
    at Objects/classobject.c:2579
#10 0x0806042a in PyObject_Call (func=0x84857ac, arg=0x82e107c, kw=0x0)
    at Objects/abstract.c:2487
#11 0x080cc367 in PyEval_EvalFrameEx (f=0x826140c, throwflag=0)
    at Python/ceval.c:3890
---Type <return> to continue, or q <return> to quit---

On 7.0 amd64, the top of the backtrace scrolls off screen so I can't get 
the start of the trace (X not installed...).

To try and remove threads from the equation, due to FreeBSD 6.3 having 
an issue with fork() in a threaded build (see issue3864 for more info), 
I configured without threads (ie ./configure --without-threads) and 
the _multiprocessing module fails to build:

gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3
-Wall-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1
-DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-I/home/andymac/build/python-svn/trunk-r66550/./Include -I. -IInclude
-I./Include -I/usr/local/include
-I/home/andymac/build/python-svn/trunk-r66550/Include
-I/home/andymac/build/python-svn/trunk-r66550 -c
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c
-o
build/temp.freebsd-6.3-RELEASE-i386-2.6/home/andymac/build/python-svn/trunk-r66550/Modules/_mult
iprocessing/semaphore.o
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:
In function `semlock_acquire':
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: `_save' undeclared (first use in this function)
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: (Each undeclared identifier is reported only once
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: for each function it appears in.)

It appears that some support is there for a single threaded build, but
is incomplete (there's a similar problem in socket_connections.c, but
the module build bails before then).

If its not to be supported on single threaded builds (which would be a
big shame in my opinion!) then the code should make this explicit,
otherwise the single threaded build case needs to be fixed.

I'm still trying to understand the core dump in the multithreaded build
- unfortunately I'm not terribly familiar with gdb or with debugging
from cores (and the actual failure appears to be triggering in the C
library for which I currently don't appear to have symbols...)

Any suggests on how/where to dig further on this?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Sun Sep 28 09:52:54 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 28 Sep 2008 07:52:54 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222588374.73.0.175617036267.issue3770@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

Oops - meant to add that the actual reported cause of the core dump is
"Bad system call".

Also, the OpenBSD man pages make clear that shared semaphores aren't
supported and sem_open() doesn't exist:
http://www.openbsd.org/cgi-bin/man.cgi?query=sem_open&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Sun Sep 28 10:50:50 2008
From: report at bugs.python.org (Bk)
Date: Sun, 28 Sep 2008 08:50:50 +0000
Subject: [issue3983] Typos in Documentation
In-Reply-To: <1222591849.99.0.261672488348.issue3983@psf.upfronthosting.co.za>
Message-ID: <1222591849.99.0.261672488348.issue3983@psf.upfronthosting.co.za>


New submission from Bk <jurevesel2 at gmail.com>:

Hello,

I would like to contribute to the development of the Python
documentation so I am reporting two typos. The first one is in the
documentation and the second one is in the module ntpath.

1) There's a typo under "The Python Tutorial" > "Using the Python
Interpreter" > "Invoking the Interpreter". The sentence with the typo is
positioned almost at the top, and starts like this:
"On Windows machines, the Python installation is usually placed in
C:Python30 ..."

The above text lacks a backslash in the path "C:Python30". Please add a
backslash to this path so that it would be written as "C:\Python30". The
text should be written like this:
"On Windows machines, the Python installation is usually placed in
C:\Python30 ..."


2) Please take a look at the source code of the module ntpath. The line
63 has a typo in the comment:
# set to 1 iff b makes path irrelevant

which should be
# set to 1 if b makes path irrelevant

Please note that the word 'iff' is fixed to 'if'.



Maybe just two little questions at the end... Please see the source code
of the module ntpath and note the line 72. Since the word in the comment
(i.e. 'But') is a continuation of the same sentence, doesn't it suppose
to be written with the lower-case initial as 'but'?

And also, why do some comments in modules start with the lower-case
initial and end without the dot, and others with the upper-case initial
and end with a dot? It would be nice if those things would be
conventionalized. I really don't understand when a comment must be
written as a sentence with its full orthographical rules. Please explain.

----------
assignee: georg.brandl
components: Documentation
messages: 73960
nosy: Bk, georg.brandl
severity: normal
status: open
title: Typos in Documentation
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3983>
_______________________________________

From report at bugs.python.org  Sun Sep 28 11:09:05 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 28 Sep 2008 09:09:05 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222385688.89.0.172399497004.issue3956@psf.upfronthosting.co.za>
Message-ID: <48DF49AB.5030604@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'll demonstrate here in a short interactive session (which you can
> reproduce using IDLE with the -n switch as usual), why the solution
> Martin proposes doesn't meet the requirements I tried to accomplish with
> my code. This session 'simulates' a student curiously playing around and
> experimenting with *the* Screen():
> 
>>>> from turtle import Screen, Turtle
>>>> class YellowScreen(Screen):
> 	def __init__(self):
> 		Screen.__init__(self)
> 		self.bgcolor("yellow")

Hmm. Why is it important to be able to inherit from Screen? I don't
think inheritance from a singleton is a meaningful concept, and I
believe that students are misguided when they are told that this is
the way to produce yellow screen. Instead, they should write

def YellowScreen():
    s = Screen()
    s.bgcolor("yellow")
    return s

This much better captures the notion of a singleton object: you can
not *create* them, but you have to *modify* them.

>>>> s1 = Screen()
>>>> s1.bgcolor("pink")

This is really confusing. It does *not* create a new screen, but
modifies the existing one. How can you tell your students the meaning
of object creation in the light of this strange behavior?

So I urge you to reconsider that inheritance from Screen should
be deliberately dropped. It is a flawed, undesirable concept.

> Nevertheless I decisively
> propose to accept this behaviour in order to be able do things like the
> ones demonstrated above.

You can do the things you want to just as fine with functions.

> Morover I also consider it to be a benefit to
> use spezialized and/or reusable screens derived from the Screen() class
> in scripts, what would not be possible with a Screen()-function
> returning *the* single _Screen() object. (All this meant in the context
> of teaching and learning OOP).

Not at all. It would be very easy with a Screen function.

> But if you think, that there is no way around and it has to be
> observed strictly, one had to leave everything as is and find a
> better solution (with the desired behaviour) for 2.6.1.

I propose that Screen is change to a function for 2.6. This is the
more restrictive solution (not allowing inheritance). If inheritance
would be allowed now, it could be taken back for backwards
compatibility. However, if it is changed to a function now, it can
be changed back to a class later.

> Anyway I'd like to express my hope that this controversial
> implementation of the last element in the class hierarchy for a very
> special purpose is *not* a hint at a design bug of the entire class
> hierarchy.

Perhaps not of the entire hierarchy, but certainly of the Screen class
and its potential subclasses.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Sun Sep 28 11:12:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Sep 2008 09:12:45 +0000
Subject: [issue3983] Typos in Documentation
In-Reply-To: <1222591849.99.0.261672488348.issue3983@psf.upfronthosting.co.za>
Message-ID: <1222593165.59.0.893412706196.issue3983@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed typo 1) in r66669, thanks for that. For 2), "iff" is a usual
abbreviation for "if and only if".

About your two questions, comments in modules are written in whatever
way the author likes to write his comments. There are no rules for that,
other than that a comment should explain the code it comments on. (PEP 8
has some examples of unhelpful comments.)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3983>
_______________________________________

From report at bugs.python.org  Sun Sep 28 11:14:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Sep 2008 09:14:40 +0000
Subject: [issue3960] Section permalink html anchors are wrong
In-Reply-To: <1222346508.67.0.745864435926.issue3960@psf.upfronthosting.co.za>
Message-ID: <1222593280.8.0.892166168286.issue3960@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't see that inter-document links *wouldn't* work, except on antique
browsers that insist on <a name> tags only for defining anchors.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3960>
_______________________________________

From report at bugs.python.org  Sun Sep 28 11:58:24 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 09:58:24 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

I am trying to write a patch in distutils to make use the standard
logging module, and I had a weird problem:

if I add "import logging" at the top of Lib/distutils/log.py file to
start my work, it just brakes  the interpreter. Python does not find
cStringIO and time modules anymore.

It seems that this is because Lib/site.py calls
distutils.util.get_platform when main() is launched

I have run it with -v to get more info (see the file)

----------
files: tb.txt
messages: 73964
nosy: tarek
severity: normal
status: open
title: python interpreter import dependency with disutils/util
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file11638/tb.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Sun Sep 28 11:58:38 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 09:58:38 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1222595918.77.0.805204258425.issue3984@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils, Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Sun Sep 28 12:31:28 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 10:31:28 +0000
Subject: [issue3985] removed string module from distutils
In-Reply-To: <1222597888.29.0.260615260643.issue3985@psf.upfronthosting.co.za>
Message-ID: <1222597888.29.0.260615260643.issue3985@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This patch removes string usage from dist.py, so the module uses modern
syntax.

----------
components: Distutils
files: dist-no-string.diff
keywords: patch
messages: 73965
nosy: tarek
severity: normal
status: open
title: removed string module from distutils
versions: Python 2.6
Added file: http://bugs.python.org/file11639/dist-no-string.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3985>
_______________________________________

From report at bugs.python.org  Sun Sep 28 12:31:52 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 10:31:52 +0000
Subject: [issue3985] removed string module from distutils [patch]
In-Reply-To: <1222597888.29.0.260615260643.issue3985@psf.upfronthosting.co.za>
Message-ID: <1222597912.4.0.111046610911.issue3985@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
title: removed string module from distutils -> removed string module from distutils [patch]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3985>
_______________________________________

From report at bugs.python.org  Sun Sep 28 12:42:32 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 28 Sep 2008 10:42:32 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222598552.63.0.615645904462.issue3939@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

I think the patch in attachment could solve the problem. 
Note: done against the 2.x trunk; changes for 3.x are the same.

Added file: http://bugs.python.org/file11640/test_ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Sun Sep 28 12:54:20 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 10:54:20 +0000
Subject: [issue3986] removed string and type usage from distutils.cmd [patch]
In-Reply-To: <1222599260.36.0.588546522414.issue3986@psf.upfronthosting.co.za>
Message-ID: <1222599260.36.0.588546522414.issue3986@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

I am removing in this patch the usage of string and type.

1/ I have remove string import, and used the proper modern syntax

2/
Type was used to check for object types, and sometimes isinstance() was
called. 

I have replaced all the calls by isinstance() and removed types import.

----------
components: Distutils
files: cmd.no-string-no-type.diff
keywords: patch
messages: 73967
nosy: tarek
severity: normal
status: open
title: removed string and type usage from distutils.cmd [patch]
versions: Python 2.6
Added file: http://bugs.python.org/file11641/cmd.no-string-no-type.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3986>
_______________________________________

From report at bugs.python.org  Sun Sep 28 12:59:51 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 10:59:51 +0000
Subject: [issue3987] removed types from distutils.core [patch]
In-Reply-To: <1222599591.35.0.056010303755.issue3987@psf.upfronthosting.co.za>
Message-ID: <1222599591.35.0.056010303755.issue3987@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

types is not used, the import shall be removed

----------
components: Distutils
files: core-no-types.diff
keywords: patch
messages: 73968
nosy: tarek
severity: normal
status: open
title: removed types from distutils.core [patch]
versions: Python 2.6
Added file: http://bugs.python.org/file11642/core-no-types.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3987>
_______________________________________

From report at bugs.python.org  Sun Sep 28 13:32:57 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Sep 2008 11:32:57 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

In byte warning mode (-b or -bb command line argument) b'' == '' raises
an exception but b'' != '' doesn't.

./python -bb
>>> b'' == ''
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BytesWarning: Comparison between bytes and string
>>> b'' != ''
True

I can't recall why I implemented the byte warning mode this way. But
nowadays I think it could hide bugs in code like "while egg != ''" where
egg is a byte instance.

----------
assignee: barry
components: Interpreter Core
messages: 73969
nosy: barry, christian.heimes
priority: release blocker
severity: normal
status: open
title: Byte warning mode and b'' != ''
type: behavior
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 14:28:30 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Sep 2008 12:28:30 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1222604910.48.0.808529659766.issue3984@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

site.py uses distutils to include the lib directories when Python is run
from the development directory.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Sun Sep 28 15:36:06 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 13:36:06 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1222608966.91.0.641499788741.issue3984@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ok thanks, I could make it work by removing the call to 

distutils.util.get_platform() in site.addbuilddir()

and harcode the name of my platform there,

Maybe a solution would be to :

* move get_platform out of distutils.util
* move sysconfig out of distutils as well

and to create a sysconfig module at the root of Lib/ that doesn't 
depend on any other module besides os and sys.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Sun Sep 28 15:39:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 28 Sep 2008 13:39:38 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222609178.2.0.872845975226.issue3956@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch that takes the alternative route, of making Screen a
singleton function, and renaming the class to _Screen.

Added file: http://bugs.python.org/file11643/singleton.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Sun Sep 28 16:18:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Sep 2008 14:18:21 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222611501.76.0.396436923982.issue3988@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

+1

I was just confused by this fact yesterday. :)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 17:20:50 2008
From: report at bugs.python.org (arnaud.faucher)
Date: Sun, 28 Sep 2008 15:20:50 +0000
Subject: [issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
In-Reply-To: <1222615250.32.0.962224147544.issue3989@psf.upfronthosting.co.za>
Message-ID: <1222615250.32.0.962224147544.issue3989@psf.upfronthosting.co.za>


New submission from arnaud.faucher <arnaud.faucher at gmail.com>:

Under Windows (using the MSI), 2to3.py is outdated.

http://svn.python.org/view/sandbox/trunk/2to3/ contains the working
version (rev. 66173)

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 73974
nosy: arnaud.faucher, collinwinter
severity: normal
status: open
title: Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3989>
_______________________________________

From report at bugs.python.org  Sun Sep 28 18:19:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Sep 2008 16:19:28 +0000
Subject: [issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
In-Reply-To: <1222615250.32.0.962224147544.issue3989@psf.upfronthosting.co.za>
Message-ID: <1222618768.0.0.122551991973.issue3989@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Could you explain what you mean be outdated please? It looks correct to
me in the tag.
http://svn.python.org/view/python/tags/r30rc1/Tools/scripts/2to3?rev=66500&view=markup

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3989>
_______________________________________

From report at bugs.python.org  Sun Sep 28 18:38:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 28 Sep 2008 16:38:36 +0000
Subject: [issue3981] Python 3, IDLE does not start
In-Reply-To: <1222523668.6.0.778163110852.issue3981@psf.upfronthosting.co.za>
Message-ID: <1222619916.86.0.40214748771.issue3981@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IDLE won't start with 3.0rc1 because of issue #3628.
This has been corrected in r66518.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3981>
_______________________________________

From report at bugs.python.org  Sun Sep 28 19:03:20 2008
From: report at bugs.python.org (arnaud.faucher)
Date: Sun, 28 Sep 2008 17:03:20 +0000
Subject: [issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
In-Reply-To: <1222615250.32.0.962224147544.issue3989@psf.upfronthosting.co.za>
Message-ID: <1222621400.85.0.0163856660979.issue3989@psf.upfronthosting.co.za>


arnaud.faucher <arnaud.faucher at gmail.com> added the comment:

On a fresh win32 installation (using the 3.0rc1 MSI), the C:\Python30
\Tools\Scripts\2to3.py file contents is as follows:

------------------------------------------
#!/usr/bin/env python
from lib2to3 import refactor
import sys

sys.exit(refactor.main())
------------------------------------------

This version throws an error as follows:

------------------------------------------
C:\Python30\Tools\Scripts>C:\Python30\python.exe 2to3.py
Traceback (most recent call last):
  File "2to3.py", line 5, in <module>
    sys.exit(refactor.main())
AttributeError: 'module' object has no attribute 'main'
------------------------------------------


It seems that the '.py' extendion of the 2to3 script was removed some 
time ago.

Perhaps the MSI build process uses an old version of '2to3.py' and not 
the newer version of '2to3' (without the '.py' extension) ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3989>
_______________________________________

From report at bugs.python.org  Sun Sep 28 19:23:57 2008
From: report at bugs.python.org (Thiemo Seufer)
Date: Sun, 28 Sep 2008 17:23:57 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>


New submission from Thiemo Seufer <ths at networkno.de>:

The linux2 platform definition is incorrect for several architectures,
namely Alpha, PA-RISC(hppa), MIPS and SPARC. On these architectures,
Linux inherited some of the socket and dlfcn constants from the
proprietary OS provided by the hardware manufacturer, which means they
differ from the usual Linux constants.

The appended patch against current SVN adresses this by introducing
linux2-alpha, linux2-hppa, linux2-mips and linux2-sparc platforms.

I changed only the incorrect constants on each platform and kept
everything else the same.

Bugs in the Debian Bugtracker related to this problem are:
http://bugs.debian.org/499132
http://bugs.debian.org/500383
http://bugs.debian.org/500417
http://bugs.debian.org/500418

The first two bug reports carry patches for Python 2.5 and Python 2.4,
respectively.

The patch probably fixes also spurious python segfaults seen on the
Debian Autobuilders for MIPS, since the RTLD_* constants for dlopen were
incorrect. (That said, those segfaults are hard to reproduce, so this is
a somewhat speculative conclusion.)

----------
components: Library (Lib)
files: linux2-plat-upstream.diff
keywords: patch
messages: 73978
nosy: doko, ths
severity: normal
status: open
title: The Linux2 platform definition is incorrect for alpha, hppa, mips, sparc
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file11644/linux2-plat-upstream.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3990>
_______________________________________

From report at bugs.python.org  Sun Sep 28 19:49:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Sep 2008 17:49:22 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222624162.44.0.738526067564.issue3988@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1 as well. Lib/pty.py had a line like that ("while buf != ''") and I
wondered why no exception was thrown with -bb while the variable was a
bytes object.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 19:53:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 28 Sep 2008 17:53:52 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222624432.04.0.573164318769.issue3956@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Added file: http://bugs.python.org/file11645/singleton.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Sun Sep 28 19:54:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 28 Sep 2008 17:54:00 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222624440.42.0.0818614941603.issue3956@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file11643/singleton.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Sun Sep 28 20:04:24 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 28 Sep 2008 18:04:24 +0000
Subject: [issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
In-Reply-To: <1222615250.32.0.962224147544.issue3989@psf.upfronthosting.co.za>
Message-ID: <1222625064.61.0.917554383569.issue3989@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It was indeed the case that I had been packaging an unversioned file. I
don't recall the details; most likely, it was a quick work-around for
2to3 not having a .py extension, yet the MSI generator only
incorporating .py files from Scripts.

I'll look into it.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3989>
_______________________________________

From report at bugs.python.org  Sun Sep 28 20:11:22 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 18:11:22 +0000
Subject: [issue3255] [proposal] alternative for re.sub
In-Reply-To: <1214988192.81.0.533532272888.issue3255@psf.upfronthosting.co.za>
Message-ID: <1222625482.29.0.956549909392.issue3255@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Implementing Issue 3482 should solve this problem, and I will try to add 
it to issue 2636 so that it is captured in the general Regexp 2.7 
redesign.

----------
nosy: +timehorse
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3255>
_______________________________________

From report at bugs.python.org  Sun Sep 28 20:47:16 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Sun, 28 Sep 2008 18:47:16 +0000
Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII
	characters
In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>
Message-ID: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

Tested on python-3.0rc1 -- Linux Fedora 9

I wanted to make sure that python3.0 would handle url's in different
encodings.  So I created two files on an apache server which were named
??.html.  One of the filenames was encoded in utf-8 and the other in
latin-1.  Then I tried the following::

from urllib.request import urlopen
url = 'http://localhost/u/??.html'
urlopen(url.encode('utf-8')).read()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.0/urllib/request.py", line 122, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python3.0/urllib/request.py", line 350, in open
    req.timeout = timeout
AttributeError: 'bytes' object has no attribute 'timeout'

The same thing happens if I give None for the two optional arguments
(data and timeout).

Next I tried using a raw Unicode string:

>>> urlopen(url).read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.0/urllib/request.py", line 122, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python3.0/urllib/request.py", line 359, in open
    response = self._open(req, data)
  File "/usr/lib/python3.0/urllib/request.py", line 377, in _open
    '_open', req)
  File "/usr/lib/python3.0/urllib/request.py", line 337, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.0/urllib/request.py", line 1082, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib/python3.0/urllib/request.py", line 1068, in do_open
    h.request(req.get_method(), req.get_selector(), req.data, headers)
  File "/usr/lib/python3.0/http/client.py", line 843, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.0/http/client.py", line 860, in _send_request
    self.putrequest(method, url, **skips)
  File "/usr/lib/python3.0/http/client.py", line 751, in putrequest
    self._output(request.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position
7-8: ordinal not in range(128)

So, in python-3.0rc1, this method is badly broken.

----------
components: Unicode
messages: 73982
nosy: a.badger
severity: normal
status: open
title: urllib.request.urlopen does not handle non-ASCII characters
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3991>
_______________________________________

From report at bugs.python.org  Sun Sep 28 20:53:53 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 18:53:53 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1222628033.59.0.368150447999.issue2650@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Sun Sep 28 20:55:25 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 18:55:25 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1222628125.84.0.244107112306.issue2650@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:04:25 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:04:25 +0000
Subject: [issue1721518] Small case which hangs
Message-ID: <1222628665.29.0.422094570338.issue1721518@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse
versions: +Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721518>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:12:53 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:12:53 +0000
Subject: [issue1721518] Small case which hangs
Message-ID: <1222629173.86.0.663443640935.issue1721518@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Tested on 2.6rc2 and slow but successful.  Issue 1662851 may be related.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721518>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:20:16 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:20:16 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1222629616.6.0.625431151886.issue1693050@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse
versions: +Python 2.7 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693050>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:23:32 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:23:32 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1222629812.18.0.788334357703.issue2537@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2537>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:25:09 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:25:09 +0000
Subject: [issue1633953] re.compile("(.*$){1,4}", re.MULTILINE) fails
Message-ID: <1222629909.76.0.796855491762.issue1633953@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633953>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:26:27 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Sep 2008 19:26:27 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222629987.09.0.169587369757.issue3988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch for this issue.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file11646/bytes_ne_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:26:58 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:26:58 +0000
Subject: [issue1282] re module needs to support bytes / memoryview well
In-Reply-To: <1192490811.67.0.131142181278.issue1282@psf.upfronthosting.co.za>
Message-ID: <1222630018.02.0.316536982519.issue1282@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1282>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:30:21 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:30:21 +0000
Subject: [issue214033] re incompatibility in sre
Message-ID: <1222630221.19.0.566880956171.issue214033@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue214033>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:31:24 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:31:24 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1222630284.37.0.958186471183.issue1708652@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708652>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:32:11 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Sep 2008 19:32:11 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222630331.95.0.280750976665.issue3988@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks for the patch but you've missed a spot in bytearrayobject.c:

Objects/bytearrayobject.c:        if (Py_BytesWarningFlag && op == Py_EQ) {
Objects/bytesobject.c:          if (Py_BytesWarningFlag && (op == Py_EQ) &&

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:34:07 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:34:07 +0000
Subject: [issue694374] Recursive regular expressions
Message-ID: <1222630447.63.0.0937251737116.issue694374@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue694374>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:36:07 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 28 Sep 2008 19:36:07 +0000
Subject: [issue1456280] Traceback error when compiling Regex
Message-ID: <1222630567.53.0.051489343819.issue1456280@psf.upfronthosting.co.za>


Changes by Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:


----------
nosy: +timehorse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1456280>
_______________________________________

From report at bugs.python.org  Sun Sep 28 21:37:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Sep 2008 19:37:14 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222630634.13.0.00968099523171.issue3988@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It would also be nice to have tests. (in test_bytes)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 22:59:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Sep 2008 20:59:05 +0000
Subject: [issue3939] Patch to implement a real ftplib test suite
In-Reply-To: <1222126943.42.0.982602748454.issue3939@psf.upfronthosting.co.za>
Message-ID: <1222635545.83.0.682226861628.issue3939@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks. That seems to have done the trick.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3939>
_______________________________________

From report at bugs.python.org  Sun Sep 28 23:01:55 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 28 Sep 2008 21:01:55 +0000
Subject: [issue3990] The Linux2 platform definition is incorrect for alpha,
	hppa, mips, sparc
In-Reply-To: <1222622636.83.0.91904211749.issue3990@psf.upfronthosting.co.za>
Message-ID: <1222635715.17.0.716781366641.issue3990@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I dislike the brute-force approach of this patch. IMO, a less intrusive
solution should be found.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3990>
_______________________________________

From report at bugs.python.org  Sun Sep 28 23:09:17 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Sep 2008 21:09:17 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222636157.36.0.354003135056.issue3988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@christian.heimes: Oops, i totally forget the bytearray() type. Here 
is a new patch.

Added file: http://bugs.python.org/file11647/bytes_ne_warning-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 23:09:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Sep 2008 21:09:21 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222636161.14.0.731330739181.issue3988@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11646/bytes_ne_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 23:10:45 2008
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Sep 2008 21:10:45 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222636245.36.0.428881175764.issue3988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't know how to activate BytesWarning as error (as "python3 -bb" 
does). Here is an patch for tests only working with "python3 -bb".

Added file: http://bugs.python.org/file11648/test_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 23:12:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Sep 2008 21:12:55 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222636375.1.0.901953674132.issue3988@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

warnings.simplefilter("always", BytesWarning) should do the trick.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Sun Sep 28 23:31:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 28 Sep 2008 21:31:29 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222637489.65.0.737924576623.issue3187@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd like to propose yet another approach: make sure that conversion
according to the file system encoding always succeeds. If an
unconvertable byte is detected, map it into some private-use character.
To reduce the chance of conflict with other people's private-use
characters, we can use some of the plane 15 private-use characters, e.g.
map byte 0xPQ to U+F30PQ (in two-byte Unicode mode, this would result in
a surrogate pair).

This would make all file names accessible to all text processing
(including glob and friends); UI display would typically either report
an encoding error, or arrange for some replacement glyph to be shown.

There are certain variations of the approach possible, in case there is
objection to a specific detail.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Sun Sep 28 23:58:09 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 28 Sep 2008 21:58:09 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222639089.78.0.908024841021.issue3770@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I've been thinking about this - Right now, having a working mp.synchronize 
module, and thread support is key to package currently. For 2.6 - it's 
really too late to try to mock up a working mp.synchronize module, or 
significantly change the package.

My recommendation (I'm going to work on a patch to do this) is to not 
support fbsd/openbsd in this release cycle, which is unfortunate. Any 
other thoughts?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 00:16:30 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Sun, 28 Sep 2008 22:16:30 +0000
Subject: [issue3941] Help in IDLE should open the chm file
In-Reply-To: <1222129925.92.0.876996277522.issue3941@psf.upfronthosting.co.za>
Message-ID: <1222640190.79.0.910731323091.issue3941@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I just found out, that this doesn't work correctly, because the
Windows-helpfile in Python26rc2 is strangely named Python26c2.chm . It
works correctly however if one renames this file to Python26.chm (as
this is what the code in EditorWindow.py expects). 

So this will (almost certainly) be no problem in the final release.

Regards, Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3941>
_______________________________________

From report at bugs.python.org  Mon Sep 29 00:07:46 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Sun, 28 Sep 2008 22:07:46 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222639666.3.0.611031375522.issue3956@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I agree to Martin's patch for 2.6, because it seems to provide a more
clean solution. And, as he states, there will be time and opportunity to
discuss it more thoroughly later to possibly find another approach. As I
remarked before I know that singleton+inheritance is a controversial
subject. However the gang of four state in their book that one should
use the singleton design pattern if one needs exactly one instance af a
class and this should be extensible by subclassing ... (And there are
reasons why I'd like to have Screen() subclassable.)

Anyway, I think there are two more things to do:

1) Add a docstring to the Screen() function
2) Insert (at least) one sentence in the docs, 9.th paragraph of the
Introduction. Something like:

... so there can exist only one instance of Screen at a time. 
*Notice that consequently Screen cannot be sublassed.* 
It should be used when turtle is used as a standalone tool for doing
graphics. ...

Perhaps one should also note, that the singleton object is returned by a
function.

I've applied the proposed patch (file11645) to a working copy and I've
tested it in interactive mode as well as with turtleDemo and all the
supplied demoscripts and found it to work well.

Last, but not least: thanks Martin for your contribution.

Regards, 
Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Mon Sep 29 01:35:48 2008
From: report at bugs.python.org (bahiminin)
Date: Sun, 28 Sep 2008 23:35:48 +0000
Subject: [issue3981] Python 3, IDLE does not start
In-Reply-To: <1222619916.86.0.40214748771.issue3981@psf.upfronthosting.co.za>
Message-ID: <80a626f00809281635u173ac401y4a46b2eb99da42ef@mail.gmail.com>


bahiminin <art.wyse11 at gmail.com> added the comment:

Hi
Thank you. I found that file. r66518. My IDLE work now. Take care.

On Sun, Sep 28, 2008 at 9:38 AM, Amaury Forgeot d'Arc <
report at bugs.python.org> wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> IDLE won't start with 3.0rc1 because of issue #3628.
> This has been corrected in r66518.
>
> ----------
> nosy: +amaury.forgeotdarc
> resolution:  -> out of date
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3981>
> _______________________________________
>

Added file: http://bugs.python.org/file11649/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3981>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080928/18e22fca/attachment.txt>

From report at bugs.python.org  Mon Sep 29 01:40:56 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 23:40:56 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This patch removes the custom log implementation from distutils.

It keeps the compatibility with the previous logger and its specific
CONSTANTE names. It add a sys.stdout stream handler so it produces the
same output.

It is based on logging now, and a logger for distutils is created
at the root of the package.

The patch does not introduce any deprecation warning though, on
distutils.log usage, but maybe that could be a good idea, so the people
that use distutils.log know they should use distutils.logger.
(I don't know how the deprecation process works in Python)

----------
components: Distutils
files: remove-custom-log.diff
keywords: patch
messages: 73997
nosy: tarek
severity: normal
status: open
title: removed custom log from distutils
versions: Python 2.6
Added file: http://bugs.python.org/file11650/remove-custom-log.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Mon Sep 29 01:50:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Sep 2008 23:50:31 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1222645831.45.0.506864558409.issue3992@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Hey Tarek!

I fear most of your revisions - including this - can make it into 2.6
and 3.0. Python 2.6 and 3.0 are now in maintenance mode. Your patch
doesn't fall under the category bug fix. You have to target 2.7 and 3.1.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Mon Sep 29 02:35:39 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 29 Sep 2008 00:35:39 +0000
Subject: [issue3947] configure --with-threads on cygwin => crash on thread
	related tests
In-Reply-To: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za>
Message-ID: <1222648539.35.0.45079797917.issue3947@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
components: +Extension Modules
priority:  -> critical
versions: +Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3947>
_______________________________________

From report at bugs.python.org  Mon Sep 29 02:54:37 2008
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Mon, 29 Sep 2008 00:54:37 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222649677.79.0.00352087354963.issue3187@psf.upfronthosting.co.za>


Dwayne Litzenberger <dlitz at dlitz.net> added the comment:

Martin,

Consider this scenario.  On ext3/Linux, assume that UTF-8 is specified
in the system locale.  What would happen if you have two files, named
b"\xf3\xb3\x83\x80\x00" and b"\xc0\x00"?  Under your proposal, the first
file would decode successfully as "\U000f30c0\x00", and the second file
would decode unsuccessfully, so it would be mapped to
"\U000f30c0\x00"---the same thing!

Under your proposal, you could end up with multiple files having the
same filename (from Python's perspective). Python shouldn't break if
somebody deliberately created some weird filenames.  Your proposal would
make it impossible to write a robust remote backup tool in Python 3.

Pathnames on ext3/Linux *are not Unicode*.  Blindly pretending they're
Unicode is a leaky abstraction at best, and a security hole at worst.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 04:51:48 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Sep 2008 02:51:48 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222656708.28.0.407636821386.issue3187@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

You can call it a leaky abstraction all you want, but most people think
of filenames as text strings most of the time, and we need to somehow
support this, at least for users who agree .  I agree we also need to
support bytes strings (at least on Unix) in order to support backup
routines, and support for bytes in -> bytes out in os.listdir() is meant
for this.  The open() function should also support a pure bytes filename
(and almost does so -- _fileio does, but io.py doesn't yet). 
os.getcwd() is a weird case and will probably need to be given a flag to
make it return bytes (I don't like that style of API much, but the
alternative is perhaps worse -- os.getcwd_bytes()).

Conclusion: I support patches that make the I/O library work with either
bytes or strings.  (It's OK if the bytes don't actually work on Windows,
where the native type is apparently strings -- though it has a bytes API
too, doesn't it?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 04:52:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 02:52:55 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1222656775.5.0.894419875997.issue3984@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I can't find the bug right now, but this has been brought up before.
Since it is only on posix systems and only when running in a code
checkout, no one has worried about it enough to change it. And I am not
sure if it is necessarily worth pulling out of distutils just for this
one use-case. But if a patch came about that might help push it forward.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Mon Sep 29 04:56:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 29 Sep 2008 02:56:13 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1222656973.46.0.853567207599.issue3984@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Brett, are you looking for #586680?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Mon Sep 29 05:35:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 03:35:09 +0000
Subject: [issue3895] _lsprof issue
In-Reply-To: <1221705166.83.0.0369639810422.issue3895@psf.upfronthosting.co.za>
Message-ID: <1222659309.53.0.0440128181408.issue3895@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3895>
_______________________________________

From report at bugs.python.org  Mon Sep 29 06:05:28 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 04:05:28 +0000
Subject: [issue3895] _lsprof issue
In-Reply-To: <1221705166.83.0.0369639810422.issue3895@psf.upfronthosting.co.za>
Message-ID: <1222661128.51.0.148754812433.issue3895@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

2.6 is fixed in r66677 and 2.5 in r66678. 3.0 has not been applied yet
as test_cProfile is still currently listed as a broken test. So I am
blocking 66677 on py3k for now.

----------
priority: release blocker -> deferred blocker
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3895>
_______________________________________

From report at bugs.python.org  Mon Sep 29 06:09:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 04:09:26 +0000
Subject: [issue3910] 2.6 regression in socket.ssl method
In-Reply-To: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>
Message-ID: <1222661366.21.0.329733501115.issue3910@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It looks like no one objected. Can you check this in, Bill?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3910>
_______________________________________

From report at bugs.python.org  Mon Sep 29 06:14:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 04:14:32 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222661672.5.0.147529704149.issue3770@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, even if 2.6 slipped (which it is looking probably won't happen),
how much time would you need to deal with this? Sounds like you just
won't be able to get to it even with an extra week. So that means
multiprocessing is just not supported on FreeBSD and OpenBSD at this
moment. Sucks, but hopefully it can get fixed in the future. And if
people complain, bug them to get a reliable buildbot going.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 06:45:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 29 Sep 2008 04:45:31 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1222649677.79.0.00352087354963.issue3187@psf.upfronthosting.co.za>
Message-ID: <48E05D64.4000501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Consider this scenario.  On ext3/Linux, assume that UTF-8 is specified
> in the system locale.  What would happen if you have two files, named
> b"\xf3\xb3\x83\x80\x00" and b"\xc0\x00"?  Under your proposal, the first
> file would decode successfully as "\U000f30c0\x00", and the second file
> would decode unsuccessfully, so it would be mapped to
> "\U000f30c0\x00"---the same thing!

Correct.

> Under your proposal, you could end up with multiple files having the
> same filename (from Python's perspective). Python shouldn't break if
> somebody deliberately created some weird filenames.

I'm not so sure about that. Practicality beats purity.

> Your proposal would
> make it impossible to write a robust remote backup tool in Python 3.

There could be an option to set the file system encoding via an API
to some known safe value, such as Latin-1, or ASCII. If you set the
file system encoding to Latin-1, this escaping would never happen;
if you set it to ASCII, it would happen uniformly for all non-ASCII
bytes. The robust backup tool would have to know to set this option
on POSIX systems.

> Pathnames on ext3/Linux *are not Unicode*.  Blindly pretending they're
> Unicode is a leaky abstraction at best, and a security hole at worst.

I think most Linux users would disagree, and claim that file names are
indeed character strings (which is synonym to "being Unicode"). It is
technically true that it's possible to create file names which are not
text, but that's really a bug, not a feature - Unix and POSIX were never
intended to work this way. Also, in the overwhelming majority of Python
applications, consistent support for practically-existing systems
matters more than robustness against malicious users.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 06:47:18 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 29 Sep 2008 04:47:18 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1222656708.28.0.407636821386.issue3187@psf.upfronthosting.co.za>
Message-ID: <48E05DD1.4080607@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I agree we also need to
> support bytes strings (at least on Unix) in order to support backup
> routines

How about letting such applications set the file system encoding to
Latin-1?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 07:12:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 29 Sep 2008 05:12:00 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222665120.48.0.830834149713.issue3187@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

James Knight points out that UTF-8b can be used to give unambiguous
round-tripping of characters in a UTF-8 locale. So I would like to amend
my previous proposal:
- for a non-UTF-8 encoding, use private-use characters for roundtripping
- if the locale's charset is UTF-8, use UTF-8b as the file system encoding.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 07:21:25 2008
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 29 Sep 2008 05:21:25 +0000
Subject: [issue3993] Convert documentation to python 3.
In-Reply-To: <1222665685.89.0.771974548734.issue3993@psf.upfronthosting.co.za>
Message-ID: <1222665685.89.0.771974548734.issue3993@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/library/multiprocessing.html#module-
multiprocessing

uses "print" statement in pre-version 3 form.  I can easily imagine 
that this and similar 2to3 bugs pervade the manual.


(If I insisted on foolish consistency I'd point out also that the 
multiprocessing guidelines recommend joining all processes started, 
but that a few items later under "joining processes that use queues" 
hides the parenthetical remark

"... (or simply remove the p.join() line).")


At any rate, I'm looking forward to the 3.0 release.  And I'm thrilled 
that the library modules seem to be evolving toward lumps that are 
commonly used together.

----------
assignee: georg.brandl
components: Documentation
messages: 74009
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: Convert documentation to python 3.
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3993>
_______________________________________

From report at bugs.python.org  Mon Sep 29 08:07:31 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 29 Sep 2008 06:07:31 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222668451.05.0.708756002888.issue3956@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Agreeing to this patch, I'd just like to mention, that nevertheless this
change is not very pleasing for me. Not feeling that singleton with
inheritance is a 'meaningless' but rather a 'very special' concept,the
meaning of which could be explained, I've used this concept in the last
chapter of my book "Python for Kids" designing sort of a GameScreen
class derived from Screen(). Hmmm. So sthis seems to remain sort of a
unique selling point of xturtle for now. And in the 4th edition I can
certainly adapt this chapter. 

When 2.6 is out, what do you think is the right point for a further
discussion of this? (I think certainly not the bugtracker and
particularly not this issue.

Regards,
Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Mon Sep 29 08:35:30 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 29 Sep 2008 06:35:30 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222670130.19.0.197199784271.issue3956@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

... I meant: the right place for a further discussion 
Sorry, Gregor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Mon Sep 29 08:43:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 29 Sep 2008 06:43:55 +0000
Subject: [issue3993] Convert documentation to python 3.
In-Reply-To: <1222665685.89.0.771974548734.issue3993@psf.upfronthosting.co.za>
Message-ID: <1222670635.65.0.834492124582.issue3993@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed the prints in r66680.

The multiprocessing docs are a special case because they arrived after
we "upgraded" examples in the documentation to Python 3.0 code.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3993>
_______________________________________

From report at bugs.python.org  Mon Sep 29 09:06:48 2008
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 29 Sep 2008 07:06:48 +0000
Subject: [issue2532] file that breaks 2to3 (despite being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1222672008.15.0.841821789103.issue2532@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

pywin32 has a number of files that break in this way - often files
generated by h2py.py

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2532>
_______________________________________

From report at bugs.python.org  Mon Sep 29 09:13:12 2008
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 29 Sep 2008 07:13:12 +0000
Subject: [issue3994] import fixer misses some symbols
In-Reply-To: <1222672392.58.0.438026225401.issue3994@psf.upfronthosting.co.za>
Message-ID: <1222672392.58.0.438026225401.issue3994@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

The following source file:
"""
import _winreg
_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "foo")
"""

results in the following "patch":

-import _winreg
-_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "foo")
+import winreg
+winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "foo")

Note the first param has not been converted correctly.  This is probably
due to it following the paren, as using the same symbol in a local
variable works correctly.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 74014
nosy: mhammond
priority: high
severity: normal
status: open
title: import fixer misses some symbols
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3994>
_______________________________________

From report at bugs.python.org  Mon Sep 29 09:23:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 29 Sep 2008 07:23:43 +0000
Subject: [issue3941] Help in IDLE should open the chm file
In-Reply-To: <1222129925.92.0.876996277522.issue3941@psf.upfronthosting.co.za>
Message-ID: <1222673023.91.0.160448964826.issue3941@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3941>
_______________________________________

From report at bugs.python.org  Mon Sep 29 10:16:03 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 29 Sep 2008 08:16:03 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222676163.57.0.316156042523.issue3770@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Agreed - Jesse, can you work up a patch that generates a clean import
error when _multiprocessing.SemLock can't be defined (due to
HAVE_SEM_OPEN=0 or a single-threaded build), adds test_multiprocessing
to the expected skips for FreeBSD and OpenBSD, and updates the
multiprocessing docs to note the restriction to systems with a working
sem_open() implementation?

Improving the *BSD and single-threaded build compatibility of the
multiprocessing package will just have to be high on the to-do list for
2.6.1.

This may also be worth mentioning in the release notes - Barry's call on
that one.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 10:20:52 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Sep 2008 08:20:52 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222595903.95.0.266625430762.issue3984@psf.upfronthosting.co.za>
Message-ID: <1222676452.85.0.507440349925.issue3984@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Well, I have a patch in progress, that pulls it out in another package.
But I still get problems with the logging dependency, so it seems like a
lot of extra work for just this use case.

On the other hand, if distutils is going to be "cleaned" in the future,
this would probably be a good thing to extract those elements.

I am attaching a patch I have started just for the record, if something
is changed one day. It works besides the logging dependency and it shows
how it could be split maybe.

----------
keywords: +patch
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file11651/split-low-level-concerns.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Mon Sep 29 10:22:03 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Sep 2008 08:22:03 +0000
Subject: [issue3992] removed custom log from distutils
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1222676523.55.0.964883971628.issue3992@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Mon Sep 29 10:22:14 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Sep 2008 08:22:14 +0000
Subject: [issue3987] removed types from distutils.core [patch]
In-Reply-To: <1222599591.35.0.056010303755.issue3987@psf.upfronthosting.co.za>
Message-ID: <1222676534.96.0.650714799155.issue3987@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3987>
_______________________________________

From report at bugs.python.org  Mon Sep 29 10:22:27 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Sep 2008 08:22:27 +0000
Subject: [issue3986] removed string and type usage from distutils.cmd [patch]
In-Reply-To: <1222599260.36.0.588546522414.issue3986@psf.upfronthosting.co.za>
Message-ID: <1222676547.19.0.316310502426.issue3986@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3986>
_______________________________________

From report at bugs.python.org  Mon Sep 29 10:22:46 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Sep 2008 08:22:46 +0000
Subject: [issue3985] removed string module from distutils [patch]
In-Reply-To: <1222597888.29.0.260615260643.issue3985@psf.upfronthosting.co.za>
Message-ID: <1222676566.9.0.818626612608.issue3985@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3985>
_______________________________________

From report at bugs.python.org  Mon Sep 29 10:23:24 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Sep 2008 08:23:24 +0000
Subject: [issue2461] test_util.py for distutils
In-Reply-To: <1206271007.7.0.519259374853.issue2461@psf.upfronthosting.co.za>
Message-ID: <1222676604.37.0.582579568584.issue2461@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions: +Python 2.7, Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2461>
_______________________________________

From report at bugs.python.org  Mon Sep 29 11:57:03 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Mon, 29 Sep 2008 09:57:03 +0000
Subject: [issue3995] iso-xxx/cp1252  inconsistencies in Python 2.* not in 3.*
In-Reply-To: <1222682223.58.0.12502846451.issue3995@psf.upfronthosting.co.za>
Message-ID: <1222682223.58.0.12502846451.issue3995@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

XP SP2 fr_CH cp1252

I have always found, there are some inconsistencies in the Python <=2.5
serie regarding the char endodings, especially the iso-8859-1, cp1252,
iso-8859-15 encodings.

I do not know if this must be considered as a bug or as a feature.
Python is quite friendly with these encodings. It may not be a problem
for a daily work, it is more acute when one wish to teach the
chararacter encodings.

char "?": "code point" 156 in cp1252
char "?": "code point" 128 in cp1252

Python 2.5.2

>>> unicode('?', 'cp1252')
u'\u0153'
>>> unicode('?', 'cp1252')
u'\u20ac'
>>> unicode('?', 'iso-8859-15')
u'\x9c'
>>> unicode('?', 'iso-8859-15')
u'\x80'
>>> unicode('?', 'iso-8859-1') #***
u'\x80'
>>> unicode('?', 'iso-8859-1') #***
u'\x9c'
>>> #*** should raise an error since ? and ?
>>> #are not existing in an iso-8859-1 table.
>>> 

It looks like iso-8859-1 behaves as iso-8859-15 (typo somewhere?)

Python 3.0 rc1 does the job correctly and notices the difference

>>> bytes('?', 'cp1252')
b'\x9c'
>>> bytes('?', 'cp1252')
b'\x80'
>>> bytes('?', 'iso-8859-15')
b'\xbd'
>>> bytes('?', 'iso-8859-15')
b'\xa4'
>>> bytes('?', 'iso-8859-1')
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    bytes('?', 'iso-8859-1')
UnicodeEncodeError: 'latin-1' codec can't encode character '\u0153' in
position 0: ordinal not in range(256)
>>> bytes('?', 'iso-8859-1')
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    bytes('?', 'iso-8859-1')
UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in
position 0: ordinal not in range(256)
>>> # these errors are expected
>>> 

Python 2.6**

The latest version is not installed. If I recall correcly, 2.6b* are
presenting the same issue as in 2.5.2 .

----------
messages: 74017
nosy: jmfauth
severity: normal
status: open
title: iso-xxx/cp1252  inconsistencies in Python 2.* not in 3.*
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3995>
_______________________________________

From report at bugs.python.org  Mon Sep 29 12:14:30 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Sep 2008 10:14:30 +0000
Subject: [issue3995] iso-xxx/cp1252  inconsistencies in Python 2.* not in 3.*
In-Reply-To: <1222682223.58.0.12502846451.issue3995@psf.upfronthosting.co.za>
Message-ID: <1222683270.87.0.884806796928.issue3995@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If you write "?" in the Python interpreter (Python2), you will get a 
*bytes* string encoded in your terminal charset. Example on Linux 
(utf-8):

Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>> '?'
'\xe2\x82\xac'

Use "u" prefix to get unicode string:

Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>> u'?'
u'\u20ac'

If you use unicode, encoding to ISO-8859-1/-15 works correctly. 
(Truncated) example with python trunk:

Python 2.6rc2+ (trunk:66680M, Sep 29 2008, 12:03:32)
>>> u'?'.encode('ISO-8859-1')
...
UnicodeEncodeError: 'latin-1' codec can't encode character u'\u20ac'
>>> u'?'.encode('ISO-8859-15')
'\xa4'

In a script (Python code written in a file), use #coding header to 
specify your file charset. Or use "\xXX", "\uXXXX" and "\UXXXX" 
notations for non-ASCII characters.

Is there somewhere an Unicode Python FAQ? :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3995>
_______________________________________

From report at bugs.python.org  Mon Sep 29 12:22:21 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Sep 2008 10:22:21 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1222683741.72.0.542736194136.issue3982@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't think that b'...'.format() is a good idea. Programmers will 
continue to mix characters and bytes since .format() target are 
characters.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Mon Sep 29 12:40:02 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Sep 2008 10:40:02 +0000
Subject: [issue1069092] segfault on printing nested sequences of None/Ellipsis
Message-ID: <1222684802.99.0.845012231689.issue1069092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a stack overflow: your code do recursive calls to 
internal_print().

Backtrace from gdb:
--------------------------------------------
#0  0xb7e92064 in _IO_new_file_overflow () 
from /lib/tls/i686/cmov/libc.so.6
#1  0xb7e94bc3 in __overflow () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e8e03b in fputc () from /lib/tls/i686/cmov/libc.so.6
#3  0x080a2f2d in tupleprint (op=0xb7b5cc2c, fp=0xb7f744e0, flags=0) 
at Objects/tupleobject.c:193
#4  0x0808b9f7 in internal_print (op=0xb7b5cc2c, fp=0xb7f744e0, 
flags=0, nesting=0) at Objects/object.c:309
#5  0x0808ba60 in PyObject_Print (op=0xb7b5cc2c, fp=0xb7f744e0, 
flags=0) at Objects/object.c:324
(...)
#4628 0x0808ba60 in PyObject_Print (op=0xb7b68e4c, fp=0xb7f744e0, 
flags=0) at Objects/object.c:324
#4629 0x080a2f9e in tupleprint (op=0xb7b68e6c, fp=0xb7f744e0, flags=0) 
at Objects/tupleobject.c:201
#4630 0x0808b9f7 in internal_print (op=0xb7b68e6c, fp=0xb7f744e0, 
flags=0, nesting=0) at Objects/object.c:309
#4631 0x0808ba60 in PyObject_Print (op=0xb7b68e6c, fp=0xb7f744e0, 
flags=0) at Objects/object.c:324
(...)
#4638 0x080a2f9e in tupleprint (op=0xb7b68ecc, fp=0xb7f744e0, flags=0) 
at Objects/tupleobject.c:201
#4639 0x0808b9f7 in internal_print (op=0xb7b68ecc, fp=0xb7f744e0, 
flags=0, nesting=0) at Objects/object.c:309
#4640 0x0808ba60 in PyObject_Print (op=0xb7b68ecc, fp=0xb7f744e0, 
flags=0) at Objects/object.c:324
#4641 0x080a2f9e in tupleprint (op=0xb7b68eec, fp=0xb7f744e0, flags=0) 
at Objects/tupleobject.c:201
#4642 0x0808b9f7 in internal_print (op=0xb7b68eec, fp=0xb7f744e0, 
flags=0, nesting=0) at Objects/object.c:309
(...)
--------------------------------------------

Informations using my debugger (python-ptrace):
------------------------------------------------------------
PID: 1201
Signal: SIGSEGV
STACK OVERFLOW! Stack pointer is in 0xbf10d000-0xbf90d000 => [stack] 
(rw-p)
- instruction: CALL 0x80d3305
- mapping: 0xbf10cff0 is not mapped in memory
- register <stack ptr>=0xbf10cff0
------------------------------------------------------------

Some solutions:
 - avoid creation of nested sequence
 - create generic protection against stack overflow (use 
setjmp/longjmp)
 - avoid recursive call to internal_print()

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1069092>
_______________________________________

From report at bugs.python.org  Mon Sep 29 12:50:59 2008
From: report at bugs.python.org (Eric Smith)
Date: Mon, 29 Sep 2008 10:50:59 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1222685459.39.0.164347677869.issue3982@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

> I don't think that b'...'.format() is a good idea. Programmers
> will continue to mix characters and bytes since .format() target
> are characters.

b''.format() would return bytes, not a string. This is also how it works
in 2.6.

I'm also not sold on implementing it, although it would be easy and I
can see a few uses for it. I think Martin's suggesting of encoding back
to ascii might be the best thing to do (that is, don't implement
b''.format()).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Mon Sep 29 12:56:38 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Sep 2008 10:56:38 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1222685798.89.0.724902572426.issue3982@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think Martin's suggesting of encoding back to ascii might be 
> the best thing to do

As I understand, you would like to use bytes as characters, like 
b'{code} {message}'.format(code=100, message='OK'). So why no using 
explicit conversion to ASCII? ftp='{code} {message}'.format(code=100, 
message='OK').encode('ASCII').

If you need to work on bytes, it means that you will use the full 
range 0..255 whereas ASCII reject bytes in 128..255.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Mon Sep 29 13:23:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Sep 2008 11:23:28 +0000
Subject: [issue3977] Check PyInt_AsSsize_t/PyLong_AsSsize_t error
In-Reply-To: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>
Message-ID: <1222687408.65.0.48869964756.issue3977@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

All these patches seem good to me.

----------
nosy: +amaury.forgeotdarc
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3977>
_______________________________________

From report at bugs.python.org  Mon Sep 29 13:34:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Sep 2008 11:34:11 +0000
Subject: [issue3996] PyOS_CheckStack does not work
In-Reply-To: <1222688051.36.0.56998762725.issue3996@psf.upfronthosting.co.za>
Message-ID: <1222688051.36.0.56998762725.issue3996@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

On Windows, PyOS_CheckStack is supposed to protect the interpreter from
stack overflow. But doing this, it always crashes when the stack is
nearly full.

The reason is a bad check of the return value of _resetstkoflw():
according to MSDN, the return value is "Nonzero if the function
succeeds, zero if it fails.":
http://msdn.microsoft.com/en-us/library/89f73td2.aspx

The patch below is enough to replace the "Fatal Python error: Could not
reset the stack!" into a "MemoryError: stack overflow" exception.

Tested with:
>>> loop = None,
>>> for x in xrange(100000): loop = {'x': loop}
...
>>> len(repr(loop))



Index: Python/pythonrun.c
===================================================================
--- Python/pythonrun.c  (revision 66486)
+++ Python/pythonrun.c  (working copy)
@@ -1749,7 +1755,7 @@
                        EXCEPTION_EXECUTE_HANDLER :
                        EXCEPTION_CONTINUE_SEARCH) {
                int errcode = _resetstkoflw();
-               if (errcode)
+               if (errcode == 0)
                {
                        Py_FatalError("Could not reset the stack!");
                }

----------
assignee: loewis
components: Windows
keywords: patch
messages: 74024
nosy: amaury.forgeotdarc, loewis
severity: normal
status: open
title: PyOS_CheckStack does not work
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3996>
_______________________________________

From report at bugs.python.org  Mon Sep 29 13:48:00 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Mon, 29 Sep 2008 11:48:00 +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: <1222688880.88.0.678147503406.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Good work, Matthew.  Now, another bazaar hint, IMHO, is once of my
favourite commands: switch.  I generally develop all in one directory,
rather than getting a new directory for each branch.  Once does have to
be VERY careful to type "bzr info" to make sure the branch you're
editing is the one you think it is! but with "bzr switch", you do a
differential branch switch that allows you to change your development
branch quickly and painlessly.  This assumes you did a "bzr checkout"
and not a "bzr pull".  If you did a pull, you can still turn this into a
"checkout", where all VCS actions are mirrored on the server, by using
the 'bind' command.  Make sure you push your branch first.  You don't
need to worry about all this "bind"ing, "push"ing and "pull"ing if you
choose checkout, but OTOH, if your connection is over-all very slow, you
may still be better off with a "pull"ed branch rather than a
"checkout"ed one.

Anyway, good catch on those 4 lines and I'll see if I can get your
earlier branches up to date.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Sep 29 14:36:14 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Mon, 29 Sep 2008 12:36:14 +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: <1222691774.03.0.922477924771.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Matthew, I've traced down the patch failures in my merges and now each
of the 4 versions of code on Launchpad should compile, though the first
2 do not pass all the negative look-behind tests, though your later 2
do.  Any chance you could back-port that fix to the
lp:~pythonregexp2.7/python/issue2636-01+09-02+17 branch?  If you can, I
can propagate that fix to the higher levels pretty quickly.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Sep 29 14:51:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 29 Sep 2008 12:51:16 +0000
Subject: [issue3995] iso-xxx/cp1252  inconsistencies in Python 2.* not in 3.*
In-Reply-To: <1222682223.58.0.12502846451.issue3995@psf.upfronthosting.co.za>
Message-ID: <1222692676.91.0.147996286487.issue3995@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3995>
_______________________________________

From report at bugs.python.org  Mon Sep 29 14:51:57 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Sep 2008 12:51:57 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222692717.35.0.599304244398.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About os.getcwd(), another solution is merge_os_getcwd_getcwdu.patch: 
os.getcwd() always return unicode string and raise an error on unicode 
decode error. Wheras os.getcwd(bytes=True) always return bytes. 

The old function os.getcwdu() is removed since os.getcwd() already 
return unicode string.

Note: current version of os.getcwd() uses the wrong encoding to 
conversion bytes to unicode: it uses PyUnicode_FromString() instead of 
PyUnicode_Decode(..., Py_FileSystemDefaultEncoding, "strict") (as does 
getcwdu()).

Added file: http://bugs.python.org/file11652/merge_os_getcwd_getcwdu.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 16:16:00 2008
From: report at bugs.python.org (Pernici Mario)
Date: Mon, 29 Sep 2008 14:16:00 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222697760.26.0.807527042601.issue3944@psf.upfronthosting.co.za>


Pernici Mario <pernici at users.sourceforge.net> added the comment:

Mark, following your suggestions about using bigger integer types,
I added code to convert Python numbers to arrays of twodigits,
when a 64 bit integer type is supported, and for numbers with size
larger than 20; otherwise the code of the previous patch is used.
This 64 bit integer is used only inside multiplication, so no
modifications need to be made in other parts of the Python code.
Now with numbers with 300 decimal digits or more the speedup is
2x on 32 bit machine, 3x on 64 bit machine (50% and 2x respectively
for squaring).

There is a macro HAVE_INT64 to control if there is a 64 bit type;
the preprocessor instructions should be OK with gcc, but other
compilers might have a 64 bit type and not long long, so HAVE_INT64
is wrongly not defined and one falls back to multiplying arrays of
16 bit digits; these preprocessor instructions need to be fixed.

The speed difference for small integers is small;
here is a summary of some benchmarks on
Pentium M 1.6GHz, Athlon XP 2600+,
Athlon 64 X2 Dual Core 3800+, all with Debian;
speedup of this patch with respect to the current revision
(+ means the patch is faster):
In pybench, SimpleIntegerArithmetic: from -0.5% to +0.5%
            SimpleLongArithmetic:  : from -1% to +7%
pystone                            : from +0.5% to +1.5%

Added file: http://bugs.python.org/file11653/longobject2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Mon Sep 29 16:36:02 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 29 Sep 2008 14:36:02 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222698962.18.0.479099532789.issue3944@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice work!  Seems like we're going to be able to look forward to faster 
integer arithmetic in Python 2.7 / 3.1.  I'll try to find time to review 
your patch properly sometime soon.

Regarding the HAVE_INT64, there's a standard autoconf macro 
AC_TYPE_INT64_T (and its unsigned counterpart AC_TYPE_UINT64_T) that 
automatically sets int64_t (or uint64_t) to a 64-bit (unsigned) integer 
type whenever it exists.  So don't worry about the preprocessor stuff for 
the moment, so long as it's working on your machine;  we can fix it in 
Python's configure script instead sometime.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Mon Sep 29 16:45:27 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 29 Sep 2008 14:45:27 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222699527.52.0.541537041261.issue3187@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 17:10:58 2008
From: report at bugs.python.org (vali)
Date: Mon, 29 Sep 2008 15:10:58 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>


New submission from vali <georgescu at hotmail.com>:

using ZipFile library with Python 2.6 or an earlier version creates
archived files that are not compatible with windows compress or Winzip.
Other programs like 7-Zip will not have a problem with the format. 

Bug Description:
if it is attempted to create an archive with more than 65535 (e.g 2^16 +
10)  files winzip or windows compress will show only what is above 65535
(in this case 9 file) 

The attached script tries to create an archive with 2^16 + 1 files and
compress or winzip will show an empty archive.

----------
components: Extension Modules
files: bug.py
messages: 74030
nosy: vgeorge
severity: normal
status: open
title: zipfile and winzip
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11654/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Mon Sep 29 17:20:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Sep 2008 15:20:28 +0000
Subject: [issue3997] zipfile and winzip
In-Reply-To: <1222701058.88.0.102455918408.issue3997@psf.upfronthosting.co.za>
Message-ID: <1222701628.7.0.162326222592.issue3997@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

An archive with more than 65535 files must use the "64-bit extensions"
of the standard Zip format.

Such archives cannot be opened by programs that do not understand these
extensions. See http://www.winzip.com/wzdic.htm

Which version of Winzip did you try?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3997>
_______________________________________

From report at bugs.python.org  Mon Sep 29 17:58:47 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Sep 2008 15:58:47 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222703927.19.0.937700670812.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

As Steven Bethard proposed, here is a new version of my getcwd() 
patch: instead of adding a keyword argument "bytes", I created a 
function getcwdb():
 * os.getcwd() -> unicode
 * os.getcwdb() -> bytes

In Python2 it was:
 * os.getcwd() -> str (bytes)
 * os.getcwdu() -> unicode

Added file: http://bugs.python.org/file11655/os_getcwdb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Mon Sep 29 18:53:27 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 29 Sep 2008 16:53:27 +0000
Subject: [issue3910] 2.6 regression in socket.ssl method
In-Reply-To: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>
Message-ID: <1222707207.22.0.22395343467.issue3910@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Will do.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3910>
_______________________________________

From report at bugs.python.org  Mon Sep 29 18:59:05 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 29 Sep 2008 16:59:05 +0000
Subject: [issue3910] 2.6 regression in socket.ssl method
In-Reply-To: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>
Message-ID: <1222707545.45.0.908055340353.issue3910@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Maybe not.  test_ssl hangs when I run it "-u all -v".  It's hanging on
testSimpleSSLWrap.  This is on OS X 10.5.5.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3910>
_______________________________________

From report at bugs.python.org  Mon Sep 29 19:36:10 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 29 Sep 2008 17:36:10 +0000
Subject: [issue3944] faster long multiplication
In-Reply-To: <1222165559.78.0.447355238601.issue3944@psf.upfronthosting.co.za>
Message-ID: <1222709770.02.0.14066711827.issue3944@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Nice work :)

I'm changing the target versions to 2.7 and 3.1. The proposed changes
are too large for a maintenance release.

----------
components: +Interpreter Core
nosy: +christian.heimes
priority:  -> high
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3944>
_______________________________________

From report at bugs.python.org  Mon Sep 29 20:20:39 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Sep 2008 18:20:39 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222712439.75.0.0610573971026.issue3770@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Hows this error look:

>>> import multiprocessing
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/jesse/open_source/subversion/python-
trunk/Lib/multiprocessing/__init__.py", line 178, in <module>
    " function, see issue 3770.")
multiprocessing.SemaphoreImportError: This platform lacks a functioning 
sem_open implementation and thereforce, the required synchronization 
primitives needed will not function, see issue 3770.
>>>

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 20:33:16 2008
From: report at bugs.python.org (Damien Miller)
Date: Mon, 29 Sep 2008 18:33:16 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1222712439.75.0.0610573971026.issue3770@psf.upfronthosting.co.za>
Message-ID: <alpine.BSO.1.10.0809300432390.16849@fuyu.mindrot.org>


Damien Miller <djmdjm at users.sourceforge.net> added the comment:

looks good to me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 20:44:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 18:44:30 +0000
Subject: [issue3894] imageop issue
In-Reply-To: <1221705077.19.0.351380267701.issue3894@psf.upfronthosting.co.za>
Message-ID: <1222713870.37.0.961729658586.issue3894@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3894>
_______________________________________

From report at bugs.python.org  Mon Sep 29 20:45:24 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 18:45:24 +0000
Subject: [issue3984] python interpreter import dependency with disutils/util
In-Reply-To: <1222656973.46.0.853567207599.issue3984@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809291145u506f507cmf3143f2a2a402960@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Sep 28, 2008 at 7:56 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Brett, are you looking for #586680?
>

Yep, that's the issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3984>
_______________________________________

From report at bugs.python.org  Mon Sep 29 20:57:05 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 29 Sep 2008 18:57:05 +0000
Subject: [issue3910] 2.6 regression in socket.ssl method
In-Reply-To: <1221846575.92.0.833754739866.issue3910@psf.upfronthosting.co.za>
Message-ID: <1222714625.25.0.679110554781.issue3910@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

OK, I found the fix.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3910>
_______________________________________

From report at bugs.python.org  Mon Sep 29 21:24:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Sep 2008 19:24:07 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1222712439.75.0.0610573971026.issue3770@psf.upfronthosting.co.za>
Message-ID: <bbaeab100809291224l5206364bw97e51eb3afd7129e@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Sep 29, 2008 at 11:20 AM, Jesse Noller <report at bugs.python.org> wrote:
>
> Jesse Noller <jnoller at gmail.com> added the comment:
>
> Hows this error look:
>
>>>> import multiprocessing
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "/Users/jesse/open_source/subversion/python-
> trunk/Lib/multiprocessing/__init__.py", line 178, in <module>
>    " function, see issue 3770.")
> multiprocessing.SemaphoreImportError: This platform lacks a functioning
> sem_open implementation and thereforce, the required synchronization
> primitives needed will not function, see issue 3770.

Is "thereforce" an actual word? Otherwise it looks fine to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 21:29:01 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Sep 2008 19:29:01 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <bbaeab100809291224l5206364bw97e51eb3afd7129e@mail.gmail.com>
Message-ID: <4222a8490809291228y4bcc7aa7uebd582f2b904f1a7@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

> Is "thereforce" an actual word? Otherwise it looks fine to me.
>

Yeah, I caught that. Rather than disable the entire package, which
would be frustrating to many - I've changed it to only disable
mp.synchronize for now, patch is pending my final build and test/doc
check locally

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 22:05:08 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 29 Sep 2008 20:05:08 +0000
Subject: [issue3547] Ctypes is confused by bitfields of varying integer types
In-Reply-To: <1218558018.93.0.569249577557.issue3547@psf.upfronthosting.co.za>
Message-ID: <1222718708.11.0.847494283879.issue3547@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Committed as SVN rev 66683 (trunk), 66684 (py3k), and 66685
(release25-maint).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3547>
_______________________________________

From report at bugs.python.org  Mon Sep 29 22:07:33 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Sep 2008 20:07:33 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222718853.73.0.374718251538.issue3770@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Here's a patch, works on my machine. Please review it and make sure it 
satisfies what we've spoken about.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file11656/issue3770.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 22:27:31 2008
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Sep 2008 20:27:31 +0000
Subject: [issue3996] PyOS_CheckStack does not work
In-Reply-To: <1222688051.36.0.56998762725.issue3996@psf.upfronthosting.co.za>
Message-ID: <1222720051.88.0.644691379987.issue3996@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue may be related: issue1069092

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3996>
_______________________________________

From report at bugs.python.org  Mon Sep 29 22:29:32 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 29 Sep 2008 20:29:32 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222720172.66.0.758599451056.issue3770@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Could use confirmation from Damien and Andrew that they now see the
expected skips with the patch applied, but otherwise looks good to me.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Sep 29 22:47:32 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 29 Sep 2008 20:47:32 +0000
Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII
	characters
In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>
Message-ID: <1222721252.49.0.246533765795.issue3991@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

As I read RFC 2396,

1.5:  "A URI is a sequence of characters from a very
   limited set, i.e. the letters of the basic Latin alphabet, digits,
   and a few special characters."

2.4:  "Data must be escaped if it does not have a representation using an
   unreserved character; this includes data that does not correspond to
   a printable character of the US-ASCII coded character set, or that
   corresponds to any US-ASCII character that is disallowed, as
   explained below."

So your URL string is invalid.  You need to escape the characters properly.

(RFC 2396 is what the HTTP RFC cites as its authority on URLs.)

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3991>
_______________________________________

From report at bugs.python.org  Mon Sep 29 22:53:43 2008
From: report at bugs.python.org (Josiah Carlson)
Date: Mon, 29 Sep 2008 20:53:43 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1222721623.46.0.457051600089.issue1745035@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

The patch does not work as Giampaolo intends.  If the patch were applied 
as-is, no emails longer than 998 bytes could be sent.

Instead, incrementing linelen in the collect_incoming_data() method 
should only be performed if self.terminator == '\r\n'.

I can apply a modified version of this patch against trunk after 2.6 is 
released.  Backports to 2.5 and 2.6 should then be discussed.

----------
assignee: barry -> josiahcarlson
nosy: +josiahcarlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Mon Sep 29 23:22:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 29 Sep 2008 21:22:16 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222668451.05.0.708756002888.issue3956@psf.upfronthosting.co.za>
Message-ID: <48E14705.2060806@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> When 2.6 is out, what do you think is the right point for a further
> discussion of this? (I think certainly not the bugtracker and
> particularly not this issue.

Depends on what you want to achieve with the discussion. If you want
a public opinion, post to comp.lang.python. Most likely, the public
doesn't care - at least not so much to spend actually time trying to
understand the issue.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Mon Sep 29 23:30:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 29 Sep 2008 21:30:27 +0000
Subject: =?utf-8?q?[issue3995]_iso-xxx/cp1252_inconsistencies_in=09Python_2.*_not_in_3.*?=
In-Reply-To: <1222682223.58.0.12502846451.issue3995@psf.upfronthosting.co.za>
Message-ID: <48E148F0.90700@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>>>> unicode('?', 'iso-8859-15')
> u'\x80'
>>>> unicode('?', 'iso-8859-1') #***
> u'\x80'
> 
> It looks like iso-8859-1 behaves as iso-8859-15 (typo somewhere?)

That's correct, and intentional. iso-8850-1 and iso-8859-15 are
*indeed* the same for the respective code points (i.e \x80 and
\x9c).

----------
nosy: +loewis
title: iso-xxx/cp1252  inconsistencies in Python 2.* not in 3.* -> iso-xxx/cp1252 inconsistencies in	Python 2.* not in 3.*

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3995>
_______________________________________

From report at bugs.python.org  Mon Sep 29 23:30:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 29 Sep 2008 21:30:50 +0000
Subject: [issue3977] Check PyInt_AsSsize_t/PyLong_AsSsize_t error
In-Reply-To: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>
Message-ID: <1222723850.91.0.915192364998.issue3977@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3977>
_______________________________________

From report at bugs.python.org  Mon Sep 29 23:33:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 29 Sep 2008 21:33:09 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222685798.89.0.724902572426.issue3982@psf.upfronthosting.co.za>
Message-ID: <48E14993.1060404@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> I think Martin's suggesting of encoding back to ascii might be 
>> the best thing to do
> 
> As I understand, you would like to use bytes as characters, like 
> b'{code} {message}'.format(code=100, message='OK'). So why no using 
> explicit conversion to ASCII? ftp='{code} {message}'.format(code=100, 
> message='OK').encode('ASCII').

That's indeed exactly what I had proposed - only that you shouldn't
repeat the .encode('ascii') all over the place, but instead wrap that
into a function (which I proposed to call push_string, along with the
existing .push function.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Tue Sep 30 00:20:14 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 29 Sep 2008 22:20:14 +0000
Subject: [issue3956] turtle.py - bug in Screen.__init__()
In-Reply-To: <1222263778.39.0.275068450449.issue3956@psf.upfronthosting.co.za>
Message-ID: <1222726814.15.0.683867480216.issue3956@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Committed (with the two proposed modifications) as r66686 and r66687.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3956>
_______________________________________

From report at bugs.python.org  Tue Sep 30 00:23:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Sep 2008 22:23:01 +0000
Subject: [issue3996] PyOS_CheckStack does not work
In-Reply-To: <1222688051.36.0.56998762725.issue3996@psf.upfronthosting.co.za>
Message-ID: <1222726981.55.0.443468088542.issue3996@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, issue1069092 is another case where PyOS_CheckStack is exercised. 
But this other issue was first reported on Unix, when PyOS_CheckStack is 
currently implemented only for Windows.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3996>
_______________________________________

From report at bugs.python.org  Tue Sep 30 00:27:45 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 29 Sep 2008 22:27:45 +0000
Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII
	characters
In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>
Message-ID: <1222727265.2.0.126392267513.issue3991@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Possibly.  This is a change from python-2.x's urlopen() which escaped
the URL automatically, though.  I can see the case for having the user
call an escape function themselves instead of having urlopen() perform
the escape for them.  However, that function would need to be written.
(The present parse.quote() method only quotes correctly if only the path
component is passed; there's no function to take a full URL and quote it
appropriately.)

Without such a function, a whole lot of code bases will have to reinvent
the wheel creating functions to parse the path out, run it through
urllib.parse.quote() and then pass the result to urlib.urlopen().

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3991>
_______________________________________

From report at bugs.python.org  Tue Sep 30 00:36:22 2008
From: report at bugs.python.org (Damien Miller)
Date: Mon, 29 Sep 2008 22:36:22 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1222720172.66.0.758599451056.issue3770@psf.upfronthosting.co.za>
Message-ID: <alpine.BSO.1.10.0809300808060.16849@fuyu.mindrot.org>


Damien Miller <djmdjm at users.sourceforge.net> added the comment:

I can confirm that the patch works on OpenBSD -current. Only one nit:

Does this line in Lib/test/test_multiprocessing.py need to be there?

+#import multiprocessing.SemaphoreImportError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Tue Sep 30 00:48:36 2008
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 29 Sep 2008 22:48:36 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <alpine.BSO.1.10.0809300808060.16849@fuyu.mindrot.org>
Message-ID: <54842AC6-311E-48E4-9059-A6394729B528@gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Sep 29, 2008, at 6:36 PM, Damien Miller <report at bugs.python.org>  
wrote:

>
> Damien Miller <djmdjm at users.sourceforge.net> added the comment:
>
> I can confirm that the patch works on OpenBSD -current. Only one nit:
>
> Does this line in Lib/test/test_multiprocessing.py need to be there?
>
> +#import multiprocessing.SemaphoreImportError
>

Oops - my bad. I'll remove it and check it tonight

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Tue Sep 30 01:05:28 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Sep 2008 23:05:28 +0000
Subject: [issue3998] List.sort docstring has obsolete cmp reference.
In-Reply-To: <1222729528.45.0.803178119587.issue3998@psf.upfronthosting.co.za>
Message-ID: <1222729528.45.0.803178119587.issue3998@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

3.0rc1
>>> help(list.sort)
Help on method_descriptor:

sort(...)
    L.sort(key=None, reverse=False) -- stable sort *IN PLACE*;
    cmp(x, y) -> -1, 0, 1

The last line is left over from 2.x docstring.  Since cmp keyword param
is gone (so also says LibRef: "s.sort([key[, reverse]]) sort the items
of s in place") delete it.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 74056
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: List.sort docstring has obsolete cmp reference.
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3998>
_______________________________________

From report at bugs.python.org  Tue Sep 30 02:17:29 2008
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 30 Sep 2008 00:17:29 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222733849.44.0.546881501535.issue3770@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

checked in r66688, lowering from rb to crit to address post 2.6 final

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Tue Sep 30 02:45:10 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 30 Sep 2008 00:45:10 +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: <1222735510.15.0.396406216256.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-01+09-02+17_backport.diff is the backport fix.

Still unable to compress the download, so that's >200MB each time!

Added file: http://bugs.python.org/file11657/issue2636-01+09-02+17_backport.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Sep 30 03:08:11 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 01:08:11 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222736891.79.0.535221009659.issue3187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch python3_bytes_filename.patch:
 - open() support bytes
 - listdir(unicode) -> only unicode, *skip* invalid filenames 
   (as asked by Guido)
 - remove os.getcwdu()
 - create os.getcwdb() -> bytes
 - glob.glob() support bytes
 - fnmatch.filter() support bytes
 - posixpath.join() and posixpath.split() support bytes

Mixing bytes and str is invalid. Examples raising a TypeError:
 - posixpath.join(b'x', 'y')
 - fnmatch.filter([b'x', 'y'], '*')
 - fnmatch.filter([b'x', b'y'], '*')
 - glob.glob1('.', b'*')
 - glob.glob1(b'.', '*')

TODO:
 - review this patch :-)
 - support non-ASCII bytes in fnmatch.filter()
 - fix other functions, eg. posixpath.isabs() and 
fnmatch.fnmatchcase()
 - fix functions written in C: grep FileSystemDefaultEncoding
 - make sure that mixing bytes and str is rejected

Added file: http://bugs.python.org/file11658/python3_bytes_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Tue Sep 30 03:10:12 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 01:10:12 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I would like to be able to catch SIGSEGV in my Python code! So I 
started to hack Python trunk to support this feature. The idea is to 
use a signal handler which call longjmp(), and add setjmp() at 
Py_EvalFrameEx() enter.

See attached ("small") patch: segfault.patch

Example read.py with the *evil* ctypes module of invalid memory read:
------------------- 8< --------------
from ctypes import string_at

def fault():
    text = string_at(1, 10)
    print("text = {0!r}".format(text))

def test():
    print("test: 1")
    try:
        fault()
    except MemoryError, err:
        print "ooops!"
        print err

    print("test: 2")
    try:
        fault()
    except MemoryError, err:
        print "ooops!"
        print err

    print("test: end")

def main():
    test()

if __name__ == "__main__":
    main()
------------------- 8< --------------

Result:
------------------- 8< --------------
$ python read.py
test: 1
sizeof()=160
ooops!
segmentation fault
test: 2
sizeof()=160
ooops!
segmentation fault
test: end
------------------- 8< --------------

Example bug1.py of a stack overflow:
----------
loop = None,
for i in xrange(10**5):
    loop = loop, None
----------

Result:
----------
$ python -i bug1.py

(((((((((...Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError: segmentation fault

----------

Python is able to restore a valid state (stack/heap) after a 
segmentation fault and raise a classical Python exception (I choosed 
MemoryError, but it could be a specific exception).

On my computer (Ubuntu Gutsy/i386), each segfault_frame takes 
sizeof(sigjmpbuf) + sizeof(void*) = 160 bytes, allocated on the stack. 
I don't know if it's huge or not, but that will limit the number of 
recursive calls. The feature can be optional if we add a configure 
option and some #ifdef/#endif. A dedicated stack is needed to be call 
the signal handler on stack overflow error. I choosed 4 KB, but since 
I only call longjmp(), smaller stack might also works.

Does other VM support such feature? JVM, Mono, .NET, etc. ?

I had the idea of catching SIGSEGV after reading the issue 1069092 
(stack overflow because of too many recursive calls).

----------
files: segfault.patch
keywords: patch
messages: 74060
nosy: haypo
severity: normal
status: open
title: Real segmentation fault handler
Added file: http://bugs.python.org/file11659/segfault.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Tue Sep 30 03:48:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Sep 2008 01:48:17 +0000
Subject: [issue3894] imageop issue
In-Reply-To: <1221705077.19.0.351380267701.issue3894@psf.upfronthosting.co.za>
Message-ID: <1222739297.5.0.61476701632.issue3894@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r66689 and r66690.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3894>
_______________________________________

From report at bugs.python.org  Tue Sep 30 04:08:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Sep 2008 02:08:52 +0000
Subject: [issue3998] List.sort docstring has obsolete cmp reference.
In-Reply-To: <1222729528.45.0.803178119587.issue3998@psf.upfronthosting.co.za>
Message-ID: <1222740532.64.0.500365322046.issue3998@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks. Fixed in r66692.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3998>
_______________________________________

From report at bugs.python.org  Tue Sep 30 04:09:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Sep 2008 02:09:23 +0000
Subject: [issue3998] List.sort docstring has obsolete cmp reference.
In-Reply-To: <1222729528.45.0.803178119587.issue3998@psf.upfronthosting.co.za>
Message-ID: <1222740563.4.0.251803644267.issue3998@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3998>
_______________________________________

From report at bugs.python.org  Tue Sep 30 04:19:02 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Sep 2008 02:19:02 +0000
Subject: [issue3988] Byte warning mode and b'' != ''
In-Reply-To: <1222601577.06.0.270135591037.issue3988@psf.upfronthosting.co.za>
Message-ID: <1222741142.28.0.995845713191.issue3988@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Setting as a deferred blocker since this is a 3.0 thing and not a 2.6 thing.

----------
nosy: +brett.cannon
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3988>
_______________________________________

From report at bugs.python.org  Tue Sep 30 04:22:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Sep 2008 02:22:26 +0000
Subject: [issue3977] Check PyInt_AsSsize_t/PyLong_AsSsize_t error
In-Reply-To: <1222450562.88.0.825613583168.issue3977@psf.upfronthosting.co.za>
Message-ID: <1222741346.5.0.558475069666.issue3977@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the patches. Fixed in r66693, r66694, and r66695.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3977>
_______________________________________

From report at bugs.python.org  Tue Sep 30 06:20:34 2008
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 30 Sep 2008 04:20:34 +0000
Subject: [issue4000] Additional 2to3 documentation updates
In-Reply-To: <1222748434.01.0.683191866382.issue4000@psf.upfronthosting.co.za>
Message-ID: <1222748434.01.0.683191866382.issue4000@psf.upfronthosting.co.za>


New submission from David W. Lambert <lambertdw at corning.com>:

http://docs.python.org/dev/3.0/howto/functional.html

    a) Refers to "print statement" in Introduction,

    b) Uses syntax no longer valid:

       def get_state ((city, state)):
           '''
               alas and unfortunately argument grouping
               is no longer permitted
           '''
           return state


Thanks, that's all for tonight.

----------
assignee: georg.brandl
components: Documentation
messages: 74065
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: Additional 2to3 documentation updates
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4000>
_______________________________________

From report at bugs.python.org  Tue Sep 30 06:22:13 2008
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 30 Sep 2008 04:22:13 +0000
Subject: [issue4000] Additional 2to3 documentation updates
In-Reply-To: <1222748434.01.0.683191866382.issue4000@psf.upfronthosting.co.za>
Message-ID: <1222748533.57.0.886280282591.issue4000@psf.upfronthosting.co.za>


Changes by David W. Lambert <lambertdw at corning.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4000>
_______________________________________

From report at bugs.python.org  Tue Sep 30 10:54:26 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Sep 2008 08:54:26 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1222764866.57.0.398548769838.issue3999@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Did you consider using PyOS_CheckStack for this?
Currently there is only a Windows implementation, but it seems that the
primitives you use in your patch could form a Unix version.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Tue Sep 30 11:02:53 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 09:02:53 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1222765373.64.0.170534331375.issue3999@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@amaury.forgeotdarc: It looks like PyOS_CheckStack() is only 
implemented for Windows. It uses alloca() + __try/__except + 
_resetstkoflw(). The GNU libc nor Linux kernel don't check stack 
pointer on alloca(), it's just $esp += <alloca argument>. Using 
alloca() you may also be able to able outside the stack to move your 
stack pointer to the heap or another memory mapping. PyOS_CheckStack() 
doesn't really protect the stack: if a function use alloca() or a 
similar construction like ? void test(int size) { char 
allocated_on_the_stack[size]; ... } ?, you will not catch this error.

PyOS_CheckStack() only checks one type of error: stack overflow. It 
doesn't check invalid memory read / write (see my first example, 
read.py).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Tue Sep 30 11:06:02 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 09:06:02 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1222765562.98.0.595912171204.issue3999@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: my patch can be adapted to catch SIGFPE (divison by zero or 
other math error). For int/long types, Python avoids divison by zero, 
but for code written in C ("external modules"), Python is unable to 
catch such errors. Eg. see last imageop issue: i was possible to 
generate many divisions by zero.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Tue Sep 30 14:15:32 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 30 Sep 2008 12:15:32 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222776932.9.0.132375046627.issue3723@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Adding the functions as initfunc in module init table is of no use as 
they aren't invoked when creating a sub interpreter.

One thing that does appear to work, although no idea of whether it is 
correct way to solve problem, is to duplicate the builtin/sys 
initialisation that occurs in Py_InitializeEx() function.

Attached diff shows nature of changes. Diff is bit messy as have left 
existing code in there but #ifdef'd out.

Maybe this will give someone who knows how overall interpreter 
initialisation is supposed to work a head start on coming up with proper 
fix. But then it could be totally wrong as well.

At least with change as is, mod_wsgi works for sub interpreters now. 
I'll do more work later on whether it is correct way to solve it.

----------
nosy: +grahamd
Added file: http://bugs.python.org/file11660/pythonrun.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Tue Sep 30 14:22:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Sep 2008 12:22:02 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222777322.25.0.885585922424.issue3723@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Your patch may go in the right direction, but please provide only
context diff or unified diff files. 
Use "diff -du", or "svn diff" to generate the file.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Tue Sep 30 14:27:10 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 30 Sep 2008 12:27:10 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222777630.68.0.541232819925.issue3723@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Argh. Personally I like to provide context diff's but more often than not 
get abused for providing them over a unified diff. Was in a hurry this 
time as had only a couple of minutes of battery life left on the laptop, 
so quickly did it without thinking and then ran off to find a power point. 
:-)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Tue Sep 30 14:30:23 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 30 Sep 2008 12:30:23 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222777823.19.0.831615809726.issue3723@psf.upfronthosting.co.za>


Changes by Graham Dumpleton <Graham.Dumpleton at gmail.com>:


Removed file: http://bugs.python.org/file11660/pythonrun.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Tue Sep 30 14:31:05 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 30 Sep 2008 12:31:05 +0000
Subject: [issue3723] Py_NewInterpreter does not work
In-Reply-To: <1220011870.63.0.171875917127.issue3723@psf.upfronthosting.co.za>
Message-ID: <1222777865.36.0.777241946762.issue3723@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Unified diff now attached.

Added file: http://bugs.python.org/file11661/pythonrun.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3723>
_______________________________________

From report at bugs.python.org  Tue Sep 30 15:12:55 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 30 Sep 2008 13:12:55 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1222780375.3.0.403387444945.issue1745035@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

Yes, you're right. I mixed up SMTP with FTP which does not send data on
the same connection used for receiving commands.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Tue Sep 30 15:16:34 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 30 Sep 2008 13:16:34 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1222780594.78.0.727850609653.issue3863@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

I believe this issue ties into the underlying problem FreeBSD 6.x upto
and including 6.3R have with fork() in a threaded application - see the
6.3R errata notice referenced in issue3864.

The issue should be fixed in FreeBSD 6.4 (currently in beta), but it
would be nice to get the patch in to Python 2.6 and Python 3.0 (not sure
about 2.5) just so that running the test doesn't hang on earlier 6.x
releases.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Tue Sep 30 15:20:32 2008
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 30 Sep 2008 13:20:32 +0000
Subject: [issue4001] 2to3 does relative import for modules not in a package.
In-Reply-To: <1222780832.06.0.913683232517.issue4001@psf.upfronthosting.co.za>
Message-ID: <1222780832.06.0.913683232517.issue4001@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

Create an empty directory with only 2 files, foo.py and bar.py, both
exactly 1 line:

foo.py:
|from bar import bar
bar.py:
|bar = "bar"

Running 2to3 results in the following patch for foo.py:
-from bar import bar
+from .bar import bar

However, the resulting foo.py fails to run - the 2 files are not in a
package, so we get:

| ValueError: Attempted relative import in non-package

Attaching a patch which checks there is an __init__.py in the same
directory as the files before it considers it a potential relative import.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: relative_must_be_package.patch
keywords: patch
messages: 74075
nosy: mhammond
severity: normal
status: open
title: 2to3 does relative import for modules not in a package.
Added file: http://bugs.python.org/file11662/relative_must_be_package.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4001>
_______________________________________

From report at bugs.python.org  Tue Sep 30 15:35:22 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 30 Sep 2008 13:35:22 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1222781722.19.0.413848793074.issue3862@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

On FreeBSD 7.0 amd64, applying Mark's patch does get the test to pass.

As noted on python-dev, the response I got from the author of the new
malloc() package in FreeBSD 7.x indicates that as of 7.1 the allocator
defaults to using sbrk() rather than mmap() (strategy selection is
tunable with an environment variable) so the problematic behaviour
should be masked once 7.1 is released.

Martin: I'm missing something regarding your comment about the failure
message - the exception text seems literally correct (though not
particularly useful), though I haven't spent a lot of time trying to
understand how test_array works.  What would you suggest?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Tue Sep 30 15:43:56 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Tue, 30 Sep 2008 13:43:56 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1222782236.35.0.0817482986788.issue3770@psf.upfronthosting.co.za>


Andrew I MacIntyre <aimacintyre at users.sourceforge.net> added the comment:

The checked in change has the planned effect on FreeBSD 6.3 i386. I
can't check on my 7.0 amd64 box as I can't quickly put a current source
tree on it.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Tue Sep 30 15:56:35 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 30 Sep 2008 13:56:35 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1221355819.02.0.121896067033.issue3862@psf.upfronthosting.co.za>
Message-ID: <1222782995.71.0.0706487889829.issue3862@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The 2**16 in the error message is wrong.  Maybe the error message should
be something like:

"Attempt to create array of size larger than maxsize failed to raise
MemoryError."

A bit verbose, but more accurate.

There's another error in that patch, too.  The line:

b * maxsize//3 + 1

should be

b * (maxsize//3 + 1)

(I was mistakenly reading the '*' as '*=', as in the first test.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Tue Sep 30 16:58:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 30 Sep 2008 14:58:46 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1222786726.96.0.629680984818.issue3863@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Cygwin1.5 also hangs on test_3_join_in_forked_from_thread.
Cygwin1.7 + following snapshot doesn't hang but
http://cygwin.com/snapshots/cygwin1-20080929.dll.bz2
fails with following message.

======================================================================
FAIL: test_3_join_in_forked_from_thread (__main__.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_threading.py", line 400, in
test_3_join_in_forked_from_thr
ead
    self._run_and_join(script)
  File "Lib/test/test_threading.py", line 342, in _run_and_join
    self.assertEqual(data, "end of main\nend of thread\n")
AssertionError: '' != 'end of main\nend of thread\n'

If stdout is unbuffered mode,
$ export PYTHONUNBUFFERED=x
test passes.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Tue Sep 30 17:21:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 30 Sep 2008 15:21:16 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1222788076.91.0.0302826382378.issue3187@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch that solves the issue in a different way: it introduces
sys.setfilesystemencoding. If applications invoke
sys.setfilesystemencoding("iso-8859-1"), all file names can be
successfully converted into a character string.

Added file: http://bugs.python.org/file11663/setfsenc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Tue Sep 30 17:38:07 2008
From: report at bugs.python.org (John)
Date: Tue, 30 Sep 2008 15:38:07 +0000
Subject: [issue4002] A Bug in the Documentation
In-Reply-To: <1222789087.2.0.210162450661.issue4002@psf.upfronthosting.co.za>
Message-ID: <1222789087.2.0.210162450661.issue4002@psf.upfronthosting.co.za>


New submission from John <fretai12345 at gmail.com>:

Hello,

I've found a little bug in the documentation again and I wanna report 
it. Please navigate to where the built-in property() function is 
documented and look at the beginning of the 3rd code snippet:

class C(object):
    def __init__(self): self._x = None


Please fix this to the following...

class C(object):
    def __init__(self):
        self._x = None

----------
assignee: georg.brandl
components: Documentation
messages: 74081
nosy: fretai, georg.brandl
severity: normal
status: open
title: A Bug in the Documentation
versions: Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4002>
_______________________________________

From report at bugs.python.org  Tue Sep 30 18:01:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Sep 2008 16:01:01 +0000
Subject: [issue4003] Reference leak in test_cprofile
In-Reply-To: <1222790460.96.0.104534015771.issue4003@psf.upfronthosting.co.za>
Message-ID: <1222790460.96.0.104534015771.issue4003@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

r66677 introduces a reference leak in test_cprofile, as shown by
http://mail.python.org/pipermail/python-checkins/2008-September/074355.html

IMO, the code at the end of the function should not have been modified
this way. It is enough to do:

	if (PyErr_Occurred()) {
		PyErr_WriteUnraisable(pObj->externalTimer);
		return 0;
	}

it's the same "PyErr_WriteUnraisable" statement as 18 lines above, which
is valid because pObj->externalTimer is still a living python object
even if pObj is being cleared.

----------
assignee: brett.cannon
keywords: needs review, patch
messages: 74082
nosy: amaury.forgeotdarc, benjamin.peterson, brett.cannon
priority: high
severity: normal
status: open
title: Reference leak in test_cprofile
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4003>
_______________________________________

From report at bugs.python.org  Tue Sep 30 19:04:28 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 30 Sep 2008 17:04:28 +0000
Subject: [issue3187] os.listdir can return byte strings
In-Reply-To: <1222788076.91.0.0302826382378.issue3187@psf.upfronthosting.co.za>
Message-ID: <ca471dc20809301004q7203c5d2hc228aca2868a3ce2@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Tue, Sep 30, 2008 at 8:21 AM, Martin v. L?wis <report at bugs.python.org> wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> Here is a patch that solves the issue in a different way: it introduces
> sys.setfilesystemencoding. If applications invoke
> sys.setfilesystemencoding("iso-8859-1"), all file names can be
> successfully converted into a character string.

I'm not opposed to this going in as well, but I don't think it's the
right approach, as it can cause severe cases of mojibake (which you
have strongly opposed in the past). It's quite orthogonal to Victor's
patch IMO.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3187>
_______________________________________

From report at bugs.python.org  Tue Sep 30 19:25:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Sep 2008 17:25:37 +0000
Subject: [issue4002] A Bug in the Documentation
In-Reply-To: <1222789087.2.0.210162450661.issue4002@psf.upfronthosting.co.za>
Message-ID: <1222795537.52.0.101748750215.issue4002@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't see the bug in the code, nor what is solved by the code you propose.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4002>
_______________________________________

From report at bugs.python.org  Tue Sep 30 19:44:01 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 30 Sep 2008 17:44:01 +0000
Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII
	characters
In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>
Message-ID: <1222796641.05.0.891961925188.issue3991@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

It's not immediately clear to me how an auto-quote function can be
written; as you say (and as the URI spec points out), you have to take
a URL apart before quoting it, and you can't parse an invalid URL,
which is what the input is.

Best to think of this as a difference from 2.x.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3991>
_______________________________________

From report at bugs.python.org  Tue Sep 30 19:49:24 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Sep 2008 17:49:24 +0000
Subject: [issue4003] Reference leak in test_cprofile
In-Reply-To: <1222790460.96.0.104534015771.issue4003@psf.upfronthosting.co.za>
Message-ID: <1222796964.57.0.533292444692.issue4003@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Amaury's fix works for me; since this is an edge case situation anyway,
I am not terribly worried about some fancy error message.

Fixed in r66700 for 2.6, r66701 for 2.5.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4003>
_______________________________________

From report at bugs.python.org  Tue Sep 30 19:49:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Sep 2008 17:49:39 +0000
Subject: [issue3895] _lsprof issue
In-Reply-To: <1221705166.83.0.0369639810422.issue3895@psf.upfronthosting.co.za>
Message-ID: <1222796979.75.0.98154992196.issue3895@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

See the fix in r66700 for the change to _lsprof.c to use.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3895>
_______________________________________

From report at bugs.python.org  Tue Sep 30 19:53:55 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 30 Sep 2008 17:53:55 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1222797235.6.0.878910141926.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file11664/python-trunk-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Tue Sep 30 19:54:09 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 30 Sep 2008 17:54:09 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1222797249.82.0.868520742909.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file11337/python-trunk-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:03:40 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 30 Sep 2008 18:03:40 +0000
Subject: [issue3871] cross building python for mingw32 with distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1222797820.83.0.0447594363054.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
keywords: +patch
Added file: http://bugs.python.org/file11665/python-trunk-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:03:51 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 30 Sep 2008 18:03:51 +0000
Subject: [issue3871] cross building python for mingw32 with distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1222797831.15.0.635432654609.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file11491/python-trunk.patch-MINGW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:11:24 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Tue, 30 Sep 2008 18:11:24 +0000
Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII
	characters
In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>
Message-ID: <1222798284.52.0.823109205463.issue3991@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

The purpose of such a function would be to take something that is not a
valid uri but 1) is a common way of expressing the way to get to the
resource and 2) follows certain rules and turns that into something that
is a valid uri.  non-ASCii strings in the path are a good example of
this since there is a well defined method to encode the strings into the
URL if you are given a character encoding to apply to it.

My first, naive thought is that if the input can be parsed by
urlparse(), then there is a very good chance that we have the ability to
escape the string properly.  Looking at the invalid uri that I gave, for
instance, if you additionally specified an encoding for the path element
there's no reason a function couldn't do the escaping.

What are example inputs that you are concerned about?  I'll see if I can
come up with code that works with them.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3991>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:13:01 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 18:13:01 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1222798381.56.0.58175486298.issue3999@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, my patch was broken. I forgot to install the fault handler! Here 
is a new version of the patch which also catch SIGFPE: raise an 
ArithmeticError.

Added file: http://bugs.python.org/file11666/segfault-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:13:06 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 18:13:06 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1222798386.1.0.789475437738.issue3999@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file11659/segfault.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:17:47 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 30 Sep 2008 18:17:47 +0000
Subject: [issue3871] cross building python for mingw32 with distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1222798667.4.0.117890263616.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

note: updated patch contain unsynchronized with trunk code in
./Objects/fileobject.c (after /* EINVAL is returned when an invalid
filename or ... )

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:20:28 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 18:20:28 +0000
Subject: [issue3951] Disable Py_USING_MEMORY_DEBUGGER!
In-Reply-To: <1222216158.64.0.600054741786.issue3951@psf.upfronthosting.co.za>
Message-ID: <1222798828.0.0.760663500383.issue3951@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Close the issue since it's commited in 2.6 and 3.0. My patch 
configure-memory-debugger.patch is useless, a developer can fix 
obmalloc.c.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3951>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:25:06 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 18:25:06 +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: <1222799106.37.0.72807756807.issue3959@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm the maintainer of IPy library. Another library for IPv4/IPv6 
manipulation. The code is old (was written for Python 2.2?), but 
released under BSD license. Main issue of this library: it's unable to 
manipulation "invalid ranges": 10.20.4.0/30 is valid but 
10.20.4.1-10.20.4.5 is invalid since it's not possible to create a 
bitmask matching the range. I don't care if you choose Google library, 
maybe better. But you might check IPy to reuse some idea ;-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:25:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 18:25:33 +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: <1222799133.46.0.66608470602.issue3959@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, the website: http://software.inl.fr/trac/wiki/IPy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:27:53 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 18:27:53 +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: <1222799273.14.0.423763581844.issue3959@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another Python library: http://erlug.linux.it/~da/soft/iplib/

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________

From report at bugs.python.org  Tue Sep 30 20:35:57 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 30 Sep 2008 18:35:57 +0000
Subject: =?utf-8?q?[issue3995]_iso-xxx/cp1252_inconsistencies_in=09Python_2.*_not_in_3.*?=
In-Reply-To: <1222682223.58.0.12502846451.issue3995@psf.upfronthosting.co.za>
Message-ID: <1222799757.13.0.0688174981131.issue3995@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I don't know iso codeset that define characters in code range 0x80 0x9f.
This range is reserved for control symbols.

The code of euro is 0xa4 in iso-8859-15. Also changes include symbols
like 1/2, 3/4 and I forgot other differences.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3995>
_______________________________________

From report at bugs.python.org  Tue Sep 30 21:48:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 30 Sep 2008 19:48:40 +0000
Subject: [issue3862] test_array fails on FreeBSD7 amd64
In-Reply-To: <1222782995.71.0.0706487889829.issue3862@psf.upfronthosting.co.za>
Message-ID: <48E28295.20209@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The 2**16 in the error message is wrong. 

As he says.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3862>
_______________________________________

From report at bugs.python.org  Tue Sep 30 22:16:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 30 Sep 2008 20:16:31 +0000
Subject: [issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*
In-Reply-To: <1222799757.13.0.0688174981131.issue3995@psf.upfronthosting.co.za>
Message-ID: <48E2891A.9050807@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't know iso codeset that define characters in code range 0x80 0x9f.

That's not true. In ISO-8859-1 (atleast, in the IANA charset), these
characters are indeed assigned - for control functions. So the
ISO-8859-1 byte \x80 corresponds to the Unicode character U+0080,
likewise for \x9c and U+009c. ISO-8859-1 and ISO-8859-15 do have
differences, but *not* for the range 0x80..0x9f - they are identical
in that range (namely, referring to control characters).

----------
title: iso-xxx/cp1252 inconsistencies in	Python 2.* not in 3.* -> iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3995>
_______________________________________

From report at bugs.python.org  Tue Sep 30 22:29:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Sep 2008 20:29:33 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1222806573.38.0.292689976749.issue3623@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________

From report at bugs.python.org  Tue Sep 30 22:43:26 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Sep 2008 20:43:26 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1222807406.48.0.035079381363.issue3863@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r66703 in trunk (2.6) applies the test_threading_fbsd6.py.patch modified
to also print a note to stderr when skipping the test and adds a mention
of buggy OSes in the os.fork documentation.

still needs merging over to 3.0 and possibly 2.5.

----------
assignee:  -> gregory.p.smith
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Tue Sep 30 22:45:05 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 30 Sep 2008 20:45:05 +0000
Subject: [issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
In-Reply-To: <1221391510.13.0.209829217282.issue3863@psf.upfronthosting.co.za>
Message-ID: <1222807505.23.0.978714293813.issue3863@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

marking release blocker for 3.0, the patch just needs to be merged after
it runs through any existing trunk freebsd buildbot(s).

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3863>
_______________________________________

From report at bugs.python.org  Tue Sep 30 23:18:16 2008
From: report at bugs.python.org (Bob Ippolito)
Date: Tue, 30 Sep 2008 21:18:16 +0000
Subject: [issue3623] _json: fix raise_errmsg(),
	py_encode_basestring_ascii() and linecol()
In-Reply-To: <1219273124.72.0.104841129313.issue3623@psf.upfronthosting.co.za>
Message-ID: <1222809496.31.0.321846965969.issue3623@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I applied the changes proposed in _json26.patch to simplejson and they 
worked perfectly fine. Again I'm not the best judge of python 3.0 code 
because I have not made myself familiar with the API changes so someone 
else should review it (but it's probably fine).

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3623>
_______________________________________