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: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 13:42:49 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 01 Sep 2008 11:42:49 +0000
Subject: [New-bugs-announce] [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 16:13:22 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Mon, 01 Sep 2008 14:13:22 +0000
Subject: [New-bugs-announce] [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:58:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Sep 2008 14:58:04 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 18:03:43 2008
From: report at bugs.python.org (Pyry Pakkanen)
Date: Mon, 01 Sep 2008 16:03:43 +0000
Subject: [New-bugs-announce] [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 23:49:19 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 01 Sep 2008 21:49:19 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:19:41 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Tue, 02 Sep 2008 02:19:41 +0000
Subject: [New-bugs-announce] [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 14:14:08 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Sep 2008 12:14:08 +0000
Subject: [New-bugs-announce] [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 15:34:09 2008
From: report at bugs.python.org (Ralph Corderoy)
Date: Tue, 02 Sep 2008 13:34:09 +0000
Subject: [New-bugs-announce] [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 17:04:51 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Sep 2008 15:04:51 +0000
Subject: [New-bugs-announce] [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 21:22:24 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Tue, 02 Sep 2008 19:22:24 +0000
Subject: [New-bugs-announce] [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 22:59:48 2008
From: report at bugs.python.org (Chris Leow)
Date: Tue, 02 Sep 2008 20:59:48 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 11:15:49 2008
From: report at bugs.python.org (Swaroop)
Date: Wed, 03 Sep 2008 09:15:49 +0000
Subject: [New-bugs-announce] [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 15:26:31 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 03 Sep 2008 13:26:31 +0000
Subject: [New-bugs-announce] [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 22:55:16 2008
From: report at bugs.python.org (Christopher Li)
Date: Wed, 03 Sep 2008 20:55:16 +0000
Subject: [New-bugs-announce] [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:58:48 2008
From: report at bugs.python.org (Thorben Krueger)
Date: Wed, 03 Sep 2008 21:58:48 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 01:06:32 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Sep 2008 23:06:32 +0000
Subject: [New-bugs-announce] [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 02:23:58 2008
From: report at bugs.python.org (Damien Miller)
Date: Thu, 04 Sep 2008 00:23:58 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 05:47:15 2008
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 04 Sep 2008 03:47:15 +0000
Subject: [New-bugs-announce] [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 07:24:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 05:24:15 +0000
Subject: [New-bugs-announce] [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 15:19:31 2008
From: report at bugs.python.org (skomoroh)
Date: Thu, 04 Sep 2008 13:19:31 +0000
Subject: [New-bugs-announce] [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:46:58 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Sep 2008 13:46:58 +0000
Subject: [New-bugs-announce] [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 22:11:19 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 04 Sep 2008 20:11:19 +0000
Subject: [New-bugs-announce] [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:49:17 2008
From: report at bugs.python.org (Barry Alan Scott)
Date: Thu, 04 Sep 2008 20:49:17 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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:59:47 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Sep 2008 21:59:47 +0000
Subject: [New-bugs-announce] [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:10:09 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 04 Sep 2008 22:10:09 +0000
Subject: [New-bugs-announce] [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:41:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Sep 2008 22:41:35 +0000
Subject: [New-bugs-announce] [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 01:57:32 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 04 Sep 2008 23:57:32 +0000
Subject: [New-bugs-announce] [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 09:41:51 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 07:41:51 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:55:21 2008
From: report at bugs.python.org (Michael Schmarck)
Date: Fri, 05 Sep 2008 09:55:21 +0000
Subject: [New-bugs-announce] [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 20:52:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 05 Sep 2008 18:52:00 +0000
Subject: [New-bugs-announce] [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 23:07:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2008 21:07:04 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 02:16:31 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Sep 2008 00:16:31 +0000
Subject: [New-bugs-announce] [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:32:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 00:32:25 +0000
Subject: [New-bugs-announce] [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 06:53:06 2008
From: report at bugs.python.org (Steve Smith)
Date: Sat, 06 Sep 2008 04:53:06 +0000
Subject: [New-bugs-announce] [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 15:36:33 2008
From: report at bugs.python.org (Matt Giuca)
Date: Sat, 06 Sep 2008 13:36:33 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 21:38:15 2008
From: report at bugs.python.org (Bjarke Walling)
Date: Sat, 06 Sep 2008 19:38:15 +0000
Subject: [New-bugs-announce] [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:31:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 20:31:20 +0000
Subject: [New-bugs-announce] [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:46:13 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Sep 2008 20:46:13 +0000
Subject: [New-bugs-announce] [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 23:51:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 06 Sep 2008 21:51:02 +0000
Subject: [New-bugs-announce] [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:59:32 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 06 Sep 2008 21:59:32 +0000
Subject: [New-bugs-announce] [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  Sun Sep  7 09:46:32 2008
From: report at bugs.python.org (skomoroh)
Date: Sun, 07 Sep 2008 07:46:32 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 06:59:58 2008
From: report at bugs.python.org (Marcus CM)
Date: Mon, 08 Sep 2008 04:59:58 +0000
Subject: [New-bugs-announce] [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 08:49:30 2008
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 08 Sep 2008 06:49:30 +0000
Subject: [New-bugs-announce] [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 21:08:04 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 19:08:04 +0000
Subject: [New-bugs-announce] [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:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 08 Sep 2008 19:36:47 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 01:55:17 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 08 Sep 2008 23:55:17 +0000
Subject: [New-bugs-announce] [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 03:17:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Sep 2008 01:17:55 +0000
Subject: [New-bugs-announce] [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:56:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Sep 2008 01:56:07 +0000
Subject: [New-bugs-announce] [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 07:21:17 2008
From: report at bugs.python.org (Per Cederqvist)
Date: Tue, 09 Sep 2008 05:21:17 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 08:56:39 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 06:56:39 +0000
Subject: [New-bugs-announce] [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 10:39:05 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 08:39:05 +0000
Subject: [New-bugs-announce] [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 12:25:19 2008
From: report at bugs.python.org (Douche)
Date: Tue, 09 Sep 2008 10:25:19 +0000
Subject: [New-bugs-announce] [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 13:28:37 2008
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 09 Sep 2008 11:28:37 +0000
Subject: [New-bugs-announce] [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 14:13:14 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 09 Sep 2008 12:13:14 +0000
Subject: [New-bugs-announce] [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 15:57:25 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 09 Sep 2008 13:57:25 +0000
Subject: [New-bugs-announce] [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:58:15 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 09 Sep 2008 13:58:15 +0000
Subject: [New-bugs-announce] [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 17:12:44 2008
From: report at bugs.python.org (Kyle McFarland)
Date: Tue, 09 Sep 2008 15:12:44 +0000
Subject: [New-bugs-announce] [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 18:00:54 2008
From: report at bugs.python.org (Tim Pietzcker)
Date: Tue, 09 Sep 2008 16:00:54 +0000
Subject: [New-bugs-announce] [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:07:13 2008
From: report at bugs.python.org (Juan Javier)
Date: Tue, 09 Sep 2008 16:07:13 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 20:25:19 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Tue, 09 Sep 2008 18:25:19 +0000
Subject: [New-bugs-announce] [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 22:42:09 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 09 Sep 2008 20:42:09 +0000
Subject: [New-bugs-announce] [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 23:07:53 2008
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 09 Sep 2008 21:07:53 +0000
Subject: [New-bugs-announce] [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:21:12 2008
From: report at bugs.python.org (romkyns)
Date: Tue, 09 Sep 2008 21:21:12 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 16:08:31 2008
From: report at bugs.python.org (Andreas Kloeckner)
Date: Wed, 10 Sep 2008 14:08:31 +0000
Subject: [New-bugs-announce] [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 22:33:00 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 10 Sep 2008 20:33:00 +0000
Subject: [New-bugs-announce] [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  Thu Sep 11 00:32:48 2008
From: report at bugs.python.org (SunriseProgrammer)
Date: Wed, 10 Sep 2008 22:32:48 +0000
Subject: [New-bugs-announce] [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 03:13:59 2008
From: report at bugs.python.org (Steve Smith)
Date: Thu, 11 Sep 2008 01:13:59 +0000
Subject: [New-bugs-announce] [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:30:14 2008
From: report at bugs.python.org (vajda)
Date: Thu, 11 Sep 2008 02:30:14 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 14:22:25 2008
From: report at bugs.python.org (Christopher Arndt)
Date: Thu, 11 Sep 2008 12:22:25 +0000
Subject: [New-bugs-announce] [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 15:21:12 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 11 Sep 2008 13:21:12 +0000
Subject: [New-bugs-announce] [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 18:12:07 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 11 Sep 2008 16:12:07 +0000
Subject: [New-bugs-announce] [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:28:55 2008
From: report at bugs.python.org (Janet Swisher)
Date: Thu, 11 Sep 2008 16:28:55 +0000
Subject: [New-bugs-announce] [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 19:59:52 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 11 Sep 2008 17:59:52 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:27:36 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 11 Sep 2008 18:27:36 +0000
Subject: [New-bugs-announce] [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:41:34 2008
From: report at bugs.python.org (Stephen McInerney)
Date: Thu, 11 Sep 2008 18:41:34 +0000
Subject: [New-bugs-announce] [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 21:04:14 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Thu, 11 Sep 2008 19:04:14 +0000
Subject: [New-bugs-announce] [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 23:25:10 2008
From: report at bugs.python.org (maix)
Date: Thu, 11 Sep 2008 21:25:10 +0000
Subject: [New-bugs-announce] [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  Fri Sep 12 03:32:10 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Fri, 12 Sep 2008 01:32:10 +0000
Subject: [New-bugs-announce] [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 14:11:56 2008
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 12 Sep 2008 12:11:56 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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: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: [New-bugs-announce] [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/new-bugs-announce/attachments/20080912/7b173458/attachment.eml>

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: [New-bugs-announce] [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 21:05:43 2008
From: report at bugs.python.org (raz)
Date: Fri, 12 Sep 2008 19:05:43 +0000
Subject: [New-bugs-announce] [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 22:06:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Sep 2008 20:06:55 +0000
Subject: [New-bugs-announce] [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:15:21 2008
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 12 Sep 2008 20:15:21 +0000
Subject: [New-bugs-announce] [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 23:52:51 2008
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 12 Sep 2008 21:52:51 +0000
Subject: [New-bugs-announce] [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: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: [New-bugs-announce] [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: [New-bugs-announce] [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 05:57:31 2008
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 13 Sep 2008 03:57:31 +0000
Subject: [New-bugs-announce] [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:15:19 2008
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 13 Sep 2008 04:15:19 +0000
Subject: [New-bugs-announce] [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 10:16:51 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 13 Sep 2008 08:16:51 +0000
Subject: [New-bugs-announce] [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 13:17:16 2008
From: report at bugs.python.org (John J Lee)
Date: Sat, 13 Sep 2008 11:17:16 +0000
Subject: [New-bugs-announce] [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 15:35:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Sep 2008 13:35:51 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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  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: [New-bugs-announce] [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: [New-bugs-announce] [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 13:25:10 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 11:25:10 +0000
Subject: [New-bugs-announce] [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:41:54 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 11:41:54 +0000
Subject: [New-bugs-announce] [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:47:40 2008
From: report at bugs.python.org (Fredrik Lundh)
Date: Sun, 14 Sep 2008 11:47:40 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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:29:45 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Sun, 14 Sep 2008 12:29:45 +0000
Subject: [New-bugs-announce] [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 18:25:16 2008
From: report at bugs.python.org (Daniel)
Date: Sun, 14 Sep 2008 16:25:16 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 01:08:19 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 14 Sep 2008 23:08:19 +0000
Subject: [New-bugs-announce] [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 09:30:37 2008
From: report at bugs.python.org (Dominique Wahli)
Date: Mon, 15 Sep 2008 07:30:37 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 23:53:29 2008
From: report at bugs.python.org (jeff)
Date: Mon, 15 Sep 2008 21:53:29 +0000
Subject: [New-bugs-announce] [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:52:27 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 15 Sep 2008 22:52:27 +0000
Subject: [New-bugs-announce] [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 07:10:52 2008
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 16 Sep 2008 05:10:52 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 14:09:17 2008
From: report at bugs.python.org (anupam)
Date: Tue, 16 Sep 2008 12:09:17 +0000
Subject: [New-bugs-announce] [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:37:17 2008
From: report at bugs.python.org (vila)
Date: Tue, 16 Sep 2008 12:37:17 +0000
Subject: [New-bugs-announce] [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 15:45:16 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Sep 2008 13:45:16 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 22:56:55 2008
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 16 Sep 2008 20:56:55 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 23:06:11 2008
From: report at bugs.python.org (Kirill Simonov)
Date: Tue, 16 Sep 2008 21:06:11 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:02:55 2008
From: report at bugs.python.org (John Ehresman)
Date: Wed, 17 Sep 2008 02:02:55 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 14:34:18 2008
From: report at bugs.python.org (Greg Darke)
Date: Wed, 17 Sep 2008 12:34:18 +0000
Subject: [New-bugs-announce] [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 22:35:52 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 17 Sep 2008 20:35:52 +0000
Subject: [New-bugs-announce] [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 23:17:09 2008
From: report at bugs.python.org (Roy Smith)
Date: Wed, 17 Sep 2008 21:17:09 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:02:45 2008
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Thu, 18 Sep 2008 02:02:45 +0000
Subject: [New-bugs-announce] [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:31:17 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Sep 2008 02:31:17 +0000
Subject: [New-bugs-announce] [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:32:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Sep 2008 02:32:46 +0000
Subject: [New-bugs-announce] [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 09:55:52 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 18 Sep 2008 07:55:52 +0000
Subject: [New-bugs-announce] [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:34 2008
From: report at bugs.python.org (Dieter Kadelka)
Date: Thu, 18 Sep 2008 08:17:34 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 15:35:50 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 18 Sep 2008 13:35:50 +0000
Subject: [New-bugs-announce] [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 16:22:19 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Sep 2008 14:22:19 +0000
Subject: [New-bugs-announce] [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 18:40:41 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 18 Sep 2008 16:40:41 +0000
Subject: [New-bugs-announce] [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 20:11:46 2008
From: report at bugs.python.org (Eyal Lotem)
Date: Thu, 18 Sep 2008 18:11:46 +0000
Subject: [New-bugs-announce] [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 22:58:35 2008
From: report at bugs.python.org (Georg Grafendorfer)
Date: Thu, 18 Sep 2008 20:58:35 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 01:07:02 2008
From: report at bugs.python.org (Todd Whiteman)
Date: Thu, 18 Sep 2008 23:07:02 +0000
Subject: [New-bugs-announce] [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 04:04:47 2008
From: report at bugs.python.org (Roger Upole)
Date: Fri, 19 Sep 2008 02:04:47 +0000
Subject: [New-bugs-announce] [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:58:24 2008
From: report at bugs.python.org (endolith)
Date: Fri, 19 Sep 2008 02:58:24 +0000
Subject: [New-bugs-announce] [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 15:47:31 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 19 Sep 2008 13:47:31 +0000
Subject: [New-bugs-announce] [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 18:46:47 2008
From: report at bugs.python.org (Winfried Plappert)
Date: Fri, 19 Sep 2008 16:46:47 +0000
Subject: [New-bugs-announce] [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 19:49:35 2008
From: report at bugs.python.org (jan matejek)
Date: Fri, 19 Sep 2008 17:49:35 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 20:59:37 2008
From: report at bugs.python.org (Jason Etheridge)
Date: Sat, 20 Sep 2008 18:59:37 +0000
Subject: [New-bugs-announce] [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 22:57:34 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 20 Sep 2008 20:57:34 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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:36:55 2008
From: report at bugs.python.org (Frank Martinez)
Date: Sun, 21 Sep 2008 03:36:55 +0000
Subject: [New-bugs-announce] [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 08:58:38 2008
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 21 Sep 2008 06:58:38 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 10:11:48 2008
From: report at bugs.python.org (Takafumi SHIDO)
Date: Sun, 21 Sep 2008 08:11:48 +0000
Subject: [New-bugs-announce] [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 12:09:48 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sun, 21 Sep 2008 10:09:48 +0000
Subject: [New-bugs-announce] [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 18:16:25 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sun, 21 Sep 2008 16:16:25 +0000
Subject: [New-bugs-announce] [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 20:30:24 2008
From: report at bugs.python.org (Denis)
Date: Sun, 21 Sep 2008 18:30:24 +0000
Subject: [New-bugs-announce] [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 22:13:08 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Sep 2008 20:13:08 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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: [New-bugs-announce] [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 11:38:54 2008
From: report at bugs.python.org (Erik Sandberg)
Date: Mon, 22 Sep 2008 09:38:54 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 14:06:30 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Mon, 22 Sep 2008 12:06:30 +0000
Subject: [New-bugs-announce] [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:33:10 2008
From: report at bugs.python.org (yanne)
Date: Mon, 22 Sep 2008 12:33:10 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 20:18:15 2008
From: report at bugs.python.org (robwolfe)
Date: Mon, 22 Sep 2008 18:18:15 +0000
Subject: [New-bugs-announce] [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:54:44 2008
From: report at bugs.python.org (jason kirtland)
Date: Mon, 22 Sep 2008 18:54:44 +0000
Subject: [New-bugs-announce] [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 23:52:21 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Sep 2008 21:52:21 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:45:02 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Sep 2008 22:45:02 +0000
Subject: [New-bugs-announce] [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 01:42:23 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Sep 2008 23:42:23 +0000
Subject: [New-bugs-announce] [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 02:16:17 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 00:16:17 +0000
Subject: [New-bugs-announce] [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:32:05 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 23 Sep 2008 00:32:05 +0000
Subject: [New-bugs-announce] [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 03:53:26 2008
From: report at bugs.python.org (Martin Meredith)
Date: Tue, 23 Sep 2008 01:53:26 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 12:25:59 2008
From: report at bugs.python.org (Pernici Mario)
Date: Tue, 23 Sep 2008 10:25:59 +0000
Subject: [New-bugs-announce] [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 15:42:37 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 13:42:37 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 18:55:47 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 23 Sep 2008 16:55:47 +0000
Subject: [New-bugs-announce] [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 22:59:29 2008
From: report at bugs.python.org (Shish)
Date: Tue, 23 Sep 2008 20:59:29 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 02:29:18 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 00:29:18 +0000
Subject: [New-bugs-announce] [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 03:22:08 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 01:22:08 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 12:02:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2008 10:02:33 +0000
Subject: [New-bugs-announce] [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 14:38:22 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 24 Sep 2008 12:38:22 +0000
Subject: [New-bugs-announce] [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 15:42:58 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 24 Sep 2008 13:42:58 +0000
Subject: [New-bugs-announce] [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 17:01:03 2008
From: report at bugs.python.org (David Naylor)
Date: Wed, 24 Sep 2008 15:01:03 +0000
Subject: [New-bugs-announce] [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:17:23 2008
From: report at bugs.python.org (dominik.holler)
Date: Wed, 24 Sep 2008 15:17:23 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 14:41:48 2008
From: report at bugs.python.org (Ronny Haryanto)
Date: Thu, 25 Sep 2008 12:41:48 +0000
Subject: [New-bugs-announce] [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 15:06:51 2008
From: report at bugs.python.org (Richard)
Date: Thu, 25 Sep 2008 13:06:51 +0000
Subject: [New-bugs-announce] [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:35:49 2008
From: report at bugs.python.org (Chris)
Date: Thu, 25 Sep 2008 13:35:49 +0000
Subject: [New-bugs-announce] [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 17:10:21 2008
From: report at bugs.python.org (Erik Sandberg)
Date: Thu, 25 Sep 2008 15:10:21 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 20:35:50 2008
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 25 Sep 2008 18:35:50 +0000
Subject: [New-bugs-announce] [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 23:39:33 2008
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Sep 2008 21:39:33 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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: [New-bugs-announce] [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 02:52:32 2008
From: report at bugs.python.org (Ron Longo)
Date: Fri, 26 Sep 2008 00:52:32 +0000
Subject: [New-bugs-announce] [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 11:23:33 2008
From: report at bugs.python.org (netcaf)
Date: Fri, 26 Sep 2008 09:23:33 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 14:01:54 2008
From: report at bugs.python.org (Jens Kadenbach)
Date: Fri, 26 Sep 2008 12:01:54 +0000
Subject: [New-bugs-announce] [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 17:12:29 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 15:12:29 +0000
Subject: [New-bugs-announce] [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 18:15:00 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Fri, 26 Sep 2008 16:15:00 +0000
Subject: [New-bugs-announce] [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 19:36:02 2008
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Sep 2008 17:36:02 +0000
Subject: [New-bugs-announce] [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 21:23:39 2008
From: report at bugs.python.org (James Athey)
Date: Fri, 26 Sep 2008 19:23:39 +0000
Subject: [New-bugs-announce] [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: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: [New-bugs-announce] [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 23:08:17 2008
From: report at bugs.python.org (Alan Gardner)
Date: Fri, 26 Sep 2008 21:08:17 +0000
Subject: [New-bugs-announce] [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  Sat Sep 27 15:54:28 2008
From: report at bugs.python.org (bahiminin)
Date: Sat, 27 Sep 2008 13:54:28 +0000
Subject: [New-bugs-announce] [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 17:50:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Sep 2008 15:50:41 +0000
Subject: [New-bugs-announce] [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  Sun Sep 28 10:50:49 2008
From: report at bugs.python.org (Bk)
Date: Sun, 28 Sep 2008 08:50:49 +0000
Subject: [New-bugs-announce] [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:58:23 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Sep 2008 09:58:23 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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: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: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 17:20:50 2008
From: report at bugs.python.org (arnaud.faucher)
Date: Sun, 28 Sep 2008 15:20:50 +0000
Subject: [New-bugs-announce] [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 19:23:56 2008
From: report at bugs.python.org (Thiemo Seufer)
Date: Sun, 28 Sep 2008 17:23:56 +0000
Subject: [New-bugs-announce] [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 20:47:16 2008
From: report at bugs.python.org (Toshio Kuratomi)
Date: Sun, 28 Sep 2008 18:47:16 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 07:21:25 2008
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 29 Sep 2008 05:21:25 +0000
Subject: [New-bugs-announce] [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 09:13:12 2008
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 29 Sep 2008 07:13:12 +0000
Subject: [New-bugs-announce] [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 11:57:03 2008
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Mon, 29 Sep 2008 09:57:03 +0000
Subject: [New-bugs-announce] [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 13:34:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Sep 2008 11:34:11 +0000
Subject: [New-bugs-announce] [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 17:10:58 2008
From: report at bugs.python.org (vali)
Date: Mon, 29 Sep 2008 15:10:58 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 03:10:12 2008
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Sep 2008 01:10:12 +0000
Subject: [New-bugs-announce] [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 06:20:34 2008
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 30 Sep 2008 04:20:34 +0000
Subject: [New-bugs-announce] [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 15:20:32 2008
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 30 Sep 2008 13:20:32 +0000
Subject: [New-bugs-announce] [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 17:38:07 2008
From: report at bugs.python.org (John)
Date: Tue, 30 Sep 2008 15:38:07 +0000
Subject: [New-bugs-announce] [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:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Sep 2008 16:01:00 +0000
Subject: [New-bugs-announce] [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>
_______________________________________