From report at bugs.python.org  Sun Jun  1 16:37:28 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 01 Jun 2008 14:37:28 +0000
Subject: [New-bugs-announce] [issue3020] doctest should have lib2to3
	integration
In-Reply-To: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>
Message-ID: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Running a doctest with Py2 syntax in Py3 currently involves either
running the 2to3 tool by hand or writing code to convert the doctest
using lib2to3, and then running the modified version. This basically
pushes the burden of automating this step in any test runner script in
the world onto the authors or users of these scripts.

Writing portable code is hard enough, but writing portable doctests that
remain user readable should not remain as hard as it currently is. The
doctest module in Py3 should have a simple option to run a Py2 doctest
(in a file or doc string) without requiring users to write the glue code
for it.

On a related note, if a 3to2 tool becomes available, this should be
directly supported by doctest in Py2.6.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
messages: 67594
nosy: collinwinter, scoder
severity: normal
status: open
title: doctest should have lib2to3 integration
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun  1 22:03:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jun 2008 20:03:46 +0000
Subject: [New-bugs-announce] [issue3021] Lexical exception handlers
In-Reply-To: <1212350626.42.0.00327926746922.issue3021@psf.upfronthosting.co.za>
Message-ID: <1212350626.42.0.00327926746922.issue3021@psf.upfronthosting.co.za>


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

This patch implements the proposal outlined on the py3k mailing-list
here: http://mail.python.org/pipermail/python-3000/2008-May/013740.html

It solves both #2507 and #2833, and even improves re-raising semantics
in several cases (see the test cases which were added to test_raise.py).

Anothing thing worth noting is that f_exc_* fields are not accessible
from Python code anymore, because their semantics is an implementation
detail and shouldn't be relied upon.

----------
components: Interpreter Core
files: exc_stacking.patch
keywords: patch
messages: 67598
nosy: pitrou
severity: normal
status: open
title: Lexical exception handlers
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10495/exc_stacking.patch

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

From report at bugs.python.org  Sun Jun  1 23:29:33 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 01 Jun 2008 21:29:33 +0000
Subject: [New-bugs-announce] [issue3022] mailbox module, two small fixes
In-Reply-To: <1212355773.67.0.369854949727.issue3022@psf.upfronthosting.co.za>
Message-ID: <1212355773.67.0.369854949727.issue3022@psf.upfronthosting.co.za>


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

While fixing the tkinter demos, I found some problems when moving from
mhlib to mailbox that are corrected in the attached patch.

The first fix:

-        for name, key_list in self.get_sequences():
+        for name, key_list in self.get_sequences().iteritems():

I'm not sure someone else used the module before, or at least
get_sequences() since it returns a dict and it just fails in the current
code.

The second fix is about the .mh_sequences file format I found here, it
may have some lines with one space, or two, after its content which was
causing the get_sequences() to fail too.

----------
components: Library (Lib)
files: mailbox_fixes.diff
keywords: patch, patch
messages: 67605
nosy: gpolo
severity: normal
status: open
title: mailbox module, two small fixes
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10497/mailbox_fixes.diff

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

From report at bugs.python.org  Mon Jun  2 00:22:17 2008
From: report at bugs.python.org (David Watson)
Date: Sun, 01 Jun 2008 22:22:17 +0000
Subject: [New-bugs-announce] [issue3023] Problem with invalidly-encoded
	command-line arguments (Unix)
In-Reply-To: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za>
Message-ID: <1212358937.18.0.778474192325.issue3023@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

The error message has no newline at the end:

$ LANG=en_GB.UTF-8 python3.0 test.py $'\xff'
Could not convert argument 2 to string$

Seriously, though: is this the intended behaviour?  If the
interpreter just dies when it gets a non-UTF-8 (or whatever)
argument, it creates an opportunity for a denial-of-service if
some admin is running a Python script via find(1) or similar.
And what if you want to run a Python script on some files named
in a mixture of charsets (because, say, you just untarred an
archive created in a foreign charset)?

Could sys.argv not provide bytes objects for those arguments,
like os.listdir()?  Or (better IMHO) have a separate
sys.argv_bytes interface?

----------
components: Unicode
messages: 67608
nosy: baikie
severity: normal
status: open
title: Problem with invalidly-encoded command-line arguments (Unix)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun  2 00:31:17 2008
From: report at bugs.python.org (Razvan Cosma)
Date: Sun, 01 Jun 2008 22:31:17 +0000
Subject: [New-bugs-announce] [issue3024] Integer conversion inconsistent
In-Reply-To: <1212359477.86.0.531880648063.issue3024@psf.upfronthosting.co.za>
Message-ID: <1212359477.86.0.531880648063.issue3024@psf.upfronthosting.co.za>


New submission from Razvan Cosma <helminthe at gmail.com>:

This issue is probably older than I am, and was amazed to discover it in
python:
Python 2.5.2 (r252:60911, May  7 2008, 15:19:09)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
>>> int(float("-23.15"))
-23
>>> int(float("-23.65"))
-23
>>> int(float("24.9"))
24
>>> int(float("24.4"))
24
Is this by design? What is the python way of obtaining a correct result?

----------
components: None
messages: 67609
nosy: helminthe
severity: normal
status: open
title: Integer conversion inconsistent
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun  2 01:12:25 2008
From: report at bugs.python.org (Jim Jewett)
Date: Sun, 01 Jun 2008 23:12:25 +0000
Subject: [New-bugs-announce] [issue3025] batch/IDLE differ: print broken for
	chraracters>ascii
In-Reply-To: <1212361944.88.0.914955463157.issue3025@psf.upfronthosting.co.za>
Message-ID: <1212361944.88.0.914955463157.issue3025@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at users.sourceforge.net>:

The str->Unicode change widened IDLE/batch discrepancy.

In python 2.x, bytes are printable.

>>> for i in range(256): print i, chr(i)

works fine.  In python 3, chr has become (the old) unichr, and whether a 
unicode character is printable depends on the environment.  In particular, 
under my Windows XP, the equivalent

>>> for i in range(256): print (i, chr(i))

will still work fine under IDLE, but will now crash with an 
UnicodeEncodeError when run from the command line.

----------------

Unfortunately, I'm not sure what the right solution actually is, other than 
a mention in the Whats New document.  

I believe the 2.5 code was using a system page to print those characters, as 
they often looked like letters rather than <control>.  Copying that would 
probably be the wrong solution.

Limiting IDLE would add consistency, but might be a lot of work for the 
equivalent of a --pedantic flag.

PEP 3138 seems to be proposing a default stdout BackslashReplace, which may 
at least  help.

----------
assignee: georg.brandl
components: Documentation, Unicode
messages: 67617
nosy: georg.brandl, jimjjewett
severity: normal
status: open
title: batch/IDLE differ: print broken for chraracters>ascii
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun  2 04:24:58 2008
From: report at bugs.python.org (Matthew Mueller)
Date: Mon, 02 Jun 2008 02:24:58 +0000
Subject: [New-bugs-announce] [issue3026] mmap broken with large files on
	64bit system
In-Reply-To: <1212373498.52.0.766248013838.issue3026@psf.upfronthosting.co.za>
Message-ID: <1212373498.52.0.766248013838.issue3026@psf.upfronthosting.co.za>


New submission from Matthew Mueller <donut at users.sourceforge.net>:

mmap on large files on 64 bit platforms in python >=2.5 returns some
sort of garbage.  In 2.4 it would just throw an exception.  Now I get
something like this (script runs md5.md5 on mmap object, and then runs
os.system md5sum for comparison):

This is python2.5 from Ubuntu 8.04 AMD64
/tmp$ python2.5 testbigfile.py 
python mmap md5: 1230552d39b7c1751f86bae5205ec0c8
abe59e28c9a3f11b883f62c80a3833a5 *bigfile


This is python svn as of 20080601, compiled the on same system.
/tmp$ python2.6 testbigfile.py
testbigfile.py:5: DeprecationWarning: the md5 module is deprecated; use
hashlib instead
  import md5
python mmap md5: 1230552d39b7c1751f86bae5205ec0c8
abe59e28c9a3f11b883f62c80a3833a5 *bigfile


Also note how the python md5 call returns immediately, not something you
would expect when md5ing 4GB of data.

----------
components: Extension Modules
files: testbigfile.py
messages: 67623
nosy: donut
severity: normal
status: open
title: mmap broken with large files on 64bit system
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10500/testbigfile.py

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

From report at bugs.python.org  Mon Jun  2 11:53:22 2008
From: report at bugs.python.org (patrick)
Date: Mon, 02 Jun 2008 09:53:22 +0000
Subject: [New-bugs-announce] [issue3027] if extended c module is calling
	Windows API waitForSingleObject, it will block other thread.
In-Reply-To: <1212400401.02.0.0405050375682.issue3027@psf.upfronthosting.co.za>
Message-ID: <1212400401.02.0.0405050375682.issue3027@psf.upfronthosting.co.za>


New submission from patrick <patrick_jiang at phoenix.com>:

The c extend module is as the attached file "WindowsFuncs.cpp", it 
wraps some Windows event APIs

The python script is as the attached file "test.py", run that script, 
we could find in the new thread, the calling to Windows API 
waitForSingleObject will block the main thread printing, that's really 
strange. 

The output of running is as the attached file "test.output".

----------
components: Interpreter Core
files: attach.zip
messages: 67633
nosy: patrick
severity: normal
status: open
title: if extended c module is calling Windows API waitForSingleObject, it will block other thread.
versions: Python 2.5
Added file: http://bugs.python.org/file10502/attach.zip

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

From report at bugs.python.org  Mon Jun  2 13:33:32 2008
From: report at bugs.python.org (Noam Raphael)
Date: Mon, 02 Jun 2008 11:33:32 +0000
Subject: [New-bugs-announce] [issue3028] tokenize module: normal lines,
	not "logical"
In-Reply-To: <1212406411.84.0.811061181289.issue3028@psf.upfronthosting.co.za>
Message-ID: <1212406411.84.0.811061181289.issue3028@psf.upfronthosting.co.za>


New submission from Noam Raphael <noamraph at gmail.com>:

Hello,

The documentation of the tokenize module says: "The line passed is the
*logical* line; continuation lines are included."

Some background: The tokenize module splits a python source into tokens,
and says for each token where it begins and where it ends, in the format
of (row, offset). This note in the documentation made me think that
continuation lines are considered as one line, and made me break my head
how I should find the offset of the token in the original string. The
truth is that the row number is simply the index of the line as returned
by the readline function, and it's very simple to reconstruct the string
offset.

I suggest that this will be changed to something like "The line passed
is the index of the string returned by the readline function, plus 1.
That is, the first string returned is called line 1, the second is
called line 2, and so on."

Thanks,
Noam

----------
assignee: georg.brandl
components: Documentation
messages: 67635
nosy: georg.brandl, noam
severity: normal
status: open
title: tokenize module: normal lines, not "logical"
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun  2 16:12:59 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Mon, 02 Jun 2008 14:12:59 +0000
Subject: [New-bugs-announce] [issue3029] free list management - list, dict,
	set
In-Reply-To: <1212415979.8.0.492351620272.issue3029@psf.upfronthosting.co.za>
Message-ID: <1212415979.8.0.492351620272.issue3029@psf.upfronthosting.co.za>


New submission from Andrew I MacIntyre <aimacintyre at users.sourceforge.net>:

The attached patch adds free list clearing routines for the list, dict &
set objects.  These objects are the only ones with free lists that don't
already have some form of free list management API.  This patch
complements the patch in issue 2862.

----------
assignee: christian.heimes
components: Interpreter Core
files: list_dict_set_clearfreelist.patch
keywords: patch, patch
messages: 67636
nosy: aimacintyre, christian.heimes
priority: high
severity: normal
status: open
title: free list management - list, dict, set
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10503/list_dict_set_clearfreelist.patch

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

From report at bugs.python.org  Tue Jun  3 07:55:57 2008
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 03 Jun 2008 05:55:57 +0000
Subject: [New-bugs-announce] [issue3030] compiler warning on HP-UX
In-Reply-To: <1212472557.24.0.226147292753.issue3030@psf.upfronthosting.co.za>
Message-ID: <1212472557.24.0.226147292753.issue3030@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

On HP-UX, there is a compiler warning about _POSIX_C_SOURCE redefined:

bash-2.04$ make
        gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3
-Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE
-o Modules/python.o ./Modules/python.c
In file included from Include/Python.h:8,
                 from ./Modules/python.c:3:
./pyconfig.h:1023:1: warning: "_POSIX_C_SOURCE" redefined
<command line>:3:1: warning: this is the location of the previous definition
        gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3
-Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE
-o Parser/acceler.o Parser/acceler.c
In file included from Include/Python.h:8,
                 from Include/pgenheaders.h:10,
                 from Parser/acceler.c:13:
./pyconfig.h:1023:1: warning: "_POSIX_C_SOURCE" redefined
...

----------
components: Build
messages: 67649
nosy: theller
severity: normal
status: open
title: compiler warning on HP-UX
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  3 15:06:09 2008
From: report at bugs.python.org (fma)
Date: Tue, 03 Jun 2008 13:06:09 +0000
Subject: [New-bugs-announce] [issue3031] distutils package_dir/package_data
	failure
In-Reply-To: <1212498369.04.0.406397412231.issue3031@psf.upfronthosting.co.za>
Message-ID: <1212498369.04.0.406397412231.issue3031@psf.upfronthosting.co.za>


New submission from fma <fma at gbiloba.org>:

For python2.4:
Python 2.4.4 (#2, Apr 15 2008, 23:43:20)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2

The distutils documentation says to use an empty string in the 
setup() 'package_dir' param. for current dir. It works fine for python 
modules, but it fails when using 'package_data' param. For example:

.
|-- __init__.py
|-- module1.py
|-- module2.py
|-- setup.py
`-- view
    |-- __init__.py
    |-- module3.glade
    |-- module3.py
    |-- module4.glade
    `-- module4.py

setup.py:

from distutils.core import setup
setup(name='my_package',
      package_dir={'my_package': ''},
      packages=['my_package', 'my_package.view'],
      package_data={'my_package': ['view/*.glade']}
)

$ python setup.py build
running build
running build_py
creating build
creating build/lib
creating build/lib/my_package
copying module1.py -> build/lib/my_package
copying module2.py -> build/lib/my_package
copying __init__.py -> build/lib/my_package
creating build/lib/my_package/view
copying view/module3.py -> build/lib/my_package/view
copying view/module4.py -> build/lib/my_package/view
copying view/__init__.py -> build/lib/my_package/view
creating build/lib/my_package/iew
error: can't copy 'iew/module3.glade': doesn't exist or not a regular 
file

To correct this, '.' should be used instead of the empty string:

from distutils.core import setup
setup(name='my_package',
      package_dir={'my_package': '.'},
      packages=['my_package', 'my_package.view'],
      package_data={'my_package': ['view/*.glade']}
)

Note that the empty string works fine on python2.5:
Python 2.5.2 (r252:60911, Apr 17 2008, 13:15:05)
[GCC 4.2.3 (Debian 4.2.3-3)] on linux2

----------
components: Distutils
messages: 67659
nosy: fma
severity: normal
status: open
title: distutils package_dir/package_data failure
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Tue Jun  3 19:47:30 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 03 Jun 2008 17:47:30 +0000
Subject: [New-bugs-announce] [issue3032] tkFont added displayof where
	necessary
Message-ID: <1212515250.33.0.732386075233.issue3032@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
components: Tkinter
keywords: patch
nosy: gpolo
severity: normal
status: open
title: tkFont added displayof where necessary
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  3 19:48:14 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 03 Jun 2008 17:48:14 +0000
Subject: [New-bugs-announce] [issue3033] tkFont added displayof where
	necessary
In-Reply-To: <1212515294.71.0.756028895858.issue3033@psf.upfronthosting.co.za>
Message-ID: <1212515294.71.0.756028895858.issue3033@psf.upfronthosting.co.za>


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

Added support for -displayof where necessary in tkFont

----------
components: Tkinter
files: tkFont_displayof_added.diff
keywords: patch, patch
messages: 67662
nosy: gpolo
severity: normal
status: open
title: tkFont added displayof where necessary
versions: Python 2.6
Added file: http://bugs.python.org/file10509/tkFont_displayof_added.diff

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

From report at bugs.python.org  Tue Jun  3 19:48:19 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 03 Jun 2008 17:48:19 +0000
Subject: [New-bugs-announce] [issue3034] tkFont added displayof where
	necessary
In-Reply-To: <1212515298.97.0.682433564085.issue3034@psf.upfronthosting.co.za>
Message-ID: <1212515298.97.0.682433564085.issue3034@psf.upfronthosting.co.za>


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

Added support for -displayof where necessary in tkFont

----------
components: Tkinter
files: tkFont_displayof_added.diff
keywords: patch, patch
messages: 67663
nosy: gpolo
severity: normal
status: open
title: tkFont added displayof where necessary
versions: Python 2.6
Added file: http://bugs.python.org/file10510/tkFont_displayof_added.diff

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

From report at bugs.python.org  Tue Jun  3 20:32:49 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 03 Jun 2008 18:32:49 +0000
Subject: [New-bugs-announce] [issue3035] Removing apparently unwanted
	functions from Tkinter
In-Reply-To: <1212517969.87.0.228224366447.issue3035@psf.upfronthosting.co.za>
Message-ID: <1212517969.87.0.228224366447.issue3035@psf.upfronthosting.co.za>


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

Patch for removing some unwanted, and probably not used, functions at
tkinter/__init__.

----------
components: Tkinter
files: removed_index_funcs.diff
keywords: patch, patch
messages: 67669
nosy: gpolo
severity: normal
status: open
title: Removing apparently unwanted functions from Tkinter
versions: Python 3.0
Added file: http://bugs.python.org/file10514/removed_index_funcs.diff

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

From report at bugs.python.org  Wed Jun  4 12:31:01 2008
From: report at bugs.python.org (Nick Veitch)
Date: Wed, 04 Jun 2008 10:31:01 +0000
Subject: [New-bugs-announce] [issue3036] docs - print() example wrong in
	whatsnew
In-Reply-To: <1212575460.09.0.843945185699.issue3036@psf.upfronthosting.co.za>
Message-ID: <1212575460.09.0.843945185699.issue3036@psf.upfronthosting.co.za>


New submission from Nick Veitch <veryevilnick at googlemail.com>:

In the whatsnew/3.0.html doc, the example for print is the wrong way
around. Current version reads:
* The :func:`print` function doesn't support the "softspace" feature of
    the old ``print`` statement.  For example, in Python 2.x,
    ``print "A\n", "B"`` would write ``"A\nB\n"``; but in Python 3.0,
    ``print("A\n", "B")`` writes ``"A\n B\n"``.

should read:
* The :func:`print` function doesn't support the "softspace" feature of
    the old ``print`` statement.  For example, in Python 2.x,
    ``print "A\n", "B"`` would write ``"A\n B\n"``; but in Python 3.0,
    ``print("A\n", "B")`` writes ``"A\nB\n"``.

----------
assignee: georg.brandl
components: Documentation
messages: 67688
nosy: evilnick, georg.brandl
severity: normal
status: open
title: docs - print() example wrong in whatsnew
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun  4 21:50:19 2008
From: report at bugs.python.org (Ian Bicking)
Date: Wed, 04 Jun 2008 19:50:19 +0000
Subject: [New-bugs-announce] [issue3037] <generator> in output
In-Reply-To: <1212609019.75.0.807560443614.issue3037@psf.upfronthosting.co.za>
Message-ID: <1212609019.75.0.807560443614.issue3037@psf.upfronthosting.co.za>


New submission from Ian Bicking <ianb at colorstudy.com>:

I updated to sphinx trunk and made just a few small changes in my
template, and I'm now seeing:

    </script>
    <script type="text/javascript" src="_static/jquery.js"></script>

    <script type="text/javascript" src="_static/interface.js"></script>
    <script type="text/javascript" src="_static/doctools.js"></script>
    <link rel="contents" title="Global table of contents"
href="contents.html" />
    <link rel="index" title="Global index" href="genindex.html" />
    <link rel="search" title="Search" href="search.html" />
    <link rel="top" title="Paste v1.7 documentation" href="" />
    <link rel="next" title="News" href="news.html" />
<generator object at 0x8df250c>

<link rel="stylesheet" type="text/css"
 href="_static/paste.css.html">

  </head>

Note specifically "<generator object at 0x8df250c>", which comes right
before extrahead.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 67696
nosy: georg.brandl, ianb
severity: normal
status: open
title: <generator> in output
type: behavior

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

From report at bugs.python.org  Thu Jun  5 03:38:33 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 05 Jun 2008 01:38:33 +0000
Subject: [New-bugs-announce] [issue3038] Return results from Python
	callbacks to Tcl as Tcl objects, please backport it.
In-Reply-To: <1212629912.92.0.209823350261.issue3038@psf.upfronthosting.co.za>
Message-ID: <1212629912.92.0.209823350261.issue3038@psf.upfronthosting.co.za>


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

I'm not sure if it is okay to ask this here, but could someone backport
r59653 ("Return results from Python callbacks to Tcl as Tcl objects.")
to releas25-maint ? Maybe it is already "marked" to be backported by
someone, if it is the case this could be closed, otherwise leave this as
a remainder.

Thanks.

----------
components: Tkinter
messages: 67707
nosy: gpolo
severity: normal
status: open
title: Return results from Python callbacks to Tcl as Tcl objects, please backport it.
type: feature request

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

From report at bugs.python.org  Thu Jun  5 04:22:47 2008
From: report at bugs.python.org (Jason Kankiewicz)
Date: Thu, 05 Jun 2008 02:22:47 +0000
Subject: [New-bugs-announce] [issue3039]
	tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError
In-Reply-To: <1212632567.86.0.457282985708.issue3039@psf.upfronthosting.co.za>
Message-ID: <1212632567.86.0.457282985708.issue3039@psf.upfronthosting.co.za>


New submission from Jason Kankiewicz <jkankiewicz at acm.org>:

tarfile.TarFileCompat.writestr( self, zinfo, bytes ) raises
AttributeError("'ZipInfo' object has no attribute 'name'") because an
analog to the tarfile.TarInfo.name attribute cannot be monkeypatched
into the zinfo argument value when it's an instance of zipfile.ZipInfo.

The zipfile.ZipInfo class' attributes are slots, so no ad hoc attributes
can be monkeypatched into an instance of it.

I've replaced the monkeypatching of zinfo with the creation of a new
tarfile.TarInfo object, tinfo, which receives its relevant values instead.

This revealed another problem with the assignment of zinfo.file_size to
tinfo.size: if zinfo.file_size has not been assigned a value then an
AttributeError("file_size") will be raised because the slotted attribute
doesn't exist.
Being that the documentation for zipfile.ZipFile.writestr( self,
zinfo_or_arcname, bytes ) claims that a zipfile.ZipInfo object value for
zinfo_or_arcname must contain "at least the filename, date and time",
it's highly likely that zinfo.file_size will be unassigned in ordinary use.
I fixed this problem by ignoring the value of zinfo.file_size and using
the value of len(bytes) instead, just like the implementation of
zipfile.ZipFile.writestr.

I would have provided a patch for tarfile.TarFileCompat.writestr's unit
test suite, but it doesn't appear to exist.

----------
components: Library (Lib)
files: tarfile.TarFileCompat.patch
keywords: patch
messages: 67708
nosy: jkankiewicz
severity: normal
status: open
title: tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10520/tarfile.TarFileCompat.patch

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

From report at bugs.python.org  Thu Jun  5 05:14:39 2008
From: report at bugs.python.org (Trevor Meyerowitz)
Date: Thu, 05 Jun 2008 03:14:39 +0000
Subject: [New-bugs-announce] [issue3040] optparse documentation: variable
	arguments example doesn't work as listed
In-Reply-To: <1212635679.53.0.642286486593.issue3040@psf.upfronthosting.co.za>
Message-ID: <1212635679.53.0.642286486593.issue3040@psf.upfronthosting.co.za>


New submission from Trevor Meyerowitz <trevor.meyerowitz at sun.com>:

There are two minor bugs in the example in:
http://docs.python.org/lib/optparse-callback-example-6.html

For the optparse example documentation, the call to parser.add_option is
listed as:

parser.add_option("-c", "--callback",
                  action="callback", callback=varargs)

this has two bugs:
  1. It refers to the wrong function name
  2. It needs to have a dest variable defined, b/c the callback function
operates on that.

This can be fixed if the parser.add_option call is changed to:
parser.add_option("-c", "--callback",
      action="callback", dest="foo", callback=varargs_callback)

----------
assignee: georg.brandl
components: Demos and Tools, Documentation
messages: 67709
nosy: georg.brandl, meyerowitz
severity: normal
status: open
title: optparse documentation: variable arguments example doesn't work as listed
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun  5 12:21:35 2008
From: report at bugs.python.org (Christophe de Vienne)
Date: Thu, 05 Jun 2008 10:21:35 +0000
Subject: [New-bugs-announce] [issue3041] autodoc does not support unicode
	docstrings
In-Reply-To: <1212661294.93.0.247406907361.issue3041@psf.upfronthosting.co.za>
Message-ID: <1212661294.93.0.247406907361.issue3041@psf.upfronthosting.co.za>


New submission from Christophe de Vienne <cdevienne at gmail.com>:

If I define unicode docstrings in my python source, autodoc crash
because it tries to decode them, which force a ascii encode first.

A trivial patch fix the issue :

Index: sphinx/ext/autodoc.py
===================================================================
--- sphinx/ext/autodoc.py	(r?vision 63954)
+++ sphinx/ext/autodoc.py	(copie de travail)
@@ -218,7 +218,7 @@
     module = getattr(todoc, '__module__', None)
     if module is not None:
         charset = get_module_charset(module)
-        docstrings = [docstring.decode(charset) for docstring in
docstrings]
+        docstrings = [docstring.decode(charset) for docstring in
docstrings if not isinstance(docstring, unicode)]
 
     # add docstring content
     for docstring in docstrings:

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 67710
nosy: cdevienne, georg.brandl
severity: normal
status: open
title: autodoc does not support unicode docstrings
type: crash

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

From report at bugs.python.org  Thu Jun  5 14:56:06 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2008 12:56:06 +0000
Subject: [New-bugs-announce] [issue3042] Add PEP 8 compliant aliases to
	threading module
In-Reply-To: <1212670566.42.0.274403876451.issue3042@psf.upfronthosting.co.za>
Message-ID: <1212670566.42.0.274403876451.issue3042@psf.upfronthosting.co.za>


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

PEP 371 highlighted the non-PEP 8 compliant nature of the threading API.
Since part of that PEP involves updating the multiprocessing API to be
PEP 8 compliant before addition the standard library, the threading API
should also be updated to be PEP 8 compliant in 3.0.

That part's easy - the trickier part if to provide both the existing API
and a PEP 8 compliant API in 2.6, with the old names triggering a
warning when run with the -3 switch, but not suffering a performance hit
otherwise.

The trick with that is to define the renamed API's differently depending
on whether or not sys.py3kwarning is set, rather than checking it every
time the old APIs are invoked.

(Left unassigned for the moment, since I'm about to go completely
offline for a few days, so it will be tough for me to get to this before
the first beta)

----------
components: Library (Lib)
messages: 67711
nosy: ncoghlan
priority: high
severity: normal
status: open
title: Add PEP 8 compliant aliases to threading module
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  5 23:03:50 2008
From: report at bugs.python.org (Tyler Laing)
Date: Thu, 05 Jun 2008 21:03:50 +0000
Subject: [New-bugs-announce] [issue3043] Recursion bug in deepcopy
In-Reply-To: <1212699830.74.0.302463788027.issue3043@psf.upfronthosting.co.za>
Message-ID: <1212699830.74.0.302463788027.issue3043@psf.upfronthosting.co.za>


New submission from Tyler Laing <trinioler at gmail.com>:

With the following code:
class Vertex:
	def __init__(self, type):
		self.type = type
		self.color=-1
		self.edges=[]
		

class Edge:
	def __init__(self, V1, V2):
		self.vertexes=[V1, V2]
		V1.edges.append(self)
		V2.edges.append(self)

Where the references are cyclic(this is for a research project into
graph algorithms), and using deepcopy, even on a tiny graph of five
vertexes and 25 edges causes deepcopy to run into the recursion limit.
At the very least, it should warn it can't copy the indicated object, as
the references are cyclic. At the very most, it should be able to handle
complex cyclic references like this properly.

----------
components: Library (Lib)
messages: 67728
nosy: Zeroth
severity: normal
status: open
title: Recursion bug in deepcopy
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun  6 00:33:36 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Jun 2008 22:33:36 +0000
Subject: [New-bugs-announce] [issue3044] Simplify the Integral ABC
In-Reply-To: <1212705216.31.0.628025639885.issue3044@psf.upfronthosting.co.za>
Message-ID: <1212705216.31.0.628025639885.issue3044@psf.upfronthosting.co.za>


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

See attached patches.

The PEP is also updated for Exact/Inexact which were removed a good
while ago.

----------
assignee: gvanrossum
components: Library (Lib)
files: numbers.diff
keywords: patch
messages: 67734
nosy: gvanrossum, rhettinger
severity: normal
status: open
title: Simplify the Integral ABC
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10528/numbers.diff

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

From report at bugs.python.org  Fri Jun  6 05:11:29 2008
From: report at bugs.python.org (Peter Whaite)
Date: Fri, 06 Jun 2008 03:11:29 +0000
Subject: [New-bugs-announce] [issue3045] Windows online help broken when
	spaces in TEMP environ
In-Reply-To: <1212721889.56.0.323857297959.issue3045@psf.upfronthosting.co.za>
Message-ID: <1212721889.56.0.323857297959.issue3045@psf.upfronthosting.co.za>


New submission from Peter Whaite <whaite at gmail.com>:

If the environ vars TEMP or TMP contain spaces on w32 the on-line help
will not work.  e.g. help('or') gives the message

    The system cannot find the file specified.

This is because pydoc.tempfilepager sets filename=tempfile.mktemp()
which will have spaces in it if TEMP does.  The filename is then used to
constuct the system command:

     os.system(cmd + ' ' + filename)

which in windows ends up as  os.system('more < FILE WITH SPACES').  The
filename should be quoted, e.g.

     os.system('%s "%s"' % (cmd,filename))

I only ran across this problem because I use uwin on windows and it sets
TEMP to a w32 style long path.  The normal windows command shell uses
the dos spaceless sort form for the TMP and TEMP env vars so the problem
doesn't arise when python is invoked from there.

And isn't tempfile.mktemp() deprecated?

----------
components: Library (Lib), Windows
messages: 67746
nosy: peta
severity: normal
status: open
title: Windows online help broken when spaces in TEMP environ
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun  6 08:47:08 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 06 Jun 2008 06:47:08 +0000
Subject: [New-bugs-announce] [issue3046] Locking should be removed from the
	new buffer protocol
In-Reply-To: <1212734828.53.0.490072473192.issue3046@psf.upfronthosting.co.za>
Message-ID: <1212734828.53.0.490072473192.issue3046@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Here is a patch against the current PEP 3118 that removes the LOCK flag.
It follows this discussion on the Py3k mailing list:

http://comments.gmane.org/gmane.comp.python.python-3000.devel/13409?set_lines=100000

It has not yet been approved by the PEP owners and requires
implementation, preferably before beta1.

----------
components: Interpreter Core
files: pep-3118-no-locking.patch
keywords: patch
messages: 67747
nosy: scoder
severity: normal
status: open
title: Locking should be removed from the new buffer protocol
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10533/pep-3118-no-locking.patch

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

From report at bugs.python.org  Fri Jun  6 09:43:20 2008
From: report at bugs.python.org (Jura)
Date: Fri, 06 Jun 2008 07:43:20 +0000
Subject: [New-bugs-announce] [issue3047] string object's lstrip function
In-Reply-To: <1212738199.97.0.591245075441.issue3047@psf.upfronthosting.co.za>
Message-ID: <1212738199.97.0.591245075441.issue3047@psf.upfronthosting.co.za>


New submission from Jura <jsostok at yahoo.com>:

example from command line:

'_element_no_of_hsscch'.lstrip('_element_')
'o_of_hsscch'
'_element_o_of_hsscch'.lstrip('_element_')
'o_of_hsscch'

----------
components: Interpreter Core
messages: 67748
nosy: jsostok
severity: normal
status: open
title: string object's lstrip function
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun  6 09:47:13 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 06 Jun 2008 07:47:13 +0000
Subject: [New-bugs-announce] [issue3048] getsizeof incorrect for Unicode
	strings
In-Reply-To: <1212738433.49.0.637321178838.issue3048@psf.upfronthosting.co.za>
Message-ID: <1212738433.49.0.637321178838.issue3048@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

sys.getsizeof doesn't take the actual length of the Unicode string into
account:

py> sys.getsizeof(u"")
32
[31332 refs]
py> sys.getsizeof(u"1"*100)
32
[31332 refs]

----------
assignee: schuppenies
messages: 67750
nosy: loewis, schuppenies
severity: normal
status: open
title: getsizeof incorrect for Unicode strings

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

From report at bugs.python.org  Fri Jun  6 09:51:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 06 Jun 2008 07:51:17 +0000
Subject: [New-bugs-announce] [issue3049] Some 3k sizeof tests fail
In-Reply-To: <1212738677.44.0.0240899165497.issue3049@psf.upfronthosting.co.za>
Message-ID: <1212738677.44.0.0240899165497.issue3049@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

When merging the sizeof changes to 3k, I had to disable a few tests,
marked with XXX. Can you please take a look at why precisely they broke,
and change them appropriately?

----------
assignee: schuppenies
messages: 67752
nosy: loewis, schuppenies
severity: normal
status: open
title: Some 3k sizeof tests fail

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

From report at bugs.python.org  Fri Jun  6 13:57:55 2008
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 06 Jun 2008 11:57:55 +0000
Subject: [New-bugs-announce] [issue3050] Implement PEP 371: multiprocessing
	module
In-Reply-To: <1212753475.27.0.272334979501.issue3050@psf.upfronthosting.co.za>
Message-ID: <1212753475.27.0.272334979501.issue3050@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

This issue tracks the work pending for the inclusion of the pyprocessing 
module under the multiprocessing name for Python 2.6 and 3.0. If needed, 
additional tickets will be created for issues which will need to be 
addressed after initial inclusion.

Currently open:
- Redo all documentation to match ReST format of stdlib
- Update docs to reflect new PEP8 names
- Update all unit tests to be in Unittest format

Closed:
- Rename module API to be PEP8 compliant (roudkerk)
- Link csource libs into python-trunk build (jnoller)
- redo all local "." style imports to reflect the new namespace 
(jnoller)

----------
components: Extension Modules
messages: 67763
nosy: jnoller, roudkerk
severity: normal
status: open
title: Implement PEP 371: multiprocessing module
type: feature request
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun  6 14:37:38 2008
From: report at bugs.python.org (Thomas Herve)
Date: Fri, 06 Jun 2008 12:37:38 +0000
Subject: [New-bugs-announce] [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>


New submission from Thomas Herve <therve at free.fr>:

A recent change in heapq implements it in terms of less-than:
http://svn.python.org/view/python/trunk/Modules/_heapqmodule.c?rev=63827&r1=63675&r2=63827

Unfortunately, it breaks usage of heapq when a class only implements
__le__ and not __ge__ or __cmp__. This is done this way in Twisted:
http://twistedmatrix.com/trac/browser/trunk/twisted/internet/base.py#L159.

If not mandatory, it would be nice if this change was reverted or that a
backward compatible change was done instead.

----------
components: Library (Lib)
messages: 67765
nosy: therve
severity: normal
status: open
title: heapq change breaking compatibility
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun  6 16:15:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Jun 2008 14:15:17 +0000
Subject: [New-bugs-announce] [issue3052] Mac Modules failing to compile
In-Reply-To: <1212761717.02.0.568849147453.issue3052@psf.upfronthosting.co.za>
Message-ID: <1212761717.02.0.568849147453.issue3052@psf.upfronthosting.co.za>


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

On Mac 10.4 PPC:

building 'MacOS' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/temp/python/trunk/./Include
-I/temp/python/trunk/./Mac/Include -I. -IInclude -I./Include
-I/usr/local/include -I/temp/python/trunk/Include -I/temp/python/trunk
-c /temp/python/trunk/Mac/Modules/MacOS.c -o
build/temp.macosx-10.3-ppc-2.6/temp/python/trunk/Mac/Modules/MacOS.o-Wno-deprecated-declarations
/temp/python/trunk/Mac/Modules/MacOS.c:44: error: parse error before
'Fsiorefnum'
/temp/python/trunk/Mac/Modules/MacOS.c:44: warning: no semicolon at end
of struct or union
/temp/python/trunk/Mac/Modules/MacOS.c:46: error: parse error before '}'
token
/temp/python/trunk/Mac/Modules/MacOS.c:46: warning: type defaults to
'int' in declaration of 'rfobject'
/temp/python/trunk/Mac/Modules/MacOS.c:46: warning: data definition has
no type or storage class
/temp/python/trunk/Mac/Modules/MacOS.c:55: error: parse error before '*'
token
/temp/python/trunk/Mac/Modules/MacOS.c:56: warning: function declaration
isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'do_close':
/temp/python/trunk/Mac/Modules/MacOS.c:57: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:57: error: (Each undeclared
identifier is reported only once
/temp/python/trunk/Mac/Modules/MacOS.c:57: error: for each function it
appears in.)
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:67: error: parse error before '*'
token
/temp/python/trunk/Mac/Modules/MacOS.c:68: warning: function declaration
isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'rf_read':
/temp/python/trunk/Mac/Modules/MacOS.c:74: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:79: error: 'args' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:88: warning: implicit declaration
of function 'PyMac_Error'
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:102: error: parse error before
'*' token
/temp/python/trunk/Mac/Modules/MacOS.c:103: warning: function
declaration isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'rf_write':
/temp/python/trunk/Mac/Modules/MacOS.c:108: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:112: error: 'args' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:129: error: parse error before
'*' token
/temp/python/trunk/Mac/Modules/MacOS.c:130: warning: function
declaration isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'rf_seek':
/temp/python/trunk/Mac/Modules/MacOS.c:136: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:140: error: 'args' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:174: error: parse error before
'*' token
/temp/python/trunk/Mac/Modules/MacOS.c:175: warning: function
declaration isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'rf_tell':
/temp/python/trunk/Mac/Modules/MacOS.c:179: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:183: error: 'args' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:199: error: parse error before
'*' token
/temp/python/trunk/Mac/Modules/MacOS.c:200: warning: function
declaration isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'rf_close':
/temp/python/trunk/Mac/Modules/MacOS.c:201: error: 'args' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:203: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:222: error: parse error before
'*' token
/temp/python/trunk/Mac/Modules/MacOS.c:224: warning: return type
defaults to 'int'
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'newrfobject':
/temp/python/trunk/Mac/Modules/MacOS.c:225: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:227: error: parse error before
')' token
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:236: error: parse error before
'*' token
/temp/python/trunk/Mac/Modules/MacOS.c:237: warning: function
declaration isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'rf_dealloc':
/temp/python/trunk/Mac/Modules/MacOS.c:238: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: At top level:
/temp/python/trunk/Mac/Modules/MacOS.c:243: error: parse error before
'*' token
/temp/python/trunk/Mac/Modules/MacOS.c:244: warning: function
declaration isn't a prototype
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'rf_getattr':
/temp/python/trunk/Mac/Modules/MacOS.c:245: error: 'self' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:245: error: 'name' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: In function
'MacOS_GetCreatorAndType':
/temp/python/trunk/Mac/Modules/MacOS.c:295: error: 'PyMac_GetFSRef'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:304: error: 'PyMac_GetFSSpec'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:308: warning: implicit
declaration of function 'PyErr_Mac'
/temp/python/trunk/Mac/Modules/MacOS.c:308: warning: return makes
pointer from integer without a cast
/temp/python/trunk/Mac/Modules/MacOS.c: In function
'MacOS_SetCreatorAndType':
/temp/python/trunk/Mac/Modules/MacOS.c:362: error: 'PyMac_GetFSRef'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:362: error: 'PyMac_GetOSType'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:369: error: 'PyMac_GetFSSpec'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:373: warning: return makes
pointer from integer without a cast
/temp/python/trunk/Mac/Modules/MacOS.c:379: warning: return makes
pointer from integer without a cast
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'MacOS_DebugStr':
/temp/python/trunk/Mac/Modules/MacOS.c:540: error: 'PyMac_GetStr255'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'MacOS_openrf':
/temp/python/trunk/Mac/Modules/MacOS.c:626: error: 'fp' undeclared
(first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c:629: error: 'PyMac_GetFSRef'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/MacOS.c: In function 'initMacOS':
/temp/python/trunk/Mac/Modules/MacOS.c:693: warning: implicit
declaration of function 'PyMac_GetOSErrException'
/temp/python/trunk/Mac/Modules/MacOS.c:693: warning: assignment makes
pointer from integer without a cast
building '_AE' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/temp/python/trunk/./Include
-I/temp/python/trunk/./Mac/Include -I. -IInclude -I./Include
-I/usr/local/include -I/temp/python/trunk/Include -I/temp/python/trunk
-c /temp/python/trunk/Mac/Modules/ae/_AEmodule.c -o
build/temp.macosx-10.3-ppc-2.6/temp/python/trunk/Mac/Modules/ae/_AEmodule.o
-Wno-deprecated-declarations
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c: In function
'AEDesc_AEResumeTheCurrentEvent':
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:687: error: 'SRefCon'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:687: error: (Each
undeclared identifier is reported only once
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:687: error: for each
function it appears in.)
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:687: error: parse error
before 'dispatcher'
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c: In function
'AE_AEInstallEventHandler':
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:1158: error: 'SRefCon'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:1158: error: parse error
before 'handler'
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c: In function
'AE_AEGetEventHandler':
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:1207: error: 'SRefCon'
undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/ae/_AEmodule.c:1207: error: parse error
before ')' token
building '_File' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/temp/python/trunk/./Include
-I/temp/python/trunk/./Mac/Include -I. -IInclude -I./Include
-I/usr/local/include -I/temp/python/trunk/Include -I/temp/python/trunk
-c /temp/python/trunk/Mac/Modules/file/_Filemodule.c -o
build/temp.macosx-10.3-ppc-2.6/temp/python/trunk/Mac/Modules/file/_Filemodule.o
-Wno-deprecated-declarations
/temp/python/trunk/Mac/Modules/file/_Filemodule.c: In function
'FSRef_FSOpenFork':
/temp/python/trunk/Mac/Modules/file/_Filemodule.c:1877: error:
'FSIORefNum' undeclared (first use in this function)
/temp/python/trunk/Mac/Modules/file/_Filemodule.c:1877: error: (Each
undeclared identifier is reported only once
/temp/python/trunk/Mac/Modules/file/_Filemodule.c:1877: error: for each
function it appears in.)
/temp/python/trunk/Mac/Modules/file/_Filemodule.c:1877: error: parse
error before 'forkRefNum'
/temp/python/trunk/Mac/Modules/file/_Filemodule.c:1886: error:
'forkRefNum' undeclared (first use in this function)

----------
assignee: ronaldoussoren
messages: 67767
nosy: benjamin.peterson, ronaldoussoren
priority: critical
severity: normal
status: open
title: Mac Modules failing to compile
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun  6 16:51:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jun 2008 14:51:07 +0000
Subject: [New-bugs-announce] [issue3053] test_shutil fails under AIX
In-Reply-To: <1212763867.85.0.395528995267.issue3053@psf.upfronthosting.co.za>
Message-ID: <1212763867.85.0.395528995267.issue3053@psf.upfronthosting.co.za>


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

test_shutil fails with the following error under some AIX 5.3 machine:

======================================================================
FAIL: test_on_error (__main__.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_shutil.py", line 35, in test_on_error
    shutil.rmtree(TESTFN, onerror=self.check_args_to_onerror)
  File "/qakplus/qa_test/SandBoxes/Antoine/Python-2.5.2/Lib/shutil.py",
line 161, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "Lib/test/test_shutil.py", line 49, in check_args_to_onerror
    self.assertEqual(func, os.remove)
AssertionError: <built-in function listdir> != <built-in function remove>


The problem seems to be that the system is stricter with permissions
(please note I don't know AIX at all, and the filesystems are unknown
brands of network filesystems :-)), and @test in that test case is set
to chmod 0400:

$ chmod 400 @test
$ ./python -c "import os; print os.listdir('@test')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 13] Permission denied: '@test'
$ chmod 100 @test
$ ./python -c "import os; print os.listdir('@test')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 13] Permission denied: '@test'
$ chmod 500 @test
$ ./python -c "import os; print os.listdir('@test')"
['a']


The error was witnessed with Python 2.5.2 but the test case doesn't seem
to have changed in trunk so it should be the same there too.

----------
components: Tests
messages: 67771
nosy: pitrou
severity: normal
status: open
title: test_shutil fails under AIX
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jun  6 23:34:18 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 Jun 2008 21:34:18 +0000
Subject: [New-bugs-announce] [issue3054] test_disutils fails
In-Reply-To: <1212788058.33.0.328120732213.issue3054@psf.upfronthosting.co.za>
Message-ID: <1212788058.33.0.328120732213.issue3054@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

test_distutils fails when you're not building in the root of the source 
tree.

That is:

  mkdir build
  cd build
  ../configure
  make
  make check

This fails like this:

test test_distutils failed -- Traceback (most recent call last):
  File "/Users/ronald/Projects/python/python-
trunk/Lib/distutils/tests/test_build_ext.py", line 23, in setUp
    shutil.copy(xx_c, self.tmp_dir)
  File "/Users/ronald/Projects/python/python-trunk/Lib/shutil.py", line 
82, in copy
    copyfile(src, dst)
  File "/Users/ronald/Projects/python/python-trunk/Lib/shutil.py", line 
46, in copyfile
    fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: 
'/Users/ronald/Projects/python/python-trunk/build104/Modules/xxmodule.c'

----------
components: Distutils
messages: 67785
nosy: ronaldoussoren
priority: high
severity: normal
status: open
title: test_disutils fails
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun  6 23:37:35 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 Jun 2008 21:37:35 +0000
Subject: [New-bugs-announce] [issue3055] test_list on 64-bit platforms
In-Reply-To: <1212788254.95.0.00817873629987.issue3055@psf.upfronthosting.co.za>
Message-ID: <1212788254.95.0.00817873629987.issue3055@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

test_list, and possible other tests, use a lot of memory when Python is 
build in 64-bit mode. This causes heavy swapping when the machine doesn't 
have a huge amount of memory.

I've filed this bug because an OSX box with 3 GBytes of RAM gets 
completely unresponsive when trying to run test_list (due to heavy 
swapping).

----------
components: Tests
messages: 67786
nosy: ronaldoussoren
priority: low
severity: normal
status: open
title: test_list on 64-bit platforms
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun  7 03:57:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Jun 2008 01:57:25 +0000
Subject: [New-bugs-announce] [issue3056] Simplify the Integral ABC
In-Reply-To: <1212803845.73.0.399511532431.issue3056@psf.upfronthosting.co.za>
Message-ID: <1212803845.73.0.399511532431.issue3056@psf.upfronthosting.co.za>


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

* Reduce Integral to just a single additional abstract method.
* Supply the binary operations as mixins instead of abstract methods.
* Three argument __pow__ is now optional.
* Convert with __int__ instead of __long__.

----------
assignee: gvanrossum
components: Library (Lib)
files: numbers2.diff
keywords: patch
messages: 67792
nosy: gvanrossum, rhettinger
severity: normal
status: open
title: Simplify the Integral ABC
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10539/numbers2.diff

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

From report at bugs.python.org  Sat Jun  7 18:13:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 Jun 2008 16:13:30 +0000
Subject: [New-bugs-announce] [issue3057] 2.6 abc fixes
In-Reply-To: <1212855209.92.0.133946246819.issue3057@psf.upfronthosting.co.za>
Message-ID: <1212855209.92.0.133946246819.issue3057@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

This patch makes the 2.6 Mapping ABC use the 2.6 dict interface. It also
removes registering list as a KeysView, ValuesView and ItemsView.

----------
assignee: gvanrossum
components: Library (Lib)
files: abcoll.diff
keywords: 26backport, patch
messages: 67810
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: 2.6 abc fixes
versions: Python 2.6
Added file: http://bugs.python.org/file10544/abcoll.diff

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

From report at bugs.python.org  Sat Jun  7 18:26:12 2008
From: report at bugs.python.org (Kunshan Wang)
Date: Sat, 07 Jun 2008 16:26:12 +0000
Subject: [New-bugs-announce] [issue3058] Let SimpleXMLRPCServer pass
	client_address to called functions.
In-Reply-To: <1212855971.92.0.424447915547.issue3058@psf.upfronthosting.co.za>
Message-ID: <1212855971.92.0.424447915547.issue3058@psf.upfronthosting.co.za>


New submission from Kunshan Wang <wks1986 at gmail.com>:

I recently wrote a program making use of SimpleXMLRPCServer.
It has a function that responds to the caller according to the caller's
IP address.  However the current SimpleXMLRPCServer does not allow me to
do this (directly).

For example:

def whoami():
    # blah blah blah ....
    return the_caller_s_ip_address
svr.register_function(whoami)

The problem is that only SimpleXMLRPCRequestHandler knows the client's
IP address.  I googled and searched the google group.  Many people
recommends subclassing the SimpleXMLRPCRequestHandler.  I did this, but
found that it is not very easy, although possible.

I managed to make the RequestHandler pass its member client_address to
function _dispatch by subclassing SimpleXMLRPCRequestHandler,
copy-and-paste the code from the library, and then add an extra argument
to _dispatch.  Now _dispatch function looks like this:

_dispatch(self, method, params, client_address)

By default _dispatch assumes that the first parameter of 'method' is
client_address, and then followed by other parameters from the (remote)
caller.  So if the XMLRPC client calls:

s=xmlrpclib.Server("http://localhost:9999")
s.whoami()

the server actually calls whoami(client_address), where whoami is
defined as:

def whoami(client_address):
    return client_address


The attachment contains a subclassed version of SimpleXMLRPCServer,
named AddressRevealingXMLRPCServer.  The code is ugly (because most
codes are copied, and is vulnerable to future library changes), but it
just works now.

However this leads to more problems:  Now that client_address can be
passed to the called function, it may be needed that more informations
could be passed to the called function, such as the HTTP headers, the
response time, etc..  

My code may not be the best solution.
I suggest there may be some mechanism (such as overridable methods) to
be added to SimpleXMLRPCServer so that user can specify *what* to pass
to the called function.

----------
components: Library (Lib)
files: AddressRevealingXMLRPCServer.py
messages: 67811
nosy: cloverprince
severity: normal
status: open
title: Let SimpleXMLRPCServer pass client_address to called functions.
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file10545/AddressRevealingXMLRPCServer.py

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

From report at bugs.python.org  Sat Jun  7 21:40:04 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 07 Jun 2008 19:40:04 +0000
Subject: [New-bugs-announce] [issue3059] Removing s.decode at Lib/calendar.py
In-Reply-To: <1212867603.86.0.654177679684.issue3059@psf.upfronthosting.co.za>
Message-ID: <1212867603.86.0.654177679684.issue3059@psf.upfronthosting.co.za>


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

I've removed calls to s.decode found at Lib/calendar.py as it is no
longer needed in py3k and doesn't even work (since .decode is gone).

----------
components: Library (Lib)
files: no_strdecode.diff
keywords: patch
messages: 67815
nosy: gpolo
severity: normal
status: open
title: Removing s.decode at Lib/calendar.py
versions: Python 3.0
Added file: http://bugs.python.org/file10546/no_strdecode.diff

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

From report at bugs.python.org  Sun Jun  8 03:45:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 08 Jun 2008 01:45:54 +0000
Subject: [New-bugs-announce] [issue3060] Warn about tuple parameters
In-Reply-To: <1212889554.57.0.975996757634.issue3060@psf.upfronthosting.co.za>
Message-ID: <1212889554.57.0.975996757634.issue3060@psf.upfronthosting.co.za>


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

This patch adds Py3k warnings to nested tuple parameters.

----------
assignee: georg.brandl
components: Interpreter Core
files: tuple_parameters_warn.patch
keywords: patch
messages: 67820
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: Warn about tuple parameters
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10549/tuple_parameters_warn.patch

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

From report at bugs.python.org  Sun Jun  8 10:44:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Jun 2008 08:44:29 +0000
Subject: [New-bugs-announce] [issue3061] time.strftime() always decodes
	result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

It decodes the system strftime's result using TZNAME_ENCODING which is
also used to decode timezone names.  This may be correct for timezone
names themselves (I don't know), but the strftime result is encoded in
the LC_TIME encoding - at least on my Linux system.

----------
assignee: loewis
messages: 67828
nosy: georg.brandl, loewis
priority: high
severity: normal
status: open
title: time.strftime() always decodes result with UTF-8
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun  8 13:06:55 2008
From: report at bugs.python.org (Pierre Bourdon)
Date: Sun, 08 Jun 2008 11:06:55 +0000
Subject: [New-bugs-announce] [issue3062] Turtle speed() function has no
	effect under Mac OS X
In-Reply-To: <1212923215.43.0.432854849061.issue3062@psf.upfronthosting.co.za>
Message-ID: <1212923215.43.0.432854849061.issue3062@psf.upfronthosting.co.za>


New submission from Pierre Bourdon <root at delroth.is-a-geek.org>:

When using the speed() function of the turtle module under Mac OS X, 
it has no effect : the turtle always draws lines with the same speed.

An easy fix is to replace line 553 of the turtle.py file 
by "sleep(self._delay / 1000.0)", however I don't know if it is the 
best solution.

----------
components: Tkinter
messages: 67831
nosy: delroth
severity: normal
status: open
title: Turtle speed() function has no effect under Mac OS X
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun  8 17:46:09 2008
From: report at bugs.python.org (Grant Tang)
Date: Sun, 08 Jun 2008 15:46:09 +0000
Subject: [New-bugs-announce] [issue3063] memory leak in random number
	generation
In-Reply-To: <1212939967.99.0.941797469942.issue3063@psf.upfronthosting.co.za>
Message-ID: <1212939967.99.0.941797469942.issue3063@psf.upfronthosting.co.za>


New submission from Grant Tang <grant.tang at gmail.com>:

#the following code consume about 800M memory, which is normal
n = 100000000
data = [0.0 for i in xrange(n)]

#however, if I assign random number to data list, it will consume extra 
2.5G memory.
from random import random
for s in xrange(n):
    data[i] = random()

#even if I delete data, only 800M memory released
del data

#call gc.collect() does not help, the extra 2.5G memory not released
import gc
gc.collect()

only when I quit Python, the memory is released. Same effect if I use 
random number generator from numpy. 
Same effect even if I just say data[i] = atpof("1.26")
I tried it in both Python 2.4 and 2.5 on linux 64bit and 32bit.

----------
components: None
messages: 67833
nosy: gtang
severity: normal
status: open
title: memory leak in random number generation
type: resource usage
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Mon Jun  9 01:46:10 2008
From: report at bugs.python.org (Gregor Lingl)
Date: Sun, 08 Jun 2008 23:46:10 +0000
Subject: [New-bugs-announce] [issue3064] new turtle module for Python 3.0
In-Reply-To: <1212968770.03.0.0198967789225.issue3064@psf.upfronthosting.co.za>
Message-ID: <1212968770.03.0.0198967789225.issue3064@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

turtle3.zip contains the port of the new turtle module (including demo
viewer and demo scripts) to Python 3.0 . One demo script has been added
(tdemo_forest.py)

It has been tested under Windows/MacOsX/Linux without showing up any
problems. 

I've done a few small changes to the API - as proposed in issue 1513695
- which are described in the docfile. 

Gregor Lingl

----------
components: Tkinter
files: turtle3.zip
messages: 67852
nosy: gregorlingl, loewis
severity: normal
status: open
title: new turtle module for Python 3.0
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10557/turtle3.zip

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

From report at bugs.python.org  Mon Jun  9 01:54:14 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 08 Jun 2008 23:54:14 +0000
Subject: [New-bugs-announce] [issue3065] Fix pickling bug of
	collections.namedtuple
In-Reply-To: <1212969254.61.0.946531358999.issue3065@psf.upfronthosting.co.za>
Message-ID: <1212969254.61.0.946531358999.issue3065@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

There is currently a pickling bug in the namedtuple factory:

  >>> from collections import namedtuple
  >>> MemoRecord = namedtuple("MemoRecord", "key, msg")
  >>> m = MemoRecord(1,"hello")
  >>> import pickle
  >>> pickle.loads(pickle.dumps(m))
  Traceback (most recent call last):
    ...
  TypeError: __new__() takes exactly 3 positional arguments (2 given)

The bug is due to the fact that classes created by namedtuple don't
handle the __new__ arguments in the same fashion as tuple.__new__. The
fix is simply to define __getnewargs__.

----------
assignee: rhettinger
components: Library (Lib)
files: fix_namedtuple_pickling.patch
keywords: patch, patch
messages: 67853
nosy: alexandre.vassalotti, rhettinger
priority: normal
severity: normal
status: open
title: Fix pickling bug of collections.namedtuple
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10558/fix_namedtuple_pickling.patch

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

From report at bugs.python.org  Mon Jun  9 13:03:09 2008
From: report at bugs.python.org (Bohdan Vlasyuk)
Date: Mon, 09 Jun 2008 11:03:09 +0000
Subject: [New-bugs-announce] [issue3066] FD leak in urllib2
In-Reply-To: <1213009389.23.0.132424094421.issue3066@psf.upfronthosting.co.za>
Message-ID: <1213009389.23.0.132424094421.issue3066@psf.upfronthosting.co.za>


New submission from Bohdan Vlasyuk <bohdan at google.com>:

In urllib2.AbstractHTTPHandler.do_open, the following like creates a
circular link:

        r.recv = r.read

[r.read is a bound method, so it contains a reference to 'r'. Therefore,
r now refers to itself.]

If the GC is disabled or doesn't run often, this creates a FD leak.

How to reproduce:

import gc
import urllib2
u = urllib2.urlopen("http://google.com")
s = [ u.fp._sock.fp._sock ]
u.close()
del u
print gc.get_referrers(s[0])
[<socket._fileobject object at 0xf7d42c34>, [<socket object, fd=4,
family=2, type=1, protocol=6>]]

I would expect that only one reference to the socket would exist (the
"s" list itself).

I can reproduce with 2.4; the problems seems to still exist in SVN HEAD.

----------
components: Library (Lib)
messages: 67860
nosy: bohdan
severity: normal
status: open
title: FD leak in urllib2
type: resource usage
versions: Python 2.4

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

From report at bugs.python.org  Mon Jun  9 14:09:15 2008
From: report at bugs.python.org (vincent.chute)
Date: Mon, 09 Jun 2008 12:09:15 +0000
Subject: [New-bugs-announce] [issue3067] setlocale Tracebacks on unicode
	locale strings
In-Reply-To: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>
Message-ID: <1213013354.87.0.861327880823.issue3067@psf.upfronthosting.co.za>


New submission from vincent.chute <vincent.chute at onelan.co.uk>:

import locale
locale.setlocale( locale.LC_ALL, u'ja_JP.utf8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/locale.py", line 475, in setlocale
    locale = normalize(_build_localename(locale))
  File "/usr/lib/python2.5/locale.py", line 383, in _build_localename
    language, encoding = localetuple
ValueError: too many values to unpack

The problem is line 473:
    if locale and type(locale) is not type(""):

Replacing this with
     if locale and not isinstance(locale, basestring):
fixes the problem.

----------
components: Library (Lib)
messages: 67861
nosy: vincent.chute
severity: normal
status: open
title: setlocale Tracebacks on unicode locale strings
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun  9 20:10:33 2008
From: report at bugs.python.org (Tal Einat)
Date: Mon, 09 Jun 2008 18:10:33 +0000
Subject: [New-bugs-announce] [issue3068] IDLE - Add an extension
	configuration dialog
In-Reply-To: <1213035033.21.0.781726477097.issue3068@psf.upfronthosting.co.za>
Message-ID: <1213035033.21.0.781726477097.issue3068@psf.upfronthosting.co.za>


New submission from Tal Einat <taleinat at users.sourceforge.net>:

Attaching a patch for a straightforward extension config dialog, largely
based on configDialog.py.

This uses the multiple-tab-rows feature of the TabbedPageSet widget from
the tabbedPages module, as well as the included VerticalScrolledFrame
widget. Other than that there's nothing really new here.

----------
components: IDLE
files: IDLE_configExtensionsDialog.080609.patch
keywords: patch
messages: 67872
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - Add an extension configuration dialog
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10560/IDLE_configExtensionsDialog.080609.patch

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

From report at bugs.python.org  Tue Jun 10 01:01:52 2008
From: report at bugs.python.org (Arnaud Delobelle)
Date: Mon, 09 Jun 2008 23:01:52 +0000
Subject: [New-bugs-announce] [issue3069] Let set.union and set.intersection
	accept multiple arguments
In-Reply-To: <1213052512.78.0.0912293391051.issue3069@psf.upfronthosting.co.za>
Message-ID: <1213052512.78.0.0912293391051.issue3069@psf.upfronthosting.co.za>


New submission from Arnaud Delobelle <arnodel at googlemail.com>:

The patch allows the following syntax for s set/frozenset:
* s.union(a, b, c,...)
* s.update(a, b, c,...)
* s.intersection(a, b, c,...)
* s.intersection_update(a, b, c,...)

By extension:
* set.union(a, b, c,...) # provided a is a set/frozenset
* ...

Union is extended by iterative application of set_union_internal
Intersection is optimized by sorting all sets/frozensets/dicts in 
increasing order of size and only iterating over elements in the 
smallest.

This was discussed on python-ideas:
http://groups.google.com/group/python-
ideas/browse_thread/thread/945a6c989ab905a3/54defd5e62b9a2a6

----------
components: Interpreter Core
files: set_ui_varargs.diff
keywords: patch
messages: 67878
nosy: arno
severity: normal
status: open
title: Let set.union and set.intersection accept multiple arguments
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10565/set_ui_varargs.diff

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

From report at bugs.python.org  Tue Jun 10 01:28:51 2008
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 09 Jun 2008 23:28:51 +0000
Subject: [New-bugs-announce] [issue3070] Wrong size calculation in
	posix_execve
In-Reply-To: <1213054131.08.0.268305843949.issue3070@psf.upfronthosting.co.za>
Message-ID: <1213054131.08.0.268305843949.issue3070@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

In 2.x, the size of C string needed for an environment variable used by
posix_execve was calculated using PyString_GetSize.  In 3.0 this is
translated to PyUnicode_GetSize.  However, in 3.0 the C string is the
UTF-8 encoded version of the unicode object, which doesn't necessarily
have the same length as what PyUnicode_GetSize reports.

The simplest solution I see is to use strlen() instead.

----------
components: Extension Modules
messages: 67880
nosy: Rhamphoryncus
severity: normal
status: open
title: Wrong size calculation in posix_execve
versions: Python 3.0

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

From report at bugs.python.org  Tue Jun 10 04:06:06 2008
From: report at bugs.python.org (Jonathan Lange)
Date: Tue, 10 Jun 2008 02:06:06 +0000
Subject: [New-bugs-announce] [issue3071] The ValueError raised by failing to
	unpack sequence should have more information.
In-Reply-To: <1213063566.77.0.933941671492.issue3071@psf.upfronthosting.co.za>
Message-ID: <1213063566.77.0.933941671492.issue3071@psf.upfronthosting.co.za>


New submission from Jonathan Lange <jml at mumak.net>:

Here's the current message:

Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> [foo] = [2, 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack

It would be good if the message of the ValueError contained information
about how many values were expected and how many values were given.

----------
components: Interpreter Core
messages: 67885
nosy: jml
severity: normal
status: open
title: The ValueError raised by failing to unpack sequence should have more information.
type: feature request
versions: Python 2.3, Python 2.4, Python 2.5

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

From report at bugs.python.org  Tue Jun 10 06:24:29 2008
From: report at bugs.python.org (Steve Emmert)
Date: Tue, 10 Jun 2008 04:24:29 +0000
Subject: [New-bugs-announce] [issue3072] Assignment to list of lists gives
	incorrect result
In-Reply-To: <1213071869.88.0.834144685445.issue3072@psf.upfronthosting.co.za>
Message-ID: <1213071869.88.0.834144685445.issue3072@psf.upfronthosting.co.za>


New submission from Steve Emmert <steve.eileen at gmail.com>:

This bug is explained in the attached file.  The list of lists does not
behave correctly when it is defined by the makeGrid function in the
attached file.  When attempting to set the value of one element, it
actually sets multiple elements.  The same operation works differently
when the list of lists is defined with a literal.  I am using version
2.5.2 with Windows XP.  I am just learning Python, so I may have gotten
some terminology wrong.
stesteve

----------
components: Interpreter Core
files: Bug_Case.py
messages: 67894
nosy: stesteve
severity: normal
status: open
title: Assignment to list of lists gives incorrect result
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10571/Bug_Case.py

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

From report at bugs.python.org  Tue Jun 10 12:11:44 2008
From: report at bugs.python.org (Lawrence Oluyede)
Date: Tue, 10 Jun 2008 10:11:44 +0000
Subject: [New-bugs-announce] [issue3073] Cookie.Morsel breaks in parsing
	cookie values with whitespace
In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za>
Message-ID: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za>


New submission from Lawrence Oluyede <l.oluyede at gmail.com>:

It seems the Cookie module has an odd behavior with whitespaces.
According to http://wp.netscape.com/newsref/std/cookie_spec.html and
http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_attributes the 'Expires'
attribute of the cookie should have this format:

"Wdy, DD-Mon-YYYY HH:MM:SS GMT"

and this is recognized by all the browsers. The oddity comes when I try
to load or create a cookie with that attribute:

Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Cookie import SimpleCookie
>>> cookies = SimpleCookie()
>>> cookies.load('foo=baz; expires=Sat, 10-Jun-1978 09:41:04 GMT')
>>> cookies
<SimpleCookie: foo='baz'>
>>> cookies['foo']['expires']
'Sat,'
>>> cookies.load('foo=baz; expires=2008-06-10T09:44:45.963024')
>>> cookies['foo']['expires']
'2008-06-10T09:44:45.963024'

It really seems the parser breaks on whitespaces.

----------
components: Library (Lib)
messages: 67901
nosy: rhymes
severity: normal
status: open
title: Cookie.Morsel breaks in parsing cookie values with whitespace
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun 10 15:06:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 10 Jun 2008 13:06:06 +0000
Subject: [New-bugs-announce] [issue3074] test_asyncore is failing
In-Reply-To: <1213103166.81.0.500161897199.issue3074@psf.upfronthosting.co.za>
Message-ID: <1213103166.81.0.500161897199.issue3074@psf.upfronthosting.co.za>


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

test_asyncore
test_closeall (test.test_asyncore.HelperFunctionTests) ... ok
test_closeall_default (test.test_asyncore.HelperFunctionTests) ... ok
test_compact_traceback (test.test_asyncore.HelperFunctionTests) ... ok
test_readwrite (test.test_asyncore.HelperFunctionTests) ... ok
test_readwriteexc (test.test_asyncore.HelperFunctionTests) ... ok
test_basic (test.test_asyncore.DispatcherTests) ... ok
test_log (test.test_asyncore.DispatcherTests) ... ok
test_log_info (test.test_asyncore.DispatcherTests) ... ok
test_repr (test.test_asyncore.DispatcherTests) ... ok
test_unhandled (test.test_asyncore.DispatcherTests) ... ok
test_send (test.test_asyncore.DispatcherWithSendTests) ... ok
test_send (test.test_asyncore.DispatcherWithSendTests_UsePoll) ... ok
test_recv (test.test_asyncore.FileWrapperTest) ... FAIL
test_send (test.test_asyncore.FileWrapperTest) ... ok

======================================================================
FAIL: test_recv (test.test_asyncore.FileWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/trunk/Lib/test/test_asyncore.py", line 387, in
test_recv
    self.assertEqual(w.fd, fd)
AssertionError: 7 != 5

----------------------------------------------------------------------
Ran 14 tests in 0.969s

FAILED (failures=1)
test test_asyncore failed -- Traceback (most recent call last):
  File "/temp/python/trunk/Lib/test/test_asyncore.py", line 387, in
test_recv
    self.assertEqual(w.fd, fd)
AssertionError: 7 != 5

1 test failed:
    test_asyncore

----------
assignee: josiahcarlson
components: Tests
messages: 67904
nosy: benjamin.peterson, josiahcarlson
priority: critical
severity: normal
status: open
title: test_asyncore is failing
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 10 20:12:04 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 10 Jun 2008 18:12:04 +0000
Subject: [New-bugs-announce] [issue3075] make minidom.toxml() encoding
	argument useful
In-Reply-To: <1213121523.99.0.8342553488.issue3075@psf.upfronthosting.co.za>
Message-ID: <1213121523.99.0.8342553488.issue3075@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Right now, the encoding argument added to
xml.dom.minidom.DOMObject.toxml() in Python 2.3 seems fairly useless. 
It has to be UTF-8.  But a one-line change to the implementation of
toprettyxml would make it useful; instead of the encoding error method
being "strict", make it "xmlcharrefreplace".  So change

    writer = codecs.lookup(encoding)[3](writer)

to

    writer = codecs.lookup(encoding)[3](writer, "xmlcharrefreplace")

----------
components: Library (Lib)
keywords: easy
messages: 67909
nosy: janssen
priority: normal
severity: normal
status: open
title: make minidom.toxml() encoding argument useful
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Jun 10 22:45:40 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 10 Jun 2008 20:45:40 +0000
Subject: [New-bugs-announce] [issue3076] xml_rpc_net fails on Darwin
In-Reply-To: <1213130740.65.0.865177105879.issue3076@psf.upfronthosting.co.za>
Message-ID: <1213130740.65.0.865177105879.issue3076@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Latest py3k branch,

test_xmlrpc_net
test test_xmlrpc_net failed -- Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/test/test_xmlrpc_net.py", line 
18, in test_current_time
    t0 = server.currentTime.getCurrentTime()
  File "/Users/cartman/Sources/py3k/Lib/xmlrpc/client.py", line 1095, in 
__call__
    return self.__send(self.__name, args)
  File "/Users/cartman/Sources/py3k/Lib/xmlrpc/client.py", line 1353, in 
__request
    verbose=self.__verbose
  File "/Users/cartman/Sources/py3k/Lib/xmlrpc/client.py", line 1136, in 
request
    return self._parse_response(resp, None)
  File "/Users/cartman/Sources/py3k/Lib/xmlrpc/client.py", line 1246, in 
_parse_response
    p.feed(response)
  File "/Users/cartman/Sources/py3k/Lib/xmlrpc/client.py", line 516, in 
feed
    self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: mismatched tag: line 10, column 7

This is MacOSX Leopard 10.5.3

----------
components: Tests
messages: 67918
nosy: cartman
severity: normal
status: open
title: xml_rpc_net fails on Darwin
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun 11 10:26:09 2008
From: report at bugs.python.org (Gabriel)
Date: Wed, 11 Jun 2008 08:26:09 +0000
Subject: [New-bugs-announce] [issue3077] h2py char literal doesn work
In-Reply-To: <1213172768.79.0.156029263713.issue3077@psf.upfronthosting.co.za>
Message-ID: <1213172768.79.0.156029263713.issue3077@psf.upfronthosting.co.za>


New submission from Gabriel <misc at evotex.ch>:

Tools/scripts/h2py.py doesn't work with char literals in a define. This
was first reported in the following post :

http://mail.python.org/pipermail/python-list/2005-September/340608.html

The fix works, I have included the patch as h2py.py.patch2.

Also, the current thing that is done when a char literal is encountered
is to use the char's ordinal value. I think that this is misleading,
since in C, if you use a char literal you are usually meaning to check
for an ascii char value like so :

#define EXIT_CHAR 'x'

/* ..... */

if(char_read == EXIT_CHAR)
   exit(0)

and not an integer/numeric value, and if you intend to do numerical
things then you'd use an integer/numeric value instead.

This is the way ctypes does it with their h2xml.py & xml2py.py scripts.

So currently, a defines like the following :

#define EXIT_CHAR 'x'
#define MASK 0xfe
#define LIMIT 4

give (after the h2py.py.patch2 being applied) :

EXIT_CHAR = 120
MASK = 0xfe
LIMIT = 4

and the second patch I am submitting (h2py.py.patch) makes it give :

EXIT_CHAR = 'x'
MASK = 0xfe
LIMIT = 4

which I think is a better interpretation of the intent of the defines.

So to resume :

h2py.py.patch2 : this fixes the bug, maintaining the way the original
h2py script tried to process a char literal.

h2py.py.patch : this fixes the bug, but makes a char literal become a
string literal in python instead of the ordinal value.

Gabriel

----------
components: Demos and Tools
files: h2py.py.patch2
messages: 67943
nosy: grossetti
severity: normal
status: open
title: h2py char literal doesn work
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10578/h2py.py.patch2

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

From report at bugs.python.org  Wed Jun 11 15:10:46 2008
From: report at bugs.python.org (Aristotelis Mikropoulos)
Date: Wed, 11 Jun 2008 13:10:46 +0000
Subject: [New-bugs-announce] [issue3078] tokenize.py improvements
In-Reply-To: <1213189845.98.0.955979167249.issue3078@psf.upfronthosting.co.za>
Message-ID: <1213189845.98.0.955979167249.issue3078@psf.upfronthosting.co.za>


New submission from Aristotelis Mikropoulos <amikrop at gmail.com>:

Various tokenize.py performance boosts and code clarifications.

----------
components: Library (Lib)
files: tokenize.py.patch
keywords: patch
messages: 67965
nosy: Indy
severity: normal
status: open
title: tokenize.py improvements
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10581/tokenize.py.patch

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

From report at bugs.python.org  Wed Jun 11 19:23:27 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 11 Jun 2008 17:23:27 +0000
Subject: [New-bugs-announce] [issue3079] sys.exit() called from optparse -
	bad, bad, bad
In-Reply-To: <1213205007.57.0.132667292732.issue3079@psf.upfronthosting.co.za>
Message-ID: <1213205007.57.0.132667292732.issue3079@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

This seems like a bug in optparse.OptionParser:

    def exit(self, status=0, msg=None):
        if msg:
            sys.stderr.write(msg)
        sys.exit(status)

    def error(self, msg):
        """error(msg : string)

        Print a usage message incorporating 'msg' to stderr and exit.
        If you override this in a subclass, it should not return -- it
        should either exit or raise an exception.
        """
        self.print_usage(sys.stderr)
        self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))

By default I think it should raise an exception when it encounters an
error, not exit.  Programmers shouldn't be forced to subclass code in
the standard library to get recommended practice.

If you feel this behavior can't be changed in 2.6 it should at least
be corrected in 3.0.

The cruel irony is that inside OptionParser.parse_args it actually
catches both BadOptionError and OptionValueError but suppresses them
by calling self.error() within the except block...  *arrgggghhh*...
The correct behavior there is (in my opinion) to get rid of the
try/except statement altogether and just let the exceptions propagate.
Other calls to self.error() should be replaced with suitable raise
statements.

Skip

----------
components: Library (Lib)
keywords: easy
messages: 67999
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: sys.exit() called from optparse - bad, bad, bad
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Jun 11 20:24:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 11 Jun 2008 18:24:57 +0000
Subject: [New-bugs-announce] [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

This is the most difficult part of issue1342:
"""
On Windows, don't use the FileSystemEncoding on Windows for sys.path items.
Instead, it should use the wide API to perform all system calls. Py3k
shouldn't ever use the file system encoding for anything on Windows.
"""

This imply to rewrite all functions in import.c, and replace all char*
arguments with unicode variables.

----------
components: Interpreter Core
messages: 68005
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Full unicode import system
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun 11 21:13:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jun 2008 19:13:53 +0000
Subject: [New-bugs-announce] [issue3081] Py_(X)SETREF macros
In-Reply-To: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>
Message-ID: <1213211633.2.0.340935924246.issue3081@psf.upfronthosting.co.za>


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

This is an implementation of the Py_SETREF and Py_XSETREF macros
proposed in http://mail.python.org/pipermail/python-dev/2008-May/079862.html

As an example, I added a few conversions among the extension modules.

----------
components: Extension Modules, Interpreter Core
files: py_setref.patch
keywords: patch
messages: 68009
nosy: pitrou
severity: normal
status: open
title: Py_(X)SETREF macros
versions: Python 3.0
Added file: http://bugs.python.org/file10591/py_setref.patch

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

From report at bugs.python.org  Wed Jun 11 23:14:23 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 Jun 2008 21:14:23 +0000
Subject: [New-bugs-announce] [issue3082] test_multiprocessing broken
In-Reply-To: <1213218863.36.0.875795212815.issue3082@psf.upfronthosting.co.za>
Message-ID: <1213218863.36.0.875795212815.issue3082@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Python 2.6a3+ (trunk:64150M, Jun 11 2008, 14:08:14)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

% ./python Lib/test/test_multiprocessing.py
Fatal Python error: Invalid thread state for this thread
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 1791, in <module>
main()
  File "Lib/test/test_multiprocessing.py", line 1788, in main
test_main(unittest.TextTestRunner(verbosity=2).run)
  File "Lib/test/test_multiprocessing.py", line 1768, in test_main
ManagerMixin.pool = ManagerMixin.manager.Pool(4)
  File
"/home/greg/sandbox/python/trunk/Lib/multiprocessing/managers.py", line
647, in temp
token, exp = self._create(typeid, *args, **kwds)
  File
"/home/greg/sandbox/python/trunk/Lib/multiprocessing/managers.py", line
545, in _create
conn = self._Client(self._address, authkey=self._authkey)
  File
"/home/greg/sandbox/python/trunk/Lib/multiprocessing/connection.py",
line 139, in Client
answer_challenge(c, authkey)
  File
"/home/greg/sandbox/python/trunk/Lib/multiprocessing/connection.py",
line 380, in answer_challenge
message = connection.recv_bytes(256)         # reject large message
EOFError
[50971 refs]


This is on a single cpu i686 linux system.

----------
components: Library (Lib)
messages: 68017
nosy: gregory.p.smith
priority: high
severity: normal
status: open
title: test_multiprocessing broken
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 11 23:22:07 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 11 Jun 2008 21:22:07 +0000
Subject: [New-bugs-announce] [issue3083] Add alternate (#) formatting for
	bin, oct, hex output for str.format()
In-Reply-To: <1213219327.93.0.0491657155546.issue3083@psf.upfronthosting.co.za>
Message-ID: <1213219327.93.0.0491657155546.issue3083@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

Per Guido in
http://mail.python.org/pipermail/python-3000/2008-May/013912.html, add
this to the PEP 3101 (Advanced String Formatting) implementation.

This will add the prefixes 0b, 0o, and 0x.

----------
assignee: eric.smith
components: Interpreter Core
messages: 68020
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Add alternate (#) formatting for bin, oct, hex output for str.format()
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Jun 12 00:50:18 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 11 Jun 2008 22:50:18 +0000
Subject: [New-bugs-announce] [issue3084] sys.exit() called from optparse -
	bad, bad, bad
In-Reply-To: <18512.1923.657436.704863@montanaro-dyndns-org.local>
Message-ID: <18512.1923.657436.704863@montanaro-dyndns-org.local>


New submission from Skip Montanaro <skip at pobox.com>:

This seems like a bug in optparse.OptionParser:

    def exit(self, status=0, msg=None):
        if msg:
            sys.stderr.write(msg)
        sys.exit(status)

    def error(self, msg):
        """error(msg : string)

        Print a usage message incorporating 'msg' to stderr and exit.
        If you override this in a subclass, it should not return -- it
        should either exit or raise an exception.
        """
        self.print_usage(sys.stderr)
        self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))

By default I think it should raise an exception when it encounters an error,
not exit.  Programmers shouldn't be forced to subclass code in the standard
library to get recommended practice.

If you feel this behavior can't be changed in 2.6 it should at least be
corrected in 3.0.

Skip

----------
messages: 68030
nosy: skip.montanaro
severity: normal
status: open
title: sys.exit() called from optparse - bad, bad, bad

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

From report at bugs.python.org  Thu Jun 12 01:01:27 2008
From: report at bugs.python.org (Jan Huelsbergen)
Date: Wed, 11 Jun 2008 23:01:27 +0000
Subject: [New-bugs-announce] [issue3085] chapter 17.1.3.5 'Replacing
	os.popen*' in the Python library reference contains an error
In-Reply-To: <1213225286.96.0.994890895881.issue3085@psf.upfronthosting.co.za>
Message-ID: <1213225286.96.0.994890895881.issue3085@psf.upfronthosting.co.za>


New submission from Jan Huelsbergen <afoo42 at gmail.com>:

the 'from' examples contain non-keyword args after keyword args:

pipe = os.popen(cmd, mode='r', bufsize)

should be

pipe = os.popen(cmd, 'r', bufsize)

and

pipe = os.popen(cmd, mode='w', bufsize)

should be

pipe = os.popen(cmd, 'w', bufsize)

----------
assignee: georg.brandl
components: Documentation
messages: 68032
nosy: afoo, georg.brandl
severity: normal
status: open
title: chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun 12 02:43:53 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 12 Jun 2008 00:43:53 +0000
Subject: [New-bugs-announce] [issue3086] sys.maxsize not available by using
	the latest Win32 build
In-Reply-To: <1213231433.03.0.97189962489.issue3086@psf.upfronthosting.co.za>
Message-ID: <1213231433.03.0.97189962489.issue3086@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

By using:
http://www.python.org/dev/daily-msi/python-2.6.14041.msi


C:\>C:\python26\python
Python 2.6a3 (r26a3:62864, May  9 2008, 14:16:26) [MSC v.1500 32 bit
(Intel)] on
 win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxsize
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'maxsize'
>>>

----------
messages: 68039
nosy: giampaolo.rodola
severity: normal
status: open
title: sys.maxsize not available by using the latest Win32 build
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 12 04:42:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 12 Jun 2008 02:42:20 +0000
Subject: [New-bugs-announce] [issue3087] Clean up Demos and Tools
In-Reply-To: <1213238540.5.0.535212077097.issue3087@psf.upfronthosting.co.za>
Message-ID: <1213238540.5.0.535212077097.issue3087@psf.upfronthosting.co.za>


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

A good bug day task:

Demos and to some extent Tools has a lot of rubbish in 3.0 that probably
doesn't work with all the module removals and such. Somebody should go
through them and chuck all the old stuff.

----------
components: Demos and Tools
keywords: easy
messages: 68045
nosy: benjamin.peterson
priority: high
severity: normal
status: open
title: Clean up Demos and Tools
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 12 06:48:45 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 12 Jun 2008 04:48:45 +0000
Subject: [New-bugs-announce] [issue3088] test_multiprocessing hangs on OS X
	10.5.3
In-Reply-To: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>
Message-ID: <1213246124.39.0.216094705029.issue3088@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

For me, test_multiprocessing hangs consistently on OS X 10.5.3.  It
passes just fine on Ubuntu 8.04.

----------
components: Library (Lib)
messages: 68053
nosy: barry
priority: release blocker
severity: normal
status: open
title: test_multiprocessing hangs on OS X 10.5.3
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 12 06:52:18 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 12 Jun 2008 04:52:18 +0000
Subject: [New-bugs-announce] [issue3089] All 3.0 buildbots are red
In-Reply-To: <1213246338.45.0.928026294572.issue3089@psf.upfronthosting.co.za>
Message-ID: <1213246338.45.0.928026294572.issue3089@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Subject says it all.  None of the 3.0 buildbots are passing.

----------
components: Build
messages: 68054
nosy: barry
priority: release blocker
severity: normal
status: open
title: All 3.0 buildbots are red
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 12 15:16:24 2008
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 12 Jun 2008 13:16:24 +0000
Subject: [New-bugs-announce] [issue3090] ARCHFLAGS parsing/concatenation in
	unixccompiler.py breaks when set to a string
In-Reply-To: <1213276584.77.0.784242980637.issue3090@psf.upfronthosting.co.za>
Message-ID: <1213276584.77.0.784242980637.issue3090@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

This is on osx 10.5.3, latest gcc tool chain.

I have $ARCHFLAGS set to "-arch i386" to prevent the OS/X gcc from 
building PPC code (as I don't want/need it) - if I leave this set as-is, 
other applications build without error, intel only.

If I don't unset it, here's the error:

  File "/Users/jesse/open_source/subversion/python-
trunk/Lib/distutils/ccompiler.py", line 697, in compile
self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
  File "/Users/jesse/open_source/subversion/python-
trunk/Lib/distutils/unixccompiler.py", line 176, in _compile
compiler_so = _darwin_compiler_fixup(compiler_so, cc_args + 
extra_postargs)
  File "/Users/jesse/open_source/subversion/python-
trunk/Lib/distutils/unixccompiler.py", line 79, in 
_darwin_compiler_fixup
compiler_so = compiler_so + ' ' + os.environ['ARCHFLAGS']
TypeError: can only concatenate list (not "str") to list
make: *** [sharedmods] Error 1

I've attached a possible patch for this which does a .split() on the os.environ['ARCHFLAGS'] variable, which fixes the issue

----------
components: Build
files: unixccompiler.py.diff
keywords: patch
messages: 68061
nosy: jnoller
severity: normal
status: open
title: ARCHFLAGS parsing/concatenation in unixccompiler.py breaks when set to a string
versions: Python 2.6
Added file: http://bugs.python.org/file10599/unixccompiler.py.diff

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

From report at bugs.python.org  Thu Jun 12 17:42:24 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 12 Jun 2008 15:42:24 +0000
Subject: [New-bugs-announce] [issue3091] Can't build datetime or time on
	py3k (r64171)
In-Reply-To: <1213285344.4.0.409695975664.issue3091@psf.upfronthosting.co.za>
Message-ID: <1213285344.4.0.409695975664.issue3091@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I'm fully up-to-date on my py3k branch (r64171).  After a make clean I
find that I can't build either the time or datetime modules.  Here are
errors from gcc:

building 'time' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/Users/skip/src/python/py3k/./Include
-I/Users/skip/local/include -I. -IInclude -I./Include
-I/opt/local/include -I/Users/skip/src/python/py3k/Include
-I/Users/skip/src/python/py3k -c
/Users/skip/src/python/py3k/Modules/strftime.c -o
build/temp.macosx-10.3-i386-3.0/Users/skip/src/python/py3k/Modules/strftime.o
/Users/skip/src/python/py3k/Modules/strftime.c: In function '_fmt':
/Users/skip/src/python/py3k/Modules/strftime.c:377: error: 'tm'
undeclared (first use in this function)
/Users/skip/src/python/py3k/Modules/strftime.c:377: error: (Each
undeclared identifier is reported only once
/Users/skip/src/python/py3k/Modules/strftime.c:377: error: for each
function it appears in.)
building 'datetime' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/Users/skip/src/python/py3k/./Include
-I/Users/skip/local/include -I. -IInclude -I./Include
-I/opt/local/include -I/Users/skip/src/python/py3k/Include
-I/Users/skip/src/python/py3k -c
/Users/skip/src/python/py3k/Modules/strftime.c -o
build/temp.macosx-10.3-i386-3.0/Users/skip/src/python/py3k/Modules/strftime.o
/Users/skip/src/python/py3k/Modules/strftime.c: In function '_fmt':
/Users/skip/src/python/py3k/Modules/strftime.c:377: error: 'tm'
undeclared (first use in this function)
/Users/skip/src/python/py3k/Modules/strftime.c:377: error: (Each
undeclared identifier is reported only once
/Users/skip/src/python/py3k/Modules/strftime.c:377: error: for each
function it appears in.)

The environment is Mac OS X 10.5.3.

Assigning to Barry since we're so close to beta.

Skip

----------
assignee: barry
messages: 68069
nosy: barry, skip.montanaro
severity: normal
status: open
title: Can't build datetime or time on py3k (r64171)
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 12 21:50:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jun 2008 19:50:00 +0000
Subject: [New-bugs-announce] [issue3092] Wrong unicode size detection in
	pybench
In-Reply-To: <1213300200.75.0.77296570553.issue3092@psf.upfronthosting.co.za>
Message-ID: <1213300200.75.0.77296570553.issue3092@psf.upfronthosting.co.za>


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

In py3k, pybench wrongly detects UCS2 builds as UCS4. Patch attached.

----------
components: Demos and Tools
files: pybench_ucs.patch
keywords: patch
messages: 68076
nosy: pitrou
severity: normal
status: open
title: Wrong unicode size detection in pybench
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10603/pybench_ucs.patch

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

From report at bugs.python.org  Thu Jun 12 21:57:40 2008
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 12 Jun 2008 19:57:40 +0000
Subject: [New-bugs-announce] [issue3093] Namespace polution from
	multiprocessing
In-Reply-To: <1213300660.18.0.995213086332.issue3093@psf.upfronthosting.co.za>
Message-ID: <1213300660.18.0.995213086332.issue3093@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

All these in multiprocessing.h are lacking suitable py/_py/Py/_Py/PY/_PY
prefixes:

PyObject *mp_SetError(PyObject *Type, int num);
extern PyObject *pickle_dumps;
extern PyObject *pickle_loads;
extern PyObject *pickle_protocol;
extern PyObject *BufferTooShort;
extern PyTypeObject SemLockType;
extern PyTypeObject ConnectionType;
extern PyTypeObject PipeConnectionType;
extern HANDLE sigint_event;

Additionally, win32_functions.c exposes Win32Type and
create_win32_namespace.

semaphore.c has sem_timedwait_save.

multiprocessing.c has ProcessError.

----------
messages: 68078
nosy: Rhamphoryncus
severity: normal
status: open
title: Namespace polution from multiprocessing

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

From report at bugs.python.org  Thu Jun 12 22:01:24 2008
From: report at bugs.python.org (Steven Wong)
Date: Thu, 12 Jun 2008 20:01:24 +0000
Subject: [New-bugs-announce] [issue3094] By default,
	HTTPSConnection should send header "Host: somehost" instead of
	"Host: somehost:443"
In-Reply-To: <1213300884.55.0.795438603527.issue3094@psf.upfronthosting.co.za>
Message-ID: <1213300884.55.0.795438603527.issue3094@psf.upfronthosting.co.za>


New submission from Steven Wong <sliderw at hotmail.com>:

Communicating over HTTPS at the default port of 443:

import httplib
conn = httplib.HTTPSConnection("my-secure-domain.com")
conn.request("GET", "/")
res = conn.getresponse()

In the current implementation, the Host header sent in the request is:

  Host: my-secure-domain.com:443

The ":443" is unnecessary because the default port of HTTPS is 443. The
attached patch file fixes this so that the Host header sent is simply:

  Host: my-secure-domain.com

----------
components: Library (Lib)
files: httplib.py.patch
keywords: patch
messages: 68079
nosy: steven.w
severity: normal
status: open
title: By default, HTTPSConnection should send header "Host: somehost" instead of "Host: somehost:443"
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10605/httplib.py.patch

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

From report at bugs.python.org  Thu Jun 12 22:23:24 2008
From: report at bugs.python.org (Adam Olsen)
Date: Thu, 12 Jun 2008 20:23:24 +0000
Subject: [New-bugs-announce] [issue3095] multiprocessing initializes flags
	dict unsafely
In-Reply-To: <1213302204.8.0.0176767503355.issue3095@psf.upfronthosting.co.za>
Message-ID: <1213302204.8.0.0176767503355.issue3095@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

multiprocessing.c currently has code like this:

	temp = PyDict_New();
	if (!temp)
		return;
	if (PyModule_AddObject(module, "flags", temp) < 0)
		return;

PyModule_AddObject consumes the reference to temp, so it could
conceivable be deleted before the rest of this function finishes.

----------
messages: 68081
nosy: Rhamphoryncus
severity: normal
status: open
title: multiprocessing initializes flags dict unsafely
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Jun 12 23:51:48 2008
From: report at bugs.python.org (Marius Gedminas)
Date: Thu, 12 Jun 2008 21:51:48 +0000
Subject: [New-bugs-announce] [issue3096] sphinx: sort warnings by filename
In-Reply-To: <1213307508.32.0.469358901919.issue3096@psf.upfronthosting.co.za>
Message-ID: <1213307508.32.0.469358901919.issue3096@psf.upfronthosting.co.za>


New submission from Marius Gedminas <marius at gedmin.as>:

Here's a patch that makes Sphinx sort warnings about unused documents by
file name.  Without it you get them in seemingly arbitrary order, which
makes it harder to parse, when your documents are scattered in a large tree.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx-sort-warnings-by-filename.diff
keywords: patch
messages: 68097
nosy: georg.brandl, mgedmin
severity: normal
status: open
title: sphinx: sort warnings by filename
type: behavior
Added file: http://bugs.python.org/file10606/sphinx-sort-warnings-by-filename.diff

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

From report at bugs.python.org  Thu Jun 12 23:57:53 2008
From: report at bugs.python.org (Marius Gedminas)
Date: Thu, 12 Jun 2008 21:57:53 +0000
Subject: [New-bugs-announce] [issue3097] sphinx: config option for
	exclude_dirnames
In-Reply-To: <1213307873.74.0.0842689115594.issue3097@psf.upfronthosting.co.za>
Message-ID: <1213307873.74.0.0842689115594.issue3097@psf.upfronthosting.co.za>


New submission from Marius Gedminas <marius at gedmin.as>:

I'm building developer documentation for an existing project that
already had reStructuredText files scattered in the source tree. 
Unfortunately these use the same extension (.txt) as functional doctest
files, but fortunately tests live only in subdirectories named 'ftests'.
 Unfortunately, sphinx doesn't support globs in exclude_dirs or
exclude_trees, so I cannot just exclude "**/ftests".

It would help me if I could specify the exclude_dirnames option that's
currently hardcoded inside BuildEnvironment.find_files in my conf.py.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 68100
nosy: georg.brandl, mgedmin
severity: normal
status: open
title: sphinx: config option for exclude_dirnames
type: feature request

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

From report at bugs.python.org  Fri Jun 13 00:13:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 12 Jun 2008 22:13:17 +0000
Subject: [New-bugs-announce] [issue3098] sys.sizeof test fails with wide
	unicode
In-Reply-To: <1213308797.17.0.524206441717.issue3098@psf.upfronthosting.co.za>
Message-ID: <1213308797.17.0.524206441717.issue3098@psf.upfronthosting.co.za>


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

test test_sys failed -- Traceback (most recent call last):
  File "/temp/python/trunk/Lib/test/test_sys.py", line 549, in
test_specialtypes
    size2=basicsize + sys.getsizeof(str(s)))
  File "/temp/python/trunk/Lib/test/test_sys.py", line 429, in check_sizeof
    self.assertEqual(result, size2, msg + str(size2))
AssertionError: wrong size for <type 'unicode'>: got 28, expected
50.5109328552

----------
assignee: schuppenies
components: Interpreter Core
messages: 68102
nosy: benjamin.peterson, schuppenies
priority: critical
severity: normal
status: open
title: sys.sizeof test fails with wide unicode
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun 13 03:18:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 13 Jun 2008 01:18:48 +0000
Subject: [New-bugs-announce] [issue3099] On windows,
	"import nul" always succeed
In-Reply-To: <1213319928.58.0.193615390811.issue3099@psf.upfronthosting.co.za>
Message-ID: <1213319928.58.0.193615390811.issue3099@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

on Windows, the stat() function always returns True for some special
device names (nul, con, com1, lpt1...), even when followed by an extension.

Thus "import con" manages to find that "con.py" exists, and tries to
read from it... fun.

A solution is to use GetFileAttributes() instead.

Note that on python2.5.2, the error message suggest that we have such a
problem, but fortunately the error is still an ImportError::
  >>> import nul
  ImportError: DLL load failed: Le module sp?cifi? est introuvable.

----------
components: Windows
messages: 68115
nosy: amaury.forgeotdarc, ocean-city
severity: normal
status: open
title: On windows, "import nul" always succeed
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun 13 05:20:00 2008
From: report at bugs.python.org (Adam Olsen)
Date: Fri, 13 Jun 2008 03:20:00 +0000
Subject: [New-bugs-announce] [issue3100] segfault after loading
	multiprocessing.reduction
In-Reply-To: <1213327200.12.0.747745402104.issue3100@psf.upfronthosting.co.za>
Message-ID: <1213327200.12.0.747745402104.issue3100@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

$ ./python 
Python 2.6a3+ (unknown, Jun 12 2008, 20:10:55) 
[GCC 4.2.3 (Debian 4.2.3-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing.reduction
[55604 refs]
>>> 
[55604 refs]
Segmentation fault (core dumped)

----------
components: Extension Modules
messages: 68120
nosy: Rhamphoryncus
severity: normal
status: open
title: segfault after loading multiprocessing.reduction
type: crash
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun 13 09:30:20 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 13 Jun 2008 07:30:20 +0000
Subject: [New-bugs-announce] [issue3101] global function _add_one_to_C
In-Reply-To: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za>
Message-ID: <1213342220.87.0.7161073703.issue3101@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

abstract.c defines two functions _add_one_to_C and _add_one_to_F. These
apparently must be global, as memoryobject.c references them. Therefore,
they should get a Py or _Py prefix.

A short comment for what these functions actually do would also be
appreciated.

----------
assignee: teoliphant
messages: 68133
nosy: loewis, teoliphant
severity: normal
status: open
title: global function _add_one_to_C
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun 13 09:54:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 13 Jun 2008 07:54:54 +0000
Subject: [New-bugs-announce] [issue3102] ctypes defines global symbols
In-Reply-To: <1213343694.16.0.290726791228.issue3102@psf.upfronthosting.co.za>
Message-ID: <1213343694.16.0.290726791228.issue3102@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

ctypes defines a number of global symbols which aren't
namespace-prefixed, such as AllocFunctionCallback, FreeClosure, GetType,
IsSimpleSubType, MallocClosure, _AddTraceback, _CallProc,
alloc_format_string, conversion_mode_encoding, conversion_mode_errors,
get_error_object, getentry, module_methods (there are more, but the
other ones can be understood as being unambiguously prefixed, such as
with CData, CField, StgDict).

It would be good if these symbols either are changed to static, or get a
proper Py/_Py prefix.

----------
assignee: theller
messages: 68135
nosy: loewis, theller
severity: normal
status: open
title: ctypes defines global symbols

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

From report at bugs.python.org  Fri Jun 13 10:00:46 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 13 Jun 2008 08:00:46 +0000
Subject: [New-bugs-announce] [issue3103] sqlite defines a few global symbols.
In-Reply-To: <1213344046.17.0.166963020016.issue3103@psf.upfronthosting.co.za>
Message-ID: <1213344046.17.0.166963020016.issue3103@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

While most global symbols in the _sqlite3 module use a sqlite_ or
_sqlite_ prefix, some don't:
_enable_callback_tracebacks, converters, microprotocols_adapt,
microprotocols_add, psyco_adapters, psyco_microprotocols_adapt.

It would be good if these could be made static, or get their own prefix.

----------
assignee: ghaering
messages: 68137
nosy: ghaering, loewis
severity: normal
status: open
title: sqlite defines a few global symbols.

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

From report at bugs.python.org  Fri Jun 13 11:23:38 2008
From: report at bugs.python.org (GreaseMonkey)
Date: Fri, 13 Jun 2008 09:23:38 +0000
Subject: [New-bugs-announce] [issue3104] overzealous garbage collector (dict)
In-Reply-To: <1213349018.67.0.856453652888.issue3104@psf.upfronthosting.co.za>
Message-ID: <1213349018.67.0.856453652888.issue3104@psf.upfronthosting.co.za>


New submission from GreaseMonkey <thematrixeatsyou at yahoo.co.nz>:

When filled with a massive database (>16MB, i'm not sure how large it's
meant to be), the dict object appears to mysteriously drop objects off
the face of the earth (in this case list objects). Wouldn't it be more
appropriate to splurt out a memory error rather than fail silently only
to screw up in another way?

----------
components: Interpreter Core
messages: 68142
nosy: GreaseMonkey
severity: normal
status: open
title: overzealous garbage collector (dict)
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun 13 19:40:47 2008
From: report at bugs.python.org (Mark English)
Date: Fri, 13 Jun 2008 17:40:47 +0000
Subject: [New-bugs-announce] [issue3105] Python 2.5.2 Windows Source
	Distribution missing Visual Studio 2005 ssl build files
In-Reply-To: <1213378847.48.0.141429051265.issue3105@psf.upfronthosting.co.za>
Message-ID: <1213378847.48.0.141429051265.issue3105@psf.upfronthosting.co.za>


New submission from Mark English <markenglish at freenet.co.uk>:

*Problem*
The directory structure of PCBuild8 differs from PCBuild in that each
project has its own subdirectory.
There is no subdirectory for _ssl, and the files that would belong in it
are also omitted.

*Solution*
The attached files, based on those included with the Python 2.5.2
PCBuild release for windows in the svn Python25 maintenance trunk
(http://svn.python.org/projects/python/branches/release25-maint/PCbuild/),
should be placed in a new directory PCBuild8\_ssl.
Once added to the parent solution file pcbuild.sln, the _ssl project
will simply build if the normal instructions have been followed.

*Changes*
Since this is a change in location, both _ssl.mak and build_ssl.py have
been altered to reflect the extra level of nesting.
As a result, the #pragma comment(lib, "Python25") in pyconfig.h did not
work. In order to add the appropriate directory to the LIB path in
_ssl.mak, build_py.py now takes an additional (second) command line
parameter derived from visual studio's $(PlatformName). This is used to
define an variable PLATFORM_NAME passed to _ssl.mak which is used to
deduce the directory containing python25.lib. The accompanying
_ssl.vcproj has been migrated from the Visual Studio 2003 vcproj file in
PCBuild, and passes the additional $(PlatformName) parameter.
_ssl.mak has also been adjusted to output a .pdb file and keep the root
_ssl directory clean, copying existing behaviour for all the other projects.
This has resulted in some ugly usage of special path splitting NMAKE
syntax (grep for %|fF.obj) which doesn't work with the @<< syntax. As a
result the link stage has been split across several lines. Someone with
a better knowledge of makefiles in general and NMAKE in particular can
probably improve on this, but it does work, and is otherwise legible.

Note that this sub-directory file structure is new in this release, and
that the Python3k trunk seems to be reverting to the flat file structure.
These additions are still helpful since they should just work out of the
box, and allow people using the current recommended build of Python
(2.5.2) to compile the ssl and hashlib modules.

*Additional Details*
Built on Windows XP SP2 with MSVS2005 SP1. Details appended to this message.
Built against openssl-0.9.8h, which is later than the standard Python25
distribution.
Note that the assembly file based build of openssl-0.9.8h, which is
triggered by build_ssl.py, currently has a small bug. See
http://www.mail-archive.com/openssl-dev at openssl.org/msg24059.html
This is easily fixed by the following one line change to
openssl-0.9.8h\crypto\perlasm\x86ms.pl
"In this file, the line 273 containing "$extra" should be removed to be
able to compile the generated assembly files."
If an openssl build has been attempted prior to this step, delete all
out32 and tmp32 directories under openssl-0.9.8h

*Code and Patch*
Attached is a zip file containing the altered files, and a patch
generated using cygwin's diff run with the command line -uarN.
The patch can be applied by:
cd PCBuild8
mkdir _ssl
cd _ssl
patch -u -p1 < [wherever_the_patch_file_is_downloaded_to]\_ssl.patch

*Tested*
Compiles and imports fine with Release and Debug builds. Other builds
(AMD, Itanium) untested.

*Build Details*
Compiled against openssl-0.9.8h

Microsoft Visual Studio 2005
Version 8.0.50727.762  (SP.050727-7600)
Microsoft .NET Framework
Version 2.0.50727 SP1

Installed Edition: Professional
Microsoft Visual C++ 2005   77626-009-0000007-41042
Microsoft Visual C++ 2005
Microsoft Visual Studio 2005 Professional Edition - ENU Service Pack 1
(KB926601)

----------
components: Build, Windows
files: Python252-PCBuild8-_ssl.zip
messages: 68172
nosy: MarkE
severity: normal
status: open
title: Python 2.5.2 Windows Source Distribution missing Visual Studio 2005 ssl build files
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file10621/Python252-PCBuild8-_ssl.zip

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

From report at bugs.python.org  Fri Jun 13 20:38:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jun 2008 18:38:04 +0000
Subject: [New-bugs-announce] [issue3106] speedup some comparisons
In-Reply-To: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za>
Message-ID: <1213382283.81.0.00112227094469.issue3106@psf.upfronthosting.co.za>


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

This patch is an experiment in making faster some of the most common
comparisons (str vs. str, int vs. int). I don't know if it may bring
noticeable speedups in real-world situations, but here are the synthetic
benchmark numbers (from pybench, "this" is the patched version and
"other" is vanilla py3k):

Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other 
 diff
-------------------------------------------------------------------------------
                 CompareFloats:   182ms   173ms   +5.4%   182ms   176ms
  +3.4%
         CompareFloatsIntegers:   238ms   232ms   +2.3%   242ms   236ms
  +2.5%
               CompareIntegers:   237ms   277ms  -14.4%   237ms   280ms
 -15.2%
        CompareInternedStrings:   163ms   257ms  -36.7%   163ms   258ms
 -36.7%
                  CompareLongs:   137ms   160ms  -14.5%   137ms   162ms
 -15.6%
                CompareStrings:   149ms   170ms  -12.1%   154ms   170ms
  -9.5%
-------------------------------------------------------------------------------
Totals:                          1105ms  1268ms  -12.9%  1115ms  1281ms
 -13.0%

----------
components: Interpreter Core
files: cpms.patch
keywords: patch
messages: 68174
nosy: pitrou
severity: normal
status: open
title: speedup some comparisons
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file10622/cpms.patch

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

From report at bugs.python.org  Sat Jun 14 00:59:27 2008
From: report at bugs.python.org (Tony Wallace)
Date: Fri, 13 Jun 2008 22:59:27 +0000
Subject: [New-bugs-announce] [issue3107] memory leak in make test (in "test
	list"), 2.5.2 not 2.5.1, Linux 64bit
In-Reply-To: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>
Message-ID: <1213397967.45.0.45678659954.issue3107@psf.upfronthosting.co.za>


New submission from Tony Wallace <hushp1pt at yahoo.com>:

[tony at gossamer Python-2.5.1]$ ./configure
--prefix=/home/tony/root/usr/local/python-2.5.2 --enable-shared
--enable-static

[tony at gossamer bin]$ file python
python: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
[tony at gossamer bin]$  uname -a
Linux gossamer.ambric.local 2.4.21-40.ELsmp #1 SMP Wed Mar 15 13:46:01
EST 2006 x86_64 x86_64 x86_64 GNU/Linux
[tony at gossamer bin]$ cat /etc/redhat-release
CentOS release 3.6 (Final)

----------
components: Demos and Tools
messages: 68188
nosy: hushp1pt
severity: normal
status: open
title: memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit
type: resource usage
versions: Python 2.5

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

From report at bugs.python.org  Sat Jun 14 01:02:34 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Jun 2008 23:02:34 +0000
Subject: [New-bugs-announce] [issue3108] Implicit exception chaining (PEP
	3134)
In-Reply-To: <1213398154.56.0.602313713782.issue3108@psf.upfronthosting.co.za>
Message-ID: <1213398154.56.0.602313713782.issue3108@psf.upfronthosting.co.za>


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

This patch implements implicit except chaining (__context__) as per PEP
3134, or not quite. The difference is that PyErr_Set* functions do set
the __context__ attribute, otherwise I think it would make an annoying
discrepancy between exceptions generated by Python modules and
exceptions generated by C modules (especially when some parts are
written in C and others in Python, e.g. the io library).

Unimplemented are the modifications in exception reporting.

----------
components: Interpreter Core
files: context.patch
keywords: patch
messages: 68189
nosy: pitrou
severity: normal
status: open
title: Implicit exception chaining (PEP 3134)
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10626/context.patch

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

From report at bugs.python.org  Sat Jun 14 02:07:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Jun 2008 00:07:55 +0000
Subject: [New-bugs-announce] [issue3109] test_multiprocessing seems fragile
In-Reply-To: <1213402075.28.0.267049888199.issue3109@psf.upfronthosting.co.za>
Message-ID: <1213402075.28.0.267049888199.issue3109@psf.upfronthosting.co.za>


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

I had the following intermittent failure under py3k:

[...]
test_multiprocessing
Process Process-24:
Traceback (most recent call last):
  File "/home/antoine/py3k/context/Lib/multiprocessing/process.py", line
237, in _bootstrap
    self.run()
  File "/home/antoine/py3k/context/Lib/multiprocessing/process.py", line
93, in run
    self._target(*self._args, **self._kwargs)
  File "/home/antoine/py3k/context/Lib/test/test_multiprocessing.py",
line 1390, in _remote
    client.connect(address)
socket.error: [Errno 111] Connection refused

----------
components: Library (Lib), Tests
messages: 68194
nosy: pitrou
severity: normal
status: open
title: test_multiprocessing seems fragile
versions: Python 3.0

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

From report at bugs.python.org  Sat Jun 14 21:36:17 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 14 Jun 2008 19:36:17 +0000
Subject: [New-bugs-announce] [issue3110] Multiprocessing package build
	problem on Solaris 10
In-Reply-To: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>
Message-ID: <1213472177.07.0.795399068376.issue3110@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

Per skip's email:
FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does 
define
_SEM_VALUE_MAX in sys/params.h.

   .../Modules/_multiprocessing/multiprocessing.c: In function 
'init_multiprocessing':
   .../Modules/_multiprocessing/multiprocessing.c:253: error: 
'SEM_VALUE_MAX' undeclared (first use in this function)
   .../Modules/_multiprocessing/multiprocessing.c:253: error: (Each 
undeclared identifier is reported only once
   .../Modules/_multiprocessing/multiprocessing.c:253: error: for each 
function it appears in.)

On Windows the author simple #defines SEM_VALUE_MAX to be LONG_MAX.  I 
used
a little cpp action to define it:

   #ifndef SEM_VALUE_MAX
   #  ifdef _SEM_VALUE_MAX
   #    define SEM_VALUE_MAX _SEM_VALUE_MAX
   #  else
   #    define SEM_VALUE_MAX INT_MAX
   #  endif
   #endif

----------
components: Extension Modules
messages: 68210
nosy: jnoller, roudkerk, skip.montanaro
severity: normal
status: open
title: Multiprocessing package build problem on Solaris 10
type: compile error
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sat Jun 14 21:46:48 2008
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 14 Jun 2008 19:46:48 +0000
Subject: [New-bugs-announce] [issue3111] multiprocessing pkg Debian
	compilation error
In-Reply-To: <1213472808.51.0.731079646072.issue3111@psf.upfronthosting.co.za>
Message-ID: <1213472808.51.0.731079646072.issue3111@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

Both debian ia64 and PPC are failing the mp test suite with the 
following error:

Re-running test 'test_multiprocessing' in verbose mode
test test_multiprocessing crashed -- <type 'exceptions.OSError'>: [Errno 
38] Function not implemented
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 554, in runtest_inner
    indirect_test()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/test/test_multiprocessing.py", line 1764, in test_main
    ProcessesMixin.pool = multiprocessing.Pool(4)
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/__init__.py", line 226, in Pool
    return Pool(processes, initializer, initargs)
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/pool.py", line 84, in __init__
    self._setup_queues()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/pool.py", line 131, in _setup_queues
    self._inqueue = SimpleQueue()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/queues.py", line 315, in __init__
    self._rlock = Lock()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/synchronize.py", line 106, in __init__
    SemLock.__init__(self, SEMAPHORE, 1, 1)
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/synchronize.py", line 38, in __init__
    sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
OSError: [Errno 38] Function not implemented
[674193 refs]
make: *** [buildbottest] Error 1
program finished with exit code 2

Buildbots:
http://www.python.org/dev/buildbot/stable/ppc%20Debian%20unstable%20trun
k/builds/1607/step-test/0
http://www.python.org/dev/buildbot/stable/ia64%20Ubuntu%20trunk/builds/1
89/step-test/0

----------
components: Extension Modules
messages: 68211
nosy: jnoller, roudkerk
severity: normal
status: open
title: multiprocessing pkg Debian compilation error
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sat Jun 14 22:30:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 Jun 2008 20:30:46 +0000
Subject: [New-bugs-announce] [issue3112] implement PEP 3134 exception
	reporting
In-Reply-To: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>
Message-ID: <1213475446.58.0.529901834278.issue3112@psf.upfronthosting.co.za>


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

Traceback reporting needs to be altered to support exception chaining as
per PEP 3134.

----------
components: Interpreter Core
messages: 68214
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: implement PEP 3134 exception reporting
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 14 22:31:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 Jun 2008 20:31:53 +0000
Subject: [New-bugs-announce] [issue3113] Document exception chaining
In-Reply-To: <1213475513.28.0.247169838861.issue3113@psf.upfronthosting.co.za>
Message-ID: <1213475513.28.0.247169838861.issue3113@psf.upfronthosting.co.za>


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

PEP 3134's features need to be documented.

----------
assignee: georg.brandl
components: Documentation
messages: 68215
nosy: benjamin.peterson, georg.brandl
priority: high
severity: normal
status: open
title: Document exception chaining
versions: Python 3.0

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

From report at bugs.python.org  Sat Jun 14 22:55:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 Jun 2008 20:55:14 +0000
Subject: [New-bugs-announce] [issue3114] bus error on lib2to3
In-Reply-To: <1213476914.28.0.330233447903.issue3114@psf.upfronthosting.co.za>
Message-ID: <1213476914.28.0.330233447903.issue3114@psf.upfronthosting.co.za>


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

I was just merging 2to3 work (and you'll have to do svnmerge.py merge in
Lib/lib2to3 for this to work) into py3k and was running the tests when
this rather alarming thing happended:

$ ./python.exe Lib/test/regrtest.py test_lib2to3
...
test test_lib2to3 crashed -- <class 'UnboundLocalError'>: local variable
'result' referenced before assignment
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 601, in runtest_inner
Bus error

Thinking this had something to do with r64281, I reverted it and got:
test test_lib2to3 crashed -- <class 'UnboundLocalError'>: local variable
'result' referenced before assignment
Fatal Python error: GC object already tracked
Abort trap

This probably isn't a lib2to3 problem, but that's how I got it.

----------
components: Interpreter Core
messages: 68218
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: bus error on lib2to3
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun 15 00:42:58 2008
From: report at bugs.python.org (philipspencer)
Date: Sat, 14 Jun 2008 22:42:58 +0000
Subject: [New-bugs-announce] [issue3115] os.listdir randomly fails on
	occasions when it shouldn't
In-Reply-To: <1213483378.87.0.0889155831871.issue3115@psf.upfronthosting.co.za>
Message-ID: <1213483378.87.0.0889155831871.issue3115@psf.upfronthosting.co.za>


New submission from philipspencer <pspencer at fields.utoronto.ca>:

Python's os.listdir function has the following code in
Modules/posixmodule.c:

   errno = 0
   ...
    for (;;) {
         Py_BEGIN_ALLOW_THREADS
         ep = readdir(dirp);
         Py_END_ALLOW_THREADS
         if (ep == NULL)
              break;
         ...
         a bunch of other stuff, including PyString_FromStringAndSize
         which calls malloc
         ...
    }
    if (errno != 0 && d != NULL) {

The assumption is that errno will be nonzero only if readdir failed.
However, this is not the case. GLibc's malloc will, in some rare cases,
set errno even when it succeeds. So, during one pass through the loop
errno gets set to ENOMEM and then it is still set to ENOMEM when the
final readdir returns null at the end of the directory listing.

The fix is to move the line "errno = 0" from outside the loop to
right before the readdir inside the loop. That is the only way to
ensure that, when the loop is exited with readdir returning null,
the condition "errno != 0" is equivalent to "readdir actually failed."

The attached patch does this. Without this patch, we experience
frequent failures with the python tools "creatrepo" and "repomanage"
when run on very large directories (> 5000 packages) on Fedora 8
systems; see RedHat bugzilla entry #451494. With the patch, the commands
work as expected.

The patch is against 2.5.1 but from what I can see of the posixmodule.c
code from SVN it should apply cleanly there too.

----------
components: Extension Modules
messages: 68223
nosy: philipspencer
severity: normal
status: open
title: os.listdir randomly fails on occasions when it shouldn't
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 15 12:29:14 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Jun 2008 10:29:14 +0000
Subject: [New-bugs-announce] [issue3116] Fix quadratic behavior for
	marshal.dumps() when len>32Mb
In-Reply-To: <1213525754.0.0.788265280234.issue3116@psf.upfronthosting.co.za>
Message-ID: <1213525754.0.0.788265280234.issue3116@psf.upfronthosting.co.za>


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

Martin, can you give this a second review?

See original discussion at:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/ac8
f121c5d043198#

Patch replaces constant size over-allocation with the amortized linear 
growth strategy used for list.append(), matching its 12.5% over-
allocation rate.

----------
assignee: loewis
files: marshal.diff
keywords: patch, patch
messages: 68230
nosy: loewis, rhettinger
priority: high
severity: normal
status: open
title: Fix quadratic behavior for marshal.dumps() when len>32Mb
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file10631/marshal.diff

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

From report at bugs.python.org  Sun Jun 15 21:39:22 2008
From: report at bugs.python.org (Enrico Santoemma)
Date: Sun, 15 Jun 2008 19:39:22 +0000
Subject: [New-bugs-announce] [issue3117] segfault with (None,
	) as argument in a def/lambda
In-Reply-To: <1213558762.43.0.0830924414202.issue3117@psf.upfronthosting.co.za>
Message-ID: <1213558762.43.0.0830924414202.issue3117@psf.upfronthosting.co.za>


New submission from Enrico Santoemma <enrico.santoemma at gmail.com>:

This wrong expression
>>> lambda (None,):None
and this statement
>>> def f( (None,) ): pass
crash the interpreter.

Python 2.5.1 (r251:54863, Mar  7 2008, 03:41:45)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> lambda (None,):None
Segmentation fault (core dumped)

Not in 2.4:
Python 2.4.4 (#2, Apr 12 2007, 21:03:11)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> lambda (None,):None
  File "<stdin>", line 1
SyntaxError: assignment to None
>>>

----------
messages: 68245
nosy: santoemma
severity: normal
status: open
title: segfault with (None,) as argument in a def/lambda
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun 16 04:39:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 16 Jun 2008 02:39:26 +0000
Subject: [New-bugs-announce] [issue3118] test_math fails on 64bit
In-Reply-To: <1213583966.69.0.618889033517.issue3118@psf.upfronthosting.co.za>
Message-ID: <1213583966.69.0.618889033517.issue3118@psf.upfronthosting.co.za>


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

Re-running failed tests in verbose mode
Re-running test 'test_math' in verbose mode
testAcos (test.test_math.MathTests) ... ok
testAcosh (test.test_math.MathTests) ... ok
testAsin (test.test_math.MathTests) ... ok
testAsinh (test.test_math.MathTests) ... ok
testAtan (test.test_math.MathTests) ... ok
testAtan2 (test.test_math.MathTests) ... ok
testAtanh (test.test_math.MathTests) ... ok
testCeil (test.test_math.MathTests) ... ok
testConstants (test.test_math.MathTests) ... ok
testCopysign (test.test_math.MathTests) ... ok
testCos (test.test_math.MathTests) ... ok
testCosh (test.test_math.MathTests) ... ok
testDegrees (test.test_math.MathTests) ... ok
testExp (test.test_math.MathTests) ... ok
testFabs (test.test_math.MathTests) ... ok
testFactorial (test.test_math.MathTests) ... ok
testFloor (test.test_math.MathTests) ... ok
testFmod (test.test_math.MathTests) ... ok
testFrexp (test.test_math.MathTests) ... ok
testHypot (test.test_math.MathTests) ... ok
testIsinf (test.test_math.MathTests) ... ok
testIsnan (test.test_math.MathTests) ... ok
testLdexp (test.test_math.MathTests) ... ok
testLog (test.test_math.MathTests) ... ok
testLog10 (test.test_math.MathTests) ... ok
testLog1p (test.test_math.MathTests) ... ok
testModf (test.test_math.MathTests) ... ok
testPow (test.test_math.MathTests) ... ok
testRadians (test.test_math.MathTests) ... ok
testSin (test.test_math.MathTests) ... ok
testSinh (test.test_math.MathTests) ... ok
testSqrt (test.test_math.MathTests) ... ok
testSum (test.test_math.MathTests) ... ok
testTan (test.test_math.MathTests) ... ok
testTanh (test.test_math.MathTests) ... ok
test_exceptions (test.test_math.MathTests) ... ok
test_testfile (test.test_math.MathTests) ... FAIL
test_trunc (test.test_math.MathTests) ... ok
Doctest: ieee754.txt ... ok

======================================================================
FAIL: test_testfile (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_math.py",
line 939, in test_testfile
    self.fail(message)
AssertionError: Unexpected OverflowError in test exp0042:exp(-745.0)


----------------------------------------------------------------------
Ran 39 tests in 46.087s

FAILED (failures=1)
test test_math failed -- Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_math.py",
line 939, in test_testfile
    self.fail(message)
AssertionError: Unexpected OverflowError in test exp0042:exp(-745.0)

----------
components: Library (Lib), Tests
keywords: 64bit
messages: 68257
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: test_math fails on 64bit
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Jun 16 06:06:25 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Mon, 16 Jun 2008 04:06:25 +0000
Subject: [New-bugs-announce] [issue3119] pickle.py is limited by python's
	call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>


New submission from Aaron Gallagher <habnabit at gmail.com>:

Currently, pickle.py in the stdlib is limited by the python call stack. 
For deeply recursive data structures, the default recursion limit of 1000 
is not enough. The patch attached modifies pickle.py to instead use a 
deque object as a call stack. Pickler.save and other methods that increase 
the recursion depth are now generators which may yield either another 
generator or None, where yielding a generator adds it to the call stack.

----------
components: Library (Lib)
files: pickle.patch
keywords: patch
messages: 68262
nosy: habnabit
severity: normal
status: open
title: pickle.py is limited by python's call stack
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10638/pickle.patch

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

From report at bugs.python.org  Mon Jun 16 06:36:01 2008
From: report at bugs.python.org (Roger Upole)
Date: Mon, 16 Jun 2008 04:36:01 +0000
Subject: [New-bugs-announce] [issue3120] subprocess module truncates handles
	on AMD64
In-Reply-To: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>
Message-ID: <1213590960.84.0.798719611709.issue3120@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

HANDLEs are pointer sized values, but there are several places in
_subprocess.c where it assumes they are the same size as longs
which are still 4 bytes on win64.

----------
components: Windows
messages: 68263
nosy: rupole
severity: normal
status: open
title: subprocess module truncates handles on AMD64
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Jun 16 10:32:09 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 16 Jun 2008 08:32:09 +0000
Subject: [New-bugs-announce] [issue3121] test_urllibnet fails
In-Reply-To: <1213605129.04.0.398853048978.issue3121@psf.upfronthosting.co.za>
Message-ID: <1213605129.04.0.398853048978.issue3121@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

This is on Linux with latest py3k branch:

test test_urllibnet failed -- Traceback (most recent call last):
  File "/home/cartman/Sources/py3k/Lib/test/test_urllibnet.py", line
145, in test_bad_address
    urllib.urlopen, "http://www.python.invalid./")
AssertionError: IOError not raised by urlopen

----------
components: Tests
messages: 68264
nosy: cartman
severity: normal
status: open
title: test_urllibnet fails
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun 16 12:51:27 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Mon, 16 Jun 2008 10:51:27 +0000
Subject: [New-bugs-announce] [issue3122] sys.getsizeof() gives an
	AttributeError for _sre objects.
In-Reply-To: <1213613487.11.0.64218401652.issue3122@psf.upfronthosting.co.za>
Message-ID: <1213613487.11.0.64218401652.issue3122@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <okkotonushi at googlemail.com>:

>>> import re
>>> import sys
>>> r = re.compile('')
>>> sys.getsizeof(r)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __sizeof__

This applies to objects of the types _sre.SRE_Pattern,
_sre.SRE_Scanner, and _sre.SRE_Match.

The attached patch addresses this issue.

----------
assignee: schuppenies
components: Interpreter Core
files: _sre_sizeof.patch
keywords: patch, patch
messages: 68266
nosy: schuppenies
severity: normal
status: open
title: sys.getsizeof() gives an AttributeError for _sre objects.
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10639/_sre_sizeof.patch

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

From report at bugs.python.org  Mon Jun 16 15:50:42 2008
From: report at bugs.python.org (djc)
Date: Mon, 16 Jun 2008 13:50:42 +0000
Subject: [New-bugs-announce] [issue3123] 2to3 fails
In-Reply-To: <1213624242.61.0.802384871781.issue3123@psf.upfronthosting.co.za>
Message-ID: <1213624242.61.0.802384871781.issue3123@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

2to3 fails in recent CPython trunk. This is because lib2to3 got some
merges, but the 2to3 script wasn't updated to match.
lib2to3.refactor.main() now requires a first argument which isn't given
by the 2to3 script.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 68267
nosy: benjamin.peterson, collinwinter, djc
severity: normal
status: open
title: 2to3 fails
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Jun 16 19:25:47 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 16 Jun 2008 17:25:47 +0000
Subject: [New-bugs-announce] [issue3124] test_multiprocessing segfaults on
	Windows
In-Reply-To: <1213637147.58.0.717278933359.issue3124@psf.upfronthosting.co.za>
Message-ID: <1213637147.58.0.717278933359.issue3124@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

When Python shuts down after running test_multiprocessing on Windows, a
segfault occurs (this is with a debug build from trunk):

>	python26_d.dll!_Py_ForgetReference(_object * op=0x012de740)  Line 2023
+ 0xf bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x012de740)  Line 2043 + 0x9
bytes	C
 	python26_d.dll!tupledealloc(PyTupleObject * op=0x00d58c78)  Line 169 +
0x8a bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x00d58c78)  Line 2044 + 0x7
bytes	C
 	python26_d.dll!PyObject_CallFunctionObjArgs(_object *
callable=0x00d64090, ...)  Line 2716 + 0x51 bytes	C
 	python26_d.dll!handle_callback(_PyWeakReference * ref=0x012de740,
_object * callback=0x00d64090)  Line 864 + 0xf bytes	C
 	python26_d.dll!PyObject_ClearWeakRefs(_object * object=0x012bcc98) 
Line 910 + 0xd bytes	C
 	python26_d.dll!func_dealloc(PyFunctionObject * op=0x012bcc98)  Line
453 + 0x9 bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x012bcc98)  Line 2044 + 0x7
bytes	C
 	python26_d.dll!tupledealloc(PyTupleObject * op=0x012ddeb8)  Line 169 +
0x8a bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x012ddeb8)  Line 2044 + 0x7
bytes	C
 	python26_d.dll!clear_slots(_typeobject * type=0x00cbbac8, _object *
self=0x012de740)  Line 821 + 0x51 bytes	C
 	python26_d.dll!subtype_dealloc(_object * self=0x012de740)  Line 950
+ 0xd bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x012de740)  Line 2044 + 0x7
bytes	C
 	python26_d.dll!dict_dealloc(_dictobject * mp=0x00d538c0)  Line 907 +
0x6c bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x00d538c0)  Line 2044 + 0x7
bytes	C
 	python26_d.dll!dict_dealloc(_dictobject * mp=0x00d536c8)  Line 907 +
0x6c bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x00d536c8)  Line 2044 + 0x7
bytes	C
 	python26_d.dll!instance_dealloc(PyInstanceObject * inst=0x00d60bf8) 
Line 668 + 0x6c bytes	C
 	python26_d.dll!_Py_Dealloc(_object * op=0x00d60bf8)  Line 2044 + 0x7
bytes	C
 	python26_d.dll!insertdict(_dictobject * mp=0x00d53620, _object *
key=0x00d5c9b8, long hash=-1896994012, _object * value=0x1e2bb004)  Line
455 + 0x51 bytes	C
 	python26_d.dll!PyDict_SetItem(_object * op=0x00d53620, _object *
key=0x00d5c9b8, _object * value=0x1e2bb004)  Line 697 + 0x15 bytes	C
 	python26_d.dll!_PyModule_Clear(_object * m=0x00d63968)  Line 125 +
0x12 bytes	C
 	python26_d.dll!PyImport_Cleanup()  Line 479 + 0x9 bytes	C
 	python26_d.dll!Py_Finalize()  Line 452	C
 	python26_d.dll!Py_Exit(int sts=0)  Line 1690	C
 	python26_d.dll!handle_system_exit()  Line 1111 + 0x9 bytes	C
 	python26_d.dll!PyErr_PrintEx(int set_sys_last_vars=1)  Line 1123	C
 	python26_d.dll!PyErr_Print()  Line 1030 + 0x7 bytes	C
 	python26_d.dll!PyRun_SimpleFileExFlags(_iobuf * fp=0x10311448, const
char * filename=0x009d5d93, int closeit=1, PyCompilerFlags *
flags=0x0022ff30)  Line 931	C
 	python26_d.dll!PyRun_AnyFileExFlags(_iobuf * fp=0x10311448, const char
* filename=0x009d5d93, int closeit=1, PyCompilerFlags *
flags=0x0022ff30)  Line 731 + 0x15 bytes	C
 	python26_d.dll!Py_Main(int argc=5, char * * argv=0x009d5d68)  Line 600
+ 0x39 bytes	C
 	python_d.exe!main(int argc=5, char * * argv=0x009d5d68)  Line 23 +
0xe bytes	C
 	python_d.exe!__tmainCRTStartup()  Line 582 + 0x19 bytes	C
 	python_d.exe!mainCRTStartup()  Line 399	C

----------
messages: 68274
nosy: theller
severity: normal
status: open
title: test_multiprocessing segfaults on Windows
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 16 19:31:37 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 16 Jun 2008 17:31:37 +0000
Subject: [New-bugs-announce] [issue3125] test_multiprocessing causes
	test_ctypes to fail
In-Reply-To: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>
Message-ID: <1213637497.57.0.0550109069119.issue3125@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

test_ctypes, when run after testmultiprocessing, fails:

...
======================================================================
ERROR: test_simple (ctypes.test.test_pickling.PickleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 29, in
test_simple
    dst = self.loads(self.dumps(src))
  File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 19, in dumps
    return pickle.dumps(item)
  File "c:\svn\trunk\lib\pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "c:\svn\trunk\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "c:\svn\trunk\lib\pickle.py", line 301, in save
    rv = reduce(obj)
  File "c:\svn\trunk\lib\multiprocessing\sharedctypes.py", line 121, in
reduce_ctype
    assert_spawning(obj)
  File "c:\svn\trunk\lib\multiprocessing\forking.py", line 25, in
assert_spawning
    ' through inheritance' % type(self).__name__
RuntimeError: c_long objects should only be shared between processes
through inheritance

======================================================================
ERROR: test_simple (ctypes.test.test_pickling.PickleTest_1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 29, in
test_simple
    dst = self.loads(self.dumps(src))
  File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 71, in dumps
    return pickle.dumps(item, 1)
  File "c:\svn\trunk\lib\pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "c:\svn\trunk\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "c:\svn\trunk\lib\pickle.py", line 301, in save
    rv = reduce(obj)
  File "c:\svn\trunk\lib\multiprocessing\sharedctypes.py", line 121, in
reduce_ctype
    assert_spawning(obj)
  File "c:\svn\trunk\lib\multiprocessing\forking.py", line 25, in
assert_spawning
    ' through inheritance' % type(self).__name__
RuntimeError: c_long objects should only be shared between processes
through inheritance

======================================================================
ERROR: test_simple (ctypes.test.test_pickling.PickleTest_2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 29, in
test_simple
    dst = self.loads(self.dumps(src))
  File "c:\svn\trunk\lib\ctypes\test\test_pickling.py", line 75, in dumps
    return pickle.dumps(item, 2)
  File "c:\svn\trunk\lib\pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "c:\svn\trunk\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "c:\svn\trunk\lib\pickle.py", line 301, in save
    rv = reduce(obj)
  File "c:\svn\trunk\lib\multiprocessing\sharedctypes.py", line 121, in
reduce_ctype
    assert_spawning(obj)
  File "c:\svn\trunk\lib\multiprocessing\forking.py", line 25, in
assert_spawning
    ' through inheritance' % type(self).__name__
RuntimeError: c_long objects should only be shared between processes
through inheritance

----------------------------------------------------------------------

----------
messages: 68276
nosy: theller
severity: normal
status: open
title: test_multiprocessing causes test_ctypes to fail
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 17 00:54:06 2008
From: report at bugs.python.org (Bob Farrell)
Date: Mon, 16 Jun 2008 22:54:06 +0000
Subject: [New-bugs-announce] [issue3126] Lib/logging/__init__.py assumes its
	stream has flush and close methods
In-Reply-To: <1213656846.24.0.635505391372.issue3126@psf.upfronthosting.co.za>
Message-ID: <1213656846.24.0.635505391372.issue3126@psf.upfronthosting.co.za>


New submission from Bob Farrell <robertanthonyfarrell at gmail.com>:

The documentation for the sys module says:
"stdout and stderr needn't be built-in file objects: any object is 
acceptable as long as it has a write() method that takes a string 
argument."

However, the logging module calls flush() and close() on 
StreamHandler.stream (and stream may be stdout), yet stdout does not 
apparently need to have these methods - this caused breakage for a 
program of mine that redirects stdout and can import arbitrary modules 
(it's an interactive interpreter).

The attached patch checks that these two methods exist (using hastattr) 
before calling them.

----------
components: Library (Lib)
files: __init__.py.patch
keywords: patch
messages: 68296
nosy: bobf
severity: normal
status: open
title: Lib/logging/__init__.py assumes its stream has flush and close methods
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10640/__init__.py.patch

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

From report at bugs.python.org  Tue Jun 17 08:56:37 2008
From: report at bugs.python.org (Aldona Majorek)
Date: Tue, 17 Jun 2008 06:56:37 +0000
Subject: [New-bugs-announce] [issue3127] Segfault provoked by generators and
	exceptions
In-Reply-To: <1213685796.92.0.800027132009.issue3127@psf.upfronthosting.co.za>
Message-ID: <1213685796.92.0.800027132009.issue3127@psf.upfronthosting.co.za>


New submission from Aldona Majorek <python at ada.majorek.org>:

Copy of issue 1579370

Programs using generators, exceptions and threads could crash.
I was not able to make plain python program to crash, but python program
embedded in C++ crashed very reliably. 

No more crashes after applying patch from 2.5 version stopped helped.

I verified that bug and patch on python 2.4.3.

Looking at the source code in svn, the same but lurks in latest 2.3 and
2.2 (since generators were introduced).

----------
components: Interpreter Core
messages: 68303
nosy: amajorek, awaters, eric_noyau, klaas, loewis, mwh, nnorwitz, tim_one
severity: normal
status: open
title: Segfault provoked by generators and exceptions
type: crash
versions: Python 2.2.3, Python 2.3, Python 2.4

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

From report at bugs.python.org  Tue Jun 17 09:16:26 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Fritzsche?=)
Date: Tue, 17 Jun 2008 07:16:26 +0000
Subject: [New-bugs-announce] [issue3128] Regex causes python to hang up? /
	loop infinite?
In-Reply-To: <1213686983.49.0.329999493672.issue3128@psf.upfronthosting.co.za>
Message-ID: <1213686983.49.0.329999493672.issue3128@psf.upfronthosting.co.za>


New submission from Andr? Fritzsche <computercrustie at users.sourceforge.net>:

After struggling around with my code for nearly 1 hour now, I found out
that one of my regular expressions with a special string causes python
to hang up - not really hang up, because the processor usage is at
nearly 100%, so I think the regex machine is looping infinite.

Here is the regex-string:

re_exc_line = re.compile (
        # ignore everything before the first match
        r'^.*' +
        # first group (includes second | third)
        r'(?:' +
         # second group "(line) (file)"
         r'(?:' +
          # (text to ignore, line [number])
          r'\([^,]+\s*,\s*line\s+(?P<line1>\d+)\)' +
          # any text ([filename]) any text
          r'.*\((?:(?P<file1>[^)]+))*\).*' +
         # end of second group
         r')' +
        # or
        r'|' +
         # third group "(file) (line)"
         r'(?:' +
          # ([filename])
          r'\((?:(?P<file2>[^)]+))*\)' +
          # any text (text to ignore, line [number]) any text
          r'.*\([^,]+\s*,\s*line\s+(?P<line2>\d+)\).*' +
          # end of third group
         r')' +
        # end of first group
        r')' +
        # any text after it
        r'.*$'
        , re.I
    )

It should match either the construct:

1. """some optional text (text to ignore, line [12]) ([any_filename])
followed by optional text"""

or:

2. """some optional text ([any_filename]) (text to ignore, line [12])
followed by optional text"""

If first text matches, it is put into 'line1' and 'file1' and if the
second one matches into 'line2' and 'file2' of the groupdict.

For the upper both examples everything is ok, but having the following
string (I had to change some pathnames, because they contained customer
names):
msg = (
r"Error: Error during parsing: invalid syntax " +
r"(D:\Projects\retest\ver_700\lib\_test\test_sapekl.py, line 14) " +
r"-- Error during parsing: invalid syntax " + 
r"(D:\projects\retest\ver_700\modules\sapekl\__init__.py, line 21) " +
r"-- Attempted relative import in non-package, or beyond toplevel " +
r"package")

used with the upper regex:

re_exc_line.match(msg)

is running for two hours now (on a 3Ghz Machine)!

I've attached everything as an example file and hope, I could help you.

----------
components: Regular Expressions
files: re_problem.py
messages: 68304
nosy: computercrustie
severity: normal
status: open
title: Regex causes python to hang up? / loop infinite?
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10642/re_problem.py

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

From report at bugs.python.org  Tue Jun 17 11:21:09 2008
From: report at bugs.python.org (Caleb Deveraux)
Date: Tue, 17 Jun 2008 09:21:09 +0000
Subject: [New-bugs-announce] [issue3129] struct allows repeat spec. without
	a format specifier
In-Reply-To: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>
Message-ID: <1213694469.69.0.0950890622628.issue3129@psf.upfronthosting.co.za>


New submission from Caleb Deveraux <carrus85 at gmail.com>:

I'm not exactly sure if this is a bug or by design.  Within the struct
module, whenever you provide a format string containing a repeat count
with no associated format specifier, the count is silently ignored.

eg.

>>> struct.pack("12345")
''
>>> struct.pack("3s42", "abc")
'abc'

(This also happens with unpack*, and pack_into)

The attached patch changes the above behavior to the following:

>>> struct.pack("12345")
struct.error: repeat count given without format specifier
>>> struct.pack("3s42", "abc")
struct.error: repeat count given without format specifier

Unit tests are included.

The attached patch is built against revision 64324 of the python SVN
trunk.  Odd behavior observed in both 2.6 (svn r64324), and 2.5.2.
(Tested on Ubuntu x86_64 w/ Linux kernel 2.6.24)

----------
components: Library (Lib)
files: patch.p0
messages: 68309
nosy: carrus85
severity: normal
status: open
title: struct allows repeat spec. without a format specifier
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10643/patch.p0

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

From report at bugs.python.org  Tue Jun 17 11:39:09 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Tue, 17 Jun 2008 09:39:09 +0000
Subject: [New-bugs-announce] [issue3130] In some UCS4 builds,
	sizeof(Py_UNICODE) could end up being more than 4.
In-Reply-To: <1213695549.9.0.858416360908.issue3130@psf.upfronthosting.co.za>
Message-ID: <1213695549.9.0.858416360908.issue3130@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <okkotonushi at googlemail.com>:

This issue is a branch from issue3098.

Below a summary of the discussion:

Antoine Pitrou wrote:
> It seems that in some UCS4 builds, sizeof(Py_UNICODE) could end
> up being more than 4 if the native int type is itself larger than 32
> bits; although the latter is probably quite rare (64-bit platforms are
> usually either LP64 or LLP64).

Marc-Andre Lemburg wrote:
> AFAIK, only Crays have this problem, but apart from that: I'd consider
> it a bug if sizeof(Py_UCS4) != 4.

Antoine Pitrou wrote:
> Perhaps a #error can be added to that effect?
> Something like (untested):
>
> #if SIZEOF_INT == 4
> typedef unsigned int Py_UCS4;
> #elif SIZEOF_LONG == 4
> typedef unsigned long Py_UCS4;
> #else
> #error Could not find a 4-byte integer type for Py_UCS4, aborting
> #endif

Marc-Andre Lemburg wrote:
> Sounds good !
>
> Python should really try to use uint32_t as fallback solution for
> UCS4 where available (and uint16_t for UCS2).
>
> We'd have to add an AC_TYPE_INT32_T and AC_TYPE_INT16_T check to
> configure:
>
>
http://www.gnu.org/software/autoconf/manual/html_node/Particular-Types.html#Particular-Types
>
> and could then use
>
> typedef uint32_t Py_UCS4
>
> and
>
> typedef uint16_t Py_UCS2
>
> Note that the code for supporting UCS2/UCS4 is not really all that
> clean. It was a quick sprint between Martin and Fredrik and appears
> to be only half-done... e.g. there currently is no Py_UCS2.

----------
components: Unicode
messages: 68310
nosy: schuppenies
severity: normal
status: open
title: In some UCS4 builds, sizeof(Py_UNICODE) could end up being more than 4.
type: behavior

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

From report at bugs.python.org  Tue Jun 17 14:57:31 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Tue, 17 Jun 2008 12:57:31 +0000
Subject: [New-bugs-announce] [issue3131] 2to3 can't find fixes_dir
In-Reply-To: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>
Message-ID: <1213707451.37.0.990669218912.issue3131@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

After install Python 3.0 r64319 on my Linux system, running 2to3 given
the below error:

$ 2to3 hello23.py
Traceback (most recent call last):
  File "/usr/bin/2to3", line 5, in <module>
sys.exit(refactor.main("lib2to3/fixes"))
  File "/usr/lib/python3.0/lib2to3/refactor.py", line 81, in main
rt = RefactoringTool(fixer_dir, options)
  File "/usr/lib/python3.0/lib2to3/refactor.py", line 160, in __init__
self.pre_order, self.post_order = self.get_fixers()
  File "/usr/lib/python3.0/lib2to3/refactor.py", line 180, in get_fixers
fix_names = get_all_fix_names(self.fixer_dir)
  File "/usr/lib/python3.0/lib2to3/refactor.py", line 95, in
get_all_fix_names
names = os.listdir(fixer_dir)
OSError: [Errno 2] No such file or directory: 'lib2to3/fixes'

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 68319
nosy: bhy, collinwinter
severity: normal
status: open
title: 2to3 can't find fixes_dir

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

From report at bugs.python.org  Wed Jun 18 00:30:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 17 Jun 2008 22:30:32 +0000
Subject: [New-bugs-announce] [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>


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

It seems the new modifiers to the struct.unpack/pack module that were
proposed in PEP 3118 haven't been implemented yet.

----------
assignee: teoliphant
messages: 68347
nosy: benjamin.peterson, teoliphant
priority: critical
severity: normal
status: open
title: implement PEP 3118 struct changes
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun 18 11:28:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Jun 2008 09:28:32 +0000
Subject: [New-bugs-announce] [issue3133] CGIHTTPRequestHandler does not work
	on windows
In-Reply-To: <1213781312.07.0.218615060623.issue3133@psf.upfronthosting.co.za>
Message-ID: <1213781312.07.0.218615060623.issue3133@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

On windows, test_httpservers fails with the error:

  File "C:\python\py3k\Lib\http\server.py", line 1104, in run_cgi
    exec(open(scriptfile).read(), {"__name__": "__main__"})
  File "<string>", line 3, in <module>
  File "C:\python\py3k\Lib\socket.py", line 222, in write
    return self._sock.send(b)
  TypeError: send() argument 1 must be bytes or read-only buffer, not str

There are two problems there:
- Lib/http/server.py still looks for os.popen2 or os.popen3 to start a
subprocess; these functions have been removed, this code should be
rewritten using the subprocess module.
- the fallback method, which exec() the cgi script in the python
interpreter, fails because sys.stdout should be set to a TextIOWrapper,
not a binary socket file.

Certainly the fallback method could be removed: every platform
implements subprocess nowadays.

----------
components: Library (Lib), Windows
messages: 68361
nosy: amaury.forgeotdarc
severity: normal
status: open
title: CGIHTTPRequestHandler does not work on windows
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun 18 22:49:50 2008
From: report at bugs.python.org (David Vitek)
Date: Wed, 18 Jun 2008 20:49:50 +0000
Subject: [New-bugs-announce] [issue3134] shutil references undefined
	WindowsError symbol
In-Reply-To: <1213822190.13.0.727070543552.issue3134@psf.upfronthosting.co.za>
Message-ID: <1213822190.13.0.727070543552.issue3134@psf.upfronthosting.co.za>


New submission from David Vitek <dvitek at grammatech.com>:

If copystat fails in copytree on a non-windows box, you will get:

NameError: global name 'WindowsError' is not defined:
...
    except WindowsError:

----------
components: Library (Lib)
files: p.patch
keywords: patch
messages: 68373
nosy: dvitek
severity: normal
status: open
title: shutil references undefined WindowsError symbol
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file10655/p.patch

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

From report at bugs.python.org  Thu Jun 19 00:16:54 2008
From: report at bugs.python.org (George Sakkis)
Date: Wed, 18 Jun 2008 22:16:54 +0000
Subject: [New-bugs-announce] [issue3135] inspect.getcallargs()
In-Reply-To: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>
Message-ID: <1213827414.08.0.250071294589.issue3135@psf.upfronthosting.co.za>


New submission from George Sakkis <george.sakkis at gmail.com>:

I'd like to propose a new function for inclusion to the inspect module
-- getcallargs(func, *args, **kwds) -- that returns a dict which maps
the formal arguments of a function (or other callable) to the values
passed as args and kwds, just as Python has to do when calling
func(*args, **kwds). For example:

>>> def func(a, b='foo', c=None, *x, **y):
...         pass
>>> sorted(getcallargs(func, 5, z=3, b=2).items())
 [('a', 5), ('b', 2), ('c', None), ('x', ()), ('y', {'z': 3})]

This is handy when writing decorators, or more generally when one would
want to do some minimal type checking without actually calling the function.

I have posted a recipe at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/551779; I can
clean it up and submit a proper patch if it's deemed useful enough for
the stdlib.

----------
components: Library (Lib)
messages: 68378
nosy: gsakkis
severity: normal
status: open
title: inspect.getcallargs()
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 19 03:02:03 2008
From: report at bugs.python.org (Leandro Lucarella)
Date: Thu, 19 Jun 2008 01:02:03 +0000
Subject: [New-bugs-announce] [issue3136] [PATCH] logging.config.fileConfig()
	compulsivly disable all existing loggers
In-Reply-To: <1213837323.33.0.0675974065144.issue3136@psf.upfronthosting.co.za>
Message-ID: <1213837323.33.0.0675974065144.issue3136@psf.upfronthosting.co.za>


New submission from Leandro Lucarella <llucax at gmail.com>:

When using logging.config.fileConfig() in a large project, with several
nested loggers, is very counterintuitive and annoying that this function
disable all non-configured-via-fileConfig() loggers, because it forces
the config file to configure *all* the loggers there, which makes the
file unmaintainable, and throws the beauty of hierarchical loggers to
the trash.

Attached is a sample patch that adds a new option
"disable_existing_loggers" to fileConfig() function (defaulting to True,
to make it backward-compatible) to control this behavior. If you like
the idea I can update the documentation and add some testcases too.

You can see a simple example about the problem and solution here:
log.py:  http://pastebin.lugmen.org.ar/4204
log.ini: http://pastebin.lugmen.org.ar/4205

without the patch, the output is:
logger:DEBUG: log debug
logger:INFO: log info
logger:WARNING: log warning
logger:ERROR: log error
logger:CRITICAL: log critical

With the patch (and passing disable_existing_loggers=False to
fileConfig()) yields this output:
logger:DEBUG: log debug
logger:INFO: log info
logger:WARNING: log warning
logger:ERROR: log error
logger:CRITICAL: log critical
logger.sublogger:DEBUG: sublog debug
logger.sublogger:INFO: sublog info
logger.sublogger:WARNING: sublog warning
logger.sublogger:ERROR: sublog error
logger.sublogger:CRITICAL: sublog critical

As one could expect when reading the logging module docs:
"""
getLogger() returns a reference to a logger instance with the specified
if it it is provided, or root if not. The names are period-separated
hierarchical structures. Multiple calls to getLogger() with the same
name will return a reference to the same logger object. Loggers that are
further down in the hierarchical list are children of loggers higher up
in the list. For example, given a logger with a name of foo, loggers
with names of foo.bar, foo.bar.baz, and foo.bam are all children of foo.
Child loggers propagate messages up to their parent loggers. Because of
this, it is unnecessary to define and configure all the loggers an
application uses. It is sufficient to configure a top-level logger and
create child loggers as needed.
"""

----------
components: Library (Lib)
files: logging.config.disable_existing_loggers.patch
keywords: patch
messages: 68388
nosy: llucax
severity: normal
status: open
title: [PATCH] logging.config.fileConfig() compulsivly disable all existing loggers
versions: Python 2.5
Added file: http://bugs.python.org/file10657/logging.config.disable_existing_loggers.patch

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

From report at bugs.python.org  Thu Jun 19 10:04:37 2008
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 19 Jun 2008 08:04:37 +0000
Subject: [New-bugs-announce] [issue3137] Python doesn't handle SIGINT well
	if it arrives during interpreter startup
In-Reply-To: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>
Message-ID: <1213862677.34.0.00995012597112.issue3137@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

If a python script receives SIGINT while the interpreter is starting up,
it's possible to get the message "import site failed; use -v for
traceback" printed on standard error and for execution to proceed. It
also seems to be possible to get half-imported modules and for the
script to fail later claiming that something like "os.getenv" doesn't exist.

If I do as instructed and use -v for traceback I get something like:

'import site' failed; traceback:
Traceback (most recent call last):
  File "/usr/lib/python2.4/site.py", line 61, in ?
    import os
  File "/usr/lib/python2.4/os.py", line 683, in ?
    import copy_reg as _copy_reg
  File "/usr/lib/python2.4/copy_reg.py", line 5, in ?
    """
KeyboardInterrupt 

I imagine there exists some code like
try:
    import site
except:
    sys.stderr.write("import site failed; use -v for traceback\n")

though I couldn't find any. If so, it seems clear that KeyboardInterrupt
needs to be re-raised, or Python's special handler for SIGINT installed
rather later.

----------
components: Interpreter Core
messages: 68392
nosy: gjb1002
severity: normal
status: open
title: Python doesn't handle SIGINT well if it arrives during interpreter startup
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun 19 10:08:17 2008
From: report at bugs.python.org (Dex)
Date: Thu, 19 Jun 2008 08:08:17 +0000
Subject: [New-bugs-announce] [issue3138] Hang when calling get() on an empty
	queue in the queue module
In-Reply-To: <1213862897.02.0.570715389583.issue3138@psf.upfronthosting.co.za>
Message-ID: <1213862897.02.0.570715389583.issue3138@psf.upfronthosting.co.za>


New submission from Dex <slash2314 at yahoo.com>:

This behavior appears in Python 3.0b1.  If you use queue.Queue and call
the get method on the empty queue, it appears to hang.  The same
behavior seems to be evident in the PriorityQueue too.

----------
messages: 68393
nosy: slash2314
severity: normal
status: open
title: Hang when calling get() on an empty queue in the queue module
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 19 12:06:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 Jun 2008 10:06:54 +0000
Subject: [New-bugs-announce] [issue3139] print is not thread safe
In-Reply-To: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>
Message-ID: <1213870014.47.0.920261148604.issue3139@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

I found this problem when adding "print" statements to multi-threaded
code. When applying the attached diff to a py3k installation, the output
on screen always contains some garbage.

The following code is an extract of fileio_write (in Modules/_fileio.c),
but the same behavior appears everywhere:

	if (!PyArg_ParseTuple(args, "s#", &ptr, &n))
		return NULL;

	Py_BEGIN_ALLOW_THREADS
	errno = 0;
	n = write(self->fd, ptr, n);
	Py_END_ALLOW_THREADS

io.BufferedWriter calls this function with a bytearray.
In this case, the GIL is released when holding a pointer to the
bytearray data.
But another thread may mutate the bytearray in between, the pointer
becomes stale and can lead to segfaults or funny results.

----------
components: Interpreter Core
files: test_threaded_print.diff
keywords: patch
messages: 68397
nosy: amaury.forgeotdarc
severity: normal
status: open
title: print is not thread safe
type: crash
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10658/test_threaded_print.diff

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

From report at bugs.python.org  Thu Jun 19 15:02:13 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 19 Jun 2008 13:02:13 +0000
Subject: [New-bugs-announce] [issue3140] str.format("{0:n}") poss. bug with
	setlocale()
In-Reply-To: <1213880533.51.0.166006060243.issue3140@psf.upfronthosting.co.za>
Message-ID: <1213880533.51.0.166006060243.issue3140@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

Python 30b1

>>> import locale
>>> locale.setlocale(locale.LC_ALL, "en_US.UTF-8")
'en_US.UTF-8'
>>> for x in
(1234,12345,123456,1234567,12345678,123456789,1234567890,12345678900):
	print("[{0:>20n}]".format(x))

	
[                1,234]
[               12,345]
[              123,456]
[             1,234,567]
[            12,345,678]
[           123,456,789]
[          1,234,567,890]
[         12,345,678,900]

I expected that the commas would not increase the width, but maybe this
was the intended behaviour?

----------
messages: 68403
nosy: mark
severity: normal
status: open
title: str.format("{0:n}") poss. bug with setlocale()
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 19 15:15:28 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 19 Jun 2008 13:15:28 +0000
Subject: [New-bugs-announce] [issue3141] Linux build requires Mac module
	_gestalt
In-Reply-To: <1213881328.23.0.078926061011.issue3141@psf.upfronthosting.co.za>
Message-ID: <1213881328.23.0.078926061011.issue3141@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

When you build 30b1 on Linux (I tried Fedora 8 and Xubuntu 8) you get a
message that make failed to find the bits to build "_gestalt", which I
think is a Mac-thing not a Linux thing.

Anyway, Barry asked me to add this as a bug.

----------
components: Build
messages: 68405
nosy: mark
severity: normal
status: open
title: Linux build requires Mac module _gestalt
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 19 15:21:26 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 19 Jun 2008 13:21:26 +0000
Subject: [New-bugs-announce] [issue3142] urllib docs don't match the new
	modules
In-Reply-To: <1213881685.97.0.203143368554.issue3142@psf.upfronthosting.co.za>
Message-ID: <1213881685.97.0.203143368554.issue3142@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

Py30b1

The module renaming of urllib's modules (and the getting rid of urllib2)
has been done---but this isn't reflected in the docs.

----------
assignee: georg.brandl
components: Documentation
messages: 68406
nosy: georg.brandl, mark
severity: normal
status: open
title: urllib docs don't match the new modules
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 19 18:48:50 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Thu, 19 Jun 2008 16:48:50 +0000
Subject: [New-bugs-announce] [issue3143] development docs waste a lot of
	horizontal space on left nav bar
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>


New submission from Forest Wilkinson <forest at users.sourceforge.net>:

I was just browsing the development docs, and noticed that the new
left-side navigation bar wastes a lot of horizontal space on the web
page.  It fills nearly a third of my browser window (at its usual size)
with useless blank space, at the expense of the pertinent information. 
This makes it harder to get much use out of a docs window placed next to
my editor window, since I am now forced to switch active windows and/or
scroll around the docs window in order to read the section I'm working
with.  In a few cases, it leaves space for so few words per line that
even the visible part of the docs actually become harder to read
(especially with text justification).

For comparison, here are screen shots from the old and new documentation:
http://hestiafire.org/forest/img/doc25.png
http://hestiafire.org/forest/img/doc26.png

Is this side bar going to be present in the final release of the python
2.6 docs?  I hope not.  It's a significant loss in readability, IMHO.

----------
assignee: georg.brandl
components: Documentation
messages: 68412
nosy: forest, georg.brandl
severity: normal
status: open
title: development docs waste a lot of horizontal space on left nav bar
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Jun 19 21:18:29 2008
From: report at bugs.python.org (Justin Cappos)
Date: Thu, 19 Jun 2008 19:18:29 +0000
Subject: [New-bugs-announce] [issue3144] popen / popen[234] inconsistent fd
	behavior
In-Reply-To: <1213903108.91.0.624214427386.issue3144@psf.upfronthosting.co.za>
Message-ID: <1213903108.91.0.624214427386.issue3144@psf.upfronthosting.co.za>


New submission from Justin Cappos <justincappos at hotmail.com>:

The behavior of popen vs popen[2-4] differs with respect to open file
descriptors (at least on the Linux implementation of popen).   popen
does not close file descriptors, thus processes retain open file
descriptors from their parent.   This is likely not desirable for
security and stability reasons.   

If this isn't fixed, at a minimum it would be a good thing to document.


Here is an example that demonstrates the issue:

<<< start of open_and_popen.py>>>
# This will not be printed if popen closes file descriptors

import os
myfd = os.open("open_and_popen.py",os.O_RDONLY)

readfo = os.popen("python print_from_fd.py "+str(myfd),"r")

print "os.popen results in:"
print readfo.read()
# it will print the first line of the file here
readfo.close()


(junkinfo, readfo) = os.popen2("python print_from_fd.py "+str(myfd),"r")
junkinfo.close()

print "os.popen2 results in:"
print readfo.read()
# the child got an error, so this is just the error text
readfo.close()

os.close(myfd)
<<< end of open_and_popen.py>>>


<<< start of print_from_fd.py>>>
import os
import sys
print os.read(int(sys.argv[1]),60)
<<< end of print_from_fd.py>>>

----------
components: Library (Lib)
messages: 68416
nosy: justincappos
severity: normal
status: open
title: popen / popen[234] inconsistent fd behavior
type: security

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

From report at bugs.python.org  Thu Jun 19 21:58:18 2008
From: report at bugs.python.org (Michael Yang)
Date: Thu, 19 Jun 2008 19:58:18 +0000
Subject: [New-bugs-announce] [issue3145] help> modules os raises
	UnicodeDecodeError
In-Reply-To: <1213905498.05.0.86036305634.issue3145@psf.upfronthosting.co.za>
Message-ID: <1213905498.05.0.86036305634.issue3145@psf.upfronthosting.co.za>


New submission from Michael Yang <yangofzeal at gmail.com>:

>>> help()
help> modules os
Here is a list of matching modules.  Enter any module name to get more help.

posix - This module provides access to operating system
...
stringprep - Library that exposes various tables found in the StringPrep
RFC 3454.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
...
File "/home/michael/python3/3.0b1/lib/python3.0/codecs.py", line 300, in
decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 8-11:
invalid data

----------
components: Interpreter Core
messages: 68419
nosy: msyang
severity: normal
status: open
title: help> modules os raises UnicodeDecodeError
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 19 23:12:12 2008
From: report at bugs.python.org (Vincent Manis)
Date: Thu, 19 Jun 2008 21:12:12 +0000
Subject: [New-bugs-announce] [issue3146] Sphinx/LaTeX fails on Python 3.0b1
	documentation
In-Reply-To: <1213909932.21.0.41888332926.issue3146@psf.upfronthosting.co.za>
Message-ID: <1213909932.21.0.41888332926.issue3146@psf.upfronthosting.co.za>


New submission from Vincent Manis <vmanis at telus.net>:

When attempting to build the LaTeX for the documentation provided with 
Python 3.0b1, the following error is produced while writing the Library 
documentation (full backtrace provided). I am running Sphinx on Python 
2.5. 

Traceback (most recent call last):
  File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/__init__.py", line 
135, in main
    app.builder.build_update()
  File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/builder.py", line 194, 
in build_update
    self.build(['__all__'], to_build)
  File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/builder.py", line 238, 
in build
    self.write(docnames, updated_docnames, method)
  File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/builder.py", line 852, 
in write
    docwriter.write(doctree, destination)
  File 
"/Users/vmanis/myenv/py3k/Doc/tools/docutils/writers/__init__.py", line 
78, in write
    self.translate()
  File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/latexwriter.py", line 
70, in translate
    self.document.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159, 
in walkabout
    child.walkabout(visitor)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 151, 
in walkabout
    visitor.dispatch_visit(self)
  File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 
1502, in dispatch_visit
    return method(node)
  File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/latexwriter.py", line 
1012, in unknown_visit
    raise NotImplementedError("Unknown node: " + 
node.__class__.__name__)
NotImplementedError: Unknown node: subscript

----------
assignee: georg.brandl
components: Documentation, Documentation tools (Sphinx)
messages: 68426
nosy: georg.brandl, vmanis1
severity: normal
status: open
title: Sphinx/LaTeX fails on Python 3.0b1 documentation
type: crash
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Fri Jun 20 00:43:46 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 Jun 2008 22:43:46 +0000
Subject: [New-bugs-announce] [issue3147] tests for sys.getsizeof fail on
	win64
In-Reply-To: <1213915426.19.0.16089164965.issue3147@psf.upfronthosting.co.za>
Message-ID: <1213915426.19.0.16089164965.issue3147@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

the buildbot "AMD64 W2k8 trunk" systematically fails with the messages:

======================================================================
FAIL: test_specialtypes (test.test_sys.SizeofTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 534, in test_specialtypes
    self.check_sizeof({}, h + 3*l + 3*p + 8*(l + 2*p))
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 431, in check_sizeof
    self.assertEqual(result, size, msg + str(size))
AssertionError: wrong size for <type 'dict'>: got 272, expected 224

======================================================================
FAIL: test_standardtypes (test.test_sys.SizeofTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 455, in test_standardtypes
    self.check_sizeof(True, h + l)
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 431, in check_sizeof
    self.assertEqual(result, size, msg + str(size))
AssertionError: wrong size for <type 'bool'>: got 40, expected 32

It seems that this platform is special: sizeof(long)==4 and
sizeof(size_t)==8

----------
assignee: schuppenies
components: Interpreter Core
messages: 68429
nosy: amaury.forgeotdarc, schuppenies
severity: normal
status: open
title: tests for sys.getsizeof fail on win64
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 20 02:06:27 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 20 Jun 2008 00:06:27 +0000
Subject: [New-bugs-announce] [issue3148] multiprocessing test hangs
In-Reply-To: <1213920386.95.0.298819928633.issue3148@psf.upfronthosting.co.za>
Message-ID: <1213920386.95.0.298819928633.issue3148@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The test_multiprocessing hangs with both Python 2.6b1 and 3.0b1 on MacOS X 
10.4.11 (Intel) but only when using  make test.

However, the test runs and passes in both builds if run separately, e.g. 
with  ./python Lib/test/test_mutliprocessing.py.

----------
components: Tests
messages: 68432
nosy: MrJean1
severity: normal
status: open
title: multiprocessing test hangs
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 20 03:38:33 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 20 Jun 2008 01:38:33 +0000
Subject: [New-bugs-announce] [issue3149] multiprocessing build fails on
	Solaris 10
In-Reply-To: <1213925912.95.0.611829708771.issue3149@psf.upfronthosting.co.za>
Message-ID: <1213925912.95.0.611829708771.issue3149@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The multiprocessing module fails to build on Solaris 10 when using the 
Sun C compiler.  The failure is due to one missing symbol  
SEM_VALUE_MAX.

Defining that symbol (e.g. as _POSIX_SEM_VALUE_MAX) builds the 
_multiprocessing module for both 32- and 64-bit.

However, for 32-bit, 5 tests from test_multiprocessing fail due to the 
missing _ctypes module.  For 64-bit, the first 3 tests fail (like for 
32-bit) but the 4th test hangs.  Here is a log:

./python Lib/test/test_multiprocessing.py
test_array (__main__.WithProcessesTestArray) ... ERROR
test_getobj_getlock_obj (__main__.WithProcessesTestArray) ... ERROR
test_rawarray (__main__.WithProcessesTestArray) ... ERROR
test_notify (__main__.WithProcessesTestCondition) ... Process Process-1:
Traceback (most recent call last):
  File "/..../64/Python-2.6b1/Lib/multiprocessing/process.py", line 237, 
in _bootstrap
    self.run()
  File "/.../64/Python-2.6b1/Lib/multiprocessing/process.py", line 93, 
in run
    self._target(*self._args, **self._kwargs)
  File "Lib/test/test_multiprocessing.py", line 610, in f
    sleeping.release()
ValueError: semaphore or lock released too many times


This is Solaris 10 on an Ultra20 (Opteron) machine:

> uname -a
SunOS unknown 5.10 Generic_118855-14 i86pc i386 i86pc

> cc -v
cc: Sun C 5.8 2005/10/13

----------
components: Build
messages: 68438
nosy: MrJean1
severity: normal
status: open
title: multiprocessing build fails on Solaris 10
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 20 03:59:12 2008
From: report at bugs.python.org (Humberto Diogenes)
Date: Fri, 20 Jun 2008 01:59:12 +0000
Subject: [New-bugs-announce] [issue3150] multiprocessing module not being
	installed
In-Reply-To: <1213927152.64.0.995620300444.issue3150@psf.upfronthosting.co.za>
Message-ID: <1213927152.64.0.995620300444.issue3150@psf.upfronthosting.co.za>


New submission from Humberto Diogenes <humberto at digi.com.br>:

The new multiprocessing module is not being installed:

$ python3.0
Python 3.0b1+ (py3k:64417, Jun 19 2008, 21:25:46) 
[GCC 4.0.1 (Apple Inc. build 5483)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named multiprocessing
>>> 

After adding it to Makefile.pre.in and rebuilding/reinstalling:

$ python3.0
Python 3.0b1+ (py3k:64417M, Jun 19 2008, 22:50:25) 
[GCC 4.0.1 (Apple Inc. build 5483)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>>

----------
components: Installation
files: install_multiprocessing.patch
keywords: patch
messages: 68439
nosy: hdiogenes
severity: normal
status: open
title: multiprocessing module not being installed
versions: Python 3.0
Added file: http://bugs.python.org/file10665/install_multiprocessing.patch

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

From report at bugs.python.org  Fri Jun 20 17:16:21 2008
From: report at bugs.python.org (robert forkel)
Date: Fri, 20 Jun 2008 15:16:21 +0000
Subject: [New-bugs-announce] [issue3151] elementtree serialization bug for
	weird namespace urls
In-Reply-To: <1213974981.57.0.313909578004.issue3151@psf.upfronthosting.co.za>
Message-ID: <1213974981.57.0.313909578004.issue3151@psf.upfronthosting.co.za>


New submission from robert forkel <xrotwang at googlemail.com>:

when serializing elementtrees with weird namespaces like {$stuff}, the
generated xml is not valid:

Python 2.5.1 (r251:54863, Mar  7 2008, 04:10:12)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

IDLE 1.2.1      ==== No Subprocess ====
>>> from xml.etree import ElementTree as et
>>> e = et.fromstring('<prefix:localname xmlns:prefix="${stuff}"/>')
>>> e.tag
'{${stuff}}localname'
>>> t = et.ElementTree(e)
>>> from StringIO import StringIO
>>> f = StringIO()
>>> t.write(f)
>>> f.seek(0)
>>> print f.read()
<ns0:}localname xmlns:ns0="${stuff" />

----------
components: Library (Lib)
messages: 68463
nosy: xrotwang
severity: normal
status: open
title: elementtree serialization bug for weird namespace urls
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun 20 22:36:33 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jun 2008 20:36:33 +0000
Subject: [New-bugs-announce] [issue3152] ast module docs document private
	attribute
In-Reply-To: <1213994193.88.0.922592845049.issue3152@psf.upfronthosting.co.za>
Message-ID: <1213994193.88.0.922592845049.issue3152@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The docs for the ast module document the '_fields' attribute on AST
instances. Either that documentation needs to go away or the attribute
needs to be renamed as the leading underscore means it is private to the
internal API.

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 68473
nosy: brett.cannon, georg.brandl
priority: critical
severity: normal
status: open
title: ast module docs document private attribute
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun 20 23:36:06 2008
From: report at bugs.python.org (Adam Olsen)
Date: Fri, 20 Jun 2008 21:36:06 +0000
Subject: [New-bugs-announce] [issue3153] sqlite leaks on error
In-Reply-To: <1213997766.53.0.685117931663.issue3153@psf.upfronthosting.co.za>
Message-ID: <1213997766.53.0.685117931663.issue3153@psf.upfronthosting.co.za>


New submission from Adam Olsen <rhamph at gmail.com>:

Found in Modules/_sqlite/cursor.c:

        self->statement = PyObject_New(pysqlite_Statement,
&pysqlite_StatementTy
pe);
        if (!self->statement) {
            goto error;
        }
        rc = pysqlite_statement_create(self->statement,
self->connection, operation);
        if (rc != SQLITE_OK) {
            self->statement = 0;
            goto error;
        }

Besides the ugliness of allocating the object before passing it to the
"create" function, if pysqlite_statement_create fails, the object is leaked.

----------
components: Extension Modules
messages: 68478
nosy: Rhamphoryncus
severity: normal
status: open
title: sqlite leaks on error
type: resource usage

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

From report at bugs.python.org  Fri Jun 20 23:47:33 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 20 Jun 2008 21:47:33 +0000
Subject: [New-bugs-announce] [issue3154] "Quick search" box renders too long
	on FireFox 3
In-Reply-To: <1213998453.68.0.954320877172.issue3154@psf.upfronthosting.co.za>
Message-ID: <1213998453.68.0.954320877172.issue3154@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

See gray area in attached screenshot

----------
assignee: georg.brandl
components: Documentation
files: doc.png
messages: 68479
nosy: georg.brandl, tebeka
severity: normal
status: open
title: "Quick search" box renders too long on FireFox 3
versions: Python 2.6
Added file: http://bugs.python.org/file10679/doc.png

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

From report at bugs.python.org  Sat Jun 21 01:23:27 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Jun 2008 23:23:27 +0000
Subject: [New-bugs-announce] [issue3155] Python should expose a
	pthread_cond_timedwait API for threading
In-Reply-To: <1214004207.53.0.484694251636.issue3155@psf.upfronthosting.co.za>
Message-ID: <1214004207.53.0.484694251636.issue3155@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Currently the threading module has loops in it such as
threading.Condition.wait's loop that attempts to acquire a lock in
non-blocking mode and if it fails, sleeps for a while and trys again. 
(with exponential backoff of sleep time from 500us to 50ms in the
current implementation).

This is inefficient.

Perhaps pthread_cond_timedwait does the same thing internally in some
implementations but even if so, it will do it a lot more efficiently
than doing it in python.

We should expose a PyThread_acquire_lock API that accepts a timeout and
uses pthread_cond_timedwait (or the equivalent on other OSes) when
available.

caveats?  This may alter behavior with regards to KeyboardInterrupt
exceptions coming in being processed or not depending on the particular
OS timedwait implementation.

----------
components: Interpreter Core
messages: 68484
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Python should expose a pthread_cond_timedwait API for threading
type: feature request

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

From report at bugs.python.org  Sat Jun 21 01:35:00 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 20 Jun 2008 23:35:00 +0000
Subject: [New-bugs-announce] [issue3156] bytes type has inconsistent methods
	(append, insert)
In-Reply-To: <1214004899.96.0.722439580753.issue3156@psf.upfronthosting.co.za>
Message-ID: <1214004899.96.0.722439580753.issue3156@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

bytearray's methods aren't consistent in what they accept.             
        

append() takes either an int or a character:                           
        
                                                                       
        
>>> b = bytearray('abc')                                               
        
>>> b.append(76) ; b                                                   
        
bytearray(b'abcL')                                                     
        
>>> b.append('M') ; b                                                  
        
bytearray(b'abcLM')                                                    
        
                                                                       
        
.insert() accepts only integers:                                       
        
                                                                       
        
>>> b.insert(0, 97) ; b                                                
        
bytearray(b'aabcLM')                                                   
        
>>> b.insert(0, 'a') ; b                                               
        
Traceback (most recent call last):                                     
        
  File "<stdin>", line 1, in <module>                                  
        
TypeError: an integer is required                                      
        
                                                                       
        
Both PEP 358 and the docstring for .append() only document 'int' as a  
        
legal input, so I suspect append() is wrong here.

----------
messages: 68487
nosy: akuchling
severity: normal
status: open
title: bytes type has inconsistent methods (append, insert)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 21 04:27:58 2008
From: report at bugs.python.org (Stephen Lewis)
Date: Sat, 21 Jun 2008 02:27:58 +0000
Subject: [New-bugs-announce] [issue3157] sqlite3 minor documentation issues
In-Reply-To: <1214015278.07.0.0768576663136.issue3157@psf.upfronthosting.co.za>
Message-ID: <1214015278.07.0.0768576663136.issue3157@psf.upfronthosting.co.za>


New submission from Stephen Lewis <thgfrj at gmail.com>:

The documentation for several methods in the sqlite3 library seems to be
at odds with the function names:

sqlite3.Cursor.fetchone --> "Fetches several rows from the resultset."
sqlite3.Cursor.fetchmany --> "Fetches all rows from the resultset."
sqlite3.Cursor.fetchall --> "Fetches one row from the resultset."

This is apparent on Ubuntu's packaged version 2.5.2-2ubuntu4, and a
quick glance at the online SVN repository implies that its present in
the trunk.

Also, it might be helpful the documentation for sqlite3.connect were to
mention that it takes a file name as a parameter :)

----------
assignee: georg.brandl
components: Documentation
messages: 68488
nosy: georg.brandl, slewis
severity: normal
status: open
title: sqlite3 minor documentation issues
versions: Python 2.5

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

From report at bugs.python.org  Sat Jun 21 04:31:45 2008
From: report at bugs.python.org (=?utf-8?q?Fernando_P=C3=A9rez?=)
Date: Sat, 21 Jun 2008 02:31:45 +0000
Subject: [New-bugs-announce] [issue3158] Doctest fails to find doctests in
	extension modules
In-Reply-To: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za>
Message-ID: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za>


New submission from Fernando P?rez <fer_perez at users.sourceforge.net>:

Doctest fails to find doctests defined in extension modules.  With tools
like cython (http://cython.org) it's trivially easy to add docstrings to
extension code, a task that is much less pleasant with hand-written
extensions.   The following patch is a minimal fix for the problem:


--- doctest_ori.py      2008-06-20 19:22:56.000000000 -0700
+++ doctest.py  2008-06-20 19:23:53.000000000 -0700
@@ -887,7 +887,8 @@
             for valname, val in obj.__dict__.items():
                 valname = '%s.%s' % (name, valname)
                 # Recurse to functions & classes.
-                if ((inspect.isfunction(val) or inspect.isclass(val)) and
+                if ((inspect.isfunction(val) or inspect.isclass(val) or
+                     inspect.isbuiltin(val) ) and
                     self._from_module(module, val)):
                     self._find(tests, val, valname, module, source_lines,
                                globs, seen)


However, it is likely not sufficient as it doesn't take into account the
__test__ dict, for which probably the same change would work, just a few
lines later.  Furthermore, the real issue is in my view in the
distinction made by inspect between isfunction() and isbuiltin() for the
sake of analyzing docstrings.  isfunction() returns false for a function
that is defined in an extension module (though it *is* a function) while
isbuiltin returns True (though it is *not* a builtin).

For purposes of doctesting, doctest should simply care:

- That it is a function.
- That it has a docstring that can be parsed.

But in too many places in doctest there are currently assumptions about
being able to extract full source, line numbers, etc.  Hopefully this
quick fix can be applied as it will immediately make doctest work with
large swaths of extension code, while a proper rethinking of doctest is
made.  

BTW, in that process doctest will hopefully be made more modular and
flexible: its current structure forces massive copy/paste subclassing
for any kind of alternate use, since it has internally hardwired use of
its own classes.  Doctest is tremendously useful, but it really could
use with some structural reorganization to make it more flexible (cleanly).

----------
components: Library (Lib)
messages: 68489
nosy: fer_perez
severity: normal
status: open
title: Doctest fails to find doctests in extension modules
versions: Python 2.5

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

From report at bugs.python.org  Sat Jun 21 11:51:17 2008
From: report at bugs.python.org (Aristotelis Mikropoulos)
Date: Sat, 21 Jun 2008 09:51:17 +0000
Subject: [New-bugs-announce] [issue3159] glob.py improvements
In-Reply-To: <1214041877.01.0.817721592815.issue3159@psf.upfronthosting.co.za>
Message-ID: <1214041877.01.0.817721592815.issue3159@psf.upfronthosting.co.za>


New submission from Aristotelis Mikropoulos <amikrop at gmail.com>:

Simplified some of the code, improving performance and readability.

----------
components: Library (Lib)
files: glob.py.patch
keywords: patch
messages: 68493
nosy: Indy
severity: normal
status: open
title: glob.py improvements
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10680/glob.py.patch

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

From report at bugs.python.org  Sat Jun 21 17:31:56 2008
From: report at bugs.python.org (Viktor Ferenczi)
Date: Sat, 21 Jun 2008 15:31:56 +0000
Subject: [New-bugs-announce] [issue3160] Building a Win32 binary installer
	crashes
In-Reply-To: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>
Message-ID: <1214062316.76.0.502930697885.issue3160@psf.upfronthosting.co.za>


New submission from Viktor Ferenczi <python at cx.hu>:

Python 3.0b1, official MSI installer.

Checkout source code of this project:
http://code.google.com/p/anntools/

Enter into the root of your working copy and try to build a Win32 installer:

C:\Python30\python.exe setup.py bdist_wininst

NOTE: You might want to replace the path above with you Python
installation path. Please ensure, that Python 3.0 is used, since all
other versions from 2.4 to 2.6b1 works well.

You will get the following traceback during the build process:

Traceback (most recent call last):
  File "setup.py", line 37, in <module>
"anntools",
  File "C:\python30\lib\distutils\core.py", line 149, in setup
dist.run_commands()
  File "C:\python30\lib\distutils\dist.py", line 941, in run_commands
self.run_command(cmd)
  File "C:\python30\lib\distutils\dist.py", line 961, in run_command
cmd_obj.run()
  File "C:\python30\lib\distutils\command\bdist_wininst.py", line 177,
in run
self.create_exe(arcname, fullname, self.bitmap)
  File "C:\python30\lib\distutils\command\bdist_wininst.py", line 263,
in create_exe
cfgdata = cfgdata + "\0"
TypeError: can't concat bytes to str

----------
components: Distutils
messages: 68500
nosy: complex
severity: normal
status: open
title: Building a Win32 binary installer crashes
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sat Jun 21 17:55:55 2008
From: report at bugs.python.org (Simon Cross)
Date: Sat, 21 Jun 2008 15:55:55 +0000
Subject: [New-bugs-announce] [issue3161] Missing import for sys in _abcoll
In-Reply-To: <1214063755.65.0.272418702742.issue3161@psf.upfronthosting.co.za>
Message-ID: <1214063755.65.0.272418702742.issue3161@psf.upfronthosting.co.za>


New submission from Simon Cross <hodgestar at gmail.com>:

The _hash method of the Set ABC uses sys.maxsize but doesn't import sys.
The attached patch (against trunk) imports sys and adds a test to show
the problem. There are also still some other _abcoll.py cleanups waiting
in issue 2226.

----------
components: Library (Lib), Tests
files: abcoll-hash.diff
keywords: patch
messages: 68504
nosy: hodgestar
severity: normal
status: open
title: Missing import for sys in _abcoll
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10682/abcoll-hash.diff

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

From report at bugs.python.org  Sat Jun 21 19:13:40 2008
From: report at bugs.python.org (Simon Cross)
Date: Sat, 21 Jun 2008 17:13:40 +0000
Subject: [New-bugs-announce] [issue3162] ssl.SSLSocket implements methods
	that are overriden by socket.socket.__init__ and methods with
	incorrect names.
In-Reply-To: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>
Message-ID: <1214068420.92.0.41617535069.issue3162@psf.upfronthosting.co.za>


New submission from Simon Cross <hodgestar at gmail.com>:

It appears that ssl.SSLSocket attempts to override some of the methods
socket.socket delegates to the underlying _socket.socket methods.
However, this overriding fails because socket.socket.__init__ replaces
all the methods mentioned in _delegate_methods.

These methods are: recv, recvfrom, recv_into, recvfrom_into, send and
sendto.

ssl.SSLSocket implements recv and send. Neither of these overrides will
actually work.  ssl.SSLSocket also implements recv_from and send_to
which seem to be attempts to override recvfrom and sendto.

In the Py3k branch it looks like the overriding done by
socket.socket.__init__ is gone so that these methods are now potentially
overridable. This could potentially be emulated in trunk by checking for
the methods using hasattr(...) before overriding them.

I'm happy to create patches which fix the method names and clean up the
methods on both branches and add tests. I just want to check that I have
an accurate picture of what's needed before starting on them.

----------
components: Library (Lib)
messages: 68517
nosy: hodgestar
severity: normal
status: open
title: ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sat Jun 21 20:05:51 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 21 Jun 2008 18:05:51 +0000
Subject: [New-bugs-announce] [issue3163] module struct support for ssize_t
	and size_t
In-Reply-To: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>
Message-ID: <1214071551.33.0.650558563727.issue3163@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

Attached is a (simplistic) patch for the struct module to support C types 
ssize_t and size_t with format characters 'z' resp. 'Z'.

The patch updates Python 2.6b1 files Modules/_struct.c and 
Doc/library/struct.rst.

Note, format character 'Z' is also proposed in PEP 3118 for C type complex  
and that has to be something else, perhaps 'C'.

----------
components: Library (Lib)
files: struct_size_t.patch
keywords: patch
messages: 68528
nosy: MrJean1
severity: normal
status: open
title: module struct support for ssize_t and size_t
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10687/struct_size_t.patch

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

From report at bugs.python.org  Sat Jun 21 23:03:00 2008
From: report at bugs.python.org (Angel Freire)
Date: Sat, 21 Jun 2008 21:03:00 +0000
Subject: [New-bugs-announce] [issue3164] cPickle calls to save_string and
	save_unicode with unicode objects.
In-Reply-To: <1214082180.06.0.267605807985.issue3164@psf.upfronthosting.co.za>
Message-ID: <1214082180.06.0.267605807985.issue3164@psf.upfronthosting.co.za>


New submission from Angel Freire <cuerty at gmail.com>:

If Python trunk is compiled using Py_USING_UNICODE it'll call both,
save_str and save_unicode for an string object.

The patch adds a break to the case statment in case it encounters a
unicode or str.

----------
components: Library (Lib)
files: cpickle-unicode-r64448.diff
keywords: patch
messages: 68541
nosy: cuerty
severity: normal
status: open
title: cPickle calls to save_string and save_unicode with unicode objects.
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10692/cpickle-unicode-r64448.diff

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

From report at bugs.python.org  Sat Jun 21 23:10:51 2008
From: report at bugs.python.org (Angel Freire)
Date: Sat, 21 Jun 2008 21:10:51 +0000
Subject: [New-bugs-announce] [issue3165] cPickle recursion problem
In-Reply-To: <1214082651.25.0.91375820207.issue3165@psf.upfronthosting.co.za>
Message-ID: <1214082651.25.0.91375820207.issue3165@psf.upfronthosting.co.za>


New submission from Angel Freire <cuerty at gmail.com>:

A single Picklerobject->nesting++ will not take into consideration the
stack overhead caused by calls from
save->save_{list,dict}->batch{list,dict}.

----------
components: Library (Lib)
files: cpickle-r64448.diff
keywords: patch
messages: 68544
nosy: cuerty
severity: normal
status: open
title: cPickle recursion problem
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10693/cpickle-r64448.diff

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

From report at bugs.python.org  Sat Jun 21 23:12:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 Jun 2008 21:12:00 +0000
Subject: [New-bugs-announce] [issue3166] Make conversions from long to float
	correctly rounded.
In-Reply-To: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za>
Message-ID: <1214082720.03.0.30402071522.issue3166@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

If n is a Python long, then one might expect float(n) to return the 
closest float to n.  Currently it doesn't do this.  For example (with 
Python 2.6, on OS X 10.5.2/Intel):

>>> n = 295147905179352891391L

The closest float to n is equal to n+1.  But float(n) returns the 
further of the two floats bracketing n, equal to n-65535:

>>> float(n)
2.9514790517935283e+20
>>> long(float(n))
295147905179352825856L
>>> n - long(float(n))
65535L

It's fairly straightforward to fix PyLong_AsDouble to return the closest 
double to a given long integer n (using the round-half-to-even rule in 
the case of a tie).  The attached patch does this.

Having a correctly rounded float(n) can be useful for testing other 
floating-point routines that are supposed to be correctly rounded.

----------
components: Interpreter Core
files: long_as_double.patch
keywords: patch
messages: 68545
nosy: marketdickinson
severity: normal
status: open
title: Make conversions from long to float correctly rounded.
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10694/long_as_double.patch

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

From report at bugs.python.org  Sat Jun 21 23:47:23 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 21 Jun 2008 21:47:23 +0000
Subject: [New-bugs-announce] [issue3167] math test fails on Solaris 10
In-Reply-To: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za>
Message-ID: <1214084843.86.0.546906644926.issue3167@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

There are 2 math test failures with 32-bit Python 2.6b1 and 3.0b1 on 
Solaris 10 both built with Sun's C compiler.  The failures do *not* 
occur for the 64-bit builds.  The same compiler options are used for all 
these builds (except -xtarget=native vs -xtarget=native64).
 

======================================================================
FAIL: testLog (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 419, in testLog
    self.assertRaises(ValueError, math.log, NINF)
AssertionError: ValueError not raised

======================================================================
FAIL: testLog10 (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 441, in testLog10
    self.assertRaises(ValueError, math.log10, NINF)
AssertionError: ValueError not raised

----------------------------------------------------------------------

----------
components: Tests
messages: 68548
nosy: MrJean1
severity: normal
status: open
title: math test fails on Solaris 10
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 21 23:54:37 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 21 Jun 2008 21:54:37 +0000
Subject: [New-bugs-announce] [issue3168] cmath test fails on Solaris 10
In-Reply-To: <1214085277.51.0.978703410568.issue3168@psf.upfronthosting.co.za>
Message-ID: <1214085277.51.0.978703410568.issue3168@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

There is on cmath test failure with 64-bit Python 2.6b1 and 3.0b1 on 
Solaris 10.  The failure does not occur in the 32-bit builds.

All builds are compiled with Sun's C compiler using the same options 
(except -xtarget=native vs -xtarget=native64).


======================================================================
FAIL: test_cmath_matches_math (__main__.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_cmath.py", line 294, in test_cmath_matches_math
    self.rAssertAlmostEqual(math.log(v, base), z.real)
  File "Lib/test/test_cmath.py", line 128, in rAssertAlmostEqual
    self.fail("%s and %s are not sufficiently close" % (repr(a), 
repr(b)))
AssertionError: 6.6438561897747244 and 0.71244141339823108 are not 
sufficiently close

----------
components: Tests
messages: 68549
nosy: MrJean1
severity: normal
status: open
title: cmath test fails on Solaris 10
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun 22 01:58:58 2008
From: report at bugs.python.org (Jason Williams)
Date: Sat, 21 Jun 2008 23:58:58 +0000
Subject: [New-bugs-announce] [issue3169] email/header.py doesn't handle
	Base64 headers that have been insufficiently padded.
In-Reply-To: <1214092738.57.0.399756790289.issue3169@psf.upfronthosting.co.za>
Message-ID: <1214092738.57.0.399756790289.issue3169@psf.upfronthosting.co.za>


New submission from Jason Williams <williamsjj at digitar.com>:

email/header.py:decode_header() Line 95: dec = 
email.base64mime.decode(encoded)

Headers that contain Subject or From headers which are Base64 encoded 
and are insufficiently padded raise a HeaderParseError. The actual 
padding error is begin generated in binascii.a2b_base64 and bubbling up 
as a HeaderParseError in header.py. 

decode_header() should detect the padding error (Base64 text length does 
not evenly divide by 3) and automatically add padding before handing off 
to a2b_base64. The problem usually occurs with spam.

Example problem header:
Subject: =?iso-8859-1?B?
UHJldmVudCBGb3JlY2xvc3VyZSAmIFNhdmUgWW91ciBIb21lIA=?=


Properly Padded:
Subject: =?iso-8859-1?B?
UHJldmVudCBGb3JlY2xvc3VyZSAmIFNhdmUgWW91ciBIb21lIA==?=

----------
components: Library (Lib)
messages: 68553
nosy: jasonjwwilliams
severity: normal
status: open
title: email/header.py doesn't handle Base64 headers that have been insufficiently padded.
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 22 05:47:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Jun 2008 03:47:07 +0000
Subject: [New-bugs-announce] [issue3170] test_pydoc has no way to regenerate
	pristine data
In-Reply-To: <1214106427.35.0.304484848957.issue3170@psf.upfronthosting.co.za>
Message-ID: <1214106427.35.0.304484848957.issue3170@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test_pydoc relies on pristine data to verify that the tests pass.
Unfortunately there is no automated way to regenerate that pristine
data, making the test easily fail if something global (e.g., __loader__
attributes on all modules) is introduced.

This was seen on Python 3.0 but might also be an issue in 2.6.

----------
assignee: benjamin.peterson
components: Tests
messages: 68556
nosy: benjamin.peterson, brett.cannon
priority: low
severity: normal
status: open
title: test_pydoc has no way to regenerate pristine data
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun 22 07:51:39 2008
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 22 Jun 2008 05:51:39 +0000
Subject: [New-bugs-announce] [issue3171] operator.*slice() should be
	deprecated in 2.6
In-Reply-To: <1214113899.38.0.968396659077.issue3171@psf.upfronthosting.co.za>
Message-ID: <1214113899.38.0.968396659077.issue3171@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

operator.delslice() and friends were removed in Python 3.0, as the
underlying object methods no longer exist. In the same way that the
slicing special methods were deprecated in favour of the item methods
should the functions in the operator module be deprecated (or at least
receive a warning that they will disappear in future interpreter versions).

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 68558
nosy: georg.brandl, scoder
severity: normal
status: open
title: operator.*slice() should be deprecated in 2.6
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 23 00:54:12 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 22 Jun 2008 22:54:12 +0000
Subject: [New-bugs-announce] [issue3172] test macos skipped "unexpected" on
	linux2
In-Reply-To: <1214175252.59.0.0667405723612.issue3172@psf.upfronthosting.co.za>
Message-ID: <1214175252.59.0.0667405723612.issue3172@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

Test test_macos is reported as an "unexpected skip" on linux2 by Python 
2.6b1 make test.

35 tests skipped:
    ...
    test_macos test_macostools ...
    ...
2 skips unexpected on linux2:
    test_tcl test_macos

$ uname -a
Linux ... 2.6.9-11.EL #1 Fri May 20 18:17:57 EDT 2005 i686 i686 i386 
GNU/Linux

$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)

----------
components: Tests
messages: 68593
nosy: MrJean1
severity: normal
status: open
title: test macos skipped "unexpected" on linux2
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 23 04:44:53 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 23 Jun 2008 02:44:53 +0000
Subject: [New-bugs-announce] [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

Back in April we had a thread on xmlrpclib's problematic handling of dates
before 1900:

    http://thread.gmane.org/gmane.comp.python.devel/93273/focus=93309

I'm still of the opinion that strftime() is the culprit and xmlrpclib is
just an innocent bystander.  Guido worried that to correct this we'd have 
to
implement strftime() from scratch.

I took a different approach and scouted around for an existing version of
strftime() which we could suck into the distribution.  I found a modified
version of the BSD 4.4 strftime which came with (I see to recall) Tcl.
The attached patch is against the py3k svn repo.  It passes all tests as
far as I can tell.

Also, see http://bugs.python.org/issue1777412 which appears to be related.

----------
files: strftime.diff
keywords: patch, patch
messages: 68603
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: external strftime for Python?
versions: Python 3.0
Added file: http://bugs.python.org/file10704/strftime.diff

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

From report at bugs.python.org  Mon Jun 23 09:52:43 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Mon, 23 Jun 2008 07:52:43 +0000
Subject: [New-bugs-announce] [issue3174] 3.0b1 doesn't seem to install on
	macs
In-Reply-To: <1214207562.58.0.0463418278377.issue3174@psf.upfronthosting.co.za>
Message-ID: <1214207562.58.0.0463418278377.issue3174@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

Revision r63851 [1] by Benjamin Peterson removed a couple mac scripts, 
including cachersrc.py. Unfortunately, this script is still referenced in 
Mac/Makefile.in, so it fails to install on my mac. Anyone have a 
workaround I could add for packaging this up for macports?

[1]: http://svn.python.org/view?rev=63851&view=rev

----------
components: Installation
messages: 68614
nosy: erickt
severity: normal
status: open
title: 3.0b1 doesn't seem to install on macs
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun 23 11:08:05 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Mon, 23 Jun 2008 09:08:05 +0000
Subject: [New-bugs-announce] [issue3175] multiprocessing build fails on
	Fedora 8 and Xubuntu 8 + solution
In-Reply-To: <1214212085.7.0.171574365182.issue3175@psf.upfronthosting.co.za>
Message-ID: <1214212085.7.0.171574365182.issue3175@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

I built Python 30b1 from the tarball on Fedora 8 and Xubuntu 8.
My only configure switch was --prefix to get a local build.

On both systems the only build error I got was:

Failed to find the necessary bits to build these modules:
_gestalt

which shouldn't matter because it is a Mac thing not a Linux thing (and
already reported)---there were no other error messages, so no warning
that multiprocessing wasn't working.

Running make test does _not_ indicate any problem with the
multiprocessing module (same output on both systems):

302 tests OK.
21 tests skipped:
    test_bsddb3 test_cProfile test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_kqueue test_normalization test_ossaudiodev test_pep277
    test_socketserver test_startfile test_timeout test_urllib2net
    test_urllibnet test_winreg test_winsound test_xmlrpc_net
    test_zipfile64
Those skips are all expected on linux2.

If I run test_multiprocessing.py manually from the _build_ directory it
works fine.

But if I use the locally installed Python 3 (soft linked to python3 in
my PATH), on both systems I get this:

: python3 -V
Python 3.0b1
: python3 Lib/test/test_multiprocessing.py
Traceback (most recent call last):
  File "Lib/test/test_multiprocessing.py", line 19, in <module>
import multiprocessing.dummy
ImportError: No module named multiprocessing.dummy

Now given that the tests all pass it seemed to me that the problem was
with the build rather than with the module itself, and that led to the
solution, which for both systems is the same simple command:

cp -R ~/download/Python-3.0b1/Lib/multiprocessing
~/opt/python30b1/lib/python3.0

So it seems that although the shared library is copied correctly from
the build directory, what has been forgotten is to copy the
multiprocessing directory itself.

----------
components: Build
messages: 68618
nosy: mark
severity: normal
status: open
title: multiprocessing build fails on Fedora 8 and Xubuntu 8 + solution
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun 23 12:57:39 2008
From: report at bugs.python.org (Hiweed)
Date: Mon, 23 Jun 2008 10:57:39 +0000
Subject: [New-bugs-announce] [issue3176] result error for 2/5 and 4/5
In-Reply-To: <1214218656.43.0.217751702107.issue3176@psf.upfronthosting.co.za>
Message-ID: <1214218656.43.0.217751702107.issue3176@psf.upfronthosting.co.za>


New submission from Hiweed <hiweed at gmail.com>:

On IDLE 3.0b1 (Windows XP SP3):
 - type 2/5 you'll get 0.40000000000000002 instead of 0.4
 - type 4/5 you'll get 0.80000000000000004 instead of 0.8

----------
components: IDLE, Windows
messages: 68620
nosy: hiweed
severity: normal
status: open
title: result error for 2/5 and 4/5
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun 23 13:38:25 2008
From: report at bugs.python.org (Young-Ho Cha)
Date: Mon, 23 Jun 2008 11:38:25 +0000
Subject: [New-bugs-announce] [issue3177] os.startfile implement in posix and
	MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>


New submission from Young-Ho Cha <ganadist at gmail.com>:

Currently, os.startfile is implemented in Win32 only, but there are
command line tools in Unix and MacOSX that have same behavior.

As a result of http://portland.freedesktop.org, unix desktop has command
line tool named "xdg-open"
(http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html).

And MacOSX has 'open'
(http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/open.1.html)
command, and it can be used in same condition.

----------
components: Library (Lib)
messages: 68623
nosy: ganadist
severity: normal
status: open
title: os.startfile implement in posix and MacOSX
type: feature request

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

From report at bugs.python.org  Mon Jun 23 15:01:19 2008
From: report at bugs.python.org (Pyry Pakkanen)
Date: Mon, 23 Jun 2008 13:01:19 +0000
Subject: [New-bugs-announce] [issue3178] __radd__(self,
	other) isn't called if self and other are of the same class
In-Reply-To: <1214226078.67.0.621506907984.issue3178@psf.upfronthosting.co.za>
Message-ID: <1214226078.67.0.621506907984.issue3178@psf.upfronthosting.co.za>


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

>>> class test: 
... 	def __radd__(self,other):
... 		return '__radd__ called'
... 
>>> t = test()
>>> 1 + t
'__radd__ called'
>>> t + t
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'test' and 'test'


This applies to all of the reflected operations.

----------
messages: 68625
nosy: Frosburn
severity: normal
status: open
title: __radd__(self,other) isn't called if self and other are of the same class
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Mon Jun 23 16:42:13 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 23 Jun 2008 14:42:13 +0000
Subject: [New-bugs-announce] [issue3179] cPickle is seriously broken
In-Reply-To: <1214232133.4.0.366608731079.issue3179@psf.upfronthosting.co.za>
Message-ID: <1214232133.4.0.366608731079.issue3179@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

import cPickle

res=[]
for x in range(1,2000):
    res.append(dict(doc=x, similar=[]))

cPickle.dumps(res)


Traceback (most recent call last):
  File "pi.py", line 10, in <module>
cPickle.dumps(res)
RuntimeError: maximum recursion depth exceeded

svn r64471 seems to cause the problematic behaviour.

facundo, you committed that one.

----------
messages: 68629
nosy: facundobatista, schmir
severity: normal
status: open
title: cPickle is seriously broken
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 23 18:32:23 2008
From: report at bugs.python.org (Michael Abbott)
Date: Mon, 23 Jun 2008 16:32:23 +0000
Subject: [New-bugs-announce] [issue3180] Interrupts are lost during readline
	PyOS_InputHook processing
In-Reply-To: <1214238743.53.0.342771827236.issue3180@psf.upfronthosting.co.za>
Message-ID: <1214238743.53.0.342771827236.issue3180@psf.upfronthosting.co.za>


New submission from Michael Abbott <michael at araneidae.co.uk>:

The (undocumented!) API for PyOS_InputHook has two defects which are
addressed in the attached patch (at least when using the readline
module): firstly the called hook currently has to guess that input will
come on descriptor 0; secondly, any Ctrl-C interrupts encountered during
the processing of the input hook are lost.

This loss of interrupts can be rather annoying.  The attached patch
addresses these problems by redefining the API to PyOS_InputHook as 

    int PyOS_InputHook(int file_in);

where file_in is the descriptor to monitor (PyOS_InputHook need not
return until file_in is ready to read), and the return value is non-zero
if and only if processing was interrupted.

Testing for interruption is implemented in the HAVE_RL_CALLBACK and
HAVE_SELECT branch of Modules/readline.c; other uses retain their
original functionality (I believe!).

The attached patch was prepared against
http://svn.python.org/projects/python/trunk , current at the time of
writing.

----------
components: None
files: input-hook.patch
keywords: patch
messages: 68638
nosy: Araneidae
severity: normal
status: open
title: Interrupts are lost during readline PyOS_InputHook processing
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10709/input-hook.patch

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

From report at bugs.python.org  Mon Jun 23 18:48:09 2008
From: report at bugs.python.org (Ari Makela)
Date: Mon, 23 Jun 2008 16:48:09 +0000
Subject: [New-bugs-announce] [issue3181] ConfigParsers are classic classes
In-Reply-To: <1214239689.68.0.615869985575.issue3181@psf.upfronthosting.co.za>
Message-ID: <1214239689.68.0.615869985575.issue3181@psf.upfronthosting.co.za>


New submission from Ari Makela <hauva at arska.org>:

The base class, ConfigParser.RawConfigParser does not inherit object and
therefore it is a classic class.

Test script run with my normal python installation:

$ /usr/bin/python -V
Python 2.5.2

$ /usr/bin/python arska/configparser.py
bar

And run with uptodate svn checkout with modified ConfigParser.py

$ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python -V
Python 2.6b1+

$ LD_LIBRARY_PATH=/usr/local/lib arska/configparser.py
Setting value=bar
Getting value=bar
bar

Platform: Kubuntu 8.04.
$ uname -a
Linux laphroaig 2.6.24-19-generic #1 SMP Wed Jun 4 15:10:52 UTC 2008
x86_64 GNU/Linux

The test script and diff -u as attachments.

----------
components: Library (Lib)
files: configparser.diff
keywords: patch
messages: 68639
nosy: hauva
severity: normal
status: open
title: ConfigParsers are classic classes
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10710/configparser.diff

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

From report at bugs.python.org  Mon Jun 23 19:25:44 2008
From: report at bugs.python.org (Nick Edds)
Date: Mon, 23 Jun 2008 17:25:44 +0000
Subject: [New-bugs-announce] [issue3182] 2to3 Slight Patch
In-Reply-To: <1214241944.19.0.631532213789.issue3182@psf.upfronthosting.co.za>
Message-ID: <1214241944.19.0.631532213789.issue3182@psf.upfronthosting.co.za>


New submission from Nick Edds <nedds at uchicago.edu>:

This is a small patch to the 2to3 tool, replacing some calls to
isinstance (x,y) with type(x) is y in the file pytree.py. Although there
is only a slight performance increase for each time this change is made,
the recursive nature of pattern matching means that isinstance was being
calling hundreds of thousands of times per file, so overall these minor
changes result in a 3-4% speed increase in my limited testing. It
currently fails only one test due to line 432 in test_pytree, because I
had to rename the type parameter to new_type so I could call type() on
something. But with the line in the test file changed, it passes all tests.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: pytree.py
messages: 68641
nosy: collinwinter, nedds
severity: normal
status: open
title: 2to3 Slight Patch
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file10713/pytree.py

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

From report at bugs.python.org  Mon Jun 23 21:38:29 2008
From: report at bugs.python.org (Ralf W. Grosse-Kunstleve)
Date: Mon, 23 Jun 2008 19:38:29 +0000
Subject: [New-bugs-announce] [issue3183] sha modules & Modules/Setup.dist
In-Reply-To: <1214249909.74.0.55822821087.issue3183@psf.upfronthosting.co.za>
Message-ID: <1214249909.74.0.55822821087.issue3183@psf.upfronthosting.co.za>


New submission from Ralf W. Grosse-Kunstleve <rwgk at yahoo.com>:

It would be very useful to add two lines to Modules/Setup.dist:

Index: Modules/Setup.dist
===================================================================
--- Modules/Setup.dist  (revision 64489)
+++ Modules/Setup.dist  (working copy)
@@ -249,6 +249,8 @@
 # The _sha module implements the SHA checksum algorithm.
 # (NIST's Secure Hash Algorithm.)
 #_sha shamodule.c
+#_sha256 sha256module.c
+#_sha512 sha512module.c


 # SGI IRIX specific modules -- off by default.


Background:

- Python built on machine A and distributed to end-users.
  Machine A happens to have the OpenSSL libraries.

- End-user runs our package incl. the pre-built Python on
  machine B, which happens not to have the OpenSSL libraries,
  or an incompatible version.

- hashlib imports _hashlib, which fails because of the
  OpenSSL problem.

- hashlib tries to fall back to generic sha and md5 modules.
  I had _sha and md5 enabled in Modules/Setup.dist, but
  didn't know Python 2.5 needs more.

I found this out the hard way. It would be helpful to at least
have the extra two comments as suggested above. I think it would
be even better to not comment out the md5 and sha modules in
the original Python distribution since it just adds about 200k
of .o files (Linux). That's very cheap compared to the loss
in time if people have to figure out why import hashlib is
failing and how to work around the problem.

----------
components: Installation
messages: 68644
nosy: rwgk
severity: normal
status: open
title: sha modules & Modules/Setup.dist
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 24 01:13:42 2008
From: report at bugs.python.org (David Gladstein)
Date: Mon, 23 Jun 2008 23:13:42 +0000
Subject: [New-bugs-announce] [issue3184] The elementtree.ElementTree Module
	doc is missing
In-Reply-To: <1214262821.99.0.303167473736.issue3184@psf.upfronthosting.co.za>
Message-ID: <1214262821.99.0.303167473736.issue3184@psf.upfronthosting.co.za>


New submission from David Gladstein <david.gladstein at theorphanage.com>:

The documentation from
http://www.effbot.org/zone/pythondoc-elementtree-ElementTree.htm
is missing. Without it the module is pretty much impossible to use,
unless you know about the effbot pages.

----------
assignee: georg.brandl
components: Documentation
messages: 68659
nosy: georg.brandl, gladstein
severity: normal
status: open
title: The elementtree.ElementTree Module doc is missing
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun 24 07:53:04 2008
From: report at bugs.python.org (Carsten Grohmann)
Date: Tue, 24 Jun 2008 05:53:04 +0000
Subject: [New-bugs-announce] [issue3185] Documentation of time.time()
	differs from source documentation
In-Reply-To: <1214286784.44.0.321359332465.issue3185@psf.upfronthosting.co.za>
Message-ID: <1214286784.44.0.321359332465.issue3185@psf.upfronthosting.co.za>


New submission from Carsten Grohmann <cgrohmann at users.sourceforge.net>:

The current python documentation of the time module
(http://docs.python.org/lib/module-time.html) means that time.time()
returns the "seconds since the epoch, in UTC".

But in the current source documentation of the time module
(http://svn.python.org/view/python/trunk/Modules/timemodule.c?rev=64048&view=markup)
is written that "time() -- return current time in seconds since the Epoch". 

time.time() returns the current local unix seconds during tests on a
system using Python 2.5.

Please adapt the documentation.

Thanks,
Carsten

----------
assignee: georg.brandl
components: Documentation
messages: 68666
nosy: cgrohmann, georg.brandl
severity: normal
status: open
title: Documentation of time.time() differs from source documentation
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun 24 10:55:48 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 Jun 2008 08:55:48 +0000
Subject: [New-bugs-announce] [issue3186] bin(long) doesn't have a trailing
	'L'
In-Reply-To: <1214297748.38.0.171793356702.issue3186@psf.upfronthosting.co.za>
Message-ID: <1214297748.38.0.171793356702.issue3186@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In Python 2.6, for a long n, hex(n) and oct(n) have a trailing 'L', while 
bin(n) does not:

>>> hex(1L)
'0x1L'
>>> oct(1L)
'01L'
>>> bin(1L)
'0b1'

I'm guessing that this is intentional, and that the only reason hex(n) and 
oct(n) still have a trailing 'L' is backwards compatibility, but I thought 
I'd better check.

----------
assignee: rhettinger
messages: 68672
nosy: marketdickinson, rhettinger
severity: normal
status: open
title: bin(long) doesn't have a trailing 'L'
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 24 12:28:27 2008
From: report at bugs.python.org (Helmut Jarausch)
Date: Tue, 24 Jun 2008 10:28:27 +0000
Subject: [New-bugs-announce] [issue3187] os.walk - strange bug
In-Reply-To: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>
Message-ID: <1214303307.09.0.102277146744.issue3187@psf.upfronthosting.co.za>


New submission from Helmut Jarausch <jarausch at skynet.be>:

The script below produces 1664 lines of output before it bails out with
Traceback (most recent call last):
  File "WalkBug.py", line 5, in <module>
for Dir, SubDirs, Files in os.walk('/home/jarausch') :
  File "/usr/local/lib/python3.0/os.py", line 278, in walk
for x in walk(path, topdown, onerror, followlinks):
  File "/usr/local/lib/python3.0/os.py", line 268, in walk
if isdir(join(top, name)):
  File "/usr/local/lib/python3.0/posixpath.py", line 64, in join
if b.startswith('/'):
TypeError: expected an object with the buffer interface

=========================
file  WalkBug.py:

#!/usr/local/bin/python3.0

import os

for Dir, SubDirs, Files in os.walk('/home/jarausch') :
  print("processing {0:d} files in {1}".format(len(Files),Dir))

----------
components: Library (Lib)
messages: 68674
nosy: HWJ
severity: normal
status: open
title: os.walk - strange bug
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Tue Jun 24 12:47:35 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 Jun 2008 10:47:35 +0000
Subject: [New-bugs-announce] [issue3188] float('infinity') should be valid
In-Reply-To: <1214304455.81.0.663476079399.issue3188@psf.upfronthosting.co.za>
Message-ID: <1214304455.81.0.663476079399.issue3188@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

2.6 adds float('inf') and float('nan') as cross-platform ways to 
generate infinities and NaNs.  The C99 standard (section 7.20.1.3, 
paragraph 3) specifies that 'infinity' (in any case, with optional 
preceding sign) should also be a valid input to strtod, and I propose 
that in Python float('infinity') should correspondingly be valid.

Note that the IEEE 754 standard also states that 'inf' and 'infinity' 
should be valid input string representations of infinity, and Python's 
decimal module also allows both 'inf' and 'infinity'.

A patch is attached.

Unless I'm mistaken, this change is simple and unlikely to be 
controversial.  I plan to check it in in a week or two if there's no 
feedback before then.

----------
assignee: marketdickinson
files: infinity.patch
keywords: patch
messages: 68675
nosy: christian.heimes, marketdickinson
severity: normal
status: open
title: float('infinity') should be valid
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0
Added file: http://bugs.python.org/file10716/infinity.patch

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

From report at bugs.python.org  Tue Jun 24 13:36:12 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 24 Jun 2008 11:36:12 +0000
Subject: [New-bugs-announce] [issue3189] Py3k DeprecationWarning in difflib
In-Reply-To: <1214307372.86.0.564003200617.issue3189@psf.upfronthosting.co.za>
Message-ID: <1214307372.86.0.564003200617.issue3189@psf.upfronthosting.co.za>


New submission from Virgil Dupras <hsoft at hardcoded.net>:

When running with the -3 flag, difflib creates DeprecationWarnings. I 
attach a patch fixing them.

There was a note in the code saying "DOES NOT WORK for x in a". However, 
after my changes, tests still pass, so I removed these notices. If someone 
knows what this was all about, let me know.

----------
components: Library (Lib)
files: difflib_py3k_deprecation.diff
keywords: patch
messages: 68677
nosy: vdupras
severity: normal
status: open
title: Py3k DeprecationWarning in difflib
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10717/difflib_py3k_deprecation.diff

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

From report at bugs.python.org  Tue Jun 24 14:18:44 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 Jun 2008 12:18:44 +0000
Subject: [New-bugs-announce] [issue3190] Pydoc should ignore __package__
	attributes
In-Reply-To: <1214309924.87.0.972230589947.issue3190@psf.upfronthosting.co.za>
Message-ID: <1214309924.87.0.972230589947.issue3190@psf.upfronthosting.co.za>


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

Pydoc doesn't display the standard special attributes for packages and
modules (__name__, __file__, __path__).

It shouldn't display PEP 361's new __package__ attribute either.

----------
assignee: ncoghlan
components: Library (Lib)
messages: 68682
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Pydoc should ignore __package__ attributes
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Jun 24 17:03:38 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 Jun 2008 15:03:38 +0000
Subject: [New-bugs-announce] [issue3191] round docstring is inaccurate
In-Reply-To: <1214319817.88.0.0731467937099.issue3191@psf.upfronthosting.co.za>
Message-ID: <1214319817.88.0.0731467937099.issue3191@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In Python 3.0, help(round) gives the following:

round(...)
    round(number[, ndigits]) -> floating point number
    
    Round a number to a given precision in decimal digits (default 0 
digits).
    This returns an int when called with one argument, otherwise a 
float.
    Precision may be negative.

But in Python 3.x, round(x, n) doesn't always return a float;  for 
example, if x is a Decimal or Fraction then round(x, 2) is again a 
Decimal or Fraction (respectively).

----------
assignee: georg.brandl
components: Documentation
messages: 68690
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: round docstring is inaccurate
versions: Python 3.0

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

From report at bugs.python.org  Tue Jun 24 22:45:47 2008
From: report at bugs.python.org (Mike Speciner)
Date: Tue, 24 Jun 2008 20:45:47 +0000
Subject: [New-bugs-announce] [issue3192] exec(open(filename)) doesn't work
In-Reply-To: <1214340347.28.0.744958218652.issue3192@psf.upfronthosting.co.za>
Message-ID: <1214340347.28.0.744958218652.issue3192@psf.upfronthosting.co.za>


New submission from Mike Speciner <speciner_michael at emc.com>:

In 2.5, exec(open(filename)), where filename refers to a file with
python code, executes the code.
In 2.5, open returns an open file, but in 3.0, open returns a stream,
and so exec (which wants "a string, file, or code object, not
TextIOWrapper") returns an error. exec should probably be able to handle
a stream.

----------
components: Interpreter Core
messages: 68700
nosy: ms
severity: normal
status: open
title: exec(open(filename)) doesn't work
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Jun 25 01:44:24 2008
From: report at bugs.python.org (Peter Dilley)
Date: Tue, 24 Jun 2008 23:44:24 +0000
Subject: [New-bugs-announce] [issue3193] Python 2.5.2 - Python[2420:613]
	Error loading / flat namespace error
In-Reply-To: <1214351063.94.0.70881873047.issue3193@psf.upfronthosting.co.za>
Message-ID: <1214351063.94.0.70881873047.issue3193@psf.upfronthosting.co.za>


New submission from Peter Dilley <peterdilley at gmail.com>:

I have noticed a new crash when using pyglet module after installing 
the latest Apple security patch/framework for Quicktime, Quicktime 
Framework 7.5.0.

This error is repeatable.

This error occurs when the opened window is selected/made active with 
the mouse pointer.

This error occured when using OpenGL.

Session below:
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) 
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from pyglet.gl import *
>>> window = pyglet.window.Window()
>>> @window.event
... def on_draw():
...     glClear(GL_COLOR_BUFFER_BIT)
...     glLoadIdentity()
...     glBegin(GL_TRIANGLES)
...     glVertex2f(0, 0)
...     glVertex2f(window.width, 0)
...     glVertex2f(window.width, window.height)
...     glEnd()
... 
>>> pyglet.app.run()
2008-06-24 20:14:06.232 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.239 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.245 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.249 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.256 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.262 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.268 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.274 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.302 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.308 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.380 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.387 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.394 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.400 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.407 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.413 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.433 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.449 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.456 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.561 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.568 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.575 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.583 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace
2008-06-24 20:14:06.589 Python[2420:613] Error 
loading /Library/QuickTime/DivX 6 Decoder.component/Contents/MacOS/DivX 
6 Decoder:  dlopen(/Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder, 262): Symbol not 
found: _GetDataHandler
  Referenced from: /Library/QuickTime/DivX 6 
Decoder.component/Contents/MacOS/DivX 6 Decoder
  Expected in: flat namespace

----------
components: None
files: Pyglet 1.1 Beta 2 GL crash after selecting window making active.rtf
messages: 68711
nosy: peterdilley
severity: normal
status: open
title: Python 2.5.2 - Python[2420:613] Error loading / flat namespace error
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file10723/Pyglet 1.1 Beta 2 GL crash after selecting window making active.rtf

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

From report at bugs.python.org  Wed Jun 25 05:25:26 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Wed, 25 Jun 2008 03:25:26 +0000
Subject: [New-bugs-announce] [issue3194] Demo/loop.c passing "char *"
	instead of "wchar_t *"
In-Reply-To: <1214364326.35.0.217778159942.issue3194@psf.upfronthosting.co.za>
Message-ID: <1214364326.35.0.217778159942.issue3194@psf.upfronthosting.co.za>


New submission from Rafael Zanella <rafael.zanella at yahoo.com.br>:

The Demo/loop.c passes a char pointer (argv[0]) while 
Py_SetProgramName() now expects a wchar_t pointer.

I've attached a patch, the solution on the patch was borrowed,
ok stolen, from Python/frozenmain.c

----------
files: loop_c.diff
keywords: patch
messages: 68715
nosy: zanella
severity: normal
status: open
title: Demo/loop.c passing "char *" instead of "wchar_t *"
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file10725/loop_c.diff

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

From report at bugs.python.org  Wed Jun 25 11:09:16 2008
From: report at bugs.python.org (Pavel Strashkin)
Date: Wed, 25 Jun 2008 09:09:16 +0000
Subject: [New-bugs-announce] [issue3195] invalid conversion
	xml.etree.ElementTree.Element object to boolean
In-Reply-To: <1214384956.08.0.408285823661.issue3195@psf.upfronthosting.co.za>
Message-ID: <1214384956.08.0.408285823661.issue3195@psf.upfronthosting.co.za>


New submission from Pavel Strashkin <xaka2004 at gmail.com>:

Python 2.5.2 (r252:60911, May  7 2008, 15:19:09)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import Element
>>> e = Element('Test', {'attr' : 'value'})
>>> b = not e
>>> print b
True

Why i'm getting True here instead of False?
Because of this i can not do:
if not e:
    # here some logic
    pass

----------
components: XML
messages: 68720
nosy: xaka
severity: normal
status: open
title: invalid conversion xml.etree.ElementTree.Element object to boolean
versions: Python 2.5

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

From report at bugs.python.org  Wed Jun 25 11:32:35 2008
From: report at bugs.python.org (Morten Lied Johansen)
Date: Wed, 25 Jun 2008 09:32:35 +0000
Subject: [New-bugs-announce] [issue3196] Option in pydoc to show docs from
	private methods
In-Reply-To: <1214386355.64.0.670337337662.issue3196@psf.upfronthosting.co.za>
Message-ID: <1214386355.64.0.670337337662.issue3196@psf.upfronthosting.co.za>


New submission from Morten Lied Johansen <mortenjo at ifi.uio.no>:

Currently, running pydoc on a module will show you the documentation on 
all regular methods, and all special methods (starting and ending in 
double underscores).

Private methods (starting with a single underscore) are not included.

Some times, it would be nice to include docs for these methods aswell, 
and a small change to pydoc.visiblename solves the problem.

I've included a patch that adds this behaviour as an option (-i for 
include private names). The implementation isn't as clean as one would 
hope for (sets a global flag), but was the best I could come up with in 
the short time I had available. Feel free to make a better 
implementation.

The patch is against python 2.5.

----------
components: Library (Lib)
files: pydoc.privatenames.patch
keywords: patch
messages: 68722
nosy: mortenlj
severity: normal
status: open
title: Option in pydoc to show docs from private methods
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file10727/pydoc.privatenames.patch

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

From report at bugs.python.org  Wed Jun 25 13:22:37 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 25 Jun 2008 11:22:37 +0000
Subject: [New-bugs-announce] [issue3197] Documentation for fractions module
	needs work
In-Reply-To: <1214392956.96.0.593199677678.issue3197@psf.upfronthosting.co.za>
Message-ID: <1214392956.96.0.593199677678.issue3197@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The documentation for the fractions module needs some rewriting---it 
contains minor inaccuracies, outdated statements (e.g. the regex is 
incomplete), and there are places that could use some clarification (e.g. 
the description of __round__).

I plan to take care of this in the next few days, unless anyone else wants 
to have a look.  I'm making an issue of it so that it doesn't get 
forgotten.

----------
assignee: marketdickinson
components: Documentation
messages: 68724
nosy: jyasskin, marketdickinson
priority: normal
severity: normal
status: open
title: Documentation for fractions module needs work
versions: Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Wed Jun 25 15:33:51 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 25 Jun 2008 13:33:51 +0000
Subject: [New-bugs-announce] [issue3198] strings don't seem to roundtrip
	with repr()
In-Reply-To: <1214400831.94.0.306229718194.issue3198@psf.upfronthosting.co.za>
Message-ID: <1214400831.94.0.306229718194.issue3198@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

With 2.5.2 and 30b1 strings don't round trip like numbers do.

I guess it has been like this a long time so isn't a bug, but it does
seem inconsistent.

Both 2.5.2 and 30b1:

>>> x = 5
>>> x == int(repr(x))
True
>>> x = "Test Text"
>>> x == str(repr(x))
False

The reason is that an extra set of enclosing quotes are added.

----------
components: Interpreter Core
messages: 68728
nosy: mark
severity: normal
status: open
title: strings don't seem to roundtrip with repr()
type: behavior
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Wed Jun 25 16:32:36 2008
From: report at bugs.python.org (John Abel)
Date: Wed, 25 Jun 2008 14:32:36 +0000
Subject: [New-bugs-announce] [issue3199] 2.6b1 Build Fails On OSX 10.5
In-Reply-To: <1214404356.07.0.352296574281.issue3199@psf.upfronthosting.co.za>
Message-ID: <1214404356.07.0.352296574281.issue3199@psf.upfronthosting.co.za>


New submission from John Abel <john.abel at ccj-online.co.uk>:

The build process on Leopard fails:

cd Mac && make altinstallunixtools DESTDIR=""
if [ ! -d "/usr/local/bin" ]; then  \
		/usr/bin/install -c -d -m 755 "/usr/local/bin" ;\
	fi
for fn in python2.6 pythonw2.6 idle2.6 \
		  pydoc2.6 python2.6-config) smtpd2.6.py ;\
	do \
		ln -fs 
"/Library/Frameworks/Python.framework/Versions/2.6/bin/${fn}" 
"/usr/local/bin/${fn}" ;\
	done
/bin/sh: -c: line 0: syntax error near unexpected token `)'
/bin/sh: -c: line 0: `for fn in python2.6 pythonw2.6 idle2.6 	  
pydoc2.6 python2.6-config) smtpd2.6.py ;do 	ln -fs 
"/Library/Frameworks/Python.framework/Versions/2.6/bin/${fn}" 
"/usr/local/bin/${fn}" ;done'
make[1]: *** [altinstallunixtools] Error 2
make: *** [frameworkaltinstallunixtools] Error 2

To fix, remove the additional ) following -config on line 116 of 
Mac/Makefile:

                  pydoc$(VERSION) python$(VERSION)-config) 
smtpd$(VERSION).py ;\

----------
components: Build
messages: 68730
nosy: johna
severity: normal
status: open
title: 2.6b1 Build Fails On OSX 10.5
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 25 19:27:53 2008
From: report at bugs.python.org (Eric Sadit)
Date: Wed, 25 Jun 2008 17:27:53 +0000
Subject: [New-bugs-announce] [issue3200] Python's crash in heavy
	multithreading IO operations
In-Reply-To: <1214414872.83.0.448936700487.issue3200@psf.upfronthosting.co.za>
Message-ID: <1214414872.83.0.448936700487.issue3200@psf.upfronthosting.co.za>


New submission from Eric Sadit <donsadit at gmail.com>:

Hello,

I found a rare bug in heavy multithreading IO operations. The bug arises
under a stupid sequence of I/O operations. The sequence is not a normal
one, but the real problem is that the Python's interpreter crashes. The
correct behavior should be raise an IOError exception (I think).

The bug occurs when some thread closes a file or socket whilst other
thread tries to read or write from the same socket. The failure it's
inside the fileobject.c because tries to read or write the specified
data size inside a loop without check in every iteration if the object
is closed (it checks only outside the loop). The file object is set to
NULL and a SIGSEGV happens.

I'm a python developer (in the language, but not developer of the
language), so i really don't know anything about the best way to solve
this issue, and how the project it's managed. I can develop an script to
raise this bug if anyone it's interested in this problem. I'm already
owns one, but I don't find it, and the real program that arises the
error was rewritten so i don't have it.

Cheers

Eric Sadit

----------
components: Interpreter Core, Library (Lib)
messages: 68736
nosy: sadit
severity: normal
status: open
title: Python's crash in heavy multithreading IO operations
type: crash
versions: Python 2.3, Python 2.4, Python 2.5

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

From report at bugs.python.org  Wed Jun 25 21:18:49 2008
From: report at bugs.python.org (Eric Vander Weele)
Date: Wed, 25 Jun 2008 19:18:49 +0000
Subject: [New-bugs-announce] [issue3201] struct.Struct size attribute
	undocumented
In-Reply-To: <1214421529.06.0.941954130673.issue3201@psf.upfronthosting.co.za>
Message-ID: <1214421529.06.0.941954130673.issue3201@psf.upfronthosting.co.za>


New submission from Eric Vander Weele <ericvw at gmail.com>:

The .size attribute of struct.Struct is undocumented on
http://docs.python.org/lib/struct-objects.html

----------
assignee: georg.brandl
components: Documentation
messages: 68743
nosy: ericvw, georg.brandl
severity: normal
status: open
title: struct.Struct size attribute undocumented
versions: Python 2.5

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

From report at bugs.python.org  Wed Jun 25 21:53:28 2008
From: report at bugs.python.org (Justin Mazzola Paluska)
Date: Wed, 25 Jun 2008 19:53:28 +0000
Subject: [New-bugs-announce] [issue3202] Wish: disable tests in unittest
In-Reply-To: <1214423608.55.0.624662877506.issue3202@psf.upfronthosting.co.za>
Message-ID: <1214423608.55.0.624662877506.issue3202@psf.upfronthosting.co.za>


New submission from Justin Mazzola Paluska <jmp at mit.edu>:

The attached patch (unittest-disable.patch) allows methods in
unittest.TestCases to be "disabled".  The patch is against
Python2.5 from Debian:

%python2.5
Python 2.5.2 (r252:60911, Apr 17 2008, 13:15:05) 
[GCC 4.2.3 (Debian 4.2.3-3)] on linux2

Disabled tests are not run, but are "remembered" in the output of the
test program.  For example, the attached sample_tests.py has two
tests, one of which has been disabled.  The output is:

%python sample_tests.py 
.D
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

where the D indicates that a test has been disabled.

Disabling tests is useful if you're using a "test first" coding
workflow, as some tests may test functionality that hasn't been
implemented yet.  The failures of these tests (with their noisy
tracebacks) makes it harder to concentrate on other, real failures
that may be occurring in your tests.

----------
components: Library (Lib)
files: unittest-disable.patch
keywords: patch
messages: 68752
nosy: jmp
severity: normal
status: open
title: Wish: disable tests in unittest
versions: Python 2.5
Added file: http://bugs.python.org/file10735/unittest-disable.patch

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

From report at bugs.python.org  Wed Jun 25 22:36:28 2008
From: report at bugs.python.org (Gerard M. Flanagan)
Date: Wed, 25 Jun 2008 20:36:28 +0000
Subject: [New-bugs-announce] [issue3203] sphinx - table of contents doesn't
	render correctly (html)
In-Reply-To: <1214426188.21.0.172463487619.issue3203@psf.upfronthosting.co.za>
Message-ID: <1214426188.21.0.172463487619.issue3203@psf.upfronthosting.co.za>


New submission from Gerard M. Flanagan <grflanagan at gmail.com>:

A TOC tree should render in HTML as a single 'ul', but in certain
circumstances it appears as multiple ul's.

You can see the effect here:

    http://docs.python.org/dev/c-api/index.html

and in fact in the Sphinx documentation itself:

    http://sphinx.pocoo.org/contents.html

the 'toctree' here is not an individual entity but a vertical series of
ul's, each of which has a *single* item (li). You may be able to see the
slightly increased space between the ul's which would not be present if
these were all the children of a single parent.

This should be changed so that pages have a unique 'toc' element because:

- it would be easier for css and javascript to manipulate
- there may be accessibility issues (eg. non-visual readers may not 
identify the toc as a single sequence of alternatives)

The reason for the current behaviour can be found in the method
'resolve_toctree' of class sphinx.environment.BuildEnvironment, line 863::

      newnode = addnodes.compact_paragraph('', '', *tocentries)

`tocentries` is a list of `toctrees` [<toctree>, <toctree>,..] each of
which will end up as a ul, while a compact_paragraph has no html
representation; hence the observed effect.

One way to fix this is to replace the above line with the following::

        newnode = nodes.bullet_list()
        for entry in tocentries:
            for item in entry.children:
                assert isinstance(item, nodes.list_item)
                newnode.append(item)

(and you can also take the opportunity here to add a unique id::

        newnode['ids'].append('toc')
)

Note that this new code is a noop if `tocentries` only has one element,
at least as far as html is concerned.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 68756
nosy: georg.brandl, grflanagan
severity: normal
status: open
title: sphinx - table of contents doesn't render correctly (html)
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Jun 26 09:58:31 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 26 Jun 2008 07:58:31 +0000
Subject: [New-bugs-announce] [issue3204] operator module docs are not
	updated to 3.0
In-Reply-To: <1214467110.98.0.886196184715.issue3204@psf.upfronthosting.co.za>
Message-ID: <1214467110.98.0.886196184715.issue3204@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

__*slice__() methods of sequence-like objects are removed in Python 3.0,
but "operator.rst" has sections on *slice()/__*slice__() functions.
Attached patch removes this functions from documentation.

----------
assignee: georg.brandl
components: Documentation
files: operator.rst.diff
keywords: patch
messages: 68766
nosy: georg.brandl, mishok13
severity: normal
status: open
title: operator module docs are not updated to 3.0
versions: Python 3.0
Added file: http://bugs.python.org/file10739/operator.rst.diff

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

From report at bugs.python.org  Thu Jun 26 11:08:21 2008
From: report at bugs.python.org (Michiel de Hoon)
Date: Thu, 26 Jun 2008 09:08:21 +0000
Subject: [New-bugs-announce] [issue3205] bz2 iterator fails silently on
	MemoryError
In-Reply-To: <1214471301.68.0.267247122126.issue3205@psf.upfronthosting.co.za>
Message-ID: <1214471301.68.0.267247122126.issue3205@psf.upfronthosting.co.za>


New submission from Michiel de Hoon <mdehoon at users.sourceforge.net>:

PyMem_Malloc is called in the Util_ReadAhead function in bz2module.c.
The code checks if PyMem_Malloc returns NULL, but in that case no
MemoryError is raised. So, if in the following code:

>>> input = bz2.BZ2File("myfile.txt.bz2")
>>> for line in input:
...     # do something with the line

Python runs out of memory during the for-loop, then the for-loop exits
without an Exception being raised. To the user, it appears that the end
of the myfile.txt.bz2 file was reached and that no error occurred.

In the attached patch, I call PyErr_NoMemory() if PyMem_Malloc fails.
This then raises the MemoryError exception as appropriate.

----------
components: Extension Modules
files: bz2module.c.patch
keywords: patch
messages: 68770
nosy: mdehoon
severity: normal
status: open
title: bz2 iterator fails silently on MemoryError
type: behavior
Added file: http://bugs.python.org/file10740/bz2module.c.patch

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

From report at bugs.python.org  Thu Jun 26 11:53:18 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Thu, 26 Jun 2008 09:53:18 +0000
Subject: [New-bugs-announce] [issue3206] Multiprocessing Array and
	sharedctypes.Array error in docs/implementation
In-Reply-To: <1214473998.34.0.913565828871.issue3206@psf.upfronthosting.co.za>
Message-ID: <1214473998.34.0.913565828871.issue3206@psf.upfronthosting.co.za>


New submission from Andrii V. Mishkovskyi <mishok13 at gmail.com>:

multiprocessing.sharedctypes.Array and
multiprocessing.sharedctypes.Value if used according to documentation
fail with AssertionError.

Python 3.0b1+ (py3k:64518, Jun 25 2008, 12:52:38)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import sharedctypes
>>> sharedctypes.Array('i', 1, lock=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/multiprocessing/sharedctypes.py", line
88, in Array
assert hasattr(lock, 'acquire')
AssertionError
>>> sharedctypes.Array('i', 1, lock=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/multiprocessing/sharedctypes.py", line
88, in Array
assert hasattr(lock, 'acquire')
AssertionError
>>> sharedctypes.Array('i', 1, lock=None)
<SynchronizedArray wrapper for
<multiprocessing.sharedctypes.c_long_Array_1 object at 0x83214f4>>
>>> Value('i', lock=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/multiprocessing/__init__.py", line 246,
in Value
return Value(typecode_or_type, *args, **kwds)
  File "/usr/local/lib/python3.0/multiprocessing/sharedctypes.py", line
75, in Value
assert hasattr(lock, 'acquire')
AssertionError

The same goes for multiprocessing.Array and multiprocessing.Value.

Comparing code to documentation it's obvious that lock argument can be
one of Lock, RLock or None objects (or any object with "acquire"
attribute), but not True or False. Also, looking at the code it seems
strange to me that 'lock' is a keyword-only argument. Why not use simple
default argument "lock=None" for Array() function?
Proposed patch tries to address these issues.

----------
components: Library (Lib)
messages: 68771
nosy: jnoller, mishok13, roudkerk
severity: normal
status: open
title: Multiprocessing Array and sharedctypes.Array error in docs/implementation
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 26 12:48:30 2008
From: report at bugs.python.org (Peter)
Date: Thu, 26 Jun 2008 10:48:30 +0000
Subject: [New-bugs-announce] [issue3207] file.write() after file.readline()
	in mode "r+"
In-Reply-To: <1214477310.64.0.211264115228.issue3207@psf.upfronthosting.co.za>
Message-ID: <1214477310.64.0.211264115228.issue3207@psf.upfronthosting.co.za>


New submission from Peter <poslano at gmail.com>:

Following code:
   fp = open("delete.me", "r+t")
   fp.readline()
   fp.write("New line \n")
   fp.close()

Won't do anything. I mean nor writing to file, nor raising exception. 
Nothing.
I can't find any note about this crap. So, it is the best place for it.

P.S. It's my first bug-report and I think I was wrong in filling bug-
form. Sorry.

----------
assignee: georg.brandl
components: Documentation
messages: 68773
nosy: georg.brandl, peterdemin
severity: normal
status: open
title: file.write() after file.readline() in mode "r+"
type: performance
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun 26 15:16:25 2008
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 26 Jun 2008 13:16:25 +0000
Subject: [New-bugs-announce] [issue3208] function annotation for builtin and
	C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

It is better if the function annotation(PEP 3107) can be supported by
built-in function and C function writtin in extension module, just like
the __doc__ attribute.

----------
messages: 68783
nosy: bhy
severity: normal
status: open
title: function annotation for builtin and C function
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Thu Jun 26 16:30:44 2008
From: report at bugs.python.org (Michael Schreifels)
Date: Thu, 26 Jun 2008 14:30:44 +0000
Subject: [New-bugs-announce] [issue3209] Grammar error in UserDict module
	docs
In-Reply-To: <1214490644.18.0.458364716656.issue3209@psf.upfronthosting.co.za>
Message-ID: <1214490644.18.0.458364716656.issue3209@psf.upfronthosting.co.za>


New submission from Michael Schreifels <contact at michaelschreifels.com>:

The second paragraph of the UserDict module documentation begins with this:

"This also module defines a class..."

which should be:

"This module also defines a class..."

(See http://docs.python.org/lib/module-UserDict.html )

----------
assignee: georg.brandl
components: Documentation
messages: 68784
nosy: georg.brandl, technel
severity: normal
status: open
title: Grammar error in UserDict module docs

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

From report at bugs.python.org  Thu Jun 26 17:22:42 2008
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 26 Jun 2008 15:22:42 +0000
Subject: [New-bugs-announce] [issue3210] subprocess.Popen does not release
	process handles if process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

Run the following code on Windows:

import subprocess, os

file = open("filename", "w")
try:
    proc = subprocess.Popen("nosuchprogram", stdout=file)
except OSError:
    file.close()
    os.remove("filename")

This produces the following exception:

Traceback (most recent call last):
  File "C:\processown.py", line 10, in <module>
    os.remove("filename")
WindowsError: [Error 32] The process cannot access the file because it
is being used by another process: 'filename'

When the CreateProcess call fails the subprocess module should release
the handles it provides. Unfortunately it seems to raise WindowsError
before doing this.

See also
http://groups.google.com/group/comp.lang.python/browse_thread/thread/6157691ea3324779/6274e9f8bc8a71ee?hl=en#6274e9f8bc8a71ee

As Tim Golden points out, this can be worked around by doing
os.close(file.fileno()) at the end instead of file.close()

----------
components: Extension Modules
messages: 68787
nosy: gjb1002
severity: normal
status: open
title: subprocess.Popen does not release process handles if process cannot be started
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Jun 26 18:44:30 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 26 Jun 2008 16:44:30 +0000
Subject: [New-bugs-announce] [issue3211] warnings.warn_explicit raises
	SystemError
In-Reply-To: <1214498670.25.0.948302654046.issue3211@psf.upfronthosting.co.za>
Message-ID: <1214498670.25.0.948302654046.issue3211@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Python 2.6b1+ (trunk:64531M, Jun 26 2008, 10:40:14)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn_explicit(None, UserWarning, None, 0, None, {})
None:0: UserWarning: None
>>> warnings.warn_explicit(None, UserWarning, None, 0, None, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/dictobject.c:677: bad argument to internal function
>>>

----------
components: Library (Lib)
messages: 68791
nosy: exarkun
severity: normal
status: open
title: warnings.warn_explicit raises SystemError
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 26 20:34:14 2008
From: report at bugs.python.org (Jonas Wagner)
Date: Thu, 26 Jun 2008 18:34:14 +0000
Subject: [New-bugs-announce] [issue3212] ssl module - should test for a
	wrong cert
In-Reply-To: <1214505254.08.0.113211233471.issue3212@psf.upfronthosting.co.za>
Message-ID: <1214505254.08.0.113211233471.issue3212@psf.upfronthosting.co.za>


New submission from Jonas Wagner <veers at gmx.ch>:

Currently test_ssl.py only tests for empty or broken certificates. One
can break certificate validation in _ssl.c and they still pass.

The following patch should fix this.

- Jonas

----------
components: Tests
files: add_wrong_cert_test.diff
keywords: patch
messages: 68797
nosy: janssen, jonas.wagner
severity: normal
status: open
title: ssl module - should test for a wrong cert
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10745/add_wrong_cert_test.diff

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

From report at bugs.python.org  Fri Jun 27 02:11:29 2008
From: report at bugs.python.org (Hans Ulrich Niedermann)
Date: Fri, 27 Jun 2008 00:11:29 +0000
Subject: [New-bugs-announce] [issue3213] "pydoc -p" should listen to [::] if
	IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>


New submission from Hans Ulrich Niedermann <hun at n-dimensional.de>:

According to "pydoc --help",

pydoc -p <port>
    Start an HTTP server on the given port on the local machine.

The IP address pydoc binds to is not specified, thus I would expect it
to either bind to the local address or to the wildcard address.

Current behaviour of "pydoc -p 1234" is to bind to the IPv4-only 
address 0.0.0.0:1234.

On a IPv4/IPv6 dual-stack machine, I would expect pydoc to listen to
either both 127.0.0.1:1234 and [::1]:<port>, or just [::]:<port> ([::]
also catches accesses to IPv4 addresses such as 127.0.0.1).

Then access to the pydoc webserver is
available both via IPv4 (e.g. http://127.0.0.1:1234/) and IPv6 (e.g.
http://[::1]:1234/), and in both cases via http://localhost:1234/
regardless whether localhost is resolved via IPv6 or IPv4.

Trivial patch attached (tested on Linux x86 machine with local IPv6
networking).

----------
components: Library (Lib)
files: python-pydoc-p-ipv6.patch
keywords: patch
messages: 68811
nosy: ndim
severity: normal
status: open
title: "pydoc -p" should listen to [::] if IPv6 is supported
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10748/python-pydoc-p-ipv6.patch

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

From report at bugs.python.org  Fri Jun 27 07:11:00 2008
From: report at bugs.python.org (Paddy McCarthy)
Date: Fri, 27 Jun 2008 05:11:00 +0000
Subject: [New-bugs-announce] [issue3214] Suggest change to glossary
	explanation: "Duck Typing"
In-Reply-To: <1214543459.76.0.157400708153.issue3214@psf.upfronthosting.co.za>
Message-ID: <1214543459.76.0.157400708153.issue3214@psf.upfronthosting.co.za>


New submission from Paddy McCarthy <paddy3118 at users.sourceforge.net>:

The official glossary entry here:
http://docs.python.org/tut/node18.html#l2h-46
says:
"
duck-typing
    Pythonic programming style that determines an object's type by
inspection of its method or attribute signature rather than by
explicit relationship to some type object ("If it looks like a duck
and quacks like a duck, it must be a duck.") By emphasizing interfaces
rather than specific types, well-designed code improves its
flexibility by allowing polymorphic substitution. Duck-typing avoids
tests using type() or isinstance(). Instead, it typically employs
hasattr() tests or EAFP programming.
"

I think it is should be changed to delete the use of hasattr and just
rely on EAFP as in the second example here:
http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Exceptions

The text would then read:
"
duck-typing
    Pythonic programming style that determines an object's type by
inspection of its method or attribute signature rather than by
explicit relationship to some type object ("If it looks like a duck
and quacks like a duck, it must be a duck.") By emphasizing interfaces
rather than specific types, well-designed code improves its
flexibility by allowing polymorphic substitution. Duck-typing avoids
tests using type(), hasattr() or isinstance(). Instead, it typically
employs an EAFP style of programming.
"

The reason is that a hasattr test only tests for an attribute name. If
it is present and say the method signature is wrong, then its the
excecution of the code using the attribute that will find that out so
it is redundant. Best to use EAFP for Duck typing as we trust you know
what it is you are doing.

- Paddy.

----------
assignee: georg.brandl
components: Documentation
messages: 68815
nosy: georg.brandl, paddy3118
severity: normal
status: open
title: Suggest change to glossary explanation:  "Duck Typing"
type: feature request
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun 27 15:14:02 2008
From: report at bugs.python.org (Craig Holmquist)
Date: Fri, 27 Jun 2008 13:14:02 +0000
Subject: [New-bugs-announce] [issue3215] Can't import sqlite3 in Python 2.6b1
In-Reply-To: <1214572442.55.0.146238509349.issue3215@psf.upfronthosting.co.za>
Message-ID: <1214572442.55.0.146238509349.issue3215@psf.upfronthosting.co.za>


New submission from Craig Holmquist <craig at neurotronics.com>:

This is observed on Windows XP; I don't know if it affects other platforms.

Trying to import sqlite3 gives this error:
>>> import sqlite3

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    import sqlite3
  File "C:\Python26\Lib\sqlite3\__init__.py", line 24, in <module>
    from dbapi2 import *
  File "C:\Python26\lib\sqlite3\dbapi2.py", line 27, in <module>
    from _sqlite3 import *
ImportError: DLL load failed: The specified module could not be found.

A look at the dependencies for _sqlite3.pyd shows that it's trying to
link to a file called sqlite3.pyd, which doesn't exist.  Renaming
sqlite3.dll to sqlite3.pyd doesn't work either, because then "import
sqlite3" causes Python to try to import that file as a Python module
(instead of C:\Python26\Lib\sqlite3\__init__.py).

In Python 2.5.2, the _sqlite3.pyd module correctly links to sqlite3.dll.

If there's already an issue regarding this I couldn't find it.

----------
components: Extension Modules, Windows
messages: 68827
nosy: craigneuro
severity: normal
status: open
title: Can't import sqlite3 in Python 2.6b1
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 27 16:37:50 2008
From: report at bugs.python.org (Sjoerd Mullender)
Date: Fri, 27 Jun 2008 14:37:50 +0000
Subject: [New-bugs-announce] [issue3216] errors in msilib documentation
In-Reply-To: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>
Message-ID: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>


New submission from Sjoerd Mullender <sjoerd at acm.org>:

There are several errors in the msilib documentation.  I'm sure I
haven't found them all, but here are some:

- add_data is documented to have two arguments.  In reality it has three.
- Execute on a View object is documented to have an optional argument. 
In reality it has a single required argument whose value may be None.
- When I click on any of the references to Microsoft documentation, I
get a page in Japanese.  This is possibly more due to Microsoft than
anything else (the links do contain en-us so it is a tad surprising).
- There is extremely little information on how to actually use the module.

----------
assignee: georg.brandl
components: Documentation
messages: 68831
nosy: georg.brandl, sjoerd
severity: normal
status: open
title: errors in msilib documentation
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun 27 18:14:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Jun 2008 16:14:34 +0000
Subject: [New-bugs-announce] [issue3217] make text is broken
In-Reply-To: <1214583274.28.0.668624284342.issue3217@psf.upfronthosting.co.za>
Message-ID: <1214583274.28.0.668624284342.issue3217@psf.upfronthosting.co.za>


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

Traceback (most recent call last):
  File "/temp/python/trunk/Doc/tools/sphinx/__init__.py", line 135, in main
    app.builder.build_update()
  File "/temp/python/trunk/Doc/tools/sphinx/builder.py", line 199, in
build_update
    'out of date' % len(to_build))
  File "/temp/python/trunk/Doc/tools/sphinx/builder.py", line 238, in build
    self.write(docnames, updated_docnames, method)
  File "/temp/python/trunk/Doc/tools/sphinx/builder.py", line 274, in write
    self.write_doc(docname, doctree)
  File "/temp/python/trunk/Doc/tools/sphinx/builder.py", line 1116, in
write_doc
    self.writer.write(doctree, destination)
  File "/temp/python/trunk/Doc/tools/docutils/writers/__init__.py", line
78, in write
    self.translate()
  File "/temp/python/trunk/Doc/tools/sphinx/textwriter.py", line 33, in
translate
    self.document.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 159, in
walkabout
    child.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 159, in
walkabout
    child.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 159, in
walkabout
    child.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 159, in
walkabout
    child.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 159, in
walkabout
    child.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 159, in
walkabout
    child.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 159, in
walkabout
    child.walkabout(visitor)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 151, in
walkabout
    visitor.dispatch_visit(self)
  File "/temp/python/trunk/Doc/tools/docutils/nodes.py", line 1502, in
dispatch_visit
    return method(node)
  File "/temp/python/trunk/Doc/tools/sphinx/textwriter.py", line 598, in
unknown_visit
    raise NotImplementedError("Unknown node: " + node.__class__.__name__)
NotImplementedError: Unknown node: subscript

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 68832
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: make text is broken
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jun 27 20:19:07 2008
From: report at bugs.python.org (Nick Edds)
Date: Fri, 27 Jun 2008 18:19:07 +0000
Subject: [New-bugs-announce] [issue3218] 2to3 Fix_imports optimization
In-Reply-To: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>
Message-ID: <1214590746.67.0.566923914778.issue3218@psf.upfronthosting.co.za>


New submission from Nick Edds <nedds at uchicago.edu>:

This is an optimization in pytree.py specifically for the bare_name
pattern from fix_imports.py. It also has the isinstance change I
previously suggested piggybacked onto it. Because the bare_name pattern
is so massive (764 nodes!), it is very slow to call _recursive_matches
on it. This fix has a special bare_name_matches fix that uses an
iterative matching solution specifically tailored to the bare_name
pattern. From preliminary testing, it appears to be roughly 25-30%
faster than the previous version of 2to3. If I uncomment the fix_imports
test, it fails 6 of them, but they are the same ones failed by the
current version of 2to3 and it fails them in the same way, so I think it
works. As with my previous isinstance chance, a one line change to
test_pytree is required.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: pytree.py
messages: 68840
nosy: collinwinter, nedds
severity: normal
status: open
title: 2to3 Fix_imports optimization
type: performance
Added file: http://bugs.python.org/file10751/pytree.py

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

From report at bugs.python.org  Fri Jun 27 21:17:46 2008
From: report at bugs.python.org (ganges master)
Date: Fri, 27 Jun 2008 19:17:46 +0000
Subject: [New-bugs-announce] [issue3219] repeated keyword arguments
In-Reply-To: <1214594266.45.0.948323179256.issue3219@psf.upfronthosting.co.za>
Message-ID: <1214594266.45.0.948323179256.issue3219@psf.upfronthosting.co.za>


New submission from ganges master <gangesmaster at users.sourceforge.net>:

under python 2.5 (and possibly 2.6 beta), the following code runs
successfully:

>>> def f(**kwargs):
...     print kwargs
...
>>> f(a=5,b=7,a=8)
{'a': 8, 'b': 7}

while in python 2.4, it fails as expected (complaining that "a" is given
twice")

http://mail.python.org/pipermail/python-dev/2008-June/080782.html

----------
components: Interpreter Core
messages: 68847
nosy: gangesmaster
severity: normal
status: open
title: repeated keyword arguments
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jun 27 21:47:12 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jun 2008 19:47:12 +0000
Subject: [New-bugs-announce] [issue3220] Improve Bytes and Byte Array
	Methods doc
In-Reply-To: <1214596032.47.0.841255812222.issue3220@psf.upfronthosting.co.za>
Message-ID: <1214596032.47.0.841255812222.issue3220@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Lib Ref/Built-in Types/Sequence Types/Bytes and Byte Array Methods

The following set/frozenset and dict sections repeat (and for dicts,
expands upon) the constructor interface from the Built-in Functions
section.  The sequence type sections do not.  There should as least be a
reference back.  "For the constructor interface, see xxx"

Similarly there is no mention here of the difference between bytes and
bytearray, as there is below for the difference between set and
frozenset.  I think there should be here, in this section, even though
there is back in Built-in Functions.

(Sets/frozenset have the opposite problem in that Built-in Functions
makes no mention that one is mutable and the other is not.  I also think
just one word for each should be added there too.)

"The bytes and bytearray types have an additional class method:
bytes.fromhex(string) " should be followed by
"bytearray.fromhex(string)" and
"This bytes class method returns a bytes object," changed to
"These class methods return a bytes or bytearray object,"

I don't think the line 'Example:' is needed.

A thread today on the Py3 lists again brought up the issue that just as
bytes can be created by either a literal or class call, they could be
represented on output by either, with possible confusion.
Guido responded
> Only if you didn't know that b'' is an alternative to bytes(). The b''
> notation is so much more compact and so  much more helpful that I
> really don't want to go back to it. We will somehow have to deal with
> this through education and documentation.

I suggest adding at the end:
"Just as a bytes objects can be constructed either with a literal or a
class constructor call, they could be represented on output either by a
literal or class constructor call.  The literal was chosen as being
shorter, generally more useful, and consistent with how other classes
are displayed.  Similarly, the display of bytearrays uses the
corresponding bytes literal.  If you want to see the bytes of either
class as integers, use tuple.

>>> a, b = b'abc', bytes((1,2,3))
>>> a,b
(b'abc', b'\x01\x02\x03')
>>> tuple(a), tuple(b)
((97, 98, 99), (1, 2, 3))
>>> c = bytearray(a)
>>> c, tuple(c)
(bytearray(b'abc'), (97, 98, 99))
"

----------
assignee: georg.brandl
components: Documentation
messages: 68848
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Improve Bytes and Byte Array Methods doc
versions: Python 3.0

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

From report at bugs.python.org  Fri Jun 27 22:35:29 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 27 Jun 2008 20:35:29 +0000
Subject: [New-bugs-announce] [issue3221] SystemError: Parent module 'foo'
	not loaded on import statement
In-Reply-To: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>
Message-ID: <1214598929.49.0.609710487655.issue3221@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

The following short program work in python 2.5, but does die with a
SystemError in python2.6:

~/ cat t.py 
#! /usr/bin/env python

res = dict(__package__='foo')
exec "from os import path" in res
~/ python2.5 t.py 
~/ python2.6 t.py 
Traceback (most recent call last):
  File "t.py", line 4, in <module>
exec "from os import path" in res
  File "<string>", line 1, in <module>
SystemError: Parent module 'foo' not loaded



I think this has been introduced with svn revision 42649
(http://hgpy.de/py/trunk/rev/54c72e1678d68ebbf274)

Part of the diff reads:
        modules = PyImport_GetModuleDict();
        parent = PyDict_GetItemString(modules, buf);
        if (parent == NULL)
-               parent = Py_None;
+               PyErr_Format(PyExc_SystemError,
+                               "Parent module '%.200s' not loaded", buf);
        return parent;
        /* We expect, but can't guarantee, if parent != None, that:

----------
messages: 68850
nosy: schmir
severity: normal
status: open
title: SystemError: Parent module 'foo' not loaded on import statement
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 27 22:44:53 2008
From: report at bugs.python.org (Mike Speciner)
Date: Fri, 27 Jun 2008 20:44:53 +0000
Subject: [New-bugs-announce] [issue3222] inf*inf gives inf,
	but inf**2 gives overflow error
In-Reply-To: <1214599493.01.0.661310273111.issue3222@psf.upfronthosting.co.za>
Message-ID: <1214599493.01.0.661310273111.issue3222@psf.upfronthosting.co.za>


New submission from Mike Speciner <speciner_michael at emc.com>:

Tried this on wintel 32-bit
(3.0b1 (r30b1:64403M, Jun 19 2008, 14:56:09) [MSC v.1500 32 bit (Intel)]

----------
messages: 68853
nosy: ms
severity: normal
status: open
title: inf*inf gives inf, but inf**2 gives overflow error
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Jun 27 23:01:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Jun 2008 21:01:09 +0000
Subject: [New-bugs-announce] [issue3223] py3k warn on use of frame.f_exc*
In-Reply-To: <1214600469.72.0.692863353975.issue3223@psf.upfronthosting.co.za>
Message-ID: <1214600469.72.0.692863353975.issue3223@psf.upfronthosting.co.za>


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

f_exc_value and friends are no longer available in 3.0 and should get a
Py3k warning on use.

----------
keywords: easy
messages: 68855
nosy: benjamin.peterson
priority: high
severity: normal
status: open
title: py3k warn on use of frame.f_exc*
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 28 06:01:58 2008
From: report at bugs.python.org (Chris AtLee)
Date: Sat, 28 Jun 2008 04:01:58 +0000
Subject: [New-bugs-announce] [issue3224] Small typo in 2.6 what's new
In-Reply-To: <1214625718.52.0.484421456661.issue3224@psf.upfronthosting.co.za>
Message-ID: <1214625718.52.0.484421456661.issue3224@psf.upfronthosting.co.za>


New submission from Chris AtLee <chris at atlee.ca>:

Index: Doc/whatsnew/2.6.rst
===================================================================
--- Doc/whatsnew/2.6.rst	(revision 64571)
+++ Doc/whatsnew/2.6.rst	(working copy)
@@ -1284,7 +1284,7 @@
 Here are all of the changes that Python 2.6 makes to the core Python
language.
 
 * The :func:`hasattr` function was catching and ignoring all errors,
-  under the assumption that they meant a :meth:`__getattr__` method has 
+  under the assumption that they meant a :meth:`__getattr__` method was 
   failing somewhere and the return value of :func:`hasattr` would therefore
   be ``False``.  This logic shouldn't be applied to 
   :exc:`KeyboardInterrupt` and :exc:`SystemExit`, however; Python 2.6 will

----------
assignee: georg.brandl
components: Documentation
messages: 68868
nosy: catlee, georg.brandl
severity: normal
status: open
title: Small typo in 2.6 what's new
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 28 13:30:19 2008
From: report at bugs.python.org (kai zhu)
Date: Sat, 28 Jun 2008 11:30:19 +0000
Subject: [New-bugs-announce] [issue3225] backport python 3.0 language
	functionality to python 2.5 by adding 8 opcodes to ceval.c
In-Reply-To: <1214652619.02.0.198443521566.issue3225@psf.upfronthosting.co.za>
Message-ID: <1214652619.02.0.198443521566.issue3225@psf.upfronthosting.co.za>


New submission from kai zhu <davidbranniganz at gmail.com>:

this patch touches only Python/ceval.c.

1. the only existing thing it modifies is PyEval_EvalFrameEx (adds 8
extra cases for the new 3.0 opcodes, doesn't mess w/ any of the existing
ones, or anything else as a matter of fact)

2. that, plus it defines (the new opcodes)
#define SET_ADD 17            
#define STORE_MAP 54          
#define STORE_LOCALS 69       
#define LOAD_BUILD_CLASS 34   
#define MAKE_BYTES 35         
#define POP_EXCEPT 36         
#define UNPACK_EX 94          
#define BUILD_SET 109         
and some backported vars & helper functions

only 2 contiguous areas of ceval.c is patched (1. & 2. - areas are
delimited by the comments '// py3k')

this simple patch seems sufficient in theory to allow the interpreter to
natively execute most of 3.0's language syntax (nonlocal, print,
extended unpacking... have been tested to work)
*the one exception being pep3102 - keyword-only arguments

i wrote 2 small scripts which gives an interactive function
'compile_py3k' similar to __builtin__.compile except it works only for
3.0 syntax.  it doesn't actually compile, but rather cheats by querying
it to a python 3.0 server via pipe io.

here is an interactive demonstration of my script:

example demonstrating pep3132 extended unpacking syntax: a,b,*c = 1,2,3,4

Python 2.5.2 (r252:60911, Jun 27 2008, 21:19:51)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import py3to2
py3to2 server restarting with io: (4, 5)
py3to2 server: Python 3.0b1 (r30b1:64395, Jun 24 2008, 21:53:55)
py3to2 server: [GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] on linux2
py3to2 server: Type "help", "copyright", "credits" or "license" for more
information.
py3to2 server: 

>>> src = "a,b,*c = 1,2,3,4"
>>> codeobject = py3to2.compile_py3k(src,"","exec")
  1           0 LOAD_CONST               5 ((1, 2, 3, 4))
              3 UNPACK_EX_py3k           2
              6 STORE_NAME               0 (a)
              9 STORE_NAME               1 (b)
             12 STORE_NAME               2 (c)
             15 LOAD_CONST               4 (None)
             18 RETURN_VALUE

>>> exec(codeobject); print "a=%s, b=%s, c=%s"%(a,b,c)
a=1, b=2, c=[3, 4]
>>>

u can go c
http://pypi.python.org/pypi?name=py3to2&version=20080628&:action=display
for more info

anyway, i think it would b a great boost for python 3.0 (which i think
is very cool) if developers can test/develop it under the robust 2.5
environment.  this patch plus some scripts could go a long way in making
that happen

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: ceval.c
messages: 68873
nosy: collinwinter, kaizhu
severity: normal
status: open
title: backport python 3.0 language functionality to python 2.5 by adding 8 opcodes to ceval.c
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file10758/ceval.c

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

From report at bugs.python.org  Sat Jun 28 18:45:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 28 Jun 2008 16:45:32 +0000
Subject: [New-bugs-announce] [issue3226] can't install on OSX 10.4
In-Reply-To: <1214671532.34.0.878967964042.issue3226@psf.upfronthosting.co.za>
Message-ID: <1214671532.34.0.878967964042.issue3226@psf.upfronthosting.co.za>


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

Mac/Makefile.in uses the arch command which doesn't have the ability to
run a given architecture in 10.4 like it does in 10.5. Hence, the
install fails.

----------
assignee: ronaldoussoren
messages: 68879
nosy: benjamin.peterson, ronaldoussoren
priority: release blocker
severity: normal
status: open
title: can't install on OSX 10.4
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sat Jun 28 20:21:55 2008
From: report at bugs.python.org (Joe P. Cool)
Date: Sat, 28 Jun 2008 18:21:55 +0000
Subject: [New-bugs-announce] [issue3227] os.environ.clear has no effect on
	child processes
In-Reply-To: <1214677315.57.0.385885068786.issue3227@psf.upfronthosting.co.za>
Message-ID: <1214677315.57.0.385885068786.issue3227@psf.upfronthosting.co.za>


New submission from Joe P. Cool <joe.p.cool at googlemail.com>:

If I call os.environ.clear in a python program child processes still
see the cleared entries. But when I iterate over the keys like so

names =  os.environ.keys()
for k in names:
    del  os.environ[k]

then the entries are also deleted for the child processes. Where is
the difference? Is this a bug? (Observed in Python 2.5.2)

-- 
Joe

----------
components: Library (Lib)
messages: 68891
nosy: joe.p.cool
severity: normal
status: open
title: os.environ.clear has no effect on child processes
versions: Python 2.5

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

From report at bugs.python.org  Sat Jun 28 21:23:39 2008
From: report at bugs.python.org (Piotr Lewandowski)
Date: Sat, 28 Jun 2008 19:23:39 +0000
Subject: [New-bugs-announce] [issue3228] mailbox.mbox creates files with
	execute bit set
In-Reply-To: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>
Message-ID: <1214681019.85.0.805710619223.issue3228@psf.upfronthosting.co.za>


New submission from Piotr Lewandowski <piotr.lewandowski at gmail.com>:

#v+
$ umask
0077

$ stat /tmp/foobar
stat: cannot stat `/tmp/foobar': No such file or directory

$ python -c "from mailbox import mbox; m=mbox('/tmp/foobar',
create=True); m.add(''); m.close()"

$ stat -c '%A' /tmp/foobar
-rwx------
#v-

Bug is probably present in _create_carefully() function in mailbox.py.
os.open() takes mode argument (which defaults to 0777) but it's not
supplied there.

#v+
$ grep -A2 'def _create_carefully' /usr/lib/python2.5/mailbox.py
def _create_carefully(path):
    """Create a file if it doesn't exist and open for reading and
writing."""
    fd = os.open(path, os.O_CREAT | os.O_EXCL | os.O_RDWR)
#v-

----------
components: Library (Lib)
messages: 68896
nosy: pl
severity: normal
status: open
title: mailbox.mbox creates files with execute bit set
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat Jun 28 22:44:22 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sat, 28 Jun 2008 20:44:22 +0000
Subject: [New-bugs-announce] [issue3229] Language reference,
	class definitions: missing text in "Programmer's note"
In-Reply-To: <1214685862.01.0.416464861432.issue3229@psf.upfronthosting.co.za>
Message-ID: <1214685862.01.0.416464861432.issue3229@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

In the language reference, compound statements, class definitions:
"""
Programmer?s note: Variables defined in the class definition are class can 
be set in a method with self.name = value.
"""

This sentence doesn't is not even grammatically valid. It seems that there 
is something missing after "are class".

See:
http://docs.python.org/dev/3.0/reference/compound_stmts.html#class-
definitions

In 2.5, the corresponding text is:
"""
Programmer's note: Variables defined in the class definition are class 
variables; they are shared by all instances. To define instance variables, 
they must be given a value in the __init__() method or in another method.
"""

----------
assignee: georg.brandl
components: Documentation
messages: 68908
nosy: georg.brandl, oefe
severity: normal
status: open
title: Language reference, class definitions: missing text in "Programmer's note"
versions: Python 3.0

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

From report at bugs.python.org  Sat Jun 28 23:31:47 2008
From: report at bugs.python.org (Martina Oefelein)
Date: Sat, 28 Jun 2008 21:31:47 +0000
Subject: [New-bugs-announce] [issue3230] dictobject.c: inappropriate use of
	PySet_GET_SIZE?
In-Reply-To: <1214688707.09.0.872875806221.issue3230@psf.upfronthosting.co.za>
Message-ID: <1214688707.09.0.872875806221.issue3230@psf.upfronthosting.co.za>


New submission from Martina Oefelein <Martina at oefelein.de>:

The first use of PySet_GET_SIZE in dict_fromkeys (file dictobject.c) is applied to a PyDictObject. These seem to work by chance, as the PyDictObject and PySetObject have very 
similar structure so that it does not matter if you cast a PyDictObject* to a PySetObject*. But if their structure ever diverges, this would cause unpredictable behaviour.

Thus, this use of PySet_GET_SIZE should probably be replaced with a call of PyDict_Size.

(There are two more calls to PySet_GET_SIZE resp. _PySet_NextEntry in the same function, 
but these are OK as they actually apply to a set.)

----------
components: Interpreter Core
messages: 68914
nosy: oefe
severity: normal
status: open
title: dictobject.c: inappropriate use of PySet_GET_SIZE?

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

From report at bugs.python.org  Sun Jun 29 01:11:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Jun 2008 23:11:55 +0000
Subject: [New-bugs-announce] [issue3231] re.compile fails with some bytes
	patterns
In-Reply-To: <1214694715.96.0.79941845541.issue3231@psf.upfronthosting.co.za>
Message-ID: <1214694715.96.0.79941845541.issue3231@psf.upfronthosting.co.za>


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

Some patterns can be compiled in str form but not in bytes form. This
was overlooked because the test suite wasn't correctly adapted for py3k:

>>> re.compile('[\\1]')
<_sre.SRE_Pattern object at 0xb7be1410>
>>> re.compile('\\09')
<_sre.SRE_Pattern object at 0xb7c4f2f0>
>>> re.compile('\\n')
<_sre.SRE_Pattern object at 0xb7be1f50>

but:

>>> re.compile(b'[\\1]')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/reunicode/Lib/re.py", line 188, in compile
return _compile(pattern, flags)
  File "/home/antoine/py3k/reunicode/Lib/re.py", line 240, in _compile
p = sre_compile.compile(pattern, flags)
  File "/home/antoine/py3k/reunicode/Lib/sre_compile.py", line 497, in
compile
p = sre_parse.parse(p, flags)
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 685, in parse
p = _parse_sub(source, pattern, 0)
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 320, in
_parse_sub
itemsappend(_parse(source, state))
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 409, in _parse
this = sourceget()
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 215, in get
self.__next()
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 204, in __next
char = char + c
TypeError: Can't convert 'int' object to str implicitly
>>> re.compile(b'\\09')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/reunicode/Lib/re.py", line 188, in compile
return _compile(pattern, flags)
  File "/home/antoine/py3k/reunicode/Lib/re.py", line 240, in _compile
p = sre_compile.compile(pattern, flags)
  File "/home/antoine/py3k/reunicode/Lib/sre_compile.py", line 497, in
compile
p = sre_parse.parse(p, flags)
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 678, in parse
source = Tokenizer(str)
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 187, in
__init__
self.__next()
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 204, in __next
char = char + c
TypeError: Can't convert 'int' object to str implicitly
>>> re.compile(b'\\n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/reunicode/Lib/re.py", line 188, in compile
return _compile(pattern, flags)
  File "/home/antoine/py3k/reunicode/Lib/re.py", line 240, in _compile
p = sre_compile.compile(pattern, flags)
  File "/home/antoine/py3k/reunicode/Lib/sre_compile.py", line 497, in
compile
p = sre_parse.parse(p, flags)
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 678, in parse
source = Tokenizer(str)
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 187, in
__init__
self.__next()
  File "/home/antoine/py3k/reunicode/Lib/sre_parse.py", line 204, in __next
char = char + c
TypeError: Can't convert 'int' object to str implicitly

----------
components: Regular Expressions
messages: 68925
nosy: pitrou
severity: normal
status: open
title: re.compile fails with some bytes patterns
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun 29 03:03:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jun 2008 01:03:32 +0000
Subject: [New-bugs-announce] [issue3232] Wrong str->bytes conversion in
	Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>


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

Lib/encodings/idna.py claims to do the following when `input` is a
string object (lines 183-184, and see comment line 178: "IDNA allows
decoding to operate on Unicode strings, too"):

            # Force to bytes
            input = bytes(input)

This is obviously wrong, lacking an encoding parameter. It doesn't seem
to be covered in the test suite, and I don't know what the proper
semantics should be, so I leave it to someone else to find a fix.

----------
components: Library (Lib), Unicode
messages: 68931
nosy: pitrou
severity: normal
status: open
title: Wrong str->bytes conversion in Lib/encodings/idna.py
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun 29 10:08:32 2008
From: report at bugs.python.org (Stefan Sonnenberg-Carstens)
Date: Sun, 29 Jun 2008 08:08:32 +0000
Subject: [New-bugs-announce] [issue3233] Timestamp stored in ZIP file not
	correct ?
In-Reply-To: <1214726912.22.0.742655032035.issue3233@psf.upfronthosting.co.za>
Message-ID: <1214726912.22.0.742655032035.issue3233@psf.upfronthosting.co.za>


New submission from Stefan Sonnenberg-Carstens <stefan.sonnenberg at pythonmeister.com>:

Given the attached source, I can produce these results:

[stefan at localhost ~]$ python ziptest.py 
Start 10:05:54
ZIP stored mtime: (2008, 6, 29, 10, 5, 54)
Original mtime: (2008, 6, 29, 10, 5, 54)
Duration 0.00291705131531
Stop 10:05:54
------------------------------
Start 10:05:55
ZIP stored mtime: (2008, 6, 29, 10, 5, 54)
Original mtime: (2008, 6, 29, 10, 5, 55)
Duration 0.00302505493164
Stop 10:05:55
------------------------------
Start 10:05:56
ZIP stored mtime: (2008, 6, 29, 10, 5, 56)
Original mtime: (2008, 6, 29, 10, 5, 56)
Duration 0.00260186195374
Stop 10:05:56
------------------------------
Start 10:05:57
ZIP stored mtime: (2008, 6, 29, 10, 5, 56)
Original mtime: (2008, 6, 29, 10, 5, 57)
Duration 0.00173997879028
Stop 10:05:57
------------------------------
Start 10:05:58
ZIP stored mtime: (2008, 6, 29, 10, 5, 58)
Original mtime: (2008, 6, 29, 10, 5, 58)
Duration 0.00218915939331
Stop 10:05:58
------------------------------
Start 10:05:59
ZIP stored mtime: (2008, 6, 29, 10, 5, 58)
Original mtime: (2008, 6, 29, 10, 5, 59)
Duration 0.00273489952087
Stop 10:05:59
------------------------------
Start 10:06:00
ZIP stored mtime: (2008, 6, 29, 10, 6, 0)
Original mtime: (2008, 6, 29, 10, 6, 0)
Duration 0.00237393379211
Stop 10:06:00
------------------------------
Start 10:06:01
ZIP stored mtime: (2008, 6, 29, 10, 6, 0)
Original mtime: (2008, 6, 29, 10, 6, 1)
Duration 0.00279211997986
Stop 10:06:01
------------------------------
Start 10:06:02
ZIP stored mtime: (2008, 6, 29, 10, 6, 2)
Original mtime: (2008, 6, 29, 10, 6, 2)
Duration 0.00237607955933
Stop 10:06:02
------------------------------
Start 10:06:03
ZIP stored mtime: (2008, 6, 29, 10, 6, 2)
Original mtime: (2008, 6, 29, 10, 6, 3)
Duration 0.0018618106842
Stop 10:06:03
------------------------------


I also printed the duration to see if it passes from one second to another.
It doesn't.
The behaviour is the same with ZIP_STORED as storage type.

----------
components: Library (Lib)
files: ziptest.py
messages: 68934
nosy: pythonmeister
severity: normal
status: open
title: Timestamp stored in ZIP file not correct ?
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10769/ziptest.py

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

From report at bugs.python.org  Sun Jun 29 11:17:26 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Sun, 29 Jun 2008 09:17:26 +0000
Subject: [New-bugs-announce] [issue3234] subprocess.py strips last character
	when raising an AttributeError
In-Reply-To: <1214731045.98.0.584522364195.issue3234@psf.upfronthosting.co.za>
Message-ID: <1214731045.98.0.584522364195.issue3234@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

I try to get working pipe emulation using Popen. I try to pass StringIO
object to p1.stdin of the first process and I got the following:

  File "/usr/lib/python2.5/subprocess.py", line 587, in __init__
    errread, errwrite) = self._get_handles(stdin, stdout, stderr)

  File "/usr/lib/python2.5/subprocess.py", line 932, in _get_handles
    p2cread = stdin.fileno()

AttributeError: 'cStringIO.StringI' object has no attribute 'fileno'

Aside from the fact I would hope that cStringIO could provide
self.fileno() I believe the error message should have been:

AttributeError: 'cStringIO.StringIO' object has no attribute 'fileno'

----------
components: Library (Lib)
messages: 68942
nosy: mmokrejs
severity: normal
status: open
title: subprocess.py strips last character when raising an AttributeError
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 29 11:26:14 2008
From: report at bugs.python.org (Martin Mokrejs)
Date: Sun, 29 Jun 2008 09:26:14 +0000
Subject: [New-bugs-announce] [issue3235] Improve subprocess module usage
In-Reply-To: <1214731574.46.0.694544049658.issue3235@psf.upfronthosting.co.za>
Message-ID: <1214731574.46.0.694544049658.issue3235@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

Although I do appreciate that you try to improve python it is not clear
to me from http://docs.python.org/lib/module-subprocess.html:

1. Why the old functions have been deprecated
2. I can pipe together two processes. But how can I use pipe to feed the
first process of the two? The example at
http://docs.python.org/lib/node535.html is not sufficient. Show how to
bind together cat(1) and tr(1). Cat should read from STDIN and pass the
same to STDOUT, being read by tr(1).
3. Nowhere is explained what this magic really does:
   output = p2.communicate()[0]
   I figured out the result is e.g. a string of '\n' separated lines.
   What is not clear whether at this very moment the processes get
   started and whether one can still write on input to them. It seems
   not, the p1.stdin has to be already populated with data.
Thanks.

----------
assignee: georg.brandl
components: Documentation
messages: 68943
nosy: georg.brandl, mmokrejs
severity: normal
status: open
title: Improve subprocess module usage
type: resource usage
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 29 13:38:15 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Jun 2008 11:38:15 +0000
Subject: [New-bugs-announce] [issue3236] ints contructed from strings don't
	use the smallint constants
In-Reply-To: <1214739495.01.0.514577579612.issue3236@psf.upfronthosting.co.za>
Message-ID: <1214739495.01.0.514577579612.issue3236@psf.upfronthosting.co.za>


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

The following says it all:

>>> 1+1 is 2
True
>>> int('2') is 2
False
>>> int(b'2') is 2
False

----------
components: Interpreter Core
messages: 68947
nosy: pitrou
severity: normal
status: open
title: ints contructed from strings don't use the smallint constants
type: resource usage
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun 29 20:19:45 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Jun 2008 18:19:45 +0000
Subject: [New-bugs-announce] [issue3237] idlelib3.0 still using xrange
In-Reply-To: <1214763585.13.0.0791210177458.issue3237@psf.upfronthosting.co.za>
Message-ID: <1214763585.13.0.0791210177458.issue3237@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

As reported in the py3 list
  File "/root/Py3kb1/lib/python3.0/tkinter/__init__.py", line 1409,
  in __call__
    return self.func(*args)
  File "/root/Py3kb1/lib/python3.0/idlelib/MultiCall.py", line 165,
  in handler
    r = l[i](event)
  File "/root/Py3kb1/lib/python3.0/idlelib/EditorWindow.py", line 292,
  in home_callback
    for insertpt in xrange(len(line)):
NameError: global name 'xrange' is not defined

I verified this on my xp installation.
I am curious whether 2to3 missed this or if it has never been run over
idlelib (IDLE otherwise works fine as far as I know).

----------
components: IDLE
messages: 68962
nosy: tjreedy
severity: normal
status: open
title: idlelib3.0 still using xrange
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sun Jun 29 22:07:07 2008
From: report at bugs.python.org (kai zhu)
Date: Sun, 29 Jun 2008 20:07:07 +0000
Subject: [New-bugs-announce] [issue3238] backport python 3.0 language
	functionality to python 2.6 by adding 7 opcodes to ceval.c
In-Reply-To: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>
Message-ID: <1214770027.24.0.542856927114.issue3238@psf.upfronthosting.co.za>


New submission from kai zhu <davidbranniganz at gmail.com>:

this patch touches only Python/ceval.c.

1. the only existing thing it modifies is PyEval_EvalFrameEx (adds 7
extra cases for the new 3.0 opcodes, doesn't mess w/ any of the existing
ones, or anything else as a matter of fact)

2. that, plus it defines (the new opcodes)
#define SET_ADD 17
#define STORE_LOCALS 69
#define LOAD_BUILD_CLASS 34 // 71 in py3k
#define MAKE_BYTES 35 // unused in py3k
#define POP_EXCEPT 36 // 89 in py3k
#define UNPACK_EX 94
#define BUILD_SET 109 // 104 in py3k
and some backported vars & helper functions

only 2 contiguous areas of ceval.c is patched (1. & 2. - areas are
delimited by the comments '// py3k')

this simple patch seems sufficient in theory to allow the interpreter to
natively execute most of 3.0's language syntax (nonlocal, print,
extended unpacking, ... have been tested to work)
*the one exception being pep3102 - keyword-only arguments

i wrote 2 small scripts which gives an interactive function 'compile_py3k'
similar to __builtin__.compile.  its a wrapper function which queries
the byte-compiling task to a python 3.0 server via pipe io.

example demonstrating pep3132 extended unpacking syntax:
a,b,*c = 1,2,3,4
(note the backported 3.0 opcode used in line2 of the disassembly)



Python 2.5.2 (r252:60911, Jun 27 2008, 21:19:51)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import py3to2
py3to2 server restarting with io: (4, 5)
py3to2 server: Python 3.0b1 (r30b1:64395, Jun 24 2008, 21:53:55)
py3to2 server: [GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] on linux2
py3to2 server: Type "help", "copyright", "credits" or "license" for more
information.
py3to2 server:

>>> src = "a,b,*c = 1,2,3,4"
>>> codeobject = py3to2.compile_py3k(src,"","exec")
 1           0 LOAD_CONST               5 ((1, 2, 3, 4))
             3 UNPACK_EX_py3k           2
             6 STORE_NAME               0 (a)
             9 STORE_NAME               1 (b)
            12 STORE_NAME               2 (c)
            15 LOAD_CONST               4 (None)
            18 RETURN_VALUE

>>> exec(codeobject)
>>> print a,b,c
1, 2, [3, 4]
>>>

u can go c
http://pypi.python.org/pypi?name=py3to2&version=20080628&:action=display
for more info on the script

anyway, i think it would b a great boost for python 3.0 (which i think
is very cool) if developers can test/develop it under the 2.x
environment.  this patch plus some scripts to emulated 3k extensions 
(bytes, bytearray, ...) can go a long way in making 3.0 available for
the masses.

ps. i've also attempted the reverse (forward-port 2.x opcodes to 3.0),
& its a bit more complicated (namely the PRINTxxx opcodes).  if there's
significant interest in that, i could work on it a bit more, but my
current interest is in extending 3.0 functionality to the vast 2.x
software base.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: ceval.2.6b1.c
messages: 68964
nosy: collinwinter, kaizhu
severity: normal
status: open
title: backport python 3.0 language functionality to python 2.6 by adding 7 opcodes to ceval.c
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10776/ceval.2.6b1.c

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

From report at bugs.python.org  Sun Jun 29 23:28:32 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Sun, 29 Jun 2008 21:28:32 +0000
Subject: [New-bugs-announce] [issue3239] curses/textpad.py incorrectly and
	redundantly imports ascii
In-Reply-To: <1214774912.88.0.531536472348.issue3239@psf.upfronthosting.co.za>
Message-ID: <1214774912.88.0.531536472348.issue3239@psf.upfronthosting.co.za>


New submission from Georgij Kondratjev <smpuj at bk.ru>:

Line 'import curses, ascii' should be replaced with 'import curses'

----------
components: Library (Lib)
messages: 68969
nosy: orivej
severity: normal
status: open
title: curses/textpad.py incorrectly and redundantly imports ascii
versions: Python 3.0

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

From report at bugs.python.org  Mon Jun 30 02:10:21 2008
From: report at bugs.python.org (Roger Upole)
Date: Mon, 30 Jun 2008 00:10:21 +0000
Subject: [New-bugs-announce] [issue3240] IDLE environment corrupts
	string.letters
In-Reply-To: <1214784620.79.0.803163811318.issue3240@psf.upfronthosting.co.za>
Message-ID: <1214784620.79.0.803163811318.issue3240@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

The problem seems to stem from this line in IOBinding.py:
locale.setlocale(locale.LC_CTYPE, "")

>From the command prompt:
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit 
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import string, locale
>>> print repr(string.letters)
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
>>> locale.setlocale(locale.LC_CTYPE, "")
'English_United States.1252'
>>> print repr(string.letters)
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\x83
\x8a\x8c\x8e\x9a\x9c\x9
e\x9f\xaa\xb5\xba\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9
\xca\xcb\xcc\xcd\xce\xc
f\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1
\xe2\xe3\xe
4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5
\xf6\xf8\xf
9\xfa\xfb\xfc\xfd\xfe\xff'
>>>

----------
components: IDLE
messages: 68977
nosy: rupole
severity: normal
status: open
title: IDLE environment corrupts string.letters
versions: Python 2.3, Python 2.4, Python 2.5

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

From report at bugs.python.org  Mon Jun 30 07:56:40 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 30 Jun 2008 05:56:40 +0000
Subject: [New-bugs-announce] [issue3241] warnings module prints garbage
In-Reply-To: <1214805400.27.0.0080322986331.issue3241@psf.upfronthosting.co.za>
Message-ID: <1214805400.27.0.0080322986331.issue3241@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

The warnings module prints garbage when the __file__ points to a binary.
This happens e.g. when freezing applications with bbfreeze/py2exe.

It's easy to reproduce even without freezing:

~/ python                                                          
ralf at red ok
Python 2.6b1+ (trunk, Jun 30 2008, 07:26:07) 
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> __file__=sys.executable
>>> import md5
/home/ralf/py26/bin/python:1: DeprecationWarning: the md5 module is
deprecated; use hashlib instead
 
ELF

>
@SA at 85Q@@'$@@@@@?
?@@



@@T?T? 
??t?t$z?] (?(?t(?t?
?

@
@
 P?td?N?NS?NSDUDUQ?td/lib64/ld-linux-x86-64.so.2
GNUH
                                                                         
?Y???U?
??=??W
G.@
V?
????Z3?
!$?5
?RT&
??j?>D?
=i
?w?R
J?0???'?f???X??
??5?#?U!???
???`q?L@?~???:???
     #  $    _

----------
components: Library (Lib)
messages: 68992
nosy: schmir
severity: normal
status: open
title: warnings module prints garbage
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 30 08:04:27 2008
From: report at bugs.python.org (Brodie Rao)
Date: Mon, 30 Jun 2008 06:04:27 +0000
Subject: [New-bugs-announce] [issue3242] Segfault in
	PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
In-Reply-To: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>
Message-ID: <1214805867.49.0.786809869075.issue3242@psf.upfronthosting.co.za>


New submission from Brodie Rao <junk at dackz.net>:

Running the attached script - which reassigns sys.stdout to an object 
that proxies sys.stdout, and eventually reassigns it back to the 
original object - using Apple's distribution of Python 2.5.1 on an x86 
machine, I get the following crash:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000007d312298
Crashed Thread:  0

Thread 0 Crashed:
0   ???                             0x00025d33 0 + 154931
1   org.python.python               0x001381c1 PyFloat_FromString + 6196
2   org.python.python               0x001381c1 PyFloat_FromString + 6196
3   org.python.python               0x0014cdce _PyTrash_destroy_chain + 
89
4   org.python.python               0x00198bd3 PyErr_Clear + 34
5   org.python.python               0x00132938 PyFile_SoftSpace + 117
6   org.python.python               0x0018b273 PyEval_EvalFrameEx + 7497
7   org.python.python               0x0018f45b PyEval_EvalCodeEx + 1638
8   org.python.python               0x0018f548 PyEval_EvalCode + 87
9   org.python.python               0x001a69ec PyErr_Display + 1896
10  org.python.python               0x001a7016 PyRun_FileExFlags + 135
11  org.python.python               0x001a8982 PyRun_SimpleFileExFlags + 
421
12  org.python.python               0x001b3c03 Py_Main + 3095
13  org.python.pythonapp            0x00001fca 0x1000 + 4042

During the process of whittling down the script to a test case, I 
experienced other kinds of crashes, or no crash at all. For each 
iteration of the script, the outcome was always the same, i.e. never 
inconsistent between runs.

All the various crashes I've encountered:

   :Assertion failed: (gc->gc.gc_refs != 0), function visit_decref, file 
Modules
/gcmodule.c, line 276.

   Assertion failed: (pool->ref.count > 0), function PyObject_Free, file 
Objects
/obmalloc.c, line 929.

   [1]    33289 illegal hardware instruction  python crash.py

   [1]    33352 floating point exception  python crash.py

   [1]    33502 segmentation fault  python crash.py

   [1]    34303 bus error  python crash.py

Running this on a different machine running Debian Etch Linux x86 using 
Debian's Python 2.4 distribution, I get the following crash:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209882400 (LWP 21471)]
0x080b9ffc in PyEval_EvalCodeEx ()
(gdb) bt
#0  0x080b9ffc in PyEval_EvalCodeEx ()
#1  0x08100b69 in PyClassMethod_New ()
#2  0x0805ad9c in PyObject_CallFunction ()
#3  0x08097594 in PyType_Ready ()
#4  0x080b79bf in PyEval_EvalFrame ()
#5  0x080ba755 in PyEval_EvalCodeEx ()
#6  0x08100b69 in PyClassMethod_New ()
#7  0x0805ad9c in PyObject_CallFunction ()
#8  0x08097594 in PyType_Ready ()
#9  0x080b79bf in PyEval_EvalFrame ()
#10 0x080ba755 in PyEval_EvalCodeEx ()
#11 0x08100b69 in PyClassMethod_New ()
#12 0x0805ad9c in PyObject_CallFunction ()
#13 0x08097594 in PyType_Ready ()
#14 0x080b79bf in PyEval_EvalFrame ()
[the same stack trace repeating over and over...]
#141 0x08100b69 in PyClassMethod_New ()
#142 0x0805ad9c in PyObject_CallFunction ()
#143 0x08097594 in PyType_Ready ()
#144 0x080b79bf in PyEval_EvalFrame ()
#145 0x080ba755 in PyEval_EvalCodeEx ()
#146 0x08100b69 in PyClassMethod_New ()
#147 0x0805ad9c in PyObject_CallFunction ()
#148 0x08097594 in PyType_Ready ()
#149 0x0807e5e9 in PyObject_GetAttrString ()
#150 0x08064f91 in PyFile_SoftSpace ()
#151 0x080b6420 in PyEval_EvalFrame ()
#152 0x080ba755 in PyEval_EvalCodeEx ()
#153 0x080ba7b9 in PyEval_EvalCode ()
#154 0x080dd167 in PyRun_FileExFlags ()
#155 0x080dd364 in PyRun_SimpleFileExFlags ()
#156 0x08055ba8 in Py_Main ()
#157 0x08055032 in main ()

Using Debian's distribution of Python 2.5, I didn't see any crashes.

Using the distribution of Python 2.6b1 from python.org on Mac OS X 10.5 
(x86), I saw the same crash:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000bea0
0x001b7e50 in ?? ()
(gdb) bt
#0  0x001b7e50 in ?? ()
#1  0x0002bea1 in frame_dealloc (f=0x21db20) at 
Objects/frameobject.c:417
#2  0x0002bf55 in frame_dealloc (f=0x21f220) at 
Objects/frameobject.c:425
#3  0x0002bf55 in frame_dealloc (f=0x21f380) at 
Objects/frameobject.c:425
#4  0x000466db in _PyTrash_destroy_chain () at Objects/object.c:2223
#5  0x000b2dd2 in PyErr_Clear () at Python/errors.c:239
#6  0x00024235 in PyFile_SoftSpace (f=0x3645b0, newflag=0) at 
Objects/fileobject.c:2141
#7  0x000a11e4 in PyEval_EvalFrameEx (f=0x202f20, throwflag=0) at 
Python/ceval.c:1622
#8  0x000a45ea in PyEval_EvalCodeEx (co=0x33e968, globals=0x1b7e40, 
locals=0x1b7e40, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2880
#9  0x000a46f7 in PyEval_EvalCode (co=0x21eddc, globals=0x21eddc, 
locals=0x21eddc) at Python/ceval.c:495
#10 0x000c99d3 in PyRun_FileExFlags (fp=0xa0125de0, filename=0xbffff0ec 
"/Users/brodie/Documents/Code/py-crash/crash5.py", start=257, 
globals=0x1b7e40, locals=0x1b7e40, closeit=1, flags=0xbfffef5c) at 
Python/pythonrun.c:1300
#11 0x000c9e53 in PyRun_SimpleFileExFlags (fp=<value temporarily 
unavailable, due to optimizations>, filename=0xbffff0ec 
"/Users/brodie/Documents/Code/py-crash/crash5.py", closeit=1, 
flags=0xbfffef5c) at Python/pythonrun.c:896
#12 0x000da844 in Py_Main (argc=1, argv=0xbfffefdc) at 
Modules/main.c:575
#13 0x00001c3c in _start ()
#14 0x00001b69 in start ()

I should note that I reduced the test case as much as I possibly could, 
and the actual compiled source seems to affect the crash. I.e., if I 
remove one of the unused imports, it doesn't crash; if I remove the 
unused function foo(), it doesn't crash; if I change the "height" 
variable passed to wrap_output(), it doesn't crash; if I remove the 
reassignment of buf[0] in flush(), it doesn't crash.

I'm not sure if these crashes are due to an error in the script, or if 
the script should even be capable of crashing Python in this manner.

----------
files: crash5.py
messages: 68993
nosy: brodierao
severity: normal
status: open
title: Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
type: crash
Added file: http://bugs.python.org/file10782/crash5.py

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

From report at bugs.python.org  Mon Jun 30 20:02:18 2008
From: report at bugs.python.org (Chris AtLee)
Date: Mon, 30 Jun 2008 18:02:18 +0000
Subject: [New-bugs-announce] [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>


New submission from Chris AtLee <chris at atlee.ca>:

httplib should support requests whose bodies are iterable objects.  This
would facilitate doing large file uploads via HTTP since you wouldn't
have to load the entire file into memory to create the request string.

Index: Lib/httplib.py
===================================================================
--- Lib/httplib.py      (revision 64600)
+++ Lib/httplib.py      (working copy)
@@ -688,7 +688,12 @@
        self.__state = _CS_IDLE

    def send(self, str):
-        """Send `str' to the server."""
+        """Send `str` to the server.
+
+        ``str`` can be a string object, a file-like object that supports
+        a .read() method, or an iterable object that supports a .next()
+        method.
+        """
        if self.sock is None:
            if self.auto_open:
                self.connect()
@@ -710,6 +715,10 @@
                while data:
                    self.sock.sendall(data)
                    data=str.read(blocksize)
+            elif hasattr(str,'next'):
+                if self.debuglevel > 0: print "sendIng an iterable"
+                for data in str:
+                    self.sock.sendall(data)
            else:
                self.sock.sendall(str)
        except socket.error, v:

----------
components: Library (Lib)
messages: 69014
nosy: catlee
severity: normal
status: open
title: Support iterable bodies in httplib
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 30 20:04:38 2008
From: report at bugs.python.org (Chris AtLee)
Date: Mon, 30 Jun 2008 18:04:38 +0000
Subject: [New-bugs-announce] [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>


New submission from Chris AtLee <chris at atlee.ca>:

The standard library should provide a way to encode data using the
standard multipart/form-data encoding.

This encoding is required to support file uploads via HTTP POST (or PUT)
requests.

Ideally file data could be streamed to the remote server if httplib
supported iterable request bodies (see issue #3243).

Mailing list thread:
http://mail.python.org/pipermail/python-dev/2008-June/080783.html

----------
components: Library (Lib)
messages: 69015
nosy: catlee
severity: normal
status: open
title: multipart/form-data encoding
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 30 21:24:56 2008
From: report at bugs.python.org (Edward Langley)
Date: Mon, 30 Jun 2008 19:24:56 +0000
Subject: [New-bugs-announce] [issue3245] Memory leak on OS X
In-Reply-To: <1214853896.85.0.513571586109.issue3245@psf.upfronthosting.co.za>
Message-ID: <1214853896.85.0.513571586109.issue3245@psf.upfronthosting.co.za>


New submission from Edward Langley <fiddler.wo.a.roof+python at gmail.com>:

On OS X 10.5.3 the default python has a mild memory leak.
sample session:

% python -S
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
>>> 

<switch terminals>

% leaks Python
Process 2357: 572 nodes malloced for 1031 KB
Process 2357: 1 leak for 16 total leaked bytes.
...

----------
components: Macintosh
messages: 69016
nosy: fiddlerwoaroof
severity: normal
status: open
title: Memory leak on OS X
type: performance
versions: Python 2.5

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

From report at bugs.python.org  Mon Jun 30 22:16:29 2008
From: report at bugs.python.org (ric)
Date: Mon, 30 Jun 2008 20:16:29 +0000
Subject: [New-bugs-announce] [issue3246] configure: WARNING: sys/socket.h:
	present but cannot be compiled
In-Reply-To: <1214856989.0.0.383145145027.issue3246@psf.upfronthosting.co.za>
Message-ID: <1214856989.0.0.383145145027.issue3246@psf.upfronthosting.co.za>


New submission from ric <rrochele at calix.com>:

Building Python 2.5.2 on Solaris9, receive error:

checking sys/socket.h presence... yes
configure: WARNING: sys/socket.h: present but cannot be compiled
configure: WARNING: sys/socket.h:     check for missing prerequisite
headers?
configure: WARNING: sys/socket.h: see the Autoconf documentation
configure: WARNING: sys/socket.h:     section "Present But Cannot Be
Compiled"
configure: WARNING: sys/socket.h: proceeding with the preprocessor's result
configure: WARNING: sys/socket.h: in the future, the compiler will take
precedence
configure: WARNING:     ##
------------------------------------------------ ##
configure: WARNING:     ## Report this to
http://www.python.org/python-bugs ##
configure: WARNING:     ##
------------------------------------------------ ##
checking for sys/socket.h... yes

----------
components: Build
messages: 69017
nosy: rrochele
severity: normal
status: open
title: configure: WARNING: sys/socket.h: present but cannot be compiled
type: compile error
versions: Python 2.5

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