From report at bugs.python.org  Thu Jan  1 06:06:10 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 01 Jan 2009 05:06:10 +0000
Subject: [New-bugs-announce] [issue4797] test_fileio error (windows)
In-Reply-To: <1230786370.88.0.170386258104.issue4797@psf.upfronthosting.co.za>
Message-ID: <1230786370.88.0.170386258104.issue4797@psf.upfronthosting.co.za>


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

This patch fixes this error.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1727/step-test/0

======================================================================
FAIL: testOpendir (test.test_fileio.AutoFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\test\test_fileio.py", line 112, in testOpendir
    self.assertEqual(e.filename, ".")
AssertionError: None != '.'

This error doesn't occur on py3k (because wide string is passed) but I 
think It's better to merge the patch into py3k too.

----------
components: Windows
files: fix_test_fileio_error.patch
keywords: patch
messages: 78690
nosy: ocean-city
severity: normal
status: open
title: test_fileio error (windows)
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12515/fix_test_fileio_error.patch

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

From report at bugs.python.org  Thu Jan  1 08:47:41 2009
From: report at bugs.python.org (Vikram U Shenoy)
Date: Thu, 01 Jan 2009 07:47:41 +0000
Subject: [New-bugs-announce] [issue4798] Update deprecation of 'new' module
	in PEP 4.
In-Reply-To: <1230796061.0.0.856185746745.issue4798@psf.upfronthosting.co.za>
Message-ID: <1230796061.0.0.856185746745.issue4798@psf.upfronthosting.co.za>


New submission from Vikram U Shenoy <vikram.u.shenoy at gmail.com>:

Attached are two patches:

* Update PEP 4 about 'new' module which is deprecated since python 2.6
in favour of using types module.

* Update documentation for 'new' module.

Not sure about the exact date of proposal for deprecating 'new' module,
but closest that I was able to find was this python-dev mail thread
after it had been removed from py3k branch:

http://mail.python.org/pipermail/python-dev/2007-November/075386.html

----------
assignee: georg.brandl
components: Documentation
files: doc_update_for_new_module_dec_31_2008.patch
keywords: patch
messages: 78692
nosy: georg.brandl, loewis, vshenoy
severity: normal
status: open
title: Update deprecation of 'new' module in PEP 4.
versions: Python 2.6
Added file: http://bugs.python.org/file12516/doc_update_for_new_module_dec_31_2008.patch

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

From report at bugs.python.org  Thu Jan  1 08:52:47 2009
From: report at bugs.python.org (Cournapeau David)
Date: Thu, 01 Jan 2009 07:52:47 +0000
Subject: [New-bugs-announce] [issue4799] handling inf/nan in '%f'
In-Reply-To: <1230796367.25.0.681154044554.issue4799@psf.upfronthosting.co.za>
Message-ID: <1230796367.25.0.681154044554.issue4799@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

On windows, with python 2.6,  s = '%s' % float('inf') is 'inf', but s =
'%f' % float('inf') is equal to '1.#INF'.

This patch fixes the inconsistency, by using the code from floatobject.f
format_float into stringobject.c formatfloat. I think it would be better
to use the same underlying implementations for both functions, but it is
not so easy, because format_float cannot fail (return void), whereas
formatfloat can (return error code).

----------
components: Interpreter Core
files: nan.patch
keywords: patch
messages: 78693
nosy: cdavid
severity: normal
status: open
title: handling inf/nan in '%f'
versions: Python 2.6
Added file: http://bugs.python.org/file12518/nan.patch

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

From report at bugs.python.org  Thu Jan  1 11:32:35 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Thu, 01 Jan 2009 10:32:35 +0000
Subject: [New-bugs-announce] [issue4800] little inaccuracy in Py_ssize_t
	explanation
In-Reply-To: <1230805955.17.0.970467276629.issue4800@psf.upfronthosting.co.za>
Message-ID: <1230805955.17.0.970467276629.issue4800@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Documentation says that

========
There?s no chance that the reference count can overflow; at least as many bits 
are used to hold the reference count as there are distinct memory locations in 
virtual memory (assuming sizeof(Py_ssize_t) >= sizeof(void*)). Thus, the 
reference count increment is a simple operation.
========

But Py_ssize_t is a signed type so in case of sizeof(Py_ssize_t) == sizeof
(void*)) it can only reference a half of memmory :). But because any python 
object consumes much more than 2bytes this is not a problem.

----------
assignee: georg.brandl
components: Documentation
messages: 78695
nosy: exe, georg.brandl
severity: normal
status: open
title: little inaccuracy in Py_ssize_t explanation
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jan  1 21:03:39 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 20:03:39 +0000
Subject: [New-bugs-announce] [issue4801] _collections module fail to build
	on cygwin
In-Reply-To: <1230840219.24.0.00127311298202.issue4801@psf.upfronthosting.co.za>
Message-ID: <1230840219.24.0.00127311298202.issue4801@psf.upfronthosting.co.za>


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

make log:
gcc -shared -Wl,--enable-auto-image-base
.../Modules/_collectionsmodule.o -L/usr/local/lib -L. -lpython2.7 -o
build/lib.cygwin-1.5.25-i686-2.7/_collections.dll
.../Modules/_collectionsmodule.o: In function `deque_iter':
.../Modules/_collectionsmodule.c:970: undefined reference to
`__PyGC_generation0'
....

----------
components: Build
files: py-trunk-incl-objimpl.h-patch
messages: 78723
nosy: rpetrov
severity: normal
status: open
title: _collections module fail to build on cygwin
versions: Python 2.7
Added file: http://bugs.python.org/file12519/py-trunk-incl-objimpl.h-patch

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

From report at bugs.python.org  Thu Jan  1 21:08:30 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 01 Jan 2009 20:08:30 +0000
Subject: [New-bugs-announce] [issue4802] detect_tkinter for cygwin
In-Reply-To: <1230840510.49.0.878061128691.issue4802@psf.upfronthosting.co.za>
Message-ID: <1230840510.49.0.878061128691.issue4802@psf.upfronthosting.co.za>


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

Check for installed X on cygwin can't find X11/Xlib.h in detect_tkinter
from setup.py

----------
files: py-trunk-detect_tkinter-cygwin.patch
keywords: patch
messages: 78724
nosy: rpetrov
severity: normal
status: open
title: detect_tkinter for cygwin
Added file: http://bugs.python.org/file12520/py-trunk-detect_tkinter-cygwin.patch

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

From report at bugs.python.org  Fri Jan  2 03:57:06 2009
From: report at bugs.python.org (Manas)
Date: Fri, 02 Jan 2009 02:57:06 +0000
Subject: [New-bugs-announce] [issue4803] Manas Thapliyal sent you a Friend
	Request on Yaari
In-Reply-To: <94e386e8cd976bbe7d6eb5b217870508@localhost.localdomain>
Message-ID: <94e386e8cd976bbe7d6eb5b217870508@localhost.localdomain>


New submission from Manas <gravitywarrior1 at gmail.com>:

Manas Thapliyal wants you to join Yaari!

Is Manas your friend?

<a href="http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariNSF231MZA868MBK206SAQ399">Yes, Manas is my friend!</a> <a href="http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariNSF231MZA868MBK206SAQ399">No, Manas isn't my friend.</a>

Please respond or Manas may think you said no :(

Thanks,
The Yaari Team
____
If you prefer not to receive this email tell us <a href="http://yaari.com/?controller=absn&action=addoptout&email=report at bugs.python.org">here</a>. If you have any concerns 
regarding the content of this message, please email abuse at yaari.com.  
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312

YaariNSF231MZA868MBK206SAQ399

----------
files: unnamed
messages: 78749
nosy: gravitywarrior1
severity: normal
status: open
title: Manas Thapliyal sent you a Friend Request on Yaari
Added file: http://bugs.python.org/file12526/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4803>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20090102/a15e5aa2/attachment.txt>

From report at bugs.python.org  Fri Jan  2 05:09:40 2009
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 02 Jan 2009 04:09:40 +0000
Subject: [New-bugs-announce] [issue4804] Python on Windows disables all C
	runtime library assertions
In-Reply-To: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>
Message-ID: <1230869380.06.0.720418986656.issue4804@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

This block in exceptions.c:

#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
...
    /* turn off assertions in debug mode */
    prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif

Does exactly what the comment says it does - disables all assertions. 
It disables *all* CRT assertions in the process, which includes some
very useful ones related to memory corruption, and all 'assert' and
'ASSERT' statements in all Python extension modules.

The change was introduced in:
"""
r46894 | kristjan.jonsson | 2006-06-13 01:45:12 +1000 (Tue, 13 Jun 2006)
| 2 lines

Fix the CRT argument error handling for VisualStudio .NET 2005.  Install
a CRT error handler and disable the assertion for debug builds.  This
causes CRT to set errno to EINVAL.
This update fixes crash cases in the test suite where the default CRT
error handler would cause process exit.
"""

which seems like a very large hammer to be using (ie, the problem
causing the assertions to blow should probably have been fixed).  I'd
like to remove these 2 lines.  Any objections, or should I upload the
trivial patch?

----------
components: Windows
messages: 78753
nosy: krisvale, mhammond
severity: normal
status: open
title: Python on Windows disables all C runtime library assertions
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Jan  2 05:56:46 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Jan 2009 04:56:46 +0000
Subject: [New-bugs-announce] [issue4805] Make python code compilable with a
	C++ compiler
In-Reply-To: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>
Message-ID: <1230872206.73.0.47638283248.issue4805@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I am posting this patch mainly to support python-dev discussion on this 
topic.  In the past (see r45330) it was possible to compile python core 
and standard library modules using a C++ compiler.

According to Martin v. L?wis (issue4665), "It's not a requirement that 
the Python source code is compilable as C++. Only the header files 
should be thus compilable." However, I can see certain benefits from 
such requirement:

1. It is hard to verify that header files are compilable if source code 
is not.  With compilable source code, CC=g++ ./configure; make will 
supply an adequate test that does not require anything beyond a standard 
distribution.

2. Arguably, C++ compliant code is more consistent and less error prone.   
For example, "new" is a really bad choice for a variable name regardless 
of being a C++ keyword, especially when used instead of prevailing "res" 
for a result of a function producing a PyObject. Even clearly redundant 
explicit casts of malloc return values arguably improve readability by 
reminding the type of the object that is being allocated.

3. Compiling with C++ may reveal actual coding errors that otherwise go unnoticed.  For example, use of undefined PyLong_BASE_TWODIGITS_TYPE in Objects/longobject.c.

4. Stricter type checking may promote use of specific types instead of 
void* which in turn may help optimizing compilers.

5. Once achieved, C++ compilability is not that hard to maintain, but 
restoring it with patches like this one is hard because it requires 
review of changes to many unrelated files.

----------
files: c++-patch.diff
keywords: patch
messages: 78756
nosy: belopolsky
severity: normal
status: open
title: Make python code compilable with a C++ compiler
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file12527/c++-patch.diff

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

From report at bugs.python.org  Fri Jan  2 13:46:04 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 02 Jan 2009 12:46:04 +0000
Subject: [New-bugs-announce] [issue4806] Function calls taking a generator
	as star argument can mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>


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

If we call some function f with a generator as star argument and this
generator raises a TypeError, we get the following exception:

>>> def f(x): pass
... 
>>> def broken(): raise TypeError
... 
>>> f(*(broken() for x in (0,)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() argument after * must be a sequence, not generator

This is a misleading error message, as it's usually no problem to use a
generator as a star argument. Even just replacing the TypeError by some
other exception leads to the expected result, i.e. the exception gets
correctly propagated.

The problem seems to be around line 3710 of Python/ceval.c where the
generator is converted to a tuple. If this conversion raises a
TypeError, then the error message is replaced, which will mask any
TypeError raised by the generator.

I'm not sure how to solve this. We probably can't distinguish a "good"
TypeError from a "bad" TypeError at this point, so we might have to make
a special case for the conversion of generators.

----------
components: Interpreter Core
messages: 78788
nosy: hagen
severity: normal
status: open
title: Function calls taking a generator as star argument can mask TypeErrors in the generator
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Jan  2 14:08:03 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 02 Jan 2009 13:08:03 +0000
Subject: [New-bugs-announce] [issue4807] wrong wsprintf usage
In-Reply-To: <1230901683.42.0.873273528074.issue4807@psf.upfronthosting.co.za>
Message-ID: <1230901683.42.0.873273528074.issue4807@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

Note up front: there is a win32 function wsprintf() and an ISO C
function swprintf(), these are different things in case you wonder.

In _winreg.c, there are two functions that use wsprintf on a char
buffer, while the function takes a TCHAR buffer instead. This leads to
compile warning and runtime errors when _UNICODE is defined, like e.g.
under MS Windows CE. The attached patch replaces the two calls to that
function with calls to fprintf() and PyString_FromFormat().

----------
components: Windows
files: python-2.7-no-wsprint.0.patch
keywords: patch
messages: 78790
nosy: eckhardt
severity: normal
status: open
title: wrong wsprintf usage
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file12538/python-2.7-no-wsprint.0.patch

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

From report at bugs.python.org  Fri Jan  2 15:55:13 2009
From: report at bugs.python.org (Corey Goldberg)
Date: Fri, 02 Jan 2009 14:55:13 +0000
Subject: [New-bugs-announce] [issue4808] doc issue for threading module
	(name/daemon properties)
In-Reply-To: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>
Message-ID: <1230908113.29.0.280160311198.issue4808@psf.upfronthosting.co.za>


New submission from Corey Goldberg <cgoldberg at gmail.com>:

In the current 3.0 doc for threading:
http://docs.python.org/dev/py3k/library/threading.htm

it says:

Thread.getName()
Thread.setName()
  Old API for name.
  
and

Thread.isDaemon()
Thread.setDaemon()
  Old API for daemon.
  
  
'name' and 'daemon' properties should be listed as defaults and the old
getter/setter methods should be noted as "Old API".

----------
assignee: georg.brandl
components: Documentation
messages: 78807
nosy: cgoldberg, georg.brandl
severity: normal
status: open
title: doc issue for threading module (name/daemon properties)
versions: Python 3.0

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

From report at bugs.python.org  Fri Jan  2 17:18:15 2009
From: report at bugs.python.org (Randy Syring)
Date: Fri, 02 Jan 2009 16:18:15 +0000
Subject: [New-bugs-announce] [issue4809] 2.5.4 release missing from
	python.org/downloads
In-Reply-To: <1230913095.06.0.854632300097.issue4809@psf.upfronthosting.co.za>
Message-ID: <1230913095.06.0.854632300097.issue4809@psf.upfronthosting.co.za>


New submission from Randy Syring <randy at rcs-comp.com>:

http://www.python.org/download/ is missing a link to 2.5.4 in the
standard releases section.

----------
assignee: georg.brandl
components: Documentation
messages: 78832
nosy: georg.brandl, rsyring
severity: normal
status: open
title: 2.5.4 release missing from python.org/downloads

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

From report at bugs.python.org  Fri Jan  2 17:41:28 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 02 Jan 2009 16:41:28 +0000
Subject: [New-bugs-announce] [issue4810] timeit needs "official" '--' flag
In-Reply-To: <18782.17333.839740.4416@montanaro-dyndns-org.local>
Message-ID: <18782.17333.839740.4416@montanaro-dyndns-org.local>


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

Consider this timeit run:

    % python -m timeit '-1.0e-3 < -0.0001 < 1.0e-3'
    option -1 not recognized
    use -h/--help for command line help

As it turns out this works:

    % python -m timeit -- '-1.0e-3 < -0.0001 < 1.0e-3'
    10000000 loops, best of 3: 0.192 usec per loop

but the output using the -h flag doesn't report it as a possibility.  It
probably should.

----------
messages: 78838
nosy: skip.montanaro
severity: normal
status: open
title: timeit needs "official" '--' flag

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

From report at bugs.python.org  Fri Jan  2 21:15:19 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 02 Jan 2009 20:15:19 +0000
Subject: [New-bugs-announce] [issue4811] invalid reST markup in several
	documents
In-Reply-To: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>
Message-ID: <1230927319.41.0.991139894945.issue4811@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

Several documents contain invalid reST markup that "leaks" into the 
html output (missing ``, incorrect indentation, etc.)
This patch fixes the obvious ones.

----------
assignee: georg.brandl
components: Documentation
files: invalid-doc-markup.diff
keywords: patch
messages: 78866
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: invalid reST markup in several documents
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12543/invalid-doc-markup.diff

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

From report at bugs.python.org  Fri Jan  2 23:31:05 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Jan 2009 22:31:05 +0000
Subject: [New-bugs-announce] [issue4812] Junk in the decimals namespace
In-Reply-To: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>
Message-ID: <1230935465.8.0.0565784557984.issue4812@psf.upfronthosting.co.za>


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

In r59144 , a bunch of internal-use constants were dumped in the main
namespace.  These all need to be prefixed with an underscore.  

They should be fixed right-away before people start using them.  Since
they are externally undocumented and since the internal notes describe
them as being only for internal-use, I think this can go in as a bugfix.

----------
assignee: facundobatista
components: Library (Lib)
messages: 78893
nosy: facundobatista, rhettinger
priority: high
severity: normal
status: open
title: Junk in the decimals namespace
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan  3 00:50:06 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 02 Jan 2009 23:50:06 +0000
Subject: [New-bugs-announce] [issue4813] On OS-X the directories searched by
	setup.py for Tk are in the wrong order.
In-Reply-To: <1230940206.74.0.201449731913.issue4813@psf.upfronthosting.co.za>
Message-ID: <1230940206.74.0.201449731913.issue4813@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In function detect_tkinter_darwin of setup.py framework_dirs should be 
the reverse of what it is: first the user's library should be searched, 
then /Library, and finally /System/Library.  If Tk 8.5 is installed in 
/Library or ~/Library make will otherwise find the headers from 8.4 but 
the libraries from 8.5.

Issue 4017 discusses this problem, among others, and is marked fixed, 
but it is still incorrect in the 2.6 and 3.0 downloads as well as in the 
trunk, 3.0, and 3.1 subversion repositories.  It may have been "fixed" 
in so far as someone was able to make a .dmg by manually altering 
setup.py, and that's great, but it isn't fixed in the source and the 
problem will reappear with each new version.

----------
components: Build
messages: 78904
nosy: MLModel
severity: normal
status: open
title: On OS-X the directories searched by setup.py for Tk are in the wrong order.
type: compile error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan  3 01:52:14 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 03 Jan 2009 00:52:14 +0000
Subject: [New-bugs-announce] [issue4814] ftplib does not honour "timeout"
	parameter for active data connections
In-Reply-To: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>
Message-ID: <1230943934.69.0.609460387197.issue4814@psf.upfronthosting.co.za>


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

When using the optional ftplib.FTP()'s timeout parameter which 
specifies a timeout in seconds for blocking operations like the 
connection attempt, it is applied on both FTP control and passive data 
channel (if any).
It is not applied for active (PORT/EPRT) data connections.
The patch in attachment modifies ftplib so that when ntransfer method 
is called in active mode, timeout is applied on the resulting data 
connection.

----------
files: ftplib.patch
keywords: patch
messages: 78912
nosy: giampaolo.rodola
severity: normal
status: open
title: ftplib does not honour "timeout" parameter for active data connections
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12552/ftplib.patch

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

From report at bugs.python.org  Sat Jan  3 05:56:21 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 04:56:21 +0000
Subject: [New-bugs-announce] [issue4815] idle 3.1a1 utf8
In-Reply-To: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>
Message-ID: <1230958581.39.0.288049654968.issue4815@psf.upfronthosting.co.za>


New submission from Pavel Kosina <geon at post.cz>:

When you open file without encoding declaration, make changes and save,
then IDLE changes without any question encodings to utf8. You can try it
on attached file that is cp1250 now. 

It could be that at first saving we are asked to use 
*utf8 
*current one.

----------
components: IDLE
files: cp1250.py
messages: 78932
nosy: geon
severity: normal
status: open
title: idle 3.1a1 utf8
versions: Python 3.1
Added file: http://bugs.python.org/file12559/cp1250.py

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

From report at bugs.python.org  Sat Jan  3 11:51:15 2009
From: report at bugs.python.org (Thomas Finley)
Date: Sat, 03 Jan 2009 10:51:15 +0000
Subject: [New-bugs-announce] [issue4816] Patch of itertools.{combinations,
	permutations} for empty combinations
In-Reply-To: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>
Message-ID: <1230979875.82.0.811611724155.issue4816@psf.upfronthosting.co.za>


New submission from Thomas Finley <tfinley at gmail.com>:

This is a patch for the Python 3.1 build checked out from
http://svn.python.org/projects/python/branches/py3k

The current behavior of itertools.combinations(iterable,r) and
itertools.permutations(iterable,r) is to throw a ValueError if iterable
yields fewer than r items.  This changes these functions so the
generator instead yields 0 items.

As for my argument for acceptance, while the original behavior is not a
bug insofar as its implementation was deliberate, I'd argue this is
undesirable on grounds of mathematical consistency and functionality.

In mathematics the "choose" function is defined as "(n choose r)=0" for
r>n, so itertools.combinations' behavior is inconsistent with its
obvious combinatorial analogy.  (Similar for permutations and the
combinatorial "P" function.)

For functionality I'll cite my own case as anecdote.  In writing
regression tests I wanted to ensure that a group of items obeyed a
certain "mutually consistent" property between all triples.  (Something
akin to the triangle inequality.)  So:

all(triangle_respected(*triple) for triple in
itertools.combinations(group, 3))

If len(group)<=2, that's fine, since with no triangles there is no
inconsistency, and all(())==True.  However, the code failed with a
ValueError when groups were that small.  Working around this was fairly
awkward, since I wanted to continue to fail noisily if my
triangle_respected function threw a ValueError, and I wasn't sure at all
that it wouldn't if my items were 

The patch modifies Modules/itertoolsmodule.c slightly, changing
combinationsobject_new and permutationsobject_new.  (Deleting the error
throwing code, and have one line changes in both structures to handle
the n>r case.  One could handle this special case more efficiently than
I do by not bothering to allocate certain structures in this case, but I
didn't want to tempt fate.)  The patch also changes the appropriate
tests in Lib/test/test_itertools.py .

Obviously, this would break code that depends upon Python throwing
ValueError in the event of the combination or permutation sequence being
empty.  However, I hope given that combinations and permutations are a
relative novelty that their behavior in this corner case is not yet
etched in stone.

Sorry if this belongs in a PEP -- it seems quite minor, but I don't
quite have a feel what the threshold is.

----------
components: Library (Lib), Tests
files: itertools-empty-combinations.diff
keywords: patch
messages: 78943
nosy: TFinley
severity: normal
status: open
title: Patch of itertools.{combinations,permutations} for empty combinations
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file12563/itertools-empty-combinations.diff

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

From report at bugs.python.org  Sat Jan  3 12:09:46 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sat, 03 Jan 2009 11:09:46 +0000
Subject: [New-bugs-announce] [issue4817] PyOS_GetLastModificationTime is
	unused
In-Reply-To: <1230980986.2.0.22709793272.issue4817@psf.upfronthosting.co.za>
Message-ID: <1230980986.2.0.22709793272.issue4817@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

This is just to record that the above function is wrongly documented,
inconsistently implemented, but fortunately unused, so it can be removed.

In addition to the patch attached, there are two files that can be removed:
Python/getmtime.c
RISCOS/Python/getmtime_riscos.c

----------
components: Interpreter Core
files: python-2.7-eradicate-getmtime.0.patch
keywords: patch
messages: 78945
nosy: eckhardt
severity: normal
status: open
title: PyOS_GetLastModificationTime is unused
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file12564/python-2.7-eradicate-getmtime.0.patch

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

From report at bugs.python.org  Sat Jan  3 12:24:00 2009
From: report at bugs.python.org (ebfe)
Date: Sat, 03 Jan 2009 11:24:00 +0000
Subject: [New-bugs-announce] [issue4818] Patch for thread-support in
	md5module.c
In-Reply-To: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>
Message-ID: <1230981840.09.0.761060151323.issue4818@psf.upfronthosting.co.za>


New submission from ebfe <knabberknusperhaus at yahoo.de>:

Here is another patch, this time for the fallback-md5-module. I know
that situations are rare where openssl is not present but threading is.
However they might occur out there and the md5module needed some love
anyway:

- The MD5 class from the fallback module can now also use threads with
'small locks'
- The behaviour regarding unicode data input is now consistent as to
what the openssl-driven classes do.
- Some code cleanup.


I might act on the sha modules as way the next days. sha256.c still
accepts 's#'...


Also see issue #4751

----------
files: md5module_small_locks.diff
keywords: patch
messages: 78947
nosy: ebfe
severity: normal
status: open
title: Patch for thread-support in md5module.c
Added file: http://bugs.python.org/file12565/md5module_small_locks.diff

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

From report at bugs.python.org  Sat Jan  3 14:16:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Jan 2009 13:16:34 +0000
Subject: [New-bugs-announce] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Misc/cheatsheet could do with an upgrade, both for the 2.x and 3.x branches.

For 3.x, I guess the changes needed are quite extensive.  I'm not sure
how much needs to be changed or added for 2.x; at a quick
glance, the 'with' statement, the 'x if b else y' construction, and the 
unified try-except-finally are missing.

----------
assignee: georg.brandl
components: Documentation
messages: 78955
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Misc/cheatsheet needs updating
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Jan  3 15:48:20 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 03 Jan 2009 14:48:20 +0000
Subject: [New-bugs-announce] [issue4820] ctypes.util.find_library
	incorrectly documented
In-Reply-To: <1230994100.6.0.728617029399.issue4820@psf.upfronthosting.co.za>
Message-ID: <1230994100.6.0.728617029399.issue4820@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

In the "ctypes reference / Finding shared libraries" section of the ctypes 
documentation, the find_library() function is described as being located 
in ctypes.util.   However, it's formal description right below that lists 
it as ctypes.find_library().

----------
assignee: georg.brandl
components: Documentation
messages: 78964
nosy: beazley, georg.brandl
severity: normal
status: open
title: ctypes.util.find_library incorrectly documented
versions: Python 3.0

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

From report at bugs.python.org  Sat Jan  3 18:08:24 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Sat, 03 Jan 2009 17:08:24 +0000
Subject: [New-bugs-announce] [issue4821] Patches for thread-support in
	built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>


New submission from Lukas Lueg <knabberknusperhaus at yahoo.de>:

Here is the follow-up to issue #4818. The patches attached allow the
built-in SHA modules to release the GIL.

Also the build-in SHA modules will now no longer accept "s#" as input.
Input is parsed just as in the openssl-driven classes where
unicode-objects are explicitly rejected.


The built-in hash modules have been not quite beautiful before even more
code is now copy & pasted between them. Is there any interest in
refactoring all those modules? AFAIK _sha1 and such are only used by
hashlib.py ...

----------
messages: 78975
nosy: ebfe
severity: normal
status: open
title: Patches for thread-support in built-in SHA modules

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

From report at bugs.python.org  Sat Jan  3 18:14:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Jan 2009 17:14:13 +0000
Subject: [New-bugs-announce] [issue4822] Fix indentation in memoryobject.c
In-Reply-To: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>
Message-ID: <1231002853.44.0.302489681959.issue4822@psf.upfronthosting.co.za>


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

The rules state new files should be indented with 4-spaces, but
indentation has no consistent indentation: parts of it are indented with
tabs, others with spaces.
We could probably reindent it all with 4-spaces, especially since it
hasn't been backported to trunk yet (and the versions in py3k and 3.0
should be identical).

----------
messages: 78978
nosy: pitrou
priority: low
severity: normal
status: open
title: Fix indentation in memoryobject.c
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan  3 19:02:21 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sat, 03 Jan 2009 18:02:21 +0000
Subject: [New-bugs-announce] [issue4823] idle height and place
In-Reply-To: <1231005741.18.0.260844388854.issue4823@psf.upfronthosting.co.za>
Message-ID: <1231005741.18.0.260844388854.issue4823@psf.upfronthosting.co.za>


New submission from Pavel Kosina <geon at post.cz>:

Nearly always (after opening) is IDLE window outside visible area.
Mainly the status bar is hidden under bottom windows menu bar. Same
situation happens when choosing Window-Zoom Height from IDLE menu.

xpsp3, 1024x768, py2.x-3.x

----------
components: IDLE
messages: 78983
nosy: geon
severity: normal
status: open
title: idle height and place
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan  4 00:30:39 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 03 Jan 2009 23:30:39 +0000
Subject: [New-bugs-announce] [issue4824] test_cmd_line failure on Mac OS X
	for py3k
In-Reply-To: <18783.62745.773153.314589@montanaro.dyndns.org>
Message-ID: <18783.62745.773153.314589@montanaro.dyndns.org>


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

test_cmd_line.test_run_code fails for me on Mac OS X:

    % ./python.exe -bb  Lib/test/regrtest.py -v test_cmd_line
    test_cmd_line
    test_directories (test.test_cmd_line.CmdLineTest) ... ok
    test_optimize (test.test_cmd_line.CmdLineTest) ... ok
    test_q (test.test_cmd_line.CmdLineTest) ... ok
    test_run_code (test.test_cmd_line.CmdLineTest) ... FAIL
    test_run_module (test.test_cmd_line.CmdLineTest) ... ok
    test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
    test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
    test_usage (test.test_cmd_line.CmdLineTest) ... ok
    test_verbose (test.test_cmd_line.CmdLineTest) ... ok
    test_version (test.test_cmd_line.CmdLineTest) ... ok

    ======================================================================
    FAIL: test_run_code (test.test_cmd_line.CmdLineTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/skip/src/python/py3k/Lib/test/test_cmd_line.py", line 143, in test_run_code
        0)
    AssertionError: 1 != 0

    ----------------------------------------------------------------------
    Ran 10 tests in 1.282s

Manually running what that test executes shows the problem:

    % ./python.exe 
    Python 3.1a0 (py3k:68218, Jan  3 2009, 15:06:30) 
    [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sys
    >>> sys.executable
    '/Users/skip/src/python/py3k/python.exe'
    >>> import subprocess
    >>> import sys
    >>> cmd_line = [sys.executable, '-E']
    >>> cmd_line.extend(['-c', "assert(ord('\xe9') == 0xe9)"])
    >>> cmd_line
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/skip/src/python/py3k/Lib/io.py", line 1488, in write
        b = encoder.encode(s)
      File "/Users/skip/src/python/py3k/Lib/encodings/ascii.py", line 22, in encode
        return codecs.ascii_encode(input, self.errors)[0]
    UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 68: ordinal not in range(128)
    >>> sys.getfilesystemencoding()
    'utf-8'
    >>> subprocess.call(cmd_line, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    1

If I execute that command from the shell prompt I do get a zero exit code no
matter what I try to mimic the scenario in the test:

    py3k% ./python.exe -E -c 'assert(ord("\xe9") == 0xe9)'
    py3k% echo $?
    0
    py3k% ./python.exe -E -c 'assert(ord("\xe9") == 0xe9)' > /tmp/trash 2>&1
    py3k% echo $?
    0
    py3k% ./python.exe -E -c 'assert(ord("\xe9") == 0xe9)' 2>&1 | cat > /dev/null
    py3k% echo $?
    0

I'm not sure where the problem lies.

----------
messages: 79023
nosy: skip.montanaro
severity: normal
status: open
title: test_cmd_line failure on Mac OS X for py3k

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

From report at bugs.python.org  Sun Jan  4 01:12:35 2009
From: report at bugs.python.org (MagnetoHydroDynamics)
Date: Sun, 04 Jan 2009 00:12:35 +0000
Subject: [New-bugs-announce] [issue4825] TypeError with complex.real() and
	complex.imag()
In-Reply-To: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>
Message-ID: <1231027955.73.0.619900873026.issue4825@psf.upfronthosting.co.za>


New submission from MagnetoHydroDynamics <karl at asmussen.ws>:

In both version 2.6.1 and 3.0 this issue exists:
N and M can be two numbers of any type.
>>> (N+Mj).real()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    (N+Mj).real()
TypeError: 'float' object is not callable
>>> (N+Mj).imag()
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    (N+Mj).imag()
TypeError: 'float' object is not callable

----------
components: None
messages: 79024
nosy: MagnetoHydroDynamics
severity: normal
status: open
title: TypeError with complex.real() and complex.imag()
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Jan  4 05:16:14 2009
From: report at bugs.python.org (xverify)
Date: Sun, 04 Jan 2009 04:16:14 +0000
Subject: [New-bugs-announce] [issue4826] exec() docstring bug about file
	objects
In-Reply-To: <1231042574.98.0.745471149157.issue4826@psf.upfronthosting.co.za>
Message-ID: <1231042574.98.0.745471149157.issue4826@psf.upfronthosting.co.za>


New submission from xverify <xverify at yahoo.com>:

exec() no longer accepts a file object but its docstring states otherwise.

----------
assignee: georg.brandl
components: Documentation
messages: 79036
nosy: georg.brandl, xverify
severity: normal
status: open
title: exec() docstring bug about file objects
versions: Python 3.0

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

From report at bugs.python.org  Sun Jan  4 07:50:43 2009
From: report at bugs.python.org (Jason Kankiewicz)
Date: Sun, 04 Jan 2009 06:50:43 +0000
Subject: [New-bugs-announce] [issue4827] optparse: Callback example 1 is
	confusing
In-Reply-To: <1231051843.8.0.720726802561.issue4827@psf.upfronthosting.co.za>
Message-ID: <1231051843.8.0.720726802561.issue4827@psf.upfronthosting.co.za>


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

"Callback example 1: trivial callback" reads

    Here?s an example of a callback option that takes no arguments, and
simply records that the option was seen:

        def record_foo_seen(option, opt_str, value, parser):
            parser.saw_foo = True

        parser.add_option("--foo", action="callback",
callback=record_foo_seen)

but the following paragraph

    Of course, you could do that with the store_true action.

is wrong because

        parser.add_option("--foo", action="store_true", dest="saw_foo")

would actually be duplicated by

        def record_foo_seen(option, opt_str, value, parser):
            parser.values.saw_foo = True

        parser.add_option("--foo", action="callback",
callback=record_foo_seen)

For example:
>>> from optparse import OptionParser
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
...     parser.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
<Option at 0xab4f58: --foo>
>>> parser.parse_args(['--foo'])
(<Values at 0xabb0f8: {}>, [])
>>> parser = OptionParser()
>>> parser.add_option("--foo", action="store_true", dest="saw_foo")
<Option at 0xabb1e8: --foo>
>>> parser.parse_args(['--foo'])
(<Values at 0xabb1c0: {'saw_foo': True}>, [])
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
...     parser.values.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
<Option at 0xabb508: --foo>
>>> parser.parse_args(['--foo'])
(<Values at 0xabb3f0: {'saw_foo': True}>, [])

----------
assignee: georg.brandl
components: Documentation
messages: 79039
nosy: georg.brandl, jkankiewicz
severity: normal
status: open
title: optparse: Callback example 1 is confusing
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan  4 11:09:06 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Sun, 04 Jan 2009 10:09:06 +0000
Subject: [New-bugs-announce] [issue4828] patch suggestion for webbrowser
Message-ID: <1231063746.09.0.618225413584.issue4828@psf.upfronthosting.co.za>


Changes by Yinon Ehrlich <yinoneh at users.sourceforge.net>:


----------
components: Library (Lib)
files: webbrowser.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: patch suggestion for webbrowser
versions: Python 2.6
Added file: http://bugs.python.org/file12580/webbrowser.patch

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

From report at bugs.python.org  Sun Jan  4 12:17:18 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 04 Jan 2009 11:17:18 +0000
Subject: [New-bugs-announce] [issue4829] confusing error for file("foo",
	"w++")
In-Reply-To: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>
Message-ID: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

Specifying the '+' more than once while opening a file results in the
error "Must have exactly one of read/write/append mode". The attached
patch extends that with ".. and at most one optional plus".

Further, the patch checks these after the loop that parses the mode
string, avoiding some unnecessary gotos and saving a few lines of code
overall.

----------
components: Interpreter Core
files: python-2.7-fopen-mode-parsing.0.patch
keywords: patch
messages: 79043
nosy: eckhardt
severity: normal
status: open
title: confusing error for file("foo", "w++")
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12581/python-2.7-fopen-mode-parsing.0.patch

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

From report at bugs.python.org  Sun Jan  4 12:25:37 2009
From: report at bugs.python.org (Cem Karan)
Date: Sun, 04 Jan 2009 11:25:37 +0000
Subject: [New-bugs-announce] [issue4830] regrtest.py -u largefile test_io
	fails on OS X 10.5.6
In-Reply-To: <1231068337.9.0.535376390894.issue4830@psf.upfronthosting.co.za>
Message-ID: <1231068337.9.0.535376390894.issue4830@psf.upfronthosting.co.za>


New submission from Cem Karan <cfkaran2+python at gmail.com>:

I'm running OS X 10.5.6 (uname -a == Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 
24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386) I get the following 
error after compiling Python 3.0.  Note that I have NOT installed it; I'm just trying 
to run the regression tests on the build.

Python-3.0 cfkaran2$ ./Lib/test/regrtest.py -u largefile test_io
  File "./Lib/test/regrtest.py", line 183
    print(msg, file=sys.stderr)
                   ^
SyntaxError: invalid syntax

I suspect that tester is not using the newly built python 3.0, but is using whatever 
is installed on the system, though I have not checked this at all.

----------
components: Tests
messages: 79044
nosy: ironsmith
severity: normal
status: open
title: regrtest.py -u largefile test_io fails on OS X 10.5.6
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sun Jan  4 15:52:37 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sun, 04 Jan 2009 14:52:37 +0000
Subject: [New-bugs-announce] [issue4831] exec() behavior - revisited
In-Reply-To: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za>
Message-ID: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

Please forgive me, but I'm really trying to wrap my brain around the 
behavior of exec() in Python 3.   Here's a quote from the documentation:

   "In all cases, if the optional parts are omitted, the code is
    executed in the current scope."

This is referring to the optional use of the globals/locals parameters 
and seems to indicate that if they're omitted the code executes in the 
scope where the exec() appeared.

Yet, this code fails:

def foo():
    exec("a = 42")
    print(a)         # NameError: a

Now, I realize that exec() became a function in Python 3.  However, 
regardless of that, is it really the intent that exec() not be allowed 
to ever modify any local variable of a function?   In other words, do I 
really have to do this?

def foo():
    ldict = locals()
    exec("a=42",globals(),ldict)
    a = ldict['a']
    print(a)

I submitted a bug report about this once before and it was immediately 
dismissed.   

I would appreciate some greater clarity on this matter this go around.  
Specifically, what is the approved way to have exec() modify the local 
environment of a function?

----------
components: Interpreter Core
messages: 79059
nosy: beazley
severity: normal
status: open
title: exec() behavior - revisited
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Jan  4 16:16:02 2009
From: report at bugs.python.org (Pavel Kosina)
Date: Sun, 04 Jan 2009 15:16:02 +0000
Subject: [New-bugs-announce] [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>


New submission from Pavel Kosina <geon at post.cz>:

There should not be necessity to write filename *with extension* at the
saving dialog. It should be enough, at least on Windows, to put there
just "hello" and get "hello.py". It is really complication especially
for beginners. If they, as they are used to from another programs, put
there just "hello", it is saved without extension ".py" what have 2
result: they cannot see any icons at that file and they are not able to
run in, cause python.exe is bind with ".py".

Hoping its not duplicate I haven't found anything like this here.

----------
components: IDLE
messages: 79062
nosy: geon
severity: normal
status: open
title: idle filename extension
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan  4 18:09:28 2009
From: report at bugs.python.org (Robert Schuppenies)
Date: Sun, 04 Jan 2009 17:09:28 +0000
Subject: [New-bugs-announce] [issue4833] Explicit directories for zipfiles
In-Reply-To: <1231088968.72.0.101458538333.issue4833@psf.upfronthosting.co.za>
Message-ID: <1231088968.72.0.101458538333.issue4833@psf.upfronthosting.co.za>


New submission from Robert Schuppenies <robert.schuppenies at gmail.com>:

We have an issue with the Python cheeseshop which is probably an issue
with Python itself as well.

When we create a zip file with standard linux tools ('zip os-zipped.zip
*'), uploading it works fine. But if we use the zipfile module from
Python and try to upload the result to the cheeseshop, we get this error
message:

" Error unpacking zipfile:[Errno 2] No such file or directory: 
u'/data/packagedocs/Pympler/_sources/index.txt'"

Turns out that the Python-zipped version does not include explicit
directories. The OS-zipped version contains "directory/,
directory/asizeof.txt", the Python-zipped file only
"directory/asizeof.txt". Digging deeper, Python has no way to explicitly
add directories to a zip file.

It would be useful to have an option which allows the explicit creation
of directories inside of zip files. This would help when working with
applications which do not create directories if they are not explicitly
specified.

----------
components: Library (Lib)
messages: 79070
nosy: schuppenies
severity: normal
status: open
title: Explicit directories for zipfiles
type: feature request

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

From report at bugs.python.org  Sun Jan  4 19:08:01 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 18:08:01 +0000
Subject: [New-bugs-announce] [issue4834] Trouble configuring with icc on Mac
	OS X 10.5
In-Reply-To: <18784.64250.252843.484595@montanaro.dyndns.org>
Message-ID: <18784.64250.252843.484595@montanaro.dyndns.org>


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

I get this error when trying to configure with Intel's icc on my Mac (Intel,
10.5.6, Xcode 3.1.2):

    >> configure:10332: checking size of size_t
    >> configure:10637: icc -o conftest -g -O2   conftest.c  >&5
    >> ld: library not found for -lgcc_s

After a couple notes to python-dev and a little bit of sleuthing with -v I
discovered that it was generating -lgcc_s instead of -lgcc_s.10.5 in the ld
line.  I narrowed the problem down to this code in configure.in:

            # Calculate the right deployment target for this build.
            #
            cur_target=`sw_vers -productVersion | sed 's/\(10\.[[0-9]]*\).*/\1/'`
            if test ${cur_target} '>' 10.2; then
                    cur_target=10.3
            fi
            if test "${UNIVERSAL_ARCHS}" = "all"; then
                    # Ensure that the default platform for a 4-way
                    # universal build is OSX 10.5, that's the first
                    # OS release where 4-way builds make sense.
                    cur_target='10.5'
            fi
            CONFIGURE_MACOSX_DEPLOYMENT_TARGET=${MACOSX_DEPLOYMENT_TARGET-${cur_target}}

            # Make sure that MACOSX_DEPLOYMENT_TARGET is set in the 
            # environment with a value that is the same as what we'll use
            # in the Makefile to ensure that we'll get the same compiler
            # environment during configure and build time.
            MACOSX_DEPLOYMENT_TARGET="$CONFIGURE_MACOSX_DEPLOYMENT_TARGET"
            export MACOSX_DEPLOYMENT_TARGET
            EXPORT_MACOSX_DEPLOYMENT_TARGET=''

The test of cur_target against 10.2 seems suspicious.  This code dates from
r65061 (checked in by Benjamin last July) which states:

  #3381 fix framework builds on 10.4

Maybe it should be 

            if test ${cur_target} '>' 10.2 -a ${cur_target} '<' 10.5 ; then
                    cur_target=10.3
            fi

(which works).

Skip

----------
messages: 79074
nosy: skip.montanaro
severity: normal
status: open
title: Trouble configuring with icc on Mac OS X 10.5

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

From report at bugs.python.org  Sun Jan  4 19:11:43 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 04 Jan 2009 18:11:43 +0000
Subject: [New-bugs-announce] [issue4835] SIZEOF_SOCKET_T not defined
In-Reply-To: <18784.64475.338807.986695@montanaro.dyndns.org>
Message-ID: <18784.64475.338807.986695@montanaro.dyndns.org>


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

Compiling with Intel's icc I get lots of remarks like this:

    icc -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I../Include   -DPy_BUILD_CORE -o Parser/acceler.o ../Parser/acceler.c
    ../Include/longobject.h(35): remark #193: zero used for undefined preprocessing identifier "SIZEOF_SOCKET_T"
      #if SIZEOF_SOCKET_T <= SIZEOF_LONG
          ^

This is only defined in Modules/socketmodule.h.  It should probably be
defined somewhere else if it's to be referenced by longobject.h.

Skip

----------
messages: 79075
nosy: skip.montanaro
severity: normal
status: open
title: SIZEOF_SOCKET_T not defined

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

From report at bugs.python.org  Sun Jan  4 19:15:20 2009
From: report at bugs.python.org (skillybob)
Date: Sun, 04 Jan 2009 18:15:20 +0000
Subject: [New-bugs-announce] [issue4836] Idle Hangs on Wxit Button
Message-ID: <1231092920.48.0.00559753673602.issue4836@psf.upfronthosting.co.za>


Changes by skillybob <skillybob2 at gmail.com>:


----------
components: IDLE
nosy: skillybob
severity: normal
status: open
title: Idle Hangs on Wxit Button
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jan  4 21:06:54 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 04 Jan 2009 20:06:54 +0000
Subject: [New-bugs-announce] [issue4837] Omits MACHINE and DEBUG when
	building tix8.4.3
In-Reply-To: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>
Message-ID: <1231099614.05.0.848880488218.issue4837@psf.upfronthosting.co.za>


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

Currently, to install tix we need long command like this.

nmake -f python.mak TCL_MAJOR=8 TCL_MINOR=5 TCL_PATCH=2 MACHINE=IX86 
DEBUG=0 INSTALL_DIR=..\..\tcltk install

This patch enables us to omit MACHINE and DEBUG. (Precisely, can omit 
MACHINE if CPU is i386)

This patch is for http://svn.python.org/projects/external/tix-8.4.3.1

----------
components: Build
files: python_mak_in_tix.patch
keywords: patch
messages: 79083
nosy: ocean-city
priority: low
severity: normal
status: open
title: Omits MACHINE and DEBUG when building tix8.4.3
versions: 3rd party
Added file: http://bugs.python.org/file12586/python_mak_in_tix.patch

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

From report at bugs.python.org  Mon Jan  5 00:16:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 04 Jan 2009 23:16:30 +0000
Subject: [New-bugs-announce] [issue4838] md_state is not released
In-Reply-To: <1231110990.47.0.0796872141326.issue4838@psf.upfronthosting.co.za>
Message-ID: <1231110990.47.0.0796872141326.issue4838@psf.upfronthosting.co.za>


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

module_dealloc should free md_state if it is non-zero, after m_free was
called.

----------
messages: 79095
nosy: loewis
priority: release blocker
severity: normal
status: open
title: md_state is not released
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jan  5 05:24:27 2009
From: report at bugs.python.org (Charles Hans)
Date: Mon, 05 Jan 2009 04:24:27 +0000
Subject: [New-bugs-announce] [issue4840] Compile dbm in Ubuntu
In-Reply-To: <1231129467.43.0.877411679563.issue4840@psf.upfronthosting.co.za>
Message-ID: <1231129467.43.0.877411679563.issue4840@psf.upfronthosting.co.za>


New submission from Charles Hans <cwhann at gmail.com>:

I tried and failed in compile python 3.0 in ubuntu 8.10. Then I found
the scripts in setup.py use "gdbm/ndbm.h" while in ubuntu 8.10 it should
be gdbm-ndbm.h. So I made the following change which make the compiling ok:


setup.py

787c787
<                   and find_file("gdbm/ndbm.h", inc_dirs, []) is not None):
---
>                   and find_file("gdbm-ndbm.h", inc_dirs, []) is not None):
790c790
<                                        libraries = ['gdbm'] ) )
---
>                                        libraries = ['gdbm',
'gdbm_compat'] ) )


Modules/_dbmodule.c

22c22
< #include <gdbm/ndbm.h>
---
> #include <gdbm-ndbm.h>

----------
components: Library (Lib)
messages: 79107
nosy: cwhan
severity: normal
status: open
title: Compile dbm in Ubuntu
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan  5 11:29:49 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 05 Jan 2009 10:29:49 +0000
Subject: [New-bugs-announce] [issue4841] io's close() not handling errors
	correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

In _fileio.c, there is the following comment: "Returns 0 on success,
errno (which is < 0) on failure." The problem here is the claim that
errno ever was less than zero, which is simply wrong.

You can see this being a problem with the following few lines:

import os, io
fd = os.open( "some existing file", os.O_RDONLY)
s1 = os.fdopen(fd)
s2 = io.open(fd)
os.close(fd)
s1.close()
s2.close()

The call to close() pulls the file from under the feet of the two stream
objects, but only the one opened with os.fdopen() actually detects that.
For the second one, errno is set, but to a positive value which isn't
detected correctly.

----------
components: Interpreter Core
messages: 79120
nosy: eckhardt
severity: normal
status: open
title: io's close() not handling errors correctly
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Jan  5 11:32:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Jan 2009 10:32:40 +0000
Subject: [New-bugs-announce] [issue4842] int('3L') still valid in Python 3.0
In-Reply-To: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>
Message-ID: <1231151560.41.0.758558901213.issue4842@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

int('3L') is still valid in Python 3.x.  Presumably this is unintentional.  
Is there any possibility of changing this for 3.0.1 or 3.1?

----------
components: Interpreter Core
messages: 79121
nosy: marketdickinson
severity: normal
status: open
title: int('3L') still valid in Python 3.0
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jan  5 12:58:24 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Jan 2009 11:58:24 +0000
Subject: [New-bugs-announce] [issue4843] copytree improvments
In-Reply-To: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>
Message-ID: <1231156704.22.0.372262791608.issue4843@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

In one sentence: 

Let's enhance shutil.copytree so we can drop distutils.[dir_util/file_util]

In details:

I am currently studying what could be removed from Distutils in order to
rely
on what is available in the standard library.

I have a concern about distutils.dir_util and distutils.file_util modules.

Distutils implements its own file and directory copy functions there, that
could be replaced by shutil ones, except four small features:

- verbose : each time a file is copied a "source -> target" is displayed
  in the output.
- dry_run : nothing is really copied
- update : each file will only be copied if they don't exist in the
  target path or if they are newer
- the copy_tree function returns the list of files copied (or that
  should have been copied when dry_run is True).

I think shutil could benefit from these small features, and            
       
distutils code could be refactored to use them.                        
       
                  
Here's a small proposal for distutils.copytree::                       
       
        
    copytree(src, dst, symlinks=False, ignore=None) -> None            
       
                
becomes:    
                
    copytree(src, dst, symlinks=False, ignore=None, update=False, 
             verbose=False, dry_run=False, logger=None) -> list of
copied files
            
where:          
                                                                       
       
- update    
 - if False, copytree behaves as usual: if os.path.samefile(source,
target) is True it raise an error                                      
                  
 - if True, the file is copied only if it's newer or doesn't exists,
otherwise it doesn't raise

- logger
  - if None, logger is set to logging.info

- verbose: if True, a logger.info("source -> target") call is made on
each copy

- dry_run: if True, the files are not really copied

Last, the function returns a tuple of copied files.

>From there, distutils can work with shutil.copytree, shutil.copyfile and
shutil.copy2


Pro's:
 - distutils can rely on this function and its specialized modules dissapear
 - shutil.copytree becomes more powerful
 - less redundancy in the sdtlib

Con's:
 - the API signature is getting a bit complex
 - distutils use case might not be common enough

----------
components: Library (Lib)
messages: 79129
nosy: tarek
severity: normal
status: open
title: copytree improvments
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jan  5 16:24:11 2009
From: report at bugs.python.org (Yngve AAdlandsvik)
Date: Mon, 05 Jan 2009 15:24:11 +0000
Subject: [New-bugs-announce] [issue4844] ZipFile doesn't range check in
	_EndRecData()
In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>
Message-ID: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za>


New submission from Yngve AAdlandsvik <ymgve at start.no>:

If you have a .zip file with an incomplete "End of Central Directory" 
record, _EndRecData() will throw a struct.error:

D:\c64workdir\Ultimate_Mag_Archive>e:ziptest.py "old - 
Ultimate_Mag_Archive"
Handling A-z\0\64times01-double.zip
Traceback (most recent call last):
  File "E:\wwwroot\c64db\tools\ziptest.py", line 48, in <module>
    ok = handle_file(data, rel_filename)
  File "E:\wwwroot\c64db\tools\ziptest.py", line 19, in handle_file
    z = zipfile.ZipFile(cStringIO.StringIO(data), "r")
  File "C:\Python26\lib\zipfile.py", line 698, in __init__
    self._GetContents()
  File "C:\Python26\lib\zipfile.py", line 718, in _GetContents
    self._RealGetContents()
  File "C:\Python26\lib\zipfile.py", line 728, in _RealGetContents
    endrec = _EndRecData(fp)
  File "C:\Python26\lib\zipfile.py", line 219, in _EndRecData
    endrec = list(struct.unpack(structEndArchive, recData))
struct.error: unpack requires a string argument of length 22

The fix is to include a check to see if there is data enough for the 
whole record before attempting to unpack.

----------
components: Library (Lib)
messages: 79155
nosy: ymgve
severity: normal
status: open
title: ZipFile doesn't range check in _EndRecData()
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan  5 17:00:40 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 16:00:40 +0000
Subject: [New-bugs-announce] [issue4845] warnings system and inspect module
	disagree about
In-Reply-To: <1231171240.01.0.534546346997.issue4845@psf.upfronthosting.co.za>
Message-ID: <1231171240.01.0.534546346997.issue4845@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Here's a transcript demonstrating the disagreement:

  exarkun at charm:~$ mkdir warningexample
  exarkun at charm:~$ cd warningexample/
  exarkun at charm:~/warningexample$ mkdir foo
  exarkun at charm:~/warningexample$ touch foo/__init__.py
  exarkun at charm:~/warningexample$ cat > foo/bar.py
  import warnings
  def foo():
        warnings.warn("foo")
  exarkun at charm:~/warningexample$ python -c 'import foo.bar'
  exarkun at charm:~/warningexample$ mv foo bar
  exarkun at charm:~/warningexample$ python -c 'import bar.bar; bar.bar.foo()'
  bar/bar.py:3: UserWarning: foo
    warnings.warn("foo")
  exarkun at charm:~/warningexample$ python -c 'import bar.bar, inspect;
print inspect.getabsfile(bar.bar.foo)'
  /home/exarkun/warningexample/foo/bar.py
  exarkun at charm:~/warningexample$ 

Notice that the warning is emitted for the file bar/bar.py but the
inspect module claims that the function which emitted the warning is
defined in /home/exarkun/warningexample/foo/bar.py.  It seems that the
warning system has somehow noticed that the .pyc file has the wrong
source file listed and has figured out the correct file name, whereas
the inspect module is blindly following the contents of the .pyc file.

It would be great if the inspect module were at least as good at
figuring out filenames as the warnings system.

----------
components: Library (Lib)
messages: 79159
nosy: exarkun
severity: normal
status: open
title: warnings system and inspect module disagree about
type: behavior

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

From report at bugs.python.org  Mon Jan  5 17:09:20 2009
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 05 Jan 2009 16:09:20 +0000
Subject: [New-bugs-announce] [issue4846] Py_UNICODE_ISSPACE causes linker
	error
In-Reply-To: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>
Message-ID: <1231171760.52.0.582449273969.issue4846@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

When I use Py_UNICODE_ISSPACE() in my C++ extension, I got following error.

test.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) unsigned char const * const _Py_ascii_whitespace"
(__imp_?_Py_ascii_whitespace@@3QBEB) referenced in function "struct
_object * __cdecl fff(struct _object *,struct _object *)"
(?fff@@YAPAU_object@@PAU1 at 0@Z)

Py_ascii_whitespace defined in unicodeobject.h should be enclosed by
'extern "C" {' block for C++ support.

Tested with Python 2.6.1/VS2008 express.

----------
messages: 79160
nosy: ishimoto
severity: normal
status: open
title: Py_UNICODE_ISSPACE causes linker error
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan  5 18:03:24 2009
From: report at bugs.python.org (jaywalker)
Date: Mon, 05 Jan 2009 17:03:24 +0000
Subject: [New-bugs-announce] [issue4847] csv fails when file is opened in
	binary mode
In-Reply-To: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>
Message-ID: <1231175004.95.0.780150738153.issue4847@psf.upfronthosting.co.za>


New submission from jaywalker <jaywalkie at yahoo.com>:

The following code from the documentation fails:
#################
import csv
reader = csv.reader(open("eggs.csv", "rb"))
for row in reader:
    print(row)
#####################
The output is:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in <module>
_csv.Error: iterator should return strings, not bytes (did you open the
file in text mode?)


It works as expected in python 2.6

----------
components: Library (Lib)
messages: 79165
nosy: jaywalker
severity: normal
status: open
title: csv fails when file is opened in binary mode
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan  5 18:15:58 2009
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 05 Jan 2009 17:15:58 +0000
Subject: [New-bugs-announce] [issue4848] MacPython build script uses Carbon
	and MacOS modules slated for removal
In-Reply-To: <1231175758.14.0.180038218422.issue4848@psf.upfronthosting.co.za>
Message-ID: <1231175758.14.0.180038218422.issue4848@psf.upfronthosting.co.za>


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

The build script for a Mac OS installer, in
Mac/BuildScript/build-installer.py, currently requires OS 10.4 and
Python 2.3.  At some point it will have to be ported to a newer version
of Python (and Mac OS).  It uses a number of modules which are slated
for future removal, particularly Carbon and MacOS.  These modules are
only used in the function "setIcon".  They can be replaced with a call
to a Cocoa method via PyObjC.  The "setIcon" function using PyObjC would
look like this:

def setIcon(folder, imagefile):

    try:

        import os, AppKit

        AppKit.NSApplicationLoad()      # initialize Cocoa

        return
AppKit.NSWorkspace.sharedWorkspace().setIcon_forFile_options_(
            AppKit.NSImage.alloc().initWithContentsOfFile_(imagefile),
            os.path.abspath(folder), 0)

    except ImportError:
        return False

----------
components: Build, Macintosh
messages: 79169
nosy: janssen
priority: low
severity: normal
status: open
title: MacPython build script uses Carbon and MacOS modules slated for removal
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jan  5 20:08:35 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 19:08:35 +0000
Subject: [New-bugs-announce] [issue4849] instantiating and populating
	xml.dom.minidom.Element is cumbersome
In-Reply-To: <1231182515.38.0.572857860756.issue4849@psf.upfronthosting.co.za>
Message-ID: <1231182515.38.0.572857860756.issue4849@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

In order to create an element with an attribute and a child, this is
necessary:

    e = Element("foo")
    e.setAttribute("bar", "baz")
    e.appendChild(quux)

It would be preferable if Element.__init__ accepted two additional
parameters to shorten this:

    e = Element("foo", attributes={"bar": "baz"}, children=[quux])

It may also be preferable to have a third new parameter, attributesNS,
to parallel the Element.setAttributeNS method.  This would accept a dict
mapping namespaceURI and qualifiedName to an attribute value.

----------
components: Library (Lib)
messages: 79183
nosy: exarkun
severity: normal
status: open
title: instantiating and populating xml.dom.minidom.Element is cumbersome
type: behavior

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

From report at bugs.python.org  Mon Jan  5 21:48:45 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jan 2009 20:48:45 +0000
Subject: [New-bugs-announce] [issue4850] Change type and add _Py_ prefix to
	COUNT_ALLOCS variables
In-Reply-To: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>
Message-ID: <1231188525.86.0.28964443261.issue4850@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

quick_int_allocs, quick_neg_int_allocs, tuple_zero_allocs, and 
fast_tuple_allocs are exported in -DCOUNT_ALLOCS builds.  They should get 
a conventional _Py_ prefix.  Also since tp_allocs is now Py_ssize_t, these 
should be redefined as Py_ssize_t as well.  See msg79194 .

----------
components: Interpreter Core
messages: 79199
nosy: belopolsky
severity: normal
status: open
title: Change type and add _Py_ prefix to COUNT_ALLOCS variables
type: feature request

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

From report at bugs.python.org  Mon Jan  5 23:00:10 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 05 Jan 2009 22:00:10 +0000
Subject: [New-bugs-announce] [issue4851] xml.dom.minidom.Element.cloneNode
	fails with AttributeError
In-Reply-To: <1231192810.66.0.263343969898.issue4851@psf.upfronthosting.co.za>
Message-ID: <1231192810.66.0.263343969898.issue4851@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

It seems impossible to clone an Element created without a document:

  >>> Element('foo').cloneNode(False)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 211, in cloneNode
      return _clone_node(self, deep, self.ownerDocument or self)
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 1814, in _clone_node
      if node.ownerDocument.isSameNode(newOwnerDocument):
  AttributeError: 'NoneType' object has no attribute 'isSameNode'

The documentation claims that cloneNode was fixed for releases
"subsequent" to 2.0, but this doesn't appear to be true.

http://docs.python.org/library/xml.dom.minidom.html#xml.dom.minidom.Node.cloneNode

A similar issue occurs when attempting to import a node into a document
(something I tried as a work-around for this failure):

  >>> d.importNode(e, False)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 1737, in importNode
      return _clone_node(node, deep, self)
    File "/usr/lib/python2.5/xml/dom/minidom.py", line 1814, in _clone_node
      if node.ownerDocument.isSameNode(newOwnerDocument):
  AttributeError: 'NoneType' object has no attribute 'isSameNode'

----------
components: Library (Lib)
messages: 79203
nosy: exarkun
severity: normal
status: open
title: xml.dom.minidom.Element.cloneNode fails with AttributeError
type: behavior

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

From report at bugs.python.org  Tue Jan  6 00:28:51 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 05 Jan 2009 23:28:51 +0000
Subject: [New-bugs-announce] [issue4852] Cleanup old stuff from pythread.h
In-Reply-To: <1231198131.15.0.910339238584.issue4852@psf.upfronthosting.co.za>
Message-ID: <1231198131.15.0.910339238584.issue4852@psf.upfronthosting.co.za>


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

This patch removes four functions from pythread.h, which have been 
unusable for ages:
- PyThread_exit_prog is excluded by a #ifndef, and the NO_EXIT_PROG 
symbol is defined in the same file.
- PyThread__PyThread_exit_thread appears in the .h but is not defined 
anywhere. OTOH the different thread implementations define 
PyThread__exit_thread but it is not exposed anywhere (since r12178...)

Better remove unused code...

----------
files: thread_cleanup.patch
keywords: needs review, patch, patch
messages: 79212
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Cleanup old stuff from pythread.h
versions: Python 2.7
Added file: http://bugs.python.org/file12609/thread_cleanup.patch

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

From report at bugs.python.org  Tue Jan  6 01:31:03 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jan 2009 00:31:03 +0000
Subject: [New-bugs-announce] [issue4853] I/O operation on closed socket:
	improve the error message
In-Reply-To: <1231201863.3.0.481342348653.issue4853@psf.upfronthosting.co.za>
Message-ID: <1231201863.3.0.481342348653.issue4853@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I don't like the current behaviour of Python on closed socket:

>>> import socket
>>> s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.close()
>>> s.fileno()
-1
>>> s.getsockname()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: [Errno 9] Bad file descriptor

Some operations are still allowed whereas the other raise an ugly 
error message. Most (or all) operation on a closed socket should be 
blocked by a socket.error.

My patch raises a socket.error("I/O operation on closed socket") for 
most operations except:
 - close(): it call be called twice (or more) (keep current behaviour)
 - gettimeout(): should we raise an error?
 - setblocking(), settimeout(): should we raise an error? Maybe yes 
for setter but no for getter which would be inconsistent with 
getpeername()...

The io library already has this behaviour: read(), write(), flush(), 
etc. are blocked by a ValueError("I/O operation on closed file") (see 
IOBase._check_closed in the io library).

Issue #4791 changes the behaviour of closed SocketIO object: fileno() 
method raise a socket.error if it's closed even if the socket is still 
open.

----------
files: socket_error_closed.patch
keywords: patch
messages: 79217
nosy: haypo
severity: normal
status: open
title: I/O operation on closed socket: improve the error message
versions: Python 3.0
Added file: http://bugs.python.org/file12612/socket_error_closed.patch

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

From report at bugs.python.org  Tue Jan  6 02:18:45 2009
From: report at bugs.python.org (=?utf-8?q?s=C3=A9bastien_martini?=)
Date: Tue, 06 Jan 2009 01:18:45 +0000
Subject: [New-bugs-announce] [issue4854] gnu_get_libc_version() returns bad
	number on Ubuntu 64 bits
In-Reply-To: <1231204725.41.0.336629965086.issue4854@psf.upfronthosting.co.za>
Message-ID: <1231204725.41.0.336629965086.issue4854@psf.upfronthosting.co.za>


New submission from s?bastien martini <seb at dbzteam.org>:

System: Ubuntu 8.10 Desktop AMD 64
Processor: Intel Core i7
Python: 2.5.2

While raw C code:

#include <gnu/libc-version.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
  printf("GNU libc version: %s\n", gnu_get_libc_version());
  return 0;
}

prints:
GNU libc version: 2.8.90

Python ctypes seems to bug:
$ python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, ctypes, ctypes.util
>>> sys.version
'2.5.2 (r252:60911, Oct  5 2008, 19:29:17) \n[GCC 4.3.2]'
>>> sys.platform
'linux2'
>>> LIBC = ctypes.cdll.LoadLibrary(ctypes.util.find_library('c'))
>>> LIBC
<CDLL 'libc.so.6', handle 7f6d83122958 at 7f6d82fe8210>
>>> LIBC.gnu_get_libc_version()
-2109473701

----------
assignee: theller
components: ctypes
messages: 79223
nosy: smartini, theller
severity: normal
status: open
title: gnu_get_libc_version() returns bad number on Ubuntu 64 bits
versions: Python 2.5

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

From report at bugs.python.org  Tue Jan  6 06:06:10 2009
From: report at bugs.python.org (wolfy)
Date: Tue, 06 Jan 2009 05:06:10 +0000
Subject: [New-bugs-announce] [issue4855] Popen with Shell=True should return
	the command
Message-ID: <1231218370.85.0.274309430706.issue4855@psf.upfronthosting.co.za>


Changes by wolfy <wolfgang_a_h at gmx.at>:


----------
nosy: wolfy
severity: normal
status: open
title: Popen with Shell=True should return the command

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

From report at bugs.python.org  Tue Jan  6 09:55:47 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 06 Jan 2009 08:55:47 +0000
Subject: [New-bugs-announce] [issue4856] Remove checks for win NT
In-Reply-To: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>
Message-ID: <1231232147.88.0.719794452167.issue4856@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

There are several checks like "GetVersion() < 0x80000000" that try to 
determine whether there is support for the WCHAR versions of the win32 
API. Since all support for MS Windows 95, 98 and ME has been dropped, 
all supported systems support those APIs. Also, I need that cleanup as 
preparation for porting Python to MS Windows CE, so that I don't have 
to clone/port code for obsolete systems there. I'll be providing 
patches here.

----------
components: Interpreter Core
messages: 79237
nosy: eckhardt
severity: normal
status: open
title: Remove checks for win NT
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan  6 14:11:53 2009
From: report at bugs.python.org (jura)
Date: Tue, 06 Jan 2009 13:11:53 +0000
Subject: [New-bugs-announce] [issue4857] syntax: no unpacking in augassign
In-Reply-To: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>
Message-ID: <1231247513.95.0.909259202166.issue4857@psf.upfronthosting.co.za>


New submission from jura <jura05 at narod.ru>:

the following code produces syntax error:
>>> (x, y) += 1
While this is documented in
http://docs.python.org/3.0/reference/simple_stmts.html#augmented-assignment-statements
("An augmented assignment evaluates the target (which, unlike normal
?ssignment statements, cannot be an unpacking)..."),
the syntax specification doesn't reflect this:
http://docs.python.org/3.0/reference/simple_stmts.html#grammar-token-augmented_assignment_stmt
http://docs.python.org/3.0/reference/grammar.html

----------
assignee: georg.brandl
components: Documentation
messages: 79256
nosy: georg.brandl, jura05
severity: normal
status: open
title: syntax: no unpacking in augassign
versions: Python 3.0

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

From report at bugs.python.org  Tue Jan  6 21:06:16 2009
From: report at bugs.python.org (Lukas Lueg)
Date: Tue, 06 Jan 2009 20:06:16 +0000
Subject: [New-bugs-announce] [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>


New submission from Lukas Lueg <knabberknusperhaus at yahoo.de>:

MD5 is one of the most popular cryptographic hash-functions around,
mainly for it's good performance and availability throughout
applications and libraries. The MD5 algorithm is currently implemented
in python as part of the hashlib-module and (in more general terms) as
part of SSL in the ssl-module. However, concerns about the security of
MD5 have risen during the last few years. In 2007 a practical attack to
create collisions in the compression-function has been released and on
12/31/2008 US-CERT issued a note to warn about the general insecurity of
MD5 (http://www.kb.cert.org/vuls/id/836068).


I propose and strongly suggest to start deprecate direct support for MD5
during this year and completly remove support for it afterwards.

 * MD5 is a cryptographic hash function, it's reason for being is
security. By means of current hardware and attack vectors it's a matter
of hours to create collisions and fool MD5 hashes. The reason for being
has come to an end.
 * Python runs an uncountable number of exposed user interfaces on the
web. Usually the programmers rely on the security of the backing
libraries. Python can't provide this with MD5.
 * The functionality of MD5 can be easily replaced by using other hashes
that are supported by python (e.g. SHA1). They supply compareable
performance but are not binary-compatible (yay).
 * Programmers use MD5 in python without the need for it's cryptographic
attributes (e.g. creating unique indexes). Keeping MD5 for this use
however devaluates overall security of python for the good of few.


I'd like to start a discussion about this. Please keep in mind that -
although MD5 is currently still very popular and python's support for it
is justifed by demand - it's existence will come to an end soon.

We should now act and give people time to update their implementations. 


In a rough cut:

 - Patch haslib to throw a DeprecationWarning, starting during the first
half of 2009.
 - Update documentation not to use MD5 for security reasons
 - Remove MD5 from python in 2010.
 - Keep accordance to PEP 4


Goodbye MD5 and thanks for all the fish.

----------
components: Extension Modules
messages: 79281
nosy: ebfe
severity: normal
status: open
title: Deprecation of MD5
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Jan  6 21:52:31 2009
From: report at bugs.python.org (David Watson)
Date: Tue, 06 Jan 2009 20:52:31 +0000
Subject: [New-bugs-announce] [issue4859] pwd, spwd,
	grp functions vulnerable to denial of service
In-Reply-To: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>
Message-ID: <1231275151.13.0.805176401894.issue4859@psf.upfronthosting.co.za>


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

The pwd (and spwd and grp) modules deal with data from
/etc/passwd (and/or other sources) that can be supplied by users
on the system.  Specifically, users can often change the data in
their GECOS fields without the OS requiring that it conform to a
specific encoding, and given some automated account signup
system, it's conceivable that arbitrary data could even be placed
in the username field.

This causes a problem since the functions in these modules try to
decode the data into str objects, and if a user has placed data
in /etc/passwd, say, that does not conform to the relevant
encoding, the function will raise UnicodeDecodeError and thus
prevent the program from learning the relevant mapping between
username and UID, etc. (or crash the program if it wasn't
expecting this).  For a system program written in Python, this
can amount to a denial of service attack, especially if the
program uses the get*all() functions.

Currently, the pwd module tries to decode the string fields using
the Unicode-escape codec, i.e. like a Python string literal, and
this can fail when given an invalid backslash escape.  You can
see this by running chfn(1), entering something like "\ux" in one
of the fields, and then calling pwd.getpwnam(yourname) or
pwd.getpwall().  Perhaps the use of this codec is a mistake,
given that spwd and grp decode the string fields as UTF-8, but
chfn could also be used to enter non-UTF-8 data in the GECOS
field.  You can see similar failures in the grp and spwd modules
after adding a user with a non-UTF-8 name (do something like
"useradd $'\xff'" in bash).

A debug build of Python also reports a reference counting error
in grp (count goes to -1) when its functions fail on non-UTF-8
data; what I think is going on is that in mkgrent(),
PyStructSequence_SET_ITEM steals the reference to "w", meaning
the second "Py_DECREF(w)" shouldn't be there.  Also, getpwall()
and getgrall() leave file descriptors open when they fail, since
they don't call end*ent() in this case.  The attached minor.diff
fixes both of these problems, I think.

I've also written a patch (bytes.diff, attached) that would add
new functions pwd.getpwnamb(), etc. (analogous to os.getcwdb())
to return bytes objects for the text fields, thus avoiding these
problems - what do you think?  The patch also makes pwd's
original string functions use UTF-8 like the other modules.

Alternatively or in addition, a quick "fix" for the GECOS problem
might be for the pwd module to decode the text fields as Latin-1,
since in the absence of backslash escapes this is what the
Unicode-escape encoding is equivalent to.  This would at least
block any DoS attempts using the GECOS field (or attempts to add
extra commas with \x2c, etc.) without changing the behaviour
much.  The attached latin1.diff does this.

----------
components: Extension Modules
files: bytes.diff
keywords: patch
messages: 79286
nosy: baikie
severity: normal
status: open
title: pwd, spwd, grp functions vulnerable to denial of service
type: security
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12621/bytes.diff

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

From report at bugs.python.org  Tue Jan  6 22:44:11 2009
From: report at bugs.python.org (Noufal)
Date: Tue, 06 Jan 2009 21:44:11 +0000
Subject: [New-bugs-announce] [issue4860] js_output wrong for cookies with "
	characters
In-Reply-To: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>
Message-ID: <1231278251.3.0.384248147823.issue4860@psf.upfronthosting.co.za>


New submission from Noufal <noufal at nibrahim.net.in>:

If a cookie is created with a " character in the content, the js_output
which is emitted is bad javascript. eg.
>>> import Cookie
>>> c=Cookie.Cookie('Customer="WILE_E_COYOTE"; Version=1; Path=/acme')
>>> print c
Set-Cookie: Customer="WILE_E_COYOTE"; Path=/acme; Version=1
>>> print c.js_output()

        <script type="text/javascript">
        <!-- begin hiding
        document.cookie = "Customer="WILE_E_COYOTE"; Path=/acme; Version=1";
        // end hiding -->
        </script>
        
>>> 

Also, the test_cookie tests (test_load) explicitly checks for this
(wrong) output.

I have attached a patch that seems to fix this or at the very least
produces the same Cookie settings whether the cookie is set using the
header or using javascript (I've verified this on firefox on Linux).

----------
components: Library (Lib), Tests
files: cookie.patch
keywords: patch
messages: 79292
nosy: noufal
severity: normal
status: open
title: js_output wrong for cookies with " characters
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12625/cookie.patch

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

From report at bugs.python.org  Tue Jan  6 23:02:52 2009
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 06 Jan 2009 22:02:52 +0000
Subject: [New-bugs-announce] [issue4861] fix problems with
	ctypes.util.find_library
In-Reply-To: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>
Message-ID: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

there are some problems with ctypes.util.find_library(), which I would
like to see fixed on active branches.

 - find_library is not robust, if either objdump or gcc are not
   installed. fixed by raising an exception if the tools are not
   found. Is OSError the correct type for this exception?

 - ldconfig -p already prints the shared object name. afaics there
   is no need to call objdump again.

 - the regexp to scan the ldconfig -p output is wrong for
   architectures where libraries of more than one abi type are
   installed, e.g. having ix86 libs on a x86_64 system. Having
   only the library installed which doesn't match the python
   executable lets find_library find the wrong library. Note that
   the patch is only correct under the assumption that the python
   executable is unstalled for the "main" abi.

patch attached, ok to check in?

----------
assignee: theller
components: ctypes
files: ctypes-findlib.diff
keywords: patch, patch
messages: 79294
nosy: doko, theller
severity: normal
status: open
title: fix problems with ctypes.util.find_library
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12626/ctypes-findlib.diff

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

From report at bugs.python.org  Wed Jan  7 01:21:17 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 07 Jan 2009 00:21:17 +0000
Subject: [New-bugs-announce] [issue4862] utf-16 BOM is not skipped after
	seek(0)
In-Reply-To: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>
Message-ID: <1231287677.41.0.817743984337.issue4862@psf.upfronthosting.co.za>


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

First write a utf-16 file with its signature:

>>> f1 = open('utf16.txt', 'w', encoding='utf-16')
>>> f1.write('0123456789')
>>> f1.close()

Then read it twice:

>>> f2 = open('utf16.txt', 'r', encoding='utf-16')
>>> print('read1', ascii(f2.read()))
read1 '0123456789'
>>> f2.seek(0)
0
>>> print('read2', ascii(f2.read()))
read2 '\ufeff0123456789'

The second read returns the BOM!
This is because the zero in seek(0) is a "cookie" which contains both the position 
and the decoder state. Unfortunately, state=0 means 'endianness has been determined: 
native order'.

maybe a suggestion: handle seek(0) as a special value which calls decoder.reset().
The patch implement this idea.

----------
files: io_utf16.patch
keywords: patch
messages: 79299
nosy: amaury.forgeotdarc
priority: critical
severity: normal
status: open
title: utf-16 BOM is not skipped after seek(0)
versions: Python 3.0
Added file: http://bugs.python.org/file12627/io_utf16.patch

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

From report at bugs.python.org  Wed Jan  7 06:56:11 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 07 Jan 2009 05:56:11 +0000
Subject: [New-bugs-announce] [issue4863] deprecate/delete
	distutils.mwerkscompiler...
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <18788.17382.220573.660720@montanaro.dyndns.org>


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

I was just poking around the distutils documentation and came across the
distutils.mwerkscompiler module.  Surely that can't be useful anymore, can
it?  The doc reads, in its entirety:

    Contains MWerksCompiler, an implementation of the abstract CCompiler
    class for MetroWerks CodeWarrior on the pre-Mac OS X Macintosh. Needs
    work to support CW on Windows or Mac OS X.

So the only place it used to work was on pre-Mac OS X, which Python doesn't
support any longer and "will need work" for Windows or Mac OS X which
presumably nobody has done.  This module should be deprecated in 3.1 and
removed in 3.2.

Skip

----------
messages: 79300
nosy: skip.montanaro
severity: normal
status: open
title: deprecate/delete distutils.mwerkscompiler...

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

From report at bugs.python.org  Wed Jan  7 07:04:34 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 07 Jan 2009 06:04:34 +0000
Subject: [New-bugs-announce] [issue4864] test_msvc9compiler fails on VC6
In-Reply-To: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>
Message-ID: <1231308274.82.0.340976198497.issue4864@psf.upfronthosting.co.za>


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

Currently, test_msvc9compiler fails on VC6 with following message.

//////////////////////////////////////////

Traceback (most recent call last):
  File "test_distutils.py", line 17, in <module>
    test_main()
  File "test_distutils.py", line 13, in test_main
    test.test_support.run_unittest(distutils.tests.test_suite())
  File "e:\python-dev\trunk\lib\test\test_support.py", line 710, in 
run_unittest

    _run_suite(suite)
  File "e:\python-dev\trunk\lib\test\test_support.py", line 693, in 
_run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\trunk\lib\distutils\tests\test_msvc9compiler.py", 
line 16,
 in test_no_compiler
    from distutils.msvc9compiler import query_vcvarsall
  File "e:\python-dev\trunk\lib\distutils\msvc9compiler.py", line 281, 
in <modul
e>
    raise DistutilsPlatformError("VC %0.1f is not supported by this 
module" % VE
RSION)
DistutilsPlatformError: VC 6.0 is not supported by this module

//////////////////////////////////////////

I think attached patch will fix this. Is this fix appropriate?

Thank you.

----------
components: Tests
files: test_msvc9compiler.patch
keywords: easy, needs review, patch
messages: 79301
nosy: ocean-city
severity: normal
status: open
title: test_msvc9compiler fails on VC6
versions: Python 2.7
Added file: http://bugs.python.org/file12628/test_msvc9compiler.patch

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

From martin at v.loewis.de  Wed Jan  7 11:14:47 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 07 Jan 2009 11:14:47 +0100
Subject: [New-bugs-announce] [issue4858] Deprecation of MD5
In-Reply-To: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
References: <1231272376.79.0.422670760646.issue4858@psf.upfronthosting.co.za>
Message-ID: <49648097.5030704@v.loewis.de>

> I propose and strongly suggest to start deprecate direct support for MD5
> during this year and completly remove support for it afterwards.

-1. Stopping usage of md5 should be the user's choice, not Python's.

>  * MD5 is a cryptographic hash function, it's reason for being is
> security. By means of current hardware and attack vectors it's a matter
> of hours to create collisions and fool MD5 hashes. The reason for being
> has come to an end.

I think you misunderstand the kind of problem that has been detected.
It is still *not* possible to produce a colliding text within
reasonable, when given the md5 hash. So when md5 is used as the trap
function for password storage, it's use remains perfectly safe.

Likewise, md5 is still well capable of detecting corruption of binary
files (e.g. during downloads), and will remain in use for this
application for many more years.

It is only in the context of digital signatures that the "chosen prefix"
attack can be demonstrated successfully.

>  * Python runs an uncountable number of exposed user interfaces on the
> web. Usually the programmers rely on the security of the backing
> libraries. Python can't provide this with MD5.

That's like saying "Mercedes drivers rely on efficient operation of the
motor. By putting water into the tank, the motor fails to deliver. So
let's put a ban on the usage of water in cars."

>  * The functionality of MD5 can be easily replaced by using other hashes
> that are supported by python (e.g. SHA1). They supply compareable
> performance but are not binary-compatible (yay).

In some case, yes, replacement is easy. In other cases, replacement is
not so easy. For example, for password hashes, you cannot simply rehash
all passwords - because you typically don't know what they are.

From martin at v.loewis.de  Wed Jan  7 11:29:57 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 07 Jan 2009 11:29:57 +0100
Subject: [New-bugs-announce] [issue4863]
	deprecate/delete	distutils.mwerkscompiler...
In-Reply-To: <18788.17382.220573.660720@montanaro.dyndns.org>
References: <18788.17382.220573.660720@montanaro.dyndns.org>
Message-ID: <49648425.9000208@v.loewis.de>

> So the only place it used to work was on pre-Mac OS X, which Python doesn't
> support any longer and "will need work" for Windows or Mac OS X which
> presumably nobody has done.  This module should be deprecated in 3.1 and
> removed in 3.2.

I would actually remove it right away in 2.7/3.1.

From report at bugs.python.org  Wed Jan  7 13:51:02 2009
From: report at bugs.python.org (Karsten Petersen)
Date: Wed, 07 Jan 2009 12:51:02 +0000
Subject: [New-bugs-announce] [issue4865] system wide site-packages dir not
	used on Mac OS X
In-Reply-To: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>
Message-ID: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>


New submission from Karsten Petersen <kapet at kapet.de>:

[Guido asked me to file this as an issue.]

On Mac OS X Apple has configured the system provided Python to also
search this global site-packages directory:
   /Library/Python/<version>/site-packages/

This allows users to install their own system-wide packages there (and
not have them to drop into /System/Library/Frameworks/Python....../).

Unfortunately if you install Python from python.org (or pythonmac.org)
it is not searching this path, it only searches the site-packages
directory _within_ its own framework:
  /Library/Frameworks/Python...../
That directory is of course not searched by the Apple provided Python.

This is an issue for addon package installers (think PIL or numpy): 
There is no single path that will be found by both the system provided
Python and a Python installed from python.org.  This makes most/all (?)
of the pre-built packages on pythonmac.org unusable with the version of
Python Apple ships although there is no version conflict or such - it
simply installs stuff in the "wrong" directories.

Many people who tried to install PIL for Django or App Engine stumbled
into this.  The system provided Python version was fine.  But compiling
PIL is hard.  So they installed PIL from pythonmac.org.  That couldn't
be found by Python.  Now some people manually copied stuff around, some
created symlinks, some installed a second Python 2.5.  (The lucky ones
picked a Python download from python.org, the not so lucky ones
installed the 2.5.0 release from pythonmac.org...)

I've attached a diff of a stock Python 2.5.1 library against what I
found on my Apple Mac OS X 10.5 (Leopard) system.  I've dropped changes
that are not related to the path.

----------
components: Library (Lib), Macintosh
files: apple.diff
keywords: patch
messages: 79329
nosy: kapet
severity: normal
status: open
title: system wide site-packages dir not used on Mac OS X
type: behavior
Added file: http://bugs.python.org/file12637/apple.diff

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

From report at bugs.python.org  Wed Jan  7 15:04:40 2009
From: report at bugs.python.org (ganderson)
Date: Wed, 07 Jan 2009 14:04:40 +0000
Subject: [New-bugs-announce] [issue4866] Code to remove in parsetok?
Message-ID: <1231337080.92.0.440917680493.issue4866@psf.upfronthosting.co.za>


Changes by ganderson <g.anderson at tuttoniente.net>:


----------
components: Interpreter Core
nosy: ganderson
severity: normal
status: open
title: Code to remove in parsetok?
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Jan  7 15:41:22 2009
From: report at bugs.python.org (jice)
Date: Wed, 07 Jan 2009 14:41:22 +0000
Subject: [New-bugs-announce] [issue4867] crash in ctypes when passing a
	string to a function without defining argtypes
In-Reply-To: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>
Message-ID: <1231339282.89.0.0934088116939.issue4867@psf.upfronthosting.co.za>


New submission from jice <jice.nospam at gmail.com>:

This code works in python 2.5 & 2.6 :
>>> import ctypes
>>> lib=ctypes.cdll['./libtcod.so']
>>> lib.TCOD_console_init_root(80,50,'test',0)
 1

In python 3.0, it crashes in _CallProc (callproc.c, line 1136) :
 if (atypes[i]->type == FFI_TYPE_STRUCT
atypes[i] == NULL here because when there is no argtypes, the default
converter (ConvParam) does not set ffi_type for string parameters if
HAVE_USABLE_WCHAR_T is FALSE.

To make it work, I have to define the argtypes for the function :
>>> import ctypes
>>> lib=ctypes.cdll['./libtcod.so']
>>> from ctypes import *
>>> lib.TCOD_console_init_root.argtypes=[c_int,c_int,c_char_p,c_uint]
>>> lib.TCOD_console_init_root(80,50,'test',0)
 1

I've compiled python 3.0 on a standard Ubuntu 8.04 and the test_ctypes
unit test works fine.

----------
assignee: theller
components: ctypes
messages: 79334
nosy: jice, theller
severity: normal
status: open
title: crash in ctypes when passing a string to a function without defining argtypes
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Wed Jan  7 16:25:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 15:25:03 +0000
Subject: [New-bugs-announce] [issue4868] Faster utf-8 decoding
In-Reply-To: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>
Message-ID: <1231341903.79.0.54860955311.issue4868@psf.upfronthosting.co.za>


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

Here is a patch to speedup utf8 decoding. On a 64-bit build, the maximum
speedup is around 30%, and on a 32-bit build around 15%. (*)

The patch may look disturbingly trivial, and I haven't studied the
assembler output, but I think it is explained by the fact that having a
separate loop counter breaks the register dependencies (when the 's'
pointer was incremented, other operations had to wait for the
incrementation to be committed).

[side note: utf8 encoding is still much faster than decoding, but it may
be because it allocates a smaller object, regardless of the iteration count]

The same principle can probably be applied to the other decoding
functions in unicodeobject.c, but first I wanted to know whether the
principle is ok to apply. Marc-Andr?, what is your take?


(*) the benchmark I used is:

./python -m timeit -s "import
codecs;c=codecs.utf_8_decode;s=b'abcde'*1000" "c(s)"

More complex input also gets a speedup, albeit a smaller one (~10%):

./python -m timeit -s "import
codecs;c=codecs.utf_8_decode;s=b'\xc3\xa9\xe7\xb4\xa2'*1000" "c(s)"

----------
components: Interpreter Core
files: utf8decode.patch
keywords: patch
messages: 79338
nosy: lemburg, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Faster utf-8 decoding
type: performance
versions: Python 3.1
Added file: http://bugs.python.org/file12638/utf8decode.patch

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

From report at bugs.python.org  Wed Jan  7 17:17:01 2009
From: report at bugs.python.org (Keith Briggs)
Date: Wed, 07 Jan 2009 16:17:01 +0000
Subject: [New-bugs-announce] [issue4869] random.expovariate(0.0)
In-Reply-To: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>
Message-ID: <1231345021.11.0.806380260729.issue4869@psf.upfronthosting.co.za>


New submission from Keith Briggs <kbriggs at users.sourceforge.net>:

random.expovariate(lambd) should handle lambd=0 cleanly, and probably
return a FP infinity.

At the moment it gives:

ZeroDivisionError: float division

----------
components: Extension Modules
messages: 79346
nosy: kbriggs
severity: normal
status: open
title: random.expovariate(0.0)
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan  7 19:11:44 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 07 Jan 2009 18:11:44 +0000
Subject: [New-bugs-announce] [issue4870] ssl module is missing
	SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>


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

As came out here:
http://groups.google.it/group/comp.lang.python/browse_thread/thread/7d5b96f9bacb03d3?hl=it#
...the ssl module does not provide any facility to disable SSL version
2. This is very important when writing SSLv3/TLSv1 compatible servers.

----------
components: Library (Lib)
messages: 79357
nosy: giampaolo.rodola, janssen
severity: normal
status: open
title: ssl module is missing SSL_OP_NO_SSLv2
type: security
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Jan  7 21:26:25 2009
From: report at bugs.python.org (Glade Diviney)
Date: Wed, 07 Jan 2009 20:26:25 +0000
Subject: [New-bugs-announce] [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>


New submission from Glade Diviney <gladed at sybase.com>:

If a password is supplied using zpifile.read(objName, password), a 
TypeError occurs:

  File "C:\Program Files\Python30\lib\zipfile.py", line 420, in __init__
    self._UpdateKeys(p)
  File "C:\Program Files\Python30\lib\zipfile.py", line 424, in 
_UpdateKeys
    self.key0 = self._crc32(c, self.key0)
  File "C:\Program Files\Python30\lib\zipfile.py", line 413, in _crc32
    return ((crc >> 8) & 0xffffff) ^ self.crctable[(crc ^ ch) & 0xff]
TypeError: unsupported operand type(s) for ^: 'int' and 'str'

This is resolved in zipfile.py by replacing this line in __init__:
             self._UpdateKeys(ord(p))

----------
components: Library (Lib)
messages: 79368
nosy: gladed
severity: normal
status: open
title: zipfile can't decrypt
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Wed Jan  7 22:55:32 2009
From: report at bugs.python.org (nqiang)
Date: Wed, 07 Jan 2009 21:55:32 +0000
Subject: [New-bugs-announce] [issue4872] Python will not co-exist with MFC
	(memory leak)
In-Reply-To: <1231365332.46.0.804752973069.issue4872@psf.upfronthosting.co.za>
Message-ID: <1231365332.46.0.804752973069.issue4872@psf.upfronthosting.co.za>


New submission from nqiang <NQIANG at WMAINC.COM>:

The following code will cause memory leak in debug mode using visual 
studio 2008/2005
Comment out either MFC related (CString s) or Python related PY_XX. 
Then there will be no memory leak.

#include <python.h>
#include <afx.h>


int _tmain(int argc, _TCHAR* argv[])
{
	Py_Initialize();
	Py_Finalize();
	CString	s;
	return 0;
}

----------
messages: 79375
nosy: nqiang
severity: normal
status: open
title: Python will not co-exist with MFC (memory leak)
type: resource usage
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Jan  7 23:30:46 2009
From: report at bugs.python.org (David Watson)
Date: Wed, 07 Jan 2009 22:30:46 +0000
Subject: [New-bugs-announce] [issue4873] Refcount error and file descriptor
	leaks in pwd, grp modules
In-Reply-To: <1231367446.48.0.542903635557.issue4873@psf.upfronthosting.co.za>
Message-ID: <1231367446.48.0.542903635557.issue4873@psf.upfronthosting.co.za>


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

When investigating issue #4859 I found that when pwd.getpwall()
and grp.getgrall() fail due to decoding errors, they leave open
file descriptors referring to the passwd and group files, since
they don't call the end*ent() functions in this case.  Also, the
grp.* functions have a reference counting error when they fail in
this way - a debug build reports that an object's reference count
goes to -1.  What I think happens is that in mkgrent(),
PyStructSequence_SET_ITEM steals the reference to "w", meaning
that the "Py_DECREF(w)" call shouldn't be made afterwards.  The
attached diff fixes both of these problems, I think, and applies
to the 2.x and 3.x branches.

----------
components: Extension Modules
files: minor.diff
keywords: patch
messages: 79378
nosy: baikie
severity: normal
status: open
title: Refcount error and file descriptor leaks in pwd, grp modules
type: resource usage
Added file: http://bugs.python.org/file12639/minor.diff

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

From report at bugs.python.org  Thu Jan  8 00:48:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jan 2009 23:48:16 +0000
Subject: [New-bugs-announce] [issue4874] decoding functions in _codecs
	module accept str arguments
In-Reply-To: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>
Message-ID: <1231372096.73.0.0745033084101.issue4874@psf.upfronthosting.co.za>


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

The following function calls should raise a TypeError instead. Encoding
functions are fine (they only accept str).

>>> import codecs
>>> codecs.utf_8_decode('aa')
('aa', 2)
>>> codecs.utf_8_decode('??')
('??', 4)
>>> codecs.latin_1_decode('??')
('????', 4)

----------
components: Extension Modules
messages: 79384
nosy: pitrou
priority: release blocker
severity: normal
status: open
title: decoding functions in _codecs module accept str arguments
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jan  8 01:43:36 2009
From: report at bugs.python.org (Ryan Kelly)
Date: Thu, 08 Jan 2009 00:43:36 +0000
Subject: [New-bugs-announce] [issue4875] find_library can return directories
	instead of files
In-Reply-To: <1231375416.63.0.958079386255.issue4875@psf.upfronthosting.co.za>
Message-ID: <1231375416.63.0.958079386255.issue4875@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

On win32, ctypes.util.find_library uses os.path.exists() to check for
potential library files.  This means it is quite happy to return a
directory instead of a file, if one happens to exist with the
appropriate name somewhere in the search path.  Can this please be
changed to use os.path.isfile() instead of os.path.exists()?

----------
assignee: theller
components: ctypes
messages: 79385
nosy: rfk, theller
severity: normal
status: open
title: find_library can return directories instead of files
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan  8 03:26:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 08 Jan 2009 02:26:53 +0000
Subject: [New-bugs-announce] [issue4876] Incorrect detection of module as
	local
In-Reply-To: <1231381613.0.0.23916695518.issue4876@psf.upfronthosting.co.za>
Message-ID: <1231381613.0.0.23916695518.issue4876@psf.upfronthosting.co.za>


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

There is an unfortunate interaction of two fixers to be observed in
django. django.util.text.py contains

from htmlentitydefs import name2codepoint

This gets fixed to

from .html.entities import name2codepoint

because there is also a local module django.util.html. This is
incorrect; it should have converted it to

from html.entities import name2codepoint

As a workaround, I now run

   name2codepoint = __import__('html.entities').entities.name2codepoint

on ImportError of the (converted) import statement. Is there a better
work-around?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 79395
nosy: loewis
severity: normal
status: open
title: Incorrect detection of module as local

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

From report at bugs.python.org  Thu Jan  8 06:01:16 2009
From: report at bugs.python.org (Steve Howard)
Date: Thu, 08 Jan 2009 05:01:16 +0000
Subject: [New-bugs-announce] [issue4877] xml.parsers.expat ParseFile()
	causes segmentation fault when passed a closed file object
In-Reply-To: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>
Message-ID: <1231390876.07.0.554090447949.issue4877@psf.upfronthosting.co.za>


New submission from Steve Howard <dev at gostevehoward.com>:

In Python 2.5.4 built from unmodified source:

showard at showardlt:~/src/Python-2.5.4$ ./python
Python 2.5.4 (r254:67916, Jan  7 2009, 20:28:41) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()
>>> p.ParseFile(f)
Segmentation fault

The error is in the control flow in xmlparse_ParseFile()
(Modules/pyexpat.c:1000).  When passed a real file object that's been
closed, PyFile_Check() returns true, but then PyFile_AsFile() returns 0
(since f_fp on the file object is set to zero when the file is closed).
 So the local 'fp' is set to 0, and 'readmethod' is left as NULL.  The
conditional at 1033 then fails, and the call to readinst() at 1041
passes readmethod=NULL, leading eventually to a segfault in
PyObject_Call at Objects/abstract.c:1860.

I think it's present in 2.6 as well, but I'm not sure.  It seems to have
been fixed by chance in 3.0 because Guido removed the first branch in
xmlparse_ParseFile altogether in an unrelated change a while ago.

The attached patch simply checks for fp == 0 and raises an exception.  I
don't know if it's the proper solution but you get the idea.

Built with the attached patch:

showard at showardlt:~/src/Python-2.5.4$ ./python
Python 2.5.4 (r254:67916, Jan  7 2009, 20:28:41) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()   
>>> p.ParseFile(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: attempting to parse closed file

----------
components: XML
files: pyexpat_segfault_on_closed_file.patch
keywords: patch
messages: 79398
nosy: showard
severity: normal
status: open
title: xml.parsers.expat ParseFile() causes segmentation fault when passed a closed file object
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file12646/pyexpat_segfault_on_closed_file.patch

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

From report at bugs.python.org  Thu Jan  8 10:44:54 2009
From: report at bugs.python.org (Juha Rantanen)
Date: Thu, 08 Jan 2009 09:44:54 +0000
Subject: [New-bugs-announce] [issue4878] post installer script's message is
	not shown to user with bdist_wininst
In-Reply-To: <1231407894.66.0.157123159421.issue4878@psf.upfronthosting.co.za>
Message-ID: <1231407894.66.0.157123159421.issue4878@psf.upfronthosting.co.za>


New submission from Juha Rantanen <juha.rantanen at iki.fi>:

1. Create installer with bdist_wininst with python version 2.5
2. Install it to 2.6 Python. 
3. The post installer message is not shown to user in the installer window.
4. Remove the installation from add/remove programs.
5. Messages coming from removing are not shown to the user.


This same happens if the installer is created with python 2.6 and it is
installed to 2.5 Python. See attached project, which can be used to
create the installer which contains post installer script.

----------
components: Distutils
files: simple.zip
messages: 79404
nosy: rantanen
severity: normal
status: open
title: post installer script's message is not shown to user with bdist_wininst
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12648/simple.zip

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

From report at bugs.python.org  Thu Jan  8 11:43:56 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Jan 2009 10:43:56 +0000
Subject: [New-bugs-announce] [issue4879] Allo buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

This is related to issue 4336.  While that issue finally revolved around 
fixing the Nagle problem for xmlrpc and other http clients, here I 
propose to fix another performance bottleneck with xmlrpc, reading the 
HTTP Headers.
HTTPResponse creates a socket.fileobject() with zero buffering which 
means that the readline() operations used to read the headers become 
very inefficient since individual socket.recv() calls are used for each 
character.
The reason for this is to support users who subsequently do 
socket.recv() on the underlying socket, and so we don't want to read too 
much of the headers. Note that there is no example of this in the 
standard library.
In the provided patch, I have removed some vestigial code from 
xmrlpclib.py which attempted to use recv() even though it never did 
(because the connection has been closed when HTTPConnection returns the 
response).  Even so, Guido has expressed his concern that we need to 
keep the support for this recv() behaviour in place.
Therefore, I have added a new optional argument, nobuffer=True, which 
users that promise not to call recv() can set to false.  This will then 
cause the generated fileobject from HTTPResponse to have default 
buffering, greatly increasing the performance of the reading of the 
headers.

----------
components: Library (Lib)
files: nobuffer.patch
keywords: patch, patch
messages: 79406
nosy: krisvale
severity: normal
status: open
title: Allo buffering for HTTPResponse
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12649/nobuffer.patch

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

From report at bugs.python.org  Thu Jan  8 15:56:30 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 08 Jan 2009 14:56:30 +0000
Subject: [New-bugs-announce] [issue4880] PyInt_FromSsize_t LONG_MIN and
	LONG_MAX typecasts needed
In-Reply-To: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>
Message-ID: <1231426590.2.0.669134378939.issue4880@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

there's probably a better way to do this (or a better reason), but
LONG_MIN and LONG_MAX end up as the wrong constant types when compiling
python2.5.2 under wine (don't ask...)

PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
    if ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
    {
        return PyInt_FromLong((long)ival);
    }
    return _PyLong_FromSsize_t(ival);
}

----------
messages: 79411
nosy: lkcl
severity: normal
status: open
title: PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
versions: Python 2.5

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

From report at bugs.python.org  Thu Jan  8 16:03:05 2009
From: report at bugs.python.org (Pablo Castagnino)
Date: Thu, 08 Jan 2009 15:03:05 +0000
Subject: [New-bugs-announce] [issue4881] Python's timezon handling: daylight
	saving option
In-Reply-To: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>
Message-ID: <1231426985.03.0.0279324437493.issue4881@psf.upfronthosting.co.za>


New submission from Pablo Castagnino <pablo.castagnino at gmail.com>:

Something in python's timezone handling needs to be
updated. Python does not take into account 'daylight saving' clock time
changes.

The thing is my clock time is correct. If you
ask anyone here for the time, they will tell you it's X. However, Python
believes (correct) current time is X + 1 hour. In fact, this is the case
most of the time, but because of 'daylight saving' measures, official
time has been changed. So, without a doubt, this needs to be fixed.

A solution could be adding the possibility to set a 'daylight saving'
option which helps dealing with this. So, if I set this option to 3600
secs, then Python could +/- this remainder to the, let's call it,
'expected current time' according to the timezone.

----------
components: Library (Lib)
messages: 79415
nosy: earendili510
severity: normal
status: open
title: Python's timezon handling: daylight saving option
type: feature request

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

From report at bugs.python.org  Thu Jan  8 16:35:46 2009
From: report at bugs.python.org (alec resnick)
Date: Thu, 08 Jan 2009 15:35:46 +0000
Subject: [New-bugs-announce] [issue4882] Behavior of backreferences to named
	groups in regular expressions unclear
In-Reply-To: <1231428946.66.0.0747408022841.issue4882@psf.upfronthosting.co.za>
Message-ID: <1231428946.66.0.0747408022841.issue4882@psf.upfronthosting.co.za>


New submission from alec resnick <aresnickety at gmail.com>:

I recently learned about named groups in Python regular expressions. 
Almost all the documentation I've found online explains what they are
and give a simple example of how to use them.  I was trying to use the
variables outside of the original regex, later in the code.  Nowhere in
the documentation I found after a couple hours of searching was it
mentioned that named groups can only be backreferenced _within_ the pattern.

In particular, the sections at
http://www.amk.ca/python/howto/regex/#SECTION000530000000000000000 and
the description of the (?P<name>) behavior at
http://docs.python.org/library/re.html could be modified to make it
clear that the named capture does not create a variable usable outside
of the pattern.

I would be happy to alter the documentation appropriately.

----------
assignee: georg.brandl
components: Documentation
messages: 79417
nosy: aresnick, georg.brandl
severity: normal
status: open
title: Behavior of backreferences to named groups in regular expressions unclear
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan  8 17:13:38 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 08 Jan 2009 16:13:38 +0000
Subject: [New-bugs-announce] [issue4883] Compiling python 2.5.2 under Wine
	on linux.
In-Reply-To: <1231431218.3.0.0118570431179.issue4883@psf.upfronthosting.co.za>
Message-ID: <1231431218.3.0.0118570431179.issue4883@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

messy patches which get python 2.5.2 compiling - and producing
python.exe.so - under wine.

the setup.py is presently _wholly_ unsuited to use for building
the modules - get_sysconfig("srcdir") returns None because...
it's supposed to!

but, the actual libpython2.5.a and the actual python.exe _are_
successfully built - and, amazingly, useable.

----------
components: Build
files: f
messages: 79420
nosy: lkcl
severity: normal
status: open
title: Compiling python 2.5.2 under Wine on linux.
versions: Python 2.5
Added file: http://bugs.python.org/file12653/f

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

From report at bugs.python.org  Thu Jan  8 20:08:15 2009
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 08 Jan 2009 19:08:15 +0000
Subject: [New-bugs-announce] [issue4884] Work around gethostbyaddr_r bug
In-Reply-To: <1231441695.4.0.529827841073.issue4884@psf.upfronthosting.co.za>
Message-ID: <1231441695.4.0.529827841073.issue4884@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

glibc until 2.10 has a bug in gethostbyaddr_r that assumes the buffer
argument is 8-byte aligned
(http://sources.redhat.com/ml/libc-alpha/2009-01/msg00000.html). gcc
seems to always provide such alignment for the call in
socketmodule.c:socket_gethostbyaddr(), but llvm-gcc (possibly only HEAD,
not 2.4) does not, which causes a segfault in test_socket.py. The llvm
bug investigating the problem is http://llvm.org/bugs/show_bug.cgi?id=3233.

The attached patch specifies the alignment so that llvm-gcc and unfixed
glibcs work together.

I'll commit this tomorrow if there are no objections.

----------
components: Extension Modules
files: fix_gethostbyaddr.patch
keywords: patch
messages: 79429
nosy: collinwinter, jyasskin
severity: normal
stage: patch review
status: open
title: Work around gethostbyaddr_r bug
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12654/fix_gethostbyaddr.patch

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

From report at bugs.python.org  Thu Jan  8 21:18:13 2009
From: report at bugs.python.org (ndbecker)
Date: Thu, 08 Jan 2009 20:18:13 +0000
Subject: [New-bugs-announce] [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>


New submission from ndbecker <ndbecker2 at gmail.com>:

I'd like to suggest some improvements from mmap

1) mmap assign to slice only accepts a string.  This is unfortunate,
because AFAIK a string can only be created by copying data, and this is
wasteful for large data transfers.  mmap should accept any object
supporting buffer protocol as well as string.

2) buffer (mmap_obj) gives a read_only buffer.  There should be a way to
make this read_write.  I suggest 'as_buffer' member.

3) mmap_obj does not support weak ref.  This is needed for proper
lifetime management using boost::python

----------
components: Library (Lib)
messages: 79433
nosy: ndbecker
severity: normal
status: open
title: mmap enhancement request
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Thu Jan  8 22:21:26 2009
From: report at bugs.python.org (Michael Yang)
Date: Thu, 08 Jan 2009 21:21:26 +0000
Subject: [New-bugs-announce] [issue4886] test/regrtest.py contains error on
	__import__
In-Reply-To: <1231449686.43.0.781017317614.issue4886@psf.upfronthosting.co.za>
Message-ID: <1231449686.43.0.781017317614.issue4886@psf.upfronthosting.co.za>


New submission from Michael Yang <yangofzeal at gmail.com>:

I want to use the included test.regrtest (located in 
$pythondir/lib/python[ver]/test) to regression test some of my own 
scripts located in directory myDir.  The script has some nice 
configurability features to skip some tests based on machine 
configurations, etc. that a vanilla unittest suite doesn't include 
automatically.  However, it seems that the script regrtest.py has an 
error following the __import__ line.

Here's my setup:

/sample.py
/myDir
    /__init__.py
    /test_file1.py
    /test_file2.py
    /...

in sample.py:

{{{
#!python
#!/usr/bin/env python
import test.regrtest as rt
rt.main(tests = ['myDir.test_file1','myDir.test_file2'], \
quiet = False, verbose = True)
}}}

running sample.py yields:

{{{
#!sh
myDir.test_file1
myDir.test_file1 skipped -- No module named myDir.test_file1
myDir.test_file2
myDir.test_file2 skipped -- No module named myDir.test_file2
2 tests skipped:
    myDir.test_file1 myDir.test_file2
2 skips unexpected on win32:
    myDir.test_file1 myDir.test_file2
}}}

This is due to the code snippet in regrtest.py around line 554:

{{{
#!python
...
            if test.startswith('test.'):
                abstest = test
            else:
                # Always import it from the test package
                abstest = 'test.' + test
            the_package = __import__(abstest, globals(), locals(), [])
            the_module = getattr(the_package, test)
...
}}}

should be changed to:
{{{
#!python
...
            if test.startswith('test.'):
                abstest = test
                modName = test[len('test.'):]
            else:
                # Always import it from the test package
                abstest = 'test.' + test
                modName = test
            the_package = __import__(abstest, globals(), locals(), [])
            the_module = getattr(the_package, modName)
...
}}}

This way, the the_module will correctly find the module name in 
'the_package'.

A further recommendation: the main() module should be able to work with 
test directories with name other than 'test.*'.  Otherwise, users 
wishing to use the main() on other directories will have to name them 
'test.'  Depending on the user's directory's position in sys.path 
(before or after $pythondir/lib/python[ver]), regrtest.main() will 
either fail due to the 'from test import ...' statements being shadowed 
by the user's 'test' directory or the user's 'test' directory being 
shadowed by the standard library's.

----------
components: Library (Lib)
messages: 79442
nosy: msyang
severity: normal
status: open
title: test/regrtest.py contains error on __import__
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Jan  8 23:08:07 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 08 Jan 2009 22:08:07 +0000
Subject: [New-bugs-announce] [issue4887] environment inspection and
	manipulation API is buggy,
	inconsistent with "Python philosophy" for wrapping native APIs
In-Reply-To: <1231452487.08.0.408278867366.issue4887@psf.upfronthosting.co.za>
Message-ID: <1231452487.08.0.408278867366.issue4887@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

According to a recent thread on python-dev, Python APIs with the same
name as native APIs can be trusted to just pass through to the platform
API call
(<http://mail.python.org/pipermail/python-dev/2009-January/084899.html>). 
This isn't the case for the environment APIs in the os module.  For
example, os.getenv doesn't always return the actual value of a key in
the environment.  Instead, it looks in the os.environ pseudo-dict to get
the answer.  This can be wrong because os.environ is a *copy* of the
environment which any non-Python API will use, and as a copy it can get
out of sync with the real environment.  One way it can get out of sync
is via os.environ.pop (at least on POSIX - os.environ has different
implementations on different platforms, I find the way an implementation
is selected to be rather confusing and I have not tracked down the
precise behavior for all platforms):

>>> import os
>>> os.environ.pop('PATH')
'/home/exarkun/.local/sbin:/home/exarkun/.local/bin:/home/exarkun/Projects/combinator_paths/bincache:/home/exarkun/.local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games'
>>> os.getenv('PATH')
>>> os.system("echo $PATH")
/home/exarkun/.local/sbin:/home/exarkun/.local/bin:/home/exarkun/Projects/combinator_paths/bincache:/home/exarkun/.local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
0
>>> 

Another way is via calls to the platform environment manipulation APIs
(setenv, unsetenv or putenv).  These might be invoked by a third-party
library which is exposed to Python or via ctypes.

`environ? itself is a C API, though it's a char**, whereas os.environ is
a Python dict.  It's probably convenient for os.environ to remain as a
dict, since that's so much simpler to manipulate and inspect than the C
data structure used.  However, it'd be good if were always in sync with
the real process environment.  A good way to do this would probably be
to stop maintaining a copy of the environment and always pass through to
one of the platform APIs to satisfy a method call onto it.

----------
components: Library (Lib)
messages: 79448
nosy: exarkun
severity: normal
status: open
title: environment inspection and manipulation API is buggy, inconsistent with "Python philosophy" for wrapping native APIs
type: behavior

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

From report at bugs.python.org  Fri Jan  9 05:52:14 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 09 Jan 2009 04:52:14 +0000
Subject: [New-bugs-announce] [issue4888] misplaced (or misleading) assert in
	ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>


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

There is what I believe is a misplaced - or at least misleading - assert
in the while loop following the fast_block_end label.  If why != WHY_YIELD
before the loop starts I don't see how that relationship could change
within the loop.  Proposed patch against py3k branch attached.

(Yes, I realize this is trivial and that the assert is compiled away in
non-debug builds.)

----------
files: assert.diff
keywords: patch
messages: 79453
nosy: skip.montanaro
severity: normal
status: open
title: misplaced (or misleading) assert in ceval.c
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12658/assert.diff

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

From report at bugs.python.org  Fri Jan  9 06:49:39 2009
From: report at bugs.python.org (Pratik Potnis)
Date: Fri, 09 Jan 2009 05:49:39 +0000
Subject: [New-bugs-announce] [issue4889] difflib
In-Reply-To: <1231480179.7.0.0322918194746.issue4889@psf.upfronthosting.co.za>
Message-ID: <1231480179.7.0.0322918194746.issue4889@psf.upfronthosting.co.za>


New submission from Pratik Potnis <pratik.potnis at gmail.com>:

While using function HtmlDiff() from Library difflib, if there is
difference in caps of two strings it does not provide proper diff results.
Two strings in two different files in this context that I used are:
hostname vaijain123 and (this string is in small caps)
hostname CAVANC1001CR1 (This one is in large caps)

Expected behavior after diffing : It should show hostname changed (and
highlight it with Yellow color)

instead of this it is showing Added in one file and deleted in another
file. (Highlighting them with green and red color respectively)

When tried with same caps (either small or large) it shows expected
behavior(highlighting the strings in yellow color). Also with numbers it
works well.

I think its an issue with the CAPS of letters. difflib is not able to
differentiate between the caps of letters.

----------
components: Library (Lib)
files: c1.ios
messages: 79455
nosy: pratik.potnis
severity: normal
status: open
title: difflib
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12659/c1.ios

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

From report at bugs.python.org  Fri Jan  9 11:23:49 2009
From: report at bugs.python.org (Matthias Kievernagel)
Date: Fri, 09 Jan 2009 10:23:49 +0000
Subject: [New-bugs-announce] [issue4890] handling empty text search pattern
	in tkinter
In-Reply-To: <1231496629.01.0.458062958908.issue4890@psf.upfronthosting.co.za>
Message-ID: <1231496629.01.0.458062958908.issue4890@psf.upfronthosting.co.za>


New submission from Matthias Kievernagel <mkiever at web.de>:

Split this from issue 1581476 as suggested
 by Guilherme Polo (gpolo).

>Matthias: your issue about the pattern should be placed in a 
>different
>issue.

Quote of my original report:
(This is about the search function of the Text class in Tkinter.
 An IndexError is raised when pattern == '')
...
>In addition I get an IndexError, if I delete the
>last character of the search string.
>Does Tk allow calling search with an empty pattern?

>Tkinter could handle this (with a correct result)
>with the following change in Tkinter.py / Text.search():

>if pattern[0] == '-': args.append('--')
>->
>if pattern and pattern[0] == '-': args.append('--')

A further remark from Guilherme Polo (gpolo):

>For the suggestion about fixing the search method regarding the 
>pattern:
>the fix is almost fine, but we need to disallow None as a pattern.

I do not understand that remark. Is it to avoid the TclError?
Or because the exception changes (IndexError -> TclError)?
What do you want to do when pattern == None? Raise ValueError
or IndexError (as before)?

Appended slightly simplified demo program from issue 1581476
and a patch against trunk r68445.

Cheers,
Matthias Kievernagel
mkiever/at/web/dot/de

----------
components: Tkinter
files: text_search_pattern.py
messages: 79459
nosy: mkiever
severity: normal
status: open
title: handling empty text search pattern in tkinter
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12660/text_search_pattern.py

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

From report at bugs.python.org  Fri Jan  9 12:09:01 2009
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 09 Jan 2009 11:09:01 +0000
Subject: [New-bugs-announce] [issue4891] formatwarning function signature
	change breaks code
In-Reply-To: <1231499341.14.0.968854878286.issue4891@psf.upfronthosting.co.za>
Message-ID: <1231499341.14.0.968854878286.issue4891@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

External code that temporarily replaces warnings.formatwarning, a
technique used in IDLE and worked around (see issue 4043), is broken by
the addition of the optional parameter lineno to the formatwarning function.

While normal calls to functions can be "compatibly" extended with
additional optional parameters, that is not the case when the function
is substituted for, by matching its signature... if the signature is
extended, the code breaks on a Python upgrade, because the substituted
function doesn't know about the new parameter, and has fewer than are
being supplied by calls to the function.

Whether this is good, bad, documented, or appropriate, I don't know, but
it broke CherryPy 3.1.1 when running on Python 2.6, because of the new,
optional, lineno=None parameter to warnings.formatwarning



Not sure I have type and components right.  I'm a newbie.

This problem probably also applies to 3.0, but I don't have the
environment to test it there at present.

I first described this problem on python-dev and the suggestion was made
to put it here (remainder of this comment is a quote):

This formatwarning compatibility problem between 2.5 and 2.6 is a bug.
Please file a new issue for this.

-- Amaury Forgeot d'Arc

----------
components: Interpreter Core
messages: 79462
nosy: v+python
severity: normal
status: open
title: formatwarning function signature change breaks code
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan  9 12:46:07 2009
From: report at bugs.python.org (Henrik Gustafsson)
Date: Fri, 09 Jan 2009 11:46:07 +0000
Subject: [New-bugs-announce] [issue4892] Sending Connection-objects over
	multiprocessing connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>


New submission from Henrik Gustafsson <henrik.gustafsson at purplescout.se>:

It seems the old pyprocessing (http://pyprocessing.berlios.de/) can do 
some things that the new multiprocessing package can not; 
sending/receiving connection objects for one.

This is a quite handy functionality, so it would be nice if it were 
reintroduced.

Also, the error message isn't very helpful.

Failing test below.


$ python2.6 pipetest2.py 
asdf
Traceback (most recent call last):
  File "a.py", line 10, in <module>
    print c1.recv()
TypeError: Required argument 'handle' (pos 1) not found

$ PYTHONPATH=processing-0.52-py2.5-macosx-10.5-i386.egg python2.5 
pipetest2.py 
asdf
Connection(handle=5)

$ PYTHONPATH=multiprocessing-2.6.0.2-py2.5-macosx-10.5-i386.egg 
python2.5 pipetest2.py 
asdf
Traceback (most recent call last):
  File "pipetest2.py", line 10, in <module>
    print c1.recv()
TypeError: function takes at least 1 argument (0 given)

$ uname -a
Darwin midori.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 
17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

----------
components: Library (Lib), Macintosh
messages: 79464
nosy: gsson
severity: normal
status: open
title: Sending Connection-objects over multiprocessing connections fails
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan  9 13:01:37 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 09 Jan 2009 12:01:37 +0000
Subject: [New-bugs-announce] [issue4893] Use separate thread support code
	under MS Windows CE
In-Reply-To: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>
Message-ID: <1231502497.69.0.51093314672.issue4893@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

There is a separate file thread_wince.h for use with CE, but that is
firstly not used due to a missing macro definition and secondly it
doesn't compile as it is. The attached patch defines WINCE_THREADS for
CE and makes the file at least compile.

Note that this doesn't touch any working code, because the CE port is
currently broken anyway. Further, the changes compile, but since there
are various other bits and pieces still missing, it is impossible to
test it yet.

----------
components: Interpreter Core
files: python-2.7-wince-threads.0.patch
keywords: patch
messages: 79466
nosy: eckhardt
severity: normal
status: open
title: Use separate thread support code under MS Windows CE
versions: Python 2.7
Added file: http://bugs.python.org/file12663/python-2.7-wince-threads.0.patch

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

From report at bugs.python.org  Fri Jan  9 14:58:36 2009
From: report at bugs.python.org (mroman)
Date: Fri, 09 Jan 2009 13:58:36 +0000
Subject: [New-bugs-announce] [issue4894] documentaion doesn't include
	parameter in urllib.request.HTTPRedirectHandler.redirect_request
In-Reply-To: <1231509516.06.0.732679259028.issue4894@psf.upfronthosting.co.za>
Message-ID: <1231509516.06.0.732679259028.issue4894@psf.upfronthosting.co.za>


New submission from mroman <mroman at eduapple.pl>:

documentaion doesn't include parameter in 
urllib.request.HTTPRedirectHandler.redirect_request

http://docs.python.org/3.0/library/urllib.request.html#urllib.request.HT
TPRedirectHandler.redirect_request

says:
HTTPRedirectHandler.redirect_request(req, fp, code, msg, hdrs)

while code says:
    def redirect_request(self, req, fp, code, msg, headers, newurl):

----------
assignee: georg.brandl
components: Documentation
messages: 79468
nosy: georg.brandl, mroman, quiver
severity: normal
status: open
title: documentaion doesn't include parameter in urllib.request.HTTPRedirectHandler.redirect_request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Jan  9 15:15:04 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 09 Jan 2009 14:15:04 +0000
Subject: [New-bugs-announce] [issue4895] Missing strdup() under MS Windows CE
In-Reply-To: <1231510504.25.0.240511707312.issue4895@psf.upfronthosting.co.za>
Message-ID: <1231510504.25.0.240511707312.issue4895@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

CE6 doesn't provide strdup() but provides an equivalent _strdup() in
stdlib.h. The attached patch simply #defines strdup _strdup after
including said header file.

----------
components: Interpreter Core
files: python-2.7-wince-strdup.0.patch
keywords: patch
messages: 79469
nosy: eckhardt
severity: normal
status: open
title: Missing strdup() under MS Windows CE
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file12666/python-2.7-wince-strdup.0.patch

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

From report at bugs.python.org  Fri Jan  9 15:31:53 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 09 Jan 2009 14:31:53 +0000
Subject: [New-bugs-announce] [issue4896] Faster why variable manipulation in
	ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <18791.24525.745699.580609@montanaro.dyndns.org>


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

The why_code enum in ceval.c has values which form a bit set.  Comparison of
the why variable against multiple values is going to be faster using bitwise
operations instead of logical ones.  For example, instead of

    why == WHY_RETURN || why == WHY_CONTINUE

the equivalent bitwise expression is

    why & (WHY_RETURN | WHY_CONTINUE)

which has fewer operations (one vs three treating the rhs of & as a
constant).  This is already done in one place.  The attached patch converts
all other expressions of the first form.

Also, there are some further manipulations of why in the loop after the
fast_block_end.  The loop can only be entered if why != WHY_NOT.  In the
loop when it is set to WHY_NOT, the loop breaks.  There is thus no reason to
test its value in the while expression.  Further, instead of just breaking
from the loop and then checking the why != WHY_NOT again, just jump past
that check by adding a why_not_here label.

The attached patch implements these changes (against the py3k branch).  All
tests pass on my Mac except test_cmd_line (which has been failing for
awhile).

Skip

----------
files: unnamed
messages: 79470
nosy: skip.montanaro
severity: normal
status: open
title: Faster why variable manipulation in ceval.c
Added file: http://bugs.python.org/file12667/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: application/octet-stream
Size: 2431 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20090109/72c62241/attachment-0001.obj>

From report at bugs.python.org  Fri Jan  9 15:52:16 2009
From: report at bugs.python.org (garcia)
Date: Fri, 09 Jan 2009 14:52:16 +0000
Subject: [New-bugs-announce] [issue4897] PyIter_Next documentation
	inconsistent with implementation
In-Reply-To: <1231512736.18.0.593919226046.issue4897@psf.upfronthosting.co.za>
Message-ID: <1231512736.18.0.593919226046.issue4897@psf.upfronthosting.co.za>


New submission from garcia <ronald.garcia at rice.edu>:

The documentation for PyIter_Next says it will raise TypeError if the 
object passed to it is not an iterator.  However, the implementation in 
abstract.c performs an assert rather than raising TypeError.  I would 
prefer if the implementation were adjusted to match the documentation 
rather than vice-versa.

----------
components: None
messages: 79472
nosy: garcia
severity: normal
status: open
title: PyIter_Next documentation inconsistent with implementation
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jan  9 16:38:12 2009
From: report at bugs.python.org (=?utf-8?q?Adeodato_Sim=C3=B3?=)
Date: Fri, 09 Jan 2009 15:38:12 +0000
Subject: [New-bugs-announce] [issue4898] {context,
	unified}_diff add spurious trailing whitespace if
	fromfiledate/tofiledate are emptyk
In-Reply-To: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>
Message-ID: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>


New submission from Adeodato Sim? <dato at net.com.org.es>:

Hello.

I recently noticed that Bazaar's unified_diff() was emiting ---/+++ 
lines with a trailing whitespace if fromfiledate/tofiledate were the 
empty string. (Which was bad because a program to detect spurious 
trailing whitespace in diffs would flag them as errors.)

A patch [1] was committed recently in their tree. During the 
discussion, it was pointed out that the affected function was a copy 
of Python's own unified_diff() in difflib, which suffered the same 
problem.

  [1]: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3923

I'm now attaching a patch to fix this issue in Python. It'd be great 
if you'd consider applying it. (It seems that the correct character to 
separate dates is a tab and not a space; if you feel changing this is 
breaking backwards compatibility, feel free to s/\t/ / in my patch.)

Thanks.

----------
components: Library (Lib)
files: python_difflib_fix.diff
keywords: patch
messages: 79473
nosy: dato, jameinel
severity: normal
status: open
title: {context,unified}_diff add spurious trailing whitespace if fromfiledate/tofiledate are emptyk
type: behavior
Added file: http://bugs.python.org/file12668/python_difflib_fix.diff

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

From report at bugs.python.org  Fri Jan  9 17:19:00 2009
From: report at bugs.python.org (Giovanni)
Date: Fri, 09 Jan 2009 16:19:00 +0000
Subject: [New-bugs-announce] [issue4899] doctest should support fixtures
In-Reply-To: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>
Message-ID: <1231517940.49.0.224416428352.issue4899@psf.upfronthosting.co.za>


New submission from Giovanni <dalloliogm at gmail.com>:

The doctest module should have support for fixtures (e.g. setUp and
tearDown methods).

It is very silly to be forced to always re-import all the modules needed
in every function tested with doctest.
For example, when you have to document functions that open files, you
have to import StringIO or TempFile, and then create a file, while this
could be done easily with a fixture.

----------
components: Tests
messages: 79477
nosy: dalloliogm
severity: normal
status: open
title: doctest should support fixtures
type: feature request

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

From report at bugs.python.org  Fri Jan  9 18:05:16 2009
From: report at bugs.python.org (mark pennock)
Date: Fri, 09 Jan 2009 17:05:16 +0000
Subject: [New-bugs-announce] [issue4900] Can't Locate File with No Capital
	in Name
Message-ID: <1231520716.63.0.978266493814.issue4900@psf.upfronthosting.co.za>


Changes by mark pennock <markpennock at motorola.com>:


----------
components: None
nosy: markpennock
severity: normal
status: open
title: Can't Locate File with No Capital in Name
versions: Python 2.5

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

From report at bugs.python.org  Fri Jan  9 19:56:17 2009
From: report at bugs.python.org (garcia)
Date: Fri, 09 Jan 2009 18:56:17 +0000
Subject: [New-bugs-announce] [issue4901] inconsistent API docs for tp_iter
In-Reply-To: <1231527377.73.0.506480870476.issue4901@psf.upfronthosting.co.za>
Message-ID: <1231527377.73.0.506480870476.issue4901@psf.upfronthosting.co.za>


New submission from garcia <ronald.garcia at rice.edu>:

Page 107 of api.pdf says that Py_TPFLAGS_HAVE_ITER is set if the type 
object has the tp_iter and tp_iternext fields, but on page 109, preceding 
the documentation of tp_iter and tp_iternext, it says "the next two fields 
only exist if the Py_TPFLAGS_HAVE_CLASS flag bit is set".

Should the latter refer to Py_TPFLAGS_HAVE_ITER?

----------
assignee: georg.brandl
components: Documentation
messages: 79487
nosy: garcia, georg.brandl
severity: normal
status: open
title: inconsistent API docs for tp_iter
versions: Python 2.5

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

From report at bugs.python.org  Fri Jan  9 22:15:13 2009
From: report at bugs.python.org (Aki)
Date: Fri, 09 Jan 2009 21:15:13 +0000
Subject: [New-bugs-announce] [issue4902] failed to build ctypes in
	Python2.6.1 (even with gcc)
In-Reply-To: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>
Message-ID: <1231535713.47.0.728185935162.issue4902@psf.upfronthosting.co.za>


New submission from Aki <akineko at users.sourceforge.net>:

I'm trying to build Python 2.6.1 on Solaris/x86 machine but it puked.

gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/home/neko/gnu/Python-2.6.1/./Include
-Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include
-Ibuild/temp.solaris-2.10-i86pc-2.6/libffi
-I/home/neko/gnu/Python-2.6.1/Modules/_ctypes/libffi/src -I. -IInclude
-I./Include -I/usr/local/include -I/home/neko/gnu/Python-2.6.1/Include
-I/home/neko/gnu/Python-2.6.1 -c
/home/neko/gnu/Python-2.6.1/Modules/_ctypes/libffi/src/x86/sysv.S -o
build/temp.solaris-2.10-i86pc-2.6/home/neko/gnu/Python-2.6.1/Modules/_ctypes/libffi/src/x86/sysv.o
Assembler:
    "/usr/tmp/ccF9sUxS.s", line 215 : Syntax error
    Near line: " movl ((10 + 3) & ~3)(%eax), %esi"
    "/usr/tmp/ccF9sUxS.s", line 215 : Illegal character: <7e>
    "/usr/tmp/ccF9sUxS.s", line 216 : Syntax error
    Near line: " movl ((((10 + 3) & ~3) + 4) + 4)(%eax), %edx"
    "/usr/tmp/ccF9sUxS.s", line 216 : Illegal character: <7e>
    "/usr/tmp/ccF9sUxS.s", line 223 : Syntax error
    Near line: " call *(((10 + 3) & ~3) + 4)(%eax)"
    "/usr/tmp/ccF9sUxS.s", line 223 : Illegal character: <7e>

Failed to build these modules:
_ctypes            _curses            _curses_panel

//

I'm using gcc 3.4.6 and Solaris 10/x86.

I try to identify the problem but I couldn't figure out what went wrong.
I'm using Python 2.6.1 on Solaris/SPARC and I didn't see any problem.

----------
messages: 79508
nosy: akineko
severity: normal
status: open
title: failed to build ctypes in Python2.6.1 (even with gcc)
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan 10 03:57:58 2009
From: report at bugs.python.org (David M. Beazley)
Date: Sat, 10 Jan 2009 02:57:58 +0000
Subject: [New-bugs-announce] [issue4903] binascii.crc32()
In-Reply-To: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>
Message-ID: <1231556278.06.0.571264691147.issue4903@psf.upfronthosting.co.za>


New submission from David M. Beazley <beazley at users.sourceforge.net>:

The result of binascii.crc32() is different on the same input in Python 
2.6/3.0.  For example:

Python 2.6:

>>> binascii.crc32('Hello')
-137262718

Python 3.0:

>>> binascii.crc32(b'Hello')
4157704578

----------
components: Library (Lib)
messages: 79524
nosy: beazley
severity: normal
status: open
title: binascii.crc32()
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sat Jan 10 07:33:43 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 10 Jan 2009 06:33:43 +0000
Subject: [New-bugs-announce] [issue4904] Typo for PickingError in pickle.py
In-Reply-To: <1231569223.03.0.0748221773659.issue4904@psf.upfronthosting.co.za>
Message-ID: <1231569223.03.0.0748221773659.issue4904@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

Noticed that in the release version of python 3.0 and the latest svn that 
on line 835 the exception UnpickingError is raised instead of UnpicklingError.

----------
components: Library (Lib)
messages: 79531
nosy: erickt
severity: normal
status: open
title: Typo for PickingError in pickle.py
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sat Jan 10 10:41:55 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sat, 10 Jan 2009 09:41:55 +0000
Subject: [New-bugs-announce] [issue4905] Use INVALID_FILE_ATTRIBUTES instead
	of magic numbers
In-Reply-To: <1231580515.2.0.210154432041.issue4905@psf.upfronthosting.co.za>
Message-ID: <1231580515.2.0.210154432041.issue4905@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

GetFileAttributes[W|A] returns a DWORD with this value when it 
couldn't determine the file's attributes. In the Python codebase, 
there are basically three values this is compared with, the above 
macro, 0xffffffff and (DWORD)-1, it should only be the macro.

However, this macro isn't defined in some SDKs (I don't remember if 
those were early MSVC versions or some MS Windows CE SDKs), so we also 
need to work around that.

I'm currently preparing a patch that resolves those including the 
workaround when the macro isn't defined.

----------
components: Interpreter Core
messages: 79535
nosy: eckhardt
severity: normal
status: open
title: Use INVALID_FILE_ATTRIBUTES instead of magic numbers
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan 10 12:11:51 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 10 Jan 2009 11:11:51 +0000
Subject: [New-bugs-announce] [issue4906] os.listdir fails on debug build
	(windows)
In-Reply-To: <1231585911.12.0.413619049778.issue4906@psf.upfronthosting.co.za>
Message-ID: <1231585911.12.0.413619049778.issue4906@psf.upfronthosting.co.za>


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

Due to r68455, os.listdir fails on debug build (windows).

//////////////////////////////////

Python 2.7a0 (trunk, Jan 10 2009, 18:36:15) [MSC v.1200 32 bit (Intel)] 
on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import os
[33639 refs]
>>> os.listdir(".")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 0] ???????????????: './*.*'
[33678 refs]

//////////////////////////////////

Probably a following XP Buildbot error comes from same reason.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1759/step-compile/0

This error is raised near Modules/posixmodule.c (2205)

	Py_BEGIN_ALLOW_THREADS
	result = FindNextFile(hFindFile, &FileData);
	Py_END_ALLOW_THREADS
	/* FindNextFile sets error to ERROR_NO_MORE_FILES if
	   it got to the end of the directory. */
	if (!result && GetLastError() != ERROR_NO_MORE_FILES) {

GetLastError() is sometimes 0 when should be ERROR_NO_MORE_FILES.
This happens because, on debug build, Py_END_ALLOW_THREADS finally
reaches PyThread_get_key_value in Python/thread_nt.h, and TlsGetValue
in it calls SetValueError(0) when function succeeds. See
http://msdn.microsoft.com/en-us/library/ms686812.aspx

I've attached the patch to fix this. I believe LastError set by
TlsGetValue on its failure is not used anywhere.

----------
components: Interpreter Core
files: fix_thread_nt.patch
keywords: needs review, patch
messages: 79538
nosy: ocean-city
priority: critical
severity: normal
status: open
title: os.listdir fails on debug build (windows)
versions: Python 2.7
Added file: http://bugs.python.org/file12672/fix_thread_nt.patch

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

From report at bugs.python.org  Sat Jan 10 16:45:02 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 10 Jan 2009 15:45:02 +0000
Subject: [New-bugs-announce] [issue4907] ast.literal_eval does not properly
	handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

ast.literal_eval does not properly handle complex numbers:

>>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
Traceback (most recent call last):
  ...
ValueError: malformed string
>>> ast.literal_eval("(2+1j)")
Traceback (most recent call last):
  ...
ValueError: malformed string

Expected result:

>>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
(2+1j)
>>> ast.literal_eval("(2+1j)")
(2+1j)

I attached a patch that fixes this problem.

----------
components: Library (Lib)
files: literal-eval.patch
keywords: needs review, patch, patch
messages: 79548
nosy: aronacher
priority: normal
severity: normal
stage: patch review
status: open
title: ast.literal_eval does not properly handled complex numbers
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12674/literal-eval.patch

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

From report at bugs.python.org  Sat Jan 10 18:45:06 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 10 Jan 2009 17:45:06 +0000
Subject: [New-bugs-announce] [issue4908] adding a get_metadata in distutils
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Let's add a "get_metadata" API in Distutils that would return
in a dictionary the content of the .egg-info file introduced into Python
2.5.


  >>> from distutils import get_metadata
  >>> get_metadata('ThePackage')
  {..}

(Working on a prototype)

----------
assignee: tarek
components: Distutils
messages: 79562
nosy: tarek
severity: normal
status: open
title: adding a get_metadata in distutils
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Jan 10 20:32:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 10 Jan 2009 19:32:33 +0000
Subject: [New-bugs-announce] [issue4909] incorrect renaming in imports
In-Reply-To: <1231615953.75.0.823644333839.issue4909@psf.upfronthosting.co.za>
Message-ID: <1231615953.75.0.823644333839.issue4909@psf.upfronthosting.co.za>


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

The fragment

try:
    import cStringIO as StringIO
except ImportError:
    import StringIO
s=StringIO.StringIO()

gets rewritten to

try:
    import io as StringIO
except ImportError:
    import io
s=io.StringIO()

Unfortunately, that code fails to work: the first import succeeds,
actually binding StringIO; the name io is unbound and gives NameError.

Apparently, the fixer choses to replace all occurrences of StringIO with
io; it should extend this replacement to "as" clauses.

My work-around is to import as _StringIO in both cases, and then refer
to the module as _StringIO.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 79568
nosy: loewis
severity: normal
status: open
title: incorrect renaming in imports

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

From report at bugs.python.org  Sat Jan 10 21:32:22 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Jan 2009 20:32:22 +0000
Subject: [New-bugs-announce] [issue4910] help(int.__long__) refers to
	nonexistent long function
In-Reply-To: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>
Message-ID: <1231619542.94.0.216272651809.issue4910@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In Python 3.x:

>>> int.__long__.__doc__
'x.__long__() <==> long(x)'

But the long builtin no longer exists.

I'm actually not sure why the nb_long slot still exists in 3.x at all.  
Can anyone enlighten me?

----------
messages: 79571
nosy: marketdickinson
severity: normal
status: open
title: help(int.__long__) refers to nonexistent long function
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 10 23:34:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jan 2009 22:34:45 +0000
Subject: [New-bugs-announce] [issue4912] Invalid syntax in ctypes/util.py
In-Reply-To: <1231626885.19.0.766373314699.issue4912@psf.upfronthosting.co.za>
Message-ID: <1231626885.19.0.766373314699.issue4912@psf.upfronthosting.co.za>


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

ctypes/util.py contains invalid py3k syntax at lines 106-107:

        if rv == 10:
            raise OSError, 'gcc or cc command not found'

----------
assignee: theller
components: ctypes
messages: 79582
nosy: pitrou, theller
severity: normal
status: open
title: Invalid syntax in ctypes/util.py
type: crash
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 11 03:16:43 2009
From: report at bugs.python.org (Alex Robinson)
Date: Sun, 11 Jan 2009 02:16:43 +0000
Subject: [New-bugs-announce] [issue4913] wave.py writes 16 bit sample files
	of half the correct duration
In-Reply-To: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>
Message-ID: <1231640203.22.0.836631115229.issue4913@psf.upfronthosting.co.za>


New submission from Alex Robinson <alex_python_org at tranzoa.com>:

Corrected code in writeframesraw():

            self._datawritten = self._datawritten + len(data) *
self._sampwidth
        else:
            self._file.write(data)
            self._datawritten = self._datawritten + len(data) *
self._sampwidth


Note that the default (not byte swapped) assignment to _datawritten must
also be multiplied by _sampwidth. If not, audio programs will ignore the
second half of a 16-bit-sample file.

As a side note, the calls to _patchheader() do not need to be protected
by this "if" statement:

        if self._datalength != self._datawritten:

_patchheader does the same test to optimize its operation.

----------
components: Library (Lib)
messages: 79586
nosy: alex_python_org
severity: normal
status: open
title: wave.py writes 16 bit sample files of half the correct duration
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 11 06:37:16 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 11 Jan 2009 05:37:16 +0000
Subject: [New-bugs-announce] [issue4914] trunc(x) erroneously documented as
	built-in
In-Reply-To: <1231652236.88.0.715538324364.issue4914@psf.upfronthosting.co.za>
Message-ID: <1231652236.88.0.715538324364.issue4914@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

In the Numeric Types documentation for 2.6, 3.0, and 3.1 trunc is 
documented as a built-in, like round, but while there is a trunc in math 
there is no built-in trunc. Read some of the debate on trunc from a year 
ago convinced me that this discrepancy is a documentation problem not a 
problem with the built-in functions.  Sorry if I'm completely off target 
here, but since I noticed I figured it was worth an issue.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 79590
nosy: MLModel, georg.brandl
severity: normal
status: open
title: trunc(x) erroneously documented as built-in
versions: Python 2.6, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 11 17:10:05 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Sun, 11 Jan 2009 16:10:05 +0000
Subject: [New-bugs-announce] [issue4915] Port sysmodule.c to MS Windows CE
In-Reply-To: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>
Message-ID: <1231690205.83.0.284199772738.issue4915@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

The attached patch is for sysmodule.c, it contains two changes:

1. The check whether stdin is a directory is rewritten without using
fstat(), which doesn't exist under CE.

2. Replacing sys.argv[0] with the full path is skipped, CE doesn't have
a current working dir or paths relative to it, so it must already be an
absolute path.

----------
components: Interpreter Core
files: python-2.7-wince-sysmodule.0.patch
keywords: patch
messages: 79600
nosy: eckhardt
severity: normal
status: open
title: Port sysmodule.c to MS Windows CE
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12685/python-2.7-wince-sysmodule.0.patch

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

From report at bugs.python.org  Sun Jan 11 22:53:46 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Jan 2009 21:53:46 +0000
Subject: [New-bugs-announce] [issue4916] test_io is broken on UCS4
In-Reply-To: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>
Message-ID: <1231710826.22.0.602526642764.issue4916@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

======================================================================
FAIL: testEncodedWrites (test.test_io.TextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_io.py", line 1082, in
testEncodedWrites
    self.assertEquals(f.read(), data * 2)
AssertionError:
'\U00310000\U00320000\U00330000\U00340000\U00350000\U00360000\U00370000\U00380000\U00390000\U00300000\U00310000\U00320000\U00330000\U00340000\U00350000\U00360000\U00370000\U0038000090'
!= '12345678901234567890'

======================================================================
FAIL: testNewlines (test.test_io.TextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_io.py", line 874, in testNewlines
    self.assertEquals(got_line, exp_line)
AssertionError: '\U00750000\U006e0000\U00690000\U00780000\n' != 'unix\n'

======================================================================
FAIL: test_newline_decoder (test.test_io.TextIOWrapperTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/temp/python/py3k/Lib/test/test_io.py", line 1275, in
test_newline_decoder
    self.check_newline_decoder(decoder, enc)
  File "/temp/python/py3k/Lib/test/test_io.py", line 1263, in
check_newline_decoder
    self.assertEquals(decoder.decode("abc".encode(encoding)), "abc")
AssertionError: '\U00610000\U00620000c' != 'abc'

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

----------
components: Interpreter Core
messages: 79630
nosy: benjamin.peterson
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_io is broken on UCS4
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jan 12 01:21:44 2009
From: report at bugs.python.org (O. Morvant)
Date: Mon, 12 Jan 2009 00:21:44 +0000
Subject: [New-bugs-announce] [issue4917] PyBytes_Format documented but
	doesn't exist in C/API
In-Reply-To: <1231719704.09.0.309980656756.issue4917@psf.upfronthosting.co.za>
Message-ID: <1231719704.09.0.309980656756.issue4917@psf.upfronthosting.co.za>


New submission from O. Morvant <olivier.morvant at neuf.fr>:

The C/API function PyBytes_Format(PyObject*, PyObject*) is documentated
in python 3.0 API (http://docs.python.org/3.0/c-api/bytes.html) at the
end of the Bytes Object description page. 

Examining the Python 3.0 source code, it can't be found in bytesobject.h
file or in any others files.

----------
assignee: theller
components: ctypes
messages: 79639
nosy: omorvant, theller
severity: normal
status: open
title: PyBytes_Format documented but doesn't exist in C/API
type: resource usage
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan 12 06:28:26 2009
From: report at bugs.python.org (Juha Rantanen)
Date: Mon, 12 Jan 2009 05:28:26 +0000
Subject: [New-bugs-announce] [issue4918] Windows installer created with
	Python 2.5 does not work with Python 2.6.1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>


New submission from Juha Rantanen <juha.rantanen at iki.fi>:

1. Create Windows installer with Python 2.5 from attached project.
2. Install it with Python 2.6.1.
3. The post-installer will fail with error message: 
*** run_installscript: internal error 0xFFFFFFFF ***

The code causing this is:

import socket

and the actual error is:

ImportError
DLL load failed: The specified module could not be found.
  File "<string>", line 6, in windows_binary_install
  File "c:\apps\python26\lib\socket.py", line 46, in <module>
    import _socket

If the installer is created with Python 2.6.1, it works fine. 

The problem was noticed in the Robot Framework project and the issue can
be found from http://code.google.com/p/robotframework/issues/detail?id=196.

This problem was first asked as part of issue
http://bugs.python.org/issue4566, but Martin v. L?wis recommended to
open new issue for this.

----------
components: Distutils
files: simple.zip
messages: 79647
nosy: rantanen
severity: normal
status: open
title: Windows installer created with Python 2.5  does not work with Python 2.6.1
versions: Python 2.6
Added file: http://bugs.python.org/file12694/simple.zip

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

From report at bugs.python.org  Mon Jan 12 10:14:51 2009
From: report at bugs.python.org (scott wedel)
Date: Mon, 12 Jan 2009 09:14:51 +0000
Subject: [New-bugs-announce] [issue4919] 2.6.1 build issues on solaris with
	SunStudio 12
In-Reply-To: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>
Message-ID: <1231751691.61.0.918589692105.issue4919@psf.upfronthosting.co.za>


New submission from scott wedel <taverngeek at gmail.com>:

The HUGE_VAL aka infinity issue is solved if the LIB is -lsunmath -lm
instead of just -lm

Sun Studio 12 compiler also seems to choke on the PyByteArray_GET_SIZE
and _AS_STRING because those macros use the ',' operator to stuff an
assert before the pointer lookup.  When I remove the assert portion of
those macros then they compile fine.

The assertions in those macros appear a bit silly because some places
they are used already have prior assertions and I don't see the point of
the macro which appears to be to crash due to an assertion one statement
prior to the null pointer reference causing a crash.

The configure process also appeared to make a few mistakes such as not
finding uid_t because that is in <sys/types.h> and not in the presumed
header file.  If configure were to include the standard header files AND
the file that it expects to find the definition then it would be better
at finding what is defined.  I don't know why Sun does that.

----------
components: Build
messages: 79654
nosy: taverngeek
severity: normal
status: open
title: 2.6.1 build issues on solaris with SunStudio 12
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 12 12:10:08 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:10:08 +0000
Subject: [New-bugs-announce] [issue4920] Inconsistent usage of next/__next__
	in ABC collections;
	collections.Iterator is not compatible with Python 2.6 iterators.
In-Reply-To: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>
Message-ID: <1231758608.93.0.211204811833.issue4920@psf.upfronthosting.co.za>


New submission from Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:

1. collections.MutableSet refers to __next__() slot instead of next()
buildin. 

2. collection.Iterator is not compatible with 2.6's iterators which
should have next() slot. Proposed solution: add a next() method to
collections.Iterator that falls back to __next__().

Attaching:
  1. Example code for problem 1
  2. Example code for problem 2
  3. A patch

When are you planning next bugfix release for 2.6 (I am particularly
interested in these issues :))?

----------
components: Library (Lib)
files: example1.py
messages: 79662
nosy: jrosiek
severity: normal
status: open
title: Inconsistent usage of next/__next__ in ABC collections; collections.Iterator is not compatible with Python 2.6 iterators.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12698/example1.py

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

From report at bugs.python.org  Mon Jan 12 12:19:17 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 12 Jan 2009 11:19:17 +0000
Subject: [New-bugs-announce] [issue4921] Object lifetime and inner recursive
	function
In-Reply-To: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>
Message-ID: <1231759157.93.0.0851183541991.issue4921@psf.upfronthosting.co.za>


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

Hello. Sorry if this is noise. I expected

__del__
out of function
__del__
out of function
__del__
out of function

on following code, but actually I got

out of function
out of function
out of function
__del__
__del__
__del__

Is this expected behavoir? (I believed `a' would be
freed after returned from f(), so I was suprised)

If I remove the comment of gc.collect(), the code works as expected.

///////////////////////////////

import gc

class A:
    def __del__(self):
        print("__del__")

def f():
    a = A()
    def g():
        a
        g()

def main():
    for _ in range(3):
        f()
#       gc.collect()
        print("out of function")

if __name__ == '__main__':
    main()

----------
components: Interpreter Core
messages: 79664
nosy: ocean-city
severity: normal
status: open
title: Object lifetime and inner recursive function
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jan 12 12:24:00 2009
From: report at bugs.python.org (Jaroslaw Rosiek)
Date: Mon, 12 Jan 2009 11:24:00 +0000
Subject: [New-bugs-announce] [issue4922] set.add and set.discard are not
	conformant to collections.MutableSet interface
In-Reply-To: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>
Message-ID: <1231759440.37.0.125734005136.issue4922@psf.upfronthosting.co.za>


New submission from Jaroslaw Rosiek <jaroslaw.rosiek at interia.pl>:

Methods set.add and set.discard should return boolean values according
to collections.MutableSet but they are not.

>>> print set().add(5)
None
>>> print set().discard(5)
None

----------
components: Library (Lib)
messages: 79665
nosy: jrosiek
severity: normal
status: open
title: set.add and set.discard are not conformant to collections.MutableSet interface
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 12 12:31:21 2009
From: report at bugs.python.org (Riccardo Attilio Galli)
Date: Mon, 12 Jan 2009 11:31:21 +0000
Subject: [New-bugs-announce] [issue4923] time.strftime documentation needs
	update
In-Reply-To: <1231759881.41.0.312941806858.issue4923@psf.upfronthosting.co.za>
Message-ID: <1231759881.41.0.312941806858.issue4923@psf.upfronthosting.co.za>


New submission from Riccardo Attilio Galli <riquito at gmail.com>:

there are discrepancies in the online documentation of
  strftime
in time.strftime http://docs.python.org/library/time.html
and datetime.strftime (http://docs.python.org/library/datetime.html)

In particular, seems like datetime.strftime is the one up to date,
having format codes %f and %z documented, and possibly others

----------
assignee: georg.brandl
components: Documentation
messages: 79667
nosy: georg.brandl, riquito
severity: normal
status: open
title: time.strftime documentation needs update
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 12 14:03:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Jan 2009 13:03:33 +0000
Subject: [New-bugs-announce] [issue4924] gc.collect() won't always collect
	as expected
In-Reply-To: <1231765413.97.0.063026202194.issue4924@psf.upfronthosting.co.za>
Message-ID: <1231765413.97.0.063026202194.issue4924@psf.upfronthosting.co.za>


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

I haven't verified this through any test (actually I'm wondering how to
deterministically reproduce it), but logically there are cases where
gc.collect() (and, similarly, PyGC_Collect()) won't work as advertised.

Specifically, when the GC is asked to collect a given generation but a
younger generation is already being collected, collect() will simply
notice this and return 0. However, only the younger generation will have
been collected, not the generation asked by the user.

It wouldn't take too much effort to make gc.collect() and PyGC_Collect()
truely deterministic.

----------
messages: 79673
nosy: pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: gc.collect() won't always collect as expected
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jan 12 17:26:57 2009
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 12 Jan 2009 16:26:57 +0000
Subject: [New-bugs-announce] [issue4925] Improve error message of subprocess
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>


New submission from Martin Mokrejs <mmokrejs at users.sourceforge.net>:

I think the following error output unsatisfactory as it does not give me
any hint what file was not found:

$ fetch_quals.py blah.txt 
Traceback (most recent call last):
  File "/home/mmokrejs/bin/fetch_quals.py", line 15, in <module>
    _p1 = subprocess.Popen(['query_tracedb', 'retrieve', 'quality',
_id], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
  File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
    errread, errwrite)
  File "/usr/lib/python2.5/subprocess.py", line 1091, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
$

I know now that I had to specify full path tot he binary or include
shell=True argument but anyway, please improve the error message.

----------
components: Extension Modules
messages: 79684
nosy: mmokrejs
severity: normal
status: open
title: Improve error message of subprocess
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jan 13 00:30:37 2009
From: report at bugs.python.org (David Watson)
Date: Mon, 12 Jan 2009 23:30:37 +0000
Subject: [New-bugs-announce] [issue4926] putenv() accepts names containing
	'=', return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>


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

One of these problems interacts with the other, and can cause
os.unsetenv() to free memory that's still in use.  Firstly,
calling os.putenv("FOO=BAR", "value") causes putenv(3) to be
called with the string "FOO=BAR=value", which sets a variable
called FOO, not FOO=BAR; hence, os.putenv() should not accept a
name with an "=" character in it.

The way this interacts with os.unsetenv() is that the string
(FOO=BAR=value) is stored in the internal dictionary object
posix_putenv_garbage under the key "FOO=BAR".  The reference in
this dict is supposed to prevent the bytes object (str in 3.x on
Windows) that contains the string from being garbage collected
and freed until unsetenv() is called, since putenv(3) makes the
char **environ array point to the actual string, not a copy.

The problem with os.unsetenv() is that it does not check the
return value from unsetenv(3) at all and will unconditionally
remove the corresponding string from posix_putenv_garbage.
Following the example above, when os.unsetenv("FOO=BAR") is
called, unsetenv(3) will fail because the name contains an "="
character, but the object containing the string will be garbage
collected even though char **environ still has a pointer to it.

This is a bit tricky to give a visible demonstration of, but the
attached visibility.diff adds posix_putenv_garbage to the module
namespace and prints the return value from unsetenv() so you can
see what's going on.

The other two attached diffs fix the problems (for 2.x and 3.x
separately) by making os.unsetenv() raise OSError on failure in
the usual way, and os.putenv() raise ValueError when its first
argument contains "=".  They also add test cases and docs.  In
the patch for 3.x, some of the relevant code differs between Unix
and Windows; I changed both but I've only tested the Unix
version.

----------
components: Extension Modules
files: visibility.diff
keywords: patch
messages: 79708
nosy: baikie
severity: normal
status: open
title: putenv() accepts names containing '=', return value of unsetenv() not checked
type: behavior
Added file: http://bugs.python.org/file12708/visibility.diff

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

From report at bugs.python.org  Tue Jan 13 10:21:37 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 09:21:37 +0000
Subject: [New-bugs-announce] [issue4927] Inconsistent unicode repr for
	fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The repr for fileobjects is inconsistent.  On windows:
f = file("tmp\\foo", "wb")
f
<open file 'tmp\foo', mode 'wb' at ...>
f = file(u"tmp\\foo", "wb")
f
<open file u'tmp\\foo', mode 'wb' at ...>

For unicode, the filename is a proper "repr", but for a string it is 
just the plain string, enclosed in single quotes.  Note that I consider 
the string case in error.  Like the repr of a list or tuple, it should 
be a string containin the repr of its components.

This leads to problems in the testsuite on vista.

I propose to change this with the patch provided, which always displays 
the repr of the filename.  It may have side effects in the testsuite, I 
will add a separate file for that.

----------
components: Interpreter Core
files: fileobject.patch
keywords: needs review, patch, patch
messages: 79726
nosy: krisvale
severity: normal
stage: patch review
status: open
title: Inconsistent unicode repr for fileobject
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12713/fileobject.patch

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

From report at bugs.python.org  Tue Jan 13 10:22:46 2009
From: report at bugs.python.org (Richard Philips)
Date: Tue, 13 Jan 2009 09:22:46 +0000
Subject: [New-bugs-announce] [issue4928] Problem with
	tempfile.NamedTemporaryFile on Solaris 10
In-Reply-To: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>
Message-ID: <1231838566.25.0.143957228078.issue4928@psf.upfronthosting.co.za>


New submission from Richard Philips <rphilips at users.sourceforge.net>:

On Solaris 10 (Solaris 10 5/08 s10x_u5wos_10 X86),
with python 2.5 (Python 2.5.2 (r252:60911, Sep  8 2008, 16:53:36) [C] on
sunos5),

tempfile.NamedTemporaryFile creates - as advertised - a temporary file.

After closing this file object (e.g. by exiting the python process), the
temporary file is indeed removed.

But if you just kill the python process, the temporary file is not
destroyed.

This behavior is different on Red Hat Linux and MS Vista, on these OSes
the temporary file is removed.

A snapshot to illustrate the behavior:

[moto /]# python
Python 2.5.2 (r252:60911, Sep  8 2008, 16:53:36) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, tempfile
>>> f = tempfile.NamedTemporaryFile()
>>> f.name
'/tmp/tmpfHraUd'
>>> os.getpid()
4403
>>> x = "With root priveleges, I execute: 'kill 4403'"
>>>
>>> Terminated
[moto /]#

----------
components: Library (Lib)
messages: 79727
nosy: rphilips
severity: normal
status: open
title: Problem with tempfile.NamedTemporaryFile on Solaris 10
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jan 13 12:31:17 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 13 Jan 2009 11:31:17 +0000
Subject: [New-bugs-announce] [issue4929] smptlib.py can raise socket.error
In-Reply-To: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>
Message-ID: <1231846277.69.0.939046025781.issue4929@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

the SMPT.getreply() method doesn't check for socket.error when doing its 
readline() call.  We now check for connection reset and others that can 
occur here and properly close.  This is to comply with the documentation 
that doesn't specify socket.error as part of the exceptions raised.

----------
components: Library (Lib)
files: smtplib.patch
keywords: needs review, patch, patch
messages: 79732
nosy: krisvale
severity: normal
stage: patch review
status: open
title: smptlib.py can raise socket.error
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file12716/smtplib.patch

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

From report at bugs.python.org  Tue Jan 13 14:48:47 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 13 Jan 2009 13:48:47 +0000
Subject: [New-bugs-announce] [issue4930] Small optimization in type
	construction
In-Reply-To: <1231854527.51.0.654505109034.issue4930@psf.upfronthosting.co.za>
Message-ID: <1231854527.51.0.654505109034.issue4930@psf.upfronthosting.co.za>


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

Replace a strcmp call by a direct slot address comparison.

This follows Neil's remark in 
http://mail.python.org/pipermail/python-checkins/2009-January/077156.html

----------
assignee: amaury.forgeotdarc
files: slotcomparison.patch
keywords: patch
messages: 79742
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: Small optimization in type construction
Added file: http://bugs.python.org/file12717/slotcomparison.patch

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

From report at bugs.python.org  Tue Jan 13 18:31:05 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 13 Jan 2009 17:31:05 +0000
Subject: [New-bugs-announce] [issue4931] distutils does not show any error
	msg when can't build C module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>


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

Today I was trying to compile a module using an extension in C and
noticed there are differences between compiling it on Python 2.5 and 2.6.
I was trying to compile psutil (svn checkout
http://psutil.googlecode.com/svn/trunk/ psutil) but I think that the
problem may occur with any other package using C extensions.

Python 2.5:

D:\pyftpdlib\svn\psutil\trunk>C:\python25\python.exe setup.py install
running install
running build
running build_ext
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin
installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.



Python 2.6:

D:\pyftpdlib\svn\psutil\trunk>C:\python26\python.exe setup.py install
running install
running build
running build_ext
building 'psutil/_psutil_mswindows' extension
error: None

----------
components: Distutils
messages: 79751
nosy: giampaolo.rodola
severity: normal
status: open
title: distutils does not show any error msg when can't build C module extensions due to a missing C compiler
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jan 13 18:32:35 2009
From: report at bugs.python.org (Andres Moreira)
Date: Tue, 13 Jan 2009 17:32:35 +0000
Subject: [New-bugs-announce] [issue4932] Little improvement on urlparse
	module, urlparse function.
In-Reply-To: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>
Message-ID: <1231867955.83.0.32658151911.issue4932@psf.upfronthosting.co.za>


New submission from Andres Moreira <elkpichico at gmail.com>:

Hi, 
 I make a little change in the urlsplit function of urlparse module. And
the performance when I'm parsing a lot of urls was improved a bit.
In the best case was improved around a 20% percent.

Python version:
2.5.2 (r252:60911, Oct  5 2008, 19:29:17) 
[GCC 4.3.2]

Here are the benchmarks:
#:~/tests$ python profile_urlparse.py 
timing urlparse.urlparse():
    [0.28006601333618164, 0.27513313293457031, 0.20408511161804199]
timing myurlparse.urlparse():
    [0.11000704765319824, 0.10729002952575684, 0.10677695274353027]
#:~/tests$ python profile_urlparse2.py 
timing urlparse.urlparse():
    [0.28334403038024902, 0.27912592887878418, 0.15959692001342773]
timing myurlparse.urlparse():
    [0.11277103424072266, 0.11163187026977539, 0.11175107955932617]
#:~/tests$ python profile_urlparse2.py 
timing urlparse.urlparse():
    [0.28750920295715332, 0.2779538631439209, 0.27816200256347656]
timing myurlparse.urlparse():
    [0.25010085105895996, 0.11236691474914551, 0.11198592185974121]


#-- Paste here the profiling code -----------
#-- Please rename the file as : profile_urlparse.py

urls = [
   
"http://www.notonthehighstreet.com/boxwood/product/dotty_picture_frames",
    "http://www.fancylighting.com/acatalog/Petrushka_Bronze.html",
   
"http://cgi.ebay.co.uk/3-LITRE-SUNNEX-STAINLESS-STEEL-TEAPOT-COFFEE-POT_W0QQitemZ160230173283QQcategoryZ122942QQcmdZViewItem",
   
"http://retail.ictc.co.uk/acatalog/Online_Catalogue__Homegrown_184.html",
   
"http://www.amazon.co.uk/Big-Mog-Tape-Judith-Kerr/dp/0001025252?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=0001025252",
   
"http://www.dinerstore.co.uk/acatalog/copy_of_Bedford_Oak_Table_and_Six.html",
   
"http://www.panik-design.co.uk/acatalog/Iittala_-_A_Citterio_-_Citterio_98_Cutlery_24pcs_.html",
    "http://www.johnlewis.com/230544027/Product.aspx",
   
"http://cgi.ebay.co.uk/Damask-Black-Pink-Cream-Large-Modern-Rugs-120x170cm_W0QQitemZ400021540458QQcategoryZ57237QQcmdZViewItem",
   
"http://www.amazon.co.uk/Nikon-50Mm-F1-2-Nikkor-Lens/dp/B00009R95Y?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B00009R95Y",
   
"http://www.amazon.co.uk/Storeys-Guide-Raising-Llamas-Birutta/dp/1580173284?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=1580173284",
    "http://www.24electric.com/detail.php?ProdID=46519663",
   
"http://cgi.ebay.co.uk/Antique-Pine-Midi-Sleeper-Childrens-Bed-VGC_W0QQitemZ280285887713QQcategoryZ122763QQcmdZViewItem",
    "http://www.johnlewis.com/230421907/Product.aspx",
   
"http://cgi.ebay.co.uk/WICKER-PLACE-DINNER-MATS-X6-IN-A-WICKER-BASKET-WITH-LID_W0QQitemZ350141392941QQcategoryZ20660QQcmdZViewItem",
   
"http://www.trueshopping.co.uk/product/Draper_1_4_Square_Drive_Reversible_Ratchet/3495/43235.html",
   
"http://www.amazon.co.uk/Transcend-TS128MIB6986-128MB-Module/dp/B000HCO61K?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B000HCO61K",
   
"http://www.unitedinteriors.co.uk/regency-pine-hi-fi-cabinet-4741-p.asp",
   
"http://www.amazon.co.uk/BATTERY-CAMCORDER-DCR-DVD602-DCR-DVD602E-DCRDVD602/dp/B0017UM1OU?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B0017UM1OU",
    "http://www.tooled-up.com/Product.asp?PID=145138",
   
"http://www.dinerstore.co.uk/acatalog/copy_of_Bedford_Oak_Table_and_Six.html",
   
"http://www.panik-design.co.uk/acatalog/Iittala_-_A_Citterio_-_Citterio_98_Cutlery_24pcs_.html",
    "http://www.johnlewis.com/230544027/Product.aspx",
   
"http://cgi.ebay.co.uk/Damask-Black-Pink-Cream-Large-Modern-Rugs-120x170cm_W0QQitemZ400021540458QQcategoryZ57237QQcmdZViewItem",
   
"http://www.amazon.co.uk/Nikon-50Mm-F1-2-Nikkor-Lens/dp/B00009R95Y?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B00009R95Y",
   
"http://www.amazon.co.uk/Storeys-Guide-Raising-Llamas-Birutta/dp/1580173284?SubscriptionId=0QE3E4F7T4Q5DCSKG202&tag=ws&linkCode=xm2&camp=2025&creative=165953&creativeASIN=1580173284",
    "http://www.24electric.com/detail.php?ProdID=46519663",
   
"http://cgi.ebay.co.uk/Antique-Pine-Midi-Sleeper-Childrens-Bed-VGC_W0QQitemZ280285887713QQcategoryZ122763QQcmdZViewItem",
    "http://www.johnlewis.com/230421907/Product.aspx",
   
"http://cgi.ebay.co.uk/WICKER-PLACE-DINNER-MATS-X6-IN-A-WICKER-BASKET-WITH-LID_W0QQitemZ350141392941QQcategoryZ20660QQcmdZViewItem",
   
"http://www.trueshopping.co.uk/product/Draper_1_4_Square_Drive_Reversible_Ratchet/3495/43235.html",
]

if __name__ == '__main__':
    import sys
    import timeit

    if len(sys.argv) > 1:
        times = int(sys.argv[1])
    else:
        times = 1000

    t = timeit.Timer("[urlparse.urlparse(u) for u in urls]", 
                     "from profile_urlparse import urls; import urlparse")
    print "timing urlparse.urlparse():"
    print "   ", t.repeat(3, times)


    t = timeit.Timer("[myurlparse.urlparse(u) for u in urls]", 
                     "from profile_urlparse import urls; import myurlparse")
    print "timing myurlparse.urlparse():"
    print "   ", t.repeat(3, times)

#--- End of profile code ----------------------------------------

----------
components: Library (Lib)
files: urlparse.py
messages: 79752
nosy: andrix
severity: normal
status: open
title: Little improvement on urlparse module, urlparse function.
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file12720/urlparse.py

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

From report at bugs.python.org  Tue Jan 13 18:34:37 2009
From: report at bugs.python.org (Scott McCreary)
Date: Tue, 13 Jan 2009 17:34:37 +0000
Subject: [New-bugs-announce] [issue4933] Patch to add preliminary support
	for Haiku
In-Reply-To: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>
Message-ID: <1231868077.01.0.788038628741.issue4933@psf.upfronthosting.co.za>


New submission from Scott McCreary <scottmc2 at gmail.com>:

This patch adds preliminary support for Haiku.  We still have to hand
tweak a few other files to get things to build.  We have further patches
to get python-2.5.4 to build, but it's failing some of the regression
tests so we're leaving those parts out of this submitted patch.
For more details on the progress of the Haiku port check here:
http://ports.haiku-files.org/wiki/dev-lang/python/2.5.4

----------
components: Build
files: python-2.5.4-haiku-2.diff
keywords: patch
messages: 79753
nosy: scottmc
severity: normal
status: open
title: Patch to add preliminary support for Haiku
versions: Python 2.5
Added file: http://bugs.python.org/file12721/python-2.5.4-haiku-2.diff

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

From report at bugs.python.org  Tue Jan 13 18:54:45 2009
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 13 Jan 2009 17:54:45 +0000
Subject: [New-bugs-announce] [issue4934] tp_del and tp_version_tag
	undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The PyTypeObject field "tp_version_tag" (new in 2.6) isn't documented.

"tp_del" isn't documented either.  I'm not sure when it was added.

----------
assignee: georg.brandl
components: Documentation
messages: 79755
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: tp_del and tp_version_tag undocumented
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From martin at v.loewis.de  Tue Jan 13 19:38:26 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 13 Jan 2009 19:38:26 +0100
Subject: [New-bugs-announce] [issue4927] Inconsistent unicode repr for
 fileobject
In-Reply-To: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
References: <1231838497.34.0.90195679535.issue4927@psf.upfronthosting.co.za>
Message-ID: <496CDFA2.6070607@v.loewis.de>

> This leads to problems in the testsuite on vista.

To which problem specifically?

From report at bugs.python.org  Tue Jan 13 19:50:39 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 18:50:39 +0000
Subject: [New-bugs-announce] [issue4935] Segmentation fault in bytearray
	tests
In-Reply-To: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>
Message-ID: <1231872639.69.0.60940480528.issue4935@psf.upfronthosting.co.za>


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

This happens on a 32-bit build on a 64-bit system, which happens to have
some interesting properties: for example, malloc() will happily allocate
memory larger than Py_SSIZE_T_MAX.

The crash is exactly triggered by the following snippet:

        if sys.maxsize < (1 << 32) and struct.calcsize('P') == 4:
            self.assertRaises(OverflowError,
                              self.marshal(b'\ta\n\tb').expandtabs,
sys.maxsize)

----------
components: Interpreter Core
messages: 79766
nosy: pitrou
priority: critical
severity: normal
status: open
title: Segmentation fault in bytearray tests
type: crash

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

From report at bugs.python.org  Tue Jan 13 19:59:25 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 18:59:25 +0000
Subject: [New-bugs-announce] [issue4936] bytearrayobject.o does not depend
	on stringlib files
In-Reply-To: <1231873165.21.0.228432008628.issue4936@psf.upfronthosting.co.za>
Message-ID: <1231873165.21.0.228432008628.issue4936@psf.upfronthosting.co.za>


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

Modifying one of the stringlib files does not trigger recompiling of
Objects/bytearray.c, although the latter includes the former.

----------
components: Build
messages: 79770
nosy: pitrou
priority: normal
severity: normal
status: open
title: bytearrayobject.o does not depend on stringlib files
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jan 13 22:02:31 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Tue, 13 Jan 2009 21:02:31 +0000
Subject: [New-bugs-announce] [issue4937] Mac DMG install missing
	version.plist required by bundlebuilder.py
In-Reply-To: <1231880551.46.0.128485851272.issue4937@psf.upfronthosting.co.za>
Message-ID: <1231880551.46.0.128485851272.issue4937@psf.upfronthosting.co.za>


New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:

I installed mac python 2.6.1 on Mac OS X 10.5.6

I then ran my pysvn workbench kitting script that uses
bundlebuilder.py. It fails because version.plist is not installed.

Traceback (most recent call last):
  File "make_wb_bundle.py", line 91, in <module>
    myapp.build()
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/bundlebuilder.py",
line 163, in build
    self._copyFiles()
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/bundlebuilder.py",
line 218, in _copyFiles
    copy(src, dst, mkdirs=1)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/bundlebuilder.py",
line 758, in copy
    shutil.copy2(src, dst)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shutil.py",
line 99, in copy2
    copyfile(src, dst)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shutil.py",
line 52, in copyfile
    fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'/Library/Frameworks/Python.framework/Versions/2.6/Resources/version.plist'

----------
components: Installation
messages: 79774
nosy: barry-scott
severity: normal
status: open
title: Mac DMG install missing version.plist required by bundlebuilder.py
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 13 23:55:44 2009
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Jan 2009 22:55:44 +0000
Subject: [New-bugs-announce] [issue4938] Pdb cannot access doctest source in
	postmortem
In-Reply-To: <1231887344.64.0.130142534031.issue4938@psf.upfronthosting.co.za>
Message-ID: <1231887344.64.0.130142534031.issue4938@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With attached x.py:

$ cat x.py
"""
>>> foo()
"""
def foo():
    1/0

if __name__ == '__main__':
    import doctest, pdb
    try:
        doctest.testmod(raise_on_error=True)
    except doctest.UnexpectedException, e:
        pdb.post_mortem(e.exc_info[2])

$ ./python.exe x.py
> /Users/sasha/Work/python-svn/trunk/x.py(5)foo()
-> 1/0
(Pdb) up
> <doctest __main__[0]>(1)<module>()
(Pdb) l
[EOF]


Apparently the problem is that the default getlines gets restored in the  
"finally:" section in DocTestRunner.run() before post_mortem is invoked.

The only solution that comes to mind is to patch pdb.post_mortem 
similarly to the way pdb.set_trace is patched but not restore it until 
the end of testmod().

Am I missing a simpler solution?

----------
files: x.py
messages: 79787
nosy: belopolsky
severity: normal
status: open
title: Pdb cannot access doctest source in postmortem
Added file: http://bugs.python.org/file12727/x.py

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

From report at bugs.python.org  Wed Jan 14 00:22:37 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jan 2009 23:22:37 +0000
Subject: [New-bugs-announce] [issue4939] Failures in test_xmlrpc
In-Reply-To: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>
Message-ID: <1231888957.19.0.179306748689.issue4939@psf.upfronthosting.co.za>


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

This is witnessed on trunk, at home as well as on the buildbots:

======================================================================
ERROR: test_dotted_attribute (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
492, in test_dotted_attribute
    self.test_simple1()
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
376, in test_simple1
    self.assertEqual(p.pow(6,8), 6**8)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection1 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
398, in test_introspection1
    meth = p.system.listMethods()
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection2 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
413, in test_introspection2
    divhelp = p.system.methodHelp('div')
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection3 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
425, in test_introspection3
    myfunction = p.system.methodHelp('my_function')
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_introspection4 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
438, in test_introspection4
    divsig = p.system.methodSignature('div')
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_multicall (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
453, in test_multicall
    add_result, pow_result, div_result = multicall()
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1042, in
__call__
    return
MultiCallIterator(self.__server.system.multicall(marshalled_list))
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_non_existing_multicall (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
468, in test_non_existing_multicall
    result = multicall()
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1042, in
__call__
    return
MultiCallIterator(self.__server.system.multicall(marshalled_list))
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_simple1 (test.test_xmlrpc.SimpleServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
376, in test_simple1
    self.assertEqual(p.pow(6,8), 6**8)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

======================================================================
ERROR: test_basic (test.test_xmlrpc.FailingServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_xmlrpc.py", line
534, in test_basic
    self.assertEqual(p.pow(6,8), 6**8)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1199, in
__call__
    return self.__send(self.__name, args)
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1465, in
__request
    verbose=self.__verbose
  File "/home/antoine/cpython/__svn__/Lib/xmlrpclib.py", line 1248, in
request
    return self._parse_response(h.getfile())
AttributeError: Transport instance has no attribute '_parse_response'

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

----------
components: Library (Lib)
messages: 79792
nosy: pitrou
priority: critical
severity: normal
status: open
title: Failures in test_xmlrpc
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 14 01:29:57 2009
From: report at bugs.python.org (rech)
Date: Wed, 14 Jan 2009 00:29:57 +0000
Subject: [New-bugs-announce] [issue4940] decimal.Decimal.__init__ should
	raise an instance of ValueError
In-Reply-To: <1231892997.26.0.818737849163.issue4940@psf.upfronthosting.co.za>
Message-ID: <1231892997.26.0.818737849163.issue4940@psf.upfronthosting.co.za>


New submission from rech <r.rechkemmer at web.de>:

A common pattern is to check numeric input like this:

a = input()
try:
   int(a) # or float(a)
except ValueError:
   print("Bad input")

One would expect this to work with decimal.Decimal(a), too. But, as
Decimal.__init__ raises decimal.InvalidOperation instead of a
ValueError, it fails.

Making Decimal.__init__ raise a ValueError in this context would be an
incompatible change. Also, making decimal.InvalidOperation a subclass of
ValueError might not be correct.
It would be best to create a new an more specific exception for this
case, a subclass of both decimal.InvalidOperation and ValueError. This
would keep all functionality and enable this kind of intuitive use.

----------
components: Library (Lib)
messages: 79814
nosy: lemburg, rech
severity: normal
status: open
title: decimal.Decimal.__init__ should raise an instance of ValueError
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Jan 14 03:10:30 2009
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 14 Jan 2009 02:10:30 +0000
Subject: [New-bugs-announce] [issue4941] Tell GCC Py_DECREF is unlikely to
	call the destructor
In-Reply-To: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>
Message-ID: <1231899030.81.0.577768364365.issue4941@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

As suggested by Paolo Giarrusso, add a "likely()" to Py_DECREF, telling
GCC it doesn't call the destructor in the common path.

This optimization seems to interact well with #4896 and to be slower on
top of #4753 on my system. Patching ceval.c instead of object.h seems to
give the same result, FWIW. Benchmarks most welcome :)

Paolo Giarrusso wrote:
"Anyway, yesterday I was looking at the assembly and I realized that
GCC optimizes the case where Py_DECREF calls the destructor! Since I
don't have time for this, can you hint GCC for the better by adding
unlikely() to Py_DECREF, at least (or maybe only) for ceval.c, or
maybe even only for the main interpreter?"

pybench:
    Rounds: 10
    Warp:   10
    Timer:  time.time

    Machine Details:
       Platform ID:    Linux-2.6.24-23-generic-i686-with-debian-lenny-sid
       Processor:      Intel Celeron M 410

    Python:
       Implementation: CPython
       Executable:     /home/ajaksu/py3k/python
       Version:        3.1.0
       Compiler:       GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
       Bits:           32bit
       Build:          Jan 13 2009 23:40:05 (#py3k:68571M)
       Unicode:        UCS2


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other 
 diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:   147ms   163ms   -9.7%   148ms   164ms
 -10.0%
           BuiltinMethodLookup:   138ms   154ms  -10.3%   139ms   155ms
 -10.6%
                 CompareFloats:   185ms   191ms   -3.4%   185ms   192ms
  -3.4%
         CompareFloatsIntegers:   304ms   294ms   +3.1%   304ms   296ms
  +2.7%
               CompareIntegers:   287ms   281ms   +2.0%   288ms   281ms
  +2.3%
        CompareInternedStrings:   189ms   217ms  -12.7%   192ms   217ms
 -11.7%
                  CompareLongs:   167ms   162ms   +3.3%   168ms   162ms
  +3.3%
                CompareStrings:   152ms   178ms  -14.2%   156ms   179ms
 -12.7%
    ComplexPythonFunctionCalls:   192ms   202ms   -5.1%   193ms   206ms
  -6.2%
                 ConcatStrings:   325ms   327ms   -0.7%   326ms   330ms
  -1.1%
               CreateInstances:   200ms   209ms   -4.4%   204ms   210ms
  -2.9%
            CreateNewInstances:   149ms   156ms   -4.4%   151ms   161ms
  -5.8%
       CreateStringsWithConcat:   255ms   272ms   -6.1%   258ms   275ms
  -6.3%
                  DictCreation:   145ms   151ms   -4.0%   146ms   154ms
  -5.3%
             DictWithFloatKeys:   209ms   224ms   -6.8%   209ms   224ms
  -6.7%
           DictWithIntegerKeys:   170ms   185ms   -8.0%   171ms   187ms
  -8.3%
            DictWithStringKeys:   155ms   172ms  -10.1%   156ms   173ms
 -10.2%
                      ForLoops:   162ms   183ms  -11.7%   162ms   183ms
 -11.4%
                    IfThenElse:   189ms   217ms  -12.7%   190ms   219ms
 -13.1%
                   ListSlicing:   156ms   156ms   -0.3%   156ms   158ms
  -1.0%
                NestedForLoops:   199ms   219ms   -9.1%   201ms   220ms
  -8.6%
      NestedListComprehensions:   222ms   245ms   -9.5%   228ms   251ms
  -9.2%
          NormalClassAttribute:   352ms   376ms   -6.2%   353ms   378ms
  -6.6%
       NormalInstanceAttribute:   188ms   212ms  -11.1%   191ms   215ms
 -11.3%
           PythonFunctionCalls:   173ms   192ms   -9.6%   174ms   193ms
  -9.7%
             PythonMethodCalls:   213ms   226ms   -5.6%   214ms   227ms
  -5.8%
                     Recursion:   275ms   295ms   -7.0%   276ms   296ms
  -7.0%
                  SecondImport:   158ms   158ms   +0.2%   160ms   160ms
  +0.1%
           SecondPackageImport:   164ms   168ms   -2.2%   166ms   170ms
  -2.8%
         SecondSubmoduleImport:   221ms   226ms   -2.4%   223ms   229ms
  -2.9%
       SimpleComplexArithmetic:   143ms   166ms  -13.5%   144ms   166ms
 -13.4%
        SimpleDictManipulation:   269ms   296ms   -9.2%   270ms   297ms
  -9.0%
         SimpleFloatArithmetic:   150ms   177ms  -15.3%   151ms   196ms
 -23.2%
      SimpleIntFloatArithmetic:   200ms   226ms  -11.4%   203ms   232ms
 -12.4%
       SimpleIntegerArithmetic:   200ms   226ms  -11.4%   202ms   235ms
 -13.9%
      SimpleListComprehensions:   186ms   211ms  -12.0%   193ms   218ms
 -11.5%
        SimpleListManipulation:   161ms   180ms  -10.6%   161ms   181ms
 -10.9%
          SimpleLongArithmetic:   137ms   159ms  -14.0%   137ms   162ms
 -15.2%
                    SmallLists:   197ms   209ms   -5.6%   201ms   210ms
  -4.2%
                   SmallTuples:   215ms   234ms   -8.2%   216ms   236ms
  -8.2%
         SpecialClassAttribute:   544ms   566ms   -4.0%   549ms   571ms
  -3.7%
      SpecialInstanceAttribute:   188ms   211ms  -11.0%   190ms   214ms
 -11.0%
                StringMappings:   432ms   439ms   -1.6%   433ms   441ms
  -1.9%
              StringPredicates:   183ms   198ms   -7.8%   183ms   199ms
  -7.9%
                 StringSlicing:   304ms   317ms   -4.2%   310ms   321ms
  -3.3%
                     TryExcept:   138ms   154ms  -10.5%   139ms   155ms
 -10.4%
                    TryFinally:   149ms   156ms   -4.8%   151ms   159ms
  -5.1%
                TryRaiseExcept:    76ms    78ms   -2.3%    77ms    82ms
  -6.3%
                  TupleSlicing:   254ms   254ms   -0.2%   254ms   257ms
  -1.0%
                   WithFinally:   204ms   207ms   -1.1%   206ms   209ms
  -1.1%
               WithRaiseExcept:   187ms   190ms   -2.0%   188ms   192ms
  -2.2%
-------------------------------------------------------------------------------
Totals:                         10557ms 11266ms   -6.3% 10647ms 11397ms
  -6.6%

(this=likely_object.pybench, other=classic_opcode.pybench)

----------
components: Interpreter Core
files: likely_decref.diff
keywords: patch
messages: 79821
nosy: ajaksu2, blaisorblade, pitrou
severity: normal
status: open
title: Tell GCC Py_DECREF is unlikely to call the destructor
type: performance
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12731/likely_decref.diff

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

From report at bugs.python.org  Wed Jan 14 04:48:25 2009
From: report at bugs.python.org (Hamish Moffatt)
Date: Wed, 14 Jan 2009 03:48:25 +0000
Subject: [New-bugs-announce] [issue4942] accept() on AF_UNIX sockets broken
	on arm as of 2.5.3
In-Reply-To: <1231904905.99.0.375318145536.issue4942@psf.upfronthosting.co.za>
Message-ID: <1231904905.99.0.375318145536.issue4942@psf.upfronthosting.co.za>


New submission from Hamish Moffatt <hamish at cloud.net.au>:

As of 2.5.3, calling accept() on an AF_UNIX socket fails on arm. The
following exception occurs:

SystemError: Negative size passed to PyString_FromStringAndSize

I have attached a test program that creates a socket and connects to it.
It works on x86-64 but fails on armeb (gcc 4.1.2).

This failure has been noted a few times by the arm buildbot too:
http://archives.free.net.ph/message/20081012.121034.89069ea2.en.html

It's already fixed in 2.6.x in rev 60214. I applied the same change to
2.5.4 and the problem was resolved.

----------
components: Extension Modules
files: accept_test.py
messages: 79825
nosy: hmoffatt
severity: normal
status: open
title: accept() on AF_UNIX sockets broken on arm as of 2.5.3
versions: Python 2.5
Added file: http://bugs.python.org/file12733/accept_test.py

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

From report at bugs.python.org  Wed Jan 14 05:16:06 2009
From: report at bugs.python.org (Matt McClure)
Date: Wed, 14 Jan 2009 04:16:06 +0000
Subject: [New-bugs-announce] [issue4943] trace.CoverageResults.write_results
	can't write results file for modules loaded by __path__ manipulation
In-Reply-To: <1231906566.94.0.987113502153.issue4943@psf.upfronthosting.co.za>
Message-ID: <1231906566.94.0.987113502153.issue4943@psf.upfronthosting.co.za>


New submission from Matt McClure <mlm at aya.yale.edu>:

The function trace.CoverageResults.write_results() can't write coverage
results on Windows for modules loaded by using the __path__ feature of
PEP 302.

For example, Bazaar uses the __path__ feature to load plugins from
directories specified by the BZR_PLUGIN_PATH environment variable.

The attached zip file contains a test case.  If it is unpacked so that
tracebug.py is in C:\, it will fail to produce a coverage results file
for C:\tracebug\dir2\hello.py.  Instead it will produce an empty file
named C:\tracebug\out\C .

The bug appears to be that trace.fullmodname() returns
C:.tracebug.dir2.hello .  Since the result contains a colon (:), it
can't be used as the filename of the output file produced by
trace.CoverageResults.write_results().

----------
components: Library (Lib)
files: tracebug.zip
messages: 79826
nosy: matthewlmcclure
severity: normal
status: open
title: trace.CoverageResults.write_results can't write results file for modules loaded by __path__ manipulation
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12734/tracebug.zip

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

From report at bugs.python.org  Wed Jan 14 05:42:59 2009
From: report at bugs.python.org (Javen Wang)
Date: Wed, 14 Jan 2009 04:42:59 +0000
Subject: [New-bugs-announce] [issue4944] os.fsync() doesn't work as expect
	in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>


New submission from Javen Wang <javen72 at gmail.com>:

I encountered a very strange issue in file flush operation in Windows.
Here's the scenario of my application:

    1. The main thread of my application will create makefiles sequentially.
    2. Once a makefile is generated, launch a separate process calling
nmake.exe to run it in parallell. The main thread then create another
makefile until no more makefiles to create.
    3. The number of new processes is limited by command line options.

My application has been running for almost a year without any problem.
But, after I made some changes recently to the content of makefile
generated, "nmake.exe" in separate process sometimes complains that
the makefile was not found. But when I went into the directory, the
makefile was there.

Because I didn't change any thing related to file creation and the new
makefiles are a little bit less than before, I guessed that the
makefile just created hasn't been flushed to disk because of size
change so the new process could not see it in a short time.

So I decided add code to force flush file buffer after writing the
file content (I didn't flush the file explicitly before). I did it
like below:

    Fd = open(File, "w")
    Fd.write(Content)
    Fd.flush()
    os.fsync(Fd.fileno())
    Fd.close()

The strangest thing happened. The "makefile" missing happened more
frequently than no flush operation. I searched the web but no answer
there.

Finally I tried to use Windows file API to create the file via pywin32
extension. The problem's gone.

        import win32file
        Fd = win32file.CreateFile(
                        File,
                        win32file.GENERIC_WRITE,
                        0,
                        None,
                        win32file.CREATE_ALWAYS,
                        win32file.FILE_ATTRIBUTE_NORMAL,
                        None
                        )
        win32file.WriteFile(Fd, str(Content), None)
        win32file.FlushFileBuffers(Fd)
        win32file.CloseHandle(Fd)

I tried writing small python extension in C to make use Windows API to
create file like above. It also works well, even I removed the
FlushFileBuffers() calling.

I think that there's a bug in Python file buffer mechanism.

----------
components: Windows
messages: 79829
nosy: javen72
severity: normal
status: open
title: os.fsync() doesn't work as expect in Windows
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Jan 14 06:31:38 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 14 Jan 2009 05:31:38 +0000
Subject: [New-bugs-announce] [issue4945] json checks True/False by identity,
	not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

json compares arguments against True/False by identity, not by boolean 
value; by example:

    if (skipkeys is False and ensure_ascii is True and
        check_circular is True and allow_nan is True ...

Using `ensure_ascii=1` won't work as intended. I don't see the reason 
to check those values by identity - they *are* boolean flags, and 
should be checked by value, as the usual practice.

The attached patch fixes the code and documentation (and a bug encoding 
True/False as keys, including unit tests)

----------
components: Library (Lib)
messages: 79832
nosy: gagenellina
severity: normal
status: open
title: json checks True/False by identity, not boolean value
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Jan 14 11:54:26 2009
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Wed, 14 Jan 2009 10:54:26 +0000
Subject: [New-bugs-announce] [issue4946] Lib/test/test__locale uses is to
	compare strings
In-Reply-To: <1231930466.83.0.500418142072.issue4946@psf.upfronthosting.co.za>
Message-ID: <1231930466.83.0.500418142072.issue4946@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

this is at least a bad practice. It also might break silently at any point.

----------
components: Library (Lib), Tests
files: out.diff
keywords: patch
messages: 79846
nosy: fijal
severity: normal
status: open
title: Lib/test/test__locale uses is to compare strings
versions: Python 2.7
Added file: http://bugs.python.org/file12740/out.diff

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

From report at bugs.python.org  Wed Jan 14 12:18:48 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 14 Jan 2009 11:18:48 +0000
Subject: [New-bugs-announce] [issue4947] sys.stdout fails to use default
	encoding as advertised
In-Reply-To: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>
Message-ID: <1231931928.79.0.528374921948.issue4947@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

Documentation for files states that when writing to a file, unicode 
strings are converted to byte strings using the encoding specified by 
file.encoding.
http://docs.python.org/library/stdtypes.html#file.encoding

sys.stdout is a file, but it does not behave as stated above:

>>> type(sys.stdout)
<type 'file'>
>>> sys.stdout.encoding
'UTF-8'
>>> u = u"\u554a"
>>> print u
?
>>> sys.stdout.write(u)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u554a' in 
position 0: ordinal not in range(128)
>>> sys.stdout.write(u.encode('utf-8'))
?

----------
messages: 79849
nosy: stevenjd
severity: normal
status: open
title: sys.stdout fails to use default encoding as advertised
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Jan 14 17:40:28 2009
From: report at bugs.python.org (Benoit Boissinot)
Date: Wed, 14 Jan 2009 16:40:28 +0000
Subject: [New-bugs-announce] [issue4948] Make heapq work with all mutable
	sequences
In-Reply-To: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>
Message-ID: <1231951228.13.0.336987683355.issue4948@psf.upfronthosting.co.za>


New submission from Benoit Boissinot <bboissin+pythonbugs at gmail.com>:

Generalize heapq to work with all kind of mutable sequences. It should
be investigated PySequence_SetItem is a lot slower than PyList_SET_ITEM
(same for GET_ITEM and GET_SIZE).

----------
components: Extension Modules
messages: 79859
nosy: bboissin
severity: normal
status: open
title: Make heapq work with all mutable sequences
type: feature request

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

From report at bugs.python.org  Wed Jan 14 19:04:59 2009
From: report at bugs.python.org (Andreas Kloeckner)
Date: Wed, 14 Jan 2009 18:04:59 +0000
Subject: [New-bugs-announce] [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

The "name" argument to PyErr_NewException() should be changed from "char
*" to "const char *". Since the rest of pyerrors.h is const-correct,
this seems like an omission.

----------
components: Interpreter Core
messages: 79868
nosy: inducer
severity: normal
status: open
title: Constness in PyErr_NewException
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Jan 14 19:33:28 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 14 Jan 2009 18:33:28 +0000
Subject: [New-bugs-announce] [issue4950] Redundant declaration in pyerrors.h
In-Reply-To: <1231958008.57.0.172561550702.issue4950@psf.upfronthosting.co.za>
Message-ID: <1231958008.57.0.172561550702.issue4950@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

When compiling with -Wredundant-decls gcc spots a redundant declaration:

flub at laurie:sandbox$ cat test.c 
#include <Python.h>
#include <stdio.h>

int main(void)
{
        printf("hello\n");
        return 0;
}
flub at laurie:sandbox$ gcc -I /usr/local/include/python3.0/
-Wredundant-decls test.c 
In file included from /usr/local/include/python3.0/Python.h:102,
                 from test.c:1:
/usr/local/include/python3.0/pyerrors.h:155: warning: redundant
redeclaration of ?PyExc_BufferError?
/usr/local/include/python3.0/pyerrors.h:147: warning: previous
declaration of ?PyExc_BufferError? was here
flub at laurie:sandbox$

This is annoying since when developing extension modules I usually use
-Werror on top of -Wredundant-decls (among others).

Regards
Floris

----------
components: Extension Modules
messages: 79870
nosy: flub
severity: normal
status: open
title: Redundant declaration in pyerrors.h
type: compile error
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jan 15 01:13:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Jan 2009 00:13:04 +0000
Subject: [New-bugs-announce] [issue4951] failure in test_httpservers
In-Reply-To: <1231978384.8.0.984870711272.issue4951@psf.upfronthosting.co.za>
Message-ID: <1231978384.8.0.984870711272.issue4951@psf.upfronthosting.co.za>


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

This one seems to pop up rather frequently on the buildbots:


======================================================================
FAIL: test_post (test.test_httpservers.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"E:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_httpservers.py",
line 330, in test_post
    self.assertEquals(res.read(), b'1, python, 123456\n')
AssertionError: b'' != b'1, python, 123456\n'

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

----------
components: Library (Lib), Tests
messages: 79881
nosy: pitrou
priority: high
severity: normal
status: open
title: failure in test_httpservers
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Jan 15 06:29:18 2009
From: report at bugs.python.org (Gil)
Date: Thu, 15 Jan 2009 05:29:18 +0000
Subject: [New-bugs-announce] [issue4952] Running Python Script to Run a C++
	Code
In-Reply-To: <1231997358.88.0.339846951949.issue4952@psf.upfronthosting.co.za>
Message-ID: <1231997358.88.0.339846951949.issue4952@psf.upfronthosting.co.za>


New submission from Gil <mathnasiumcos at gmail.com>:

Attached you will find my attachment "testdll.zip", my dilemma was how 
to run the attached C++ program using python scripts.  Please advise.

Thanks,
Gil

----------
components: IDLE
files: testdll.zip
messages: 79888
nosy: dominade27
severity: normal
status: open
title: Running Python Script to Run a C++ Code
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file12748/testdll.zip

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

From report at bugs.python.org  Thu Jan 15 10:02:46 2009
From: report at bugs.python.org (oopos)
Date: Thu, 15 Jan 2009 09:02:46 +0000
Subject: [New-bugs-announce] [issue4953] Cannot upload binary file from form
	?
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>


New submission from oopos <myoopos at gmail.com>:

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
---------------------------------------------
Hi,I user Python! 
 
 
UnicodeDecodeError	Python 3.0: G:\cgi\python\python.exe
Thu Jan 15 16:46:34 2009

A problem occurred in a Python script. Here is the sequence of function
calls leading up to the error, in the order they occurred.
 G:\webserver\xampp\cgi-bin\testupload.py in ()
  107 
  108 # get form
  109 opsform = cgi.FieldStorage()
  110 
  111 print ("<br>","form-data:","<br>",opsform,"<br>")
opsform undefined, cgi = <module 'cgi' from 'G:\cgi\python\lib\cgi.py'>,
cgi.FieldStorage = <class 'cgi.FieldStorage'>
 G:\cgi\python\lib\cgi.py in __init__(self=FieldStorage(None, None, []),
fp=None, headers={'content-length': '671631', 'content-type':
'multipart/form-data;
boundary=---------------------------9699301019407'}, outerboundary='',
environ=<os._Environ object at 0x00C90C50>, keep_blank_values=0,
strict_parsing=0)
  477             self.read_urlencoded()
  478         elif ctype[:10] == 'multipart/':
  479             self.read_multi(environ, keep_blank_values,
strict_parsing)
  480         else:
  481             self.read_single()
self = FieldStorage(None, None, []), self.read_multi = <bound method
FieldStorage.read_multi of FieldStorage(None, None, [])>, environ =
<os._Environ object at 0x00C90C50>, keep_blank_values = 0,
strict_parsing = 0
 G:\cgi\python\lib\cgi.py in read_multi(self=FieldStorage(None, None,
[]), environ=<os._Environ object at 0x00C90C50>, keep_blank_values=0,
strict_parsing=0)
  597         # Create bogus content-type header for proper multipart
parsing
  598         parser.feed('Content-Type: %s; boundary=%s\r\n\r\n' %
(self.type, ib))
  599         parser.feed(self.fp.read())
  600         full_msg = parser.close()
  601         # Get subparts
parser = <email.feedparser.FeedParser object at 0x00DD5650>, parser.feed
= <bound method FeedParser.feed of <email.feedparser.FeedParser object
at 0x00DD5650>>, self = FieldStorage(None, None, []), self.fp =
<io.TextIOWrapper object at 0x00BE3FB0>, self.fp.read = <bound method
TextIOWrapper.read of <io.TextIOWrapper object at 0x00BE3FB0>>
 G:\cgi\python\lib\io.py in read(self=<io.TextIOWrapper object at
0x00BE3FB0>, n=-1)
 1722             # Read everything.
 1723             result = (self._get_decoded_chars() +
 1724                       decoder.decode(self.buffer.read(), final=True))
 1725             self._set_decoded_chars('')
 1726             self._snapshot = None
decoder = <encodings.gbk.IncrementalDecoder object at 0x00DB7AB0>,
decoder.decode = <built-in method decode of IncrementalDecoder object at
0x00DB7AB0>, self = <io.TextIOWrapper object at 0x00BE3FB0>, self.buffer
= <io.BufferedReader object at 0x00BE3F90>, self.buffer.read = <bound
method BufferedReader.read of <io.BufferedReader object at 0x00BE3F90>>,
final undefined

UnicodeDecodeError: 'gbk' codec can't decode bytes in position 157-158:
illegal multibyte sequence
      args = ('gbk',
b'-----------------------------9699301019407\r\n...-----------------------------9699301019407--\r\n',
157, 159, 'illegal multibyte sequence')
      encoding = 'gbk'
      end = 159
      object =
b'-----------------------------9699301019407\r\n...-----------------------------9699301019407--\r\n'
      reason = 'illegal multibyte sequence'
      start = 157
      with_traceback = <built-in method with_traceback of
UnicodeDecodeError object at 0x00DB7BF0>

l:\tmp_dir\tmpxyeojf.html contains the description of this error. 


-------------------------------------------
Hi,
I am newbie for python under the windows.
I find that the cgi module always work wrong for the binary files to upload.
I find that it cannot auto to discern the files' mode and alway use the
default mode : 'TEXT'.
So I want to change the sys.stdin 's mode to BINARY to support the
binary files.
I got this way:
 import msvcrt,os
 msvcrt.setmode(0,os.O_BINARY) # for stdin 
 msvcrt.setmode(1,os.O_BINARY) # for stdout
but it isn't work,too.
I know use C progam language can use this function:
  freopen("somefilename","mode","stdin or stdout") to redirect the file
flow.
Can every one help me ?

Best Regards
   oopos

I

----------
components: Unicode
files: tmpav1vve.html
messages: 79892
nosy: oopos
severity: normal
status: open
title: Cannot upload binary file from form ?
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file12750/tmpav1vve.html

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

From report at bugs.python.org  Thu Jan 15 22:21:04 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 15 Jan 2009 21:21:04 +0000
Subject: [New-bugs-announce] [issue4954] native build of python win32 using
	msys under wine.
In-Reply-To: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
Message-ID: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this patch uses work from #3871 to get a build of python for win32
by running msys under Wine, the windows emulator, on linux.
no proprietary operating system or proprietary software was used.

/bin/sh.exe is so xxxxing unbelievably slow on msys under wine
(each sh.exe takes two seconds to start up, loads 240 fonts
and 40 libraries) that running configure was completely intolerable.

consequently, given that PC/config.h is perfectly useable on nt,
this patch totally bypasses the majority of autoconf tests, and
thus cuts the configure time down from three hours to (only!)
fifteen minutes.

configure must be run as:
   ./configure --prefix/python25 --enable-win32build=yes  \
               --enable=shared=yes

there is an additional bug in msys /bin/sh which stops python.exe
from executing scripts that are handed to it on the command-line.
scripts that are fed as standard-input are absolutely fine
(even the same script).  running the same script from python.exe
from wineconsole cmd prompt is _also_ fine.

as a result, the build process terminates at:
   ./python.exe -E setup.py build

to complete the build, "wineconsole cmd" must be run, cd $(BUILDDIR)
and then run the commands manually:
   ./python.exe -E setup.py build
   ./python.exe -E setup.py install
then, back in the borked /bin/sh.exe, make install can be run.

stunningly, this does actually work: python.exe is build,
libpython2.5.dll and libpython2.5.dll.a are built... amazing.

other necessary workarounds:

* gcc -shared .... --out-implib=libpython2.5.dll.a .... etc fails
  spectacularly to create both the .a implib _and_ the .dll.
  consequently, it was necessary to split these up and use dlltool
  to create the dll, implib and .def file etc. etc.

* ar and ranlib on msys, versions 2.16, 2.17 _and_ 2.19 of binutils
  are borked.  2.16 and 2.17 throw an exception; 2.19 segfaults.
  consequently, building of $LIBRARY had to be terminated with
  prejudice.  --enable-shared=no will fail miserably.

regarding testing: it's all a bit... odd.

* ctypes tests cause segfaults!  the S8H one manages a segfault
  all on its own, but there are other tests that cause corruption
  that only shows up later... euurgh.

* builtin test_open fails due to putting \r\n instead of \n in the file

* test_file.py gets a sharing violation

* test_str gets a great one!

   test_str^M
   fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
   fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
   err:seh:setup_exception_record stack overflow 872 bytes in thread
001e eip 7bc3b1dc esp 00410fc8 stack 0x410000-0x411000-0x610000

   yup.... test_floatformatting.

   ahh, this is gooood :)


overall it's a damn good start - i'm dead impressed with
wine and msys in that they exist at all.

compiling and testing python under wine + msys should help
test and improve both those projects, and both this patch
and #3871 will help get python off of its dependence on
proprietary software.

----------
components: Build
files: f
messages: 79916
nosy: lkcl
severity: normal
status: open
title: native build of python win32 using msys under wine.
versions: Python 2.5
Added file: http://bugs.python.org/file12755/f

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

From report at bugs.python.org  Thu Jan 15 23:34:32 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 15 Jan 2009 22:34:32 +0000
Subject: [New-bugs-announce] [issue4955] inconsistent, perhaps incorrect,
	behavior with respect to entities parsed by xml.sax
In-Reply-To: <1232058872.83.0.627723376398.issue4955@psf.upfronthosting.co.za>
Message-ID: <1232058872.83.0.627723376398.issue4955@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

The attached program demonstrates that the ContentHandler.skippedEntity
callback is not invoked for all skipped entities.  Specifically, it is
not invoked for those in attribute values.  Additionally, it
demonstrates that when parsing a document with no DOCTYPE, skippedEntity
is not called at all; instead the parser raises an exception about an
"undefined entity".

----------
components: Library (Lib)
files: entity-skipped-in-attribute-value.py
messages: 79920
nosy: exarkun
severity: normal
status: open
title: inconsistent, perhaps incorrect, behavior with respect to entities parsed by xml.sax
Added file: http://bugs.python.org/file12757/entity-skipped-in-attribute-value.py

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

From report at bugs.python.org  Fri Jan 16 00:00:35 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 15 Jan 2009 23:00:35 +0000
Subject: [New-bugs-announce] [issue4956] Py_Initialize needs to be done
	before file load (on msys+wine)
In-Reply-To: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>
Message-ID: <1232060435.88.0.986557230839.issue4956@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this is a _very_ strange case where the file contents cannot be read,
under msys+wine, but under _just_ wine (cmd.exe) everything goes
absolutely fine.

by moving Py_Initialize() to _before_ the file load, it works!

----------
components: Build
files: f
messages: 79924
nosy: lkcl
severity: normal
status: open
title: Py_Initialize needs to be done before file load (on msys+wine)
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file12758/f

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

From report at bugs.python.org  Fri Jan 16 00:01:02 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Jan 2009 23:01:02 +0000
Subject: [New-bugs-announce] [issue4957] os.ftruncate raises IOError instead
	of OSError
In-Reply-To: <1232060462.22.0.637111039397.issue4957@psf.upfronthosting.co.za>
Message-ID: <1232060462.22.0.637111039397.issue4957@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

I stumbled upon this.  Of all the errors in the posixmodule.c, ftruncate 
alone raises an IOError upon failure.  All the others raise OSError.  
This behaviour is not documented.  However, the os module documentation 
says>

Note
All functions in this module raise OSError in the case of invalid or 
inaccessible file names and paths, or other arguments that have the 
correct type, but are not accepted by the operating system.

This came to light when I added tests to verify that exceptions were 
being raised by invalid file descriptors.

I propose to fix this to comply with the docs.

----------
components: Interpreter Core
files: ftruncate.patch
keywords: patch, patch
messages: 79925
nosy: krisvale
severity: normal
status: open
title: os.ftruncate raises IOError instead of OSError
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12759/ftruncate.patch

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

From report at bugs.python.org  Fri Jan 16 00:33:09 2009
From: report at bugs.python.org (Jan Malakhovski)
Date: Thu, 15 Jan 2009 23:33:09 +0000
Subject: [New-bugs-announce] [issue4958] email/header.py ecre regular
	expression issue
In-Reply-To: <1232062389.84.0.560697403346.issue4958@psf.upfronthosting.co.za>
Message-ID: <1232062389.84.0.560697403346.issue4958@psf.upfronthosting.co.za>


New submission from Jan Malakhovski <jan.malachowski at gmail.com>:

Hello.

I have dedicated mail server at home
and it holds about 1G of mail.
Most of mail is in non UTF-8 codepage, so today
I wrote little script that should recode
all letters to UTF. But I found that
email.header.decode_header parses some headers wrong.

For example, header
Content-Type: application/x-msword; name="2008
=?windows-1251?B?wu7v8O7x+w==?= 2 =?windows-1251?B?4+7kIDgwONUwMC5kb2M=?="
parsed as
[('application/x-msword; name="2008', None),
('\xc2\xee\xef\xf0\xee\xf1\xfb', 'windows-1251'), ('2
=?windows-1251?B?4+7kIDgwONUwMC5kb2M=?="', None)]
that is obviously wrong.

Now I'm playing with email/header.py file in
python 2.5 debian package
(but it's same in 2.6.1 version except that all <> changed to !=).

If it's patched with
==================BEGIN CUT==================
--- oldheader.py	2009-01-16 01:47:32.553130030 +0300
+++ header.py	2009-01-16 01:47:16.783119846 +0300
@@ -39,7 +39,6 @@
   \?                    # literal ?
   (?P<encoded>.*?)      # non-greedy up to the next ?= is the encoded
string
   \?=                   # literal ?=
-  (?=[ \t]|$)           # whitespace or the end of the string
   ''', re.VERBOSE | re.IGNORECASE | re.MULTILINE)
 
 # Field name regexp, including trailing colon, but not separating
whitespace,
==================END CUT==================
it works fine.

So I wonder if this
  (?=[ \t]|$)           # whitespace or the end of the string
really needed, after all if there is only
whitespaces after encoded word, its just
appended to the list by

parts = ecre.split(line)

--
Also, there is related mail list thread:
http://mail.python.org/pipermail/python-dev/2009-January/085088.html

----------
components: Library (Lib)
messages: 79927
nosy: oxij
severity: normal
status: open
title: email/header.py ecre regular expression issue
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jan 16 06:53:21 2009
From: report at bugs.python.org (dariusp)
Date: Fri, 16 Jan 2009 05:53:21 +0000
Subject: [New-bugs-announce] [issue4959] inspect.formatargspec fails for
	keyword args without defaults, affects help and likely pydoc
In-Reply-To: <1232085201.15.0.206392471567.issue4959@psf.upfronthosting.co.za>
Message-ID: <1232085201.15.0.206392471567.issue4959@psf.upfronthosting.co.za>


New submission from dariusp <dariusp at internode.on.net>:

Hi,

Suggested log message:
formatargspec now handles keyword only args that don't have defaults. 
Previously it expected an empty dict but was being given None.


Patch:
The patch contains a suggested fix to inspect.py and a new test in
test_inspect.py and inspect_fodder2.py to demonstrate the issue.


Before:
>>> def foo(*, a):
...  print(a)
... 
>>> help(foo)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/site.py", line 427, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python3.0/pydoc.py", line 1672, in __call__
    self.help(request)
  File "/usr/local/lib/python3.0/pydoc.py", line 1716, in help
    else: doc(request, 'Help on %s:')
  File "/usr/local/lib/python3.0/pydoc.py", line 1504, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/local/lib/python3.0/pydoc.py", line 1499, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "/usr/local/lib/python3.0/pydoc.py", line 322, in document
    if inspect.isroutine(object): return self.docroutine(*args)
  File "/usr/local/lib/python3.0/pydoc.py", line 1263, in docroutine
    formatannotation=inspect.formatannotationrelativeto(object))
  File "/usr/local/lib/python3.0/inspect.py", line 895, in formatargspec
    if kwonlyarg in kwonlydefaults:
TypeError: argument of type 'NoneType' is not iterable


After:
>>> def foo(*, a):
...  print(a)
... 
>>> help(foo)

Help on function foo in module __main__:

foo(*, a)

----------
components: Library (Lib)
files: inspect_keyworded_no_default.diff
keywords: patch
messages: 79932
nosy: dariusp
severity: normal
status: open
title: inspect.formatargspec fails for keyword args without defaults, affects help and likely pydoc
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12760/inspect_keyworded_no_default.diff

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

From report at bugs.python.org  Fri Jan 16 07:29:08 2009
From: report at bugs.python.org (Martin Saturka)
Date: Fri, 16 Jan 2009 06:29:08 +0000
Subject: [New-bugs-announce] [issue4960] askdirectory from
	tkinter.filedialog does not work
In-Reply-To: <1232087348.49.0.185277091833.issue4960@psf.upfronthosting.co.za>
Message-ID: <1232087348.49.0.185277091833.issue4960@psf.upfronthosting.co.za>


New submission from Martin Saturka <kvutza at gmail.com>:

Directory selection from Tkinter part of Python 3.0, i.e. "askdirectory"
function from tkinter.filedialog does not work. It works for 2.x Python,
other Tkinter functions (askopenfilename, asksaveasfilename) work well
at both 2.x and 3.0 versions.

----------
components: Tkinter
messages: 79934
nosy: kvutza
severity: normal
status: open
title: askdirectory from tkinter.filedialog does not work
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Jan 16 10:38:25 2009
From: report at bugs.python.org (eb303)
Date: Fri, 16 Jan 2009 09:38:25 +0000
Subject: [New-bugs-announce] [issue4961] Inconsistent/wrong result of
	askyesno function in tkMessageBox
In-Reply-To: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>
Message-ID: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>


New submission from eb303 <eric.brunel at pragmadev.com>:

Scenario to reproduce the problem:
- Run the attached script.
- Click the 'Ask confirm' button and answer 'Yes'; it should print 
True, which is the expected answer.
- Click the 'Ask file' button, select any file and confirm.
- Click the 'Ask confirm' button and answer 'Yes'.
The script prints False, which is obviously wrong.
Problem reproduced on Linux Red Hat Fedora Core 4, Suse Enterprise 
Linux 9, Solaris 8 for Sparc and Solaris 10 on Intel. The script works 
as expected on Windows 2000, so it seems to be Unix-specific.

Possible cause: the result of the _show function in tkMessageBox is not 
always a string, apparently depending on what happened before. Changing 
the last line to:
return str(res)
seemed to correct the problem for me.

----------
components: Tkinter
files: dialog-bug.py
messages: 79944
nosy: eb303
severity: normal
status: open
title: Inconsistent/wrong result of askyesno function in tkMessageBox
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12761/dialog-bug.py

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

From report at bugs.python.org  Fri Jan 16 11:28:24 2009
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_BRINER?=)
Date: Fri, 16 Jan 2009 10:28:24 +0000
Subject: [New-bugs-announce] [issue4962] urlparse & nfs url (rfc 2224)
In-Reply-To: <1232101704.89.0.669847506906.issue4962@psf.upfronthosting.co.za>
Message-ID: <1232101704.89.0.669847506906.issue4962@psf.upfronthosting.co.za>


New submission from C?dric BRINER <briner at infomaniak.ch>:

Hi,

I'd like to add the ability to parse nfs url (rfc2224). Which look like:
nfs://server/my/path

To do this, we only need to add 'nfs' in uses_netloc to make it work

cEd

----------
components: Extension Modules
messages: 79946
nosy: yuhl
severity: normal
status: open
title: urlparse & nfs url (rfc 2224)
type: feature request

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

From report at bugs.python.org  Fri Jan 16 13:04:54 2009
From: report at bugs.python.org (S Arrowsmith)
Date: Fri, 16 Jan 2009 12:04:54 +0000
Subject: [New-bugs-announce] [issue4963] mimetypes.guess_extension result
	changes after mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>


New submission from S Arrowsmith <siona at chiark.greenend.org.uk>:

Asking mimetypes to reload mime.types can cause guess_extension() to
return a different result if multiple extensions are mapped to that mime
type:

>>> import mimetypes
>>> mimetypes.guess_extension('image/jpeg')
'.jpe'
>>> mimetypes.init()
>>> mimetypes.guess_extension('image/jpeg')
'.jpeg'
>>>

This is because both the forward (extension to type) and inverse (type
to extension) type mapping dicts are populated by iterating through the
existing forward (extension to type) dict (types_map), then supplemented
by reading from mime.types (or any other files given to init()). The
fully populated forward dict becomes the new types_map. Initially,
types_map is hard-coded, but when the type mapping dicts are
repopulated, by explicitly or implicitly calling init() again, it is
done by iterating over the types_map created by the first init() call,
not the hard-coded one. If the iteration order for a set of extensions
with the same type is different in these two versions of the forward
dict, the order of extensions appearing for that type in the inverse
dict will change. And so the behavior of guess_all_extensions() and
hence guess_extension() will change.

----------
components: Library (Lib)
messages: 79955
nosy: siona
severity: normal
status: open
title: mimetypes.guess_extension result changes after mimetypes.init()
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Fri Jan 16 22:26:09 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 16 Jan 2009 21:26:09 +0000
Subject: [New-bugs-announce] [issue4964] UTF-16 stream codec barfs on valid
	input
In-Reply-To: <1232141169.6.0.562983030124.issue4964@psf.upfronthosting.co.za>
Message-ID: <1232141169.6.0.562983030124.issue4964@psf.upfronthosting.co.za>


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

I am attaching a file encoded in UTF-16 (with bom) which causes the
stream codec employed by the file reader to barf when reading by lines.
 However reading the file in binary mode and decoding it in one fell
swoop works fine, and reading the whole text file with text() also works
fine; so I believe the data in the file is not corrupt (it started out
as an export of my Gmail contacts, but I x-ed out all printable ASCII
characters).

>>> x = open('contacts.csv', 'rb').read().decode('utf16')  # OK
>>> x = open('contacts.csv', encoding='utf16').read()  # OK
>>> x = open('contacts.csv', encoding='utf16').readlines()  # Dies
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.0/io.py", line 534, in readlines
    return list(self)
  File "/usr/local/lib/python3.0/io.py", line 1739, in __next__
    line = self.readline()
  File "/usr/local/lib/python3.0/io.py", line 1813, in readline
    while self._read_chunk():
  File "/usr/local/lib/python3.0/io.py", line 1562, in _read_chunk
    self._set_decoded_chars(self._decoder.decode(input_chunk, eof))
  File "/usr/local/lib/python3.0/io.py", line 1295, in decode
    output = self.decoder.decode(input, final=final)
  File "/usr/local/lib/python3.0/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
  File "/usr/local/lib/python3.0/encodings/utf_16.py", line 69, in
_buffer_decode
    return self.decoder(input, self.errors, final)
UnicodeDecodeError: 'utf16' codec can't decode byte 0x00 in position 0:
truncated data
>>>

Making certain modifications to the file elicits slightly different
error messages (e.g. "'utf16' codec can't decode bytes in position
90-91: illegal encoding" when I swap the second and first half of the
file) so it looks like some kind of data corruption in the codec's state
management or in the code in io.py that feeds the codec its data.

----------
components: Library (Lib)
files: contacts.csv
messages: 79976
nosy: gvanrossum
priority: critical
severity: normal
status: open
title: UTF-16 stream codec barfs on valid input
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12766/contacts.csv

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

From report at bugs.python.org  Sat Jan 17 00:30:33 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Jan 2009 23:30:33 +0000
Subject: [New-bugs-announce] [issue4965] Can doc index of html version be
	separately scrollable?
In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>
Message-ID: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In the Windows help version of the docs that come with the Windows .msi
installer, the index pane to the left scrolls separately from the
content pane to the right.  Very nice for jumping around even to other docs.

In the html versions at docs.python.org, there is one scroll bar and the
index disappears when one moves very far down the page.  If sensibly
possible, decoupling index and context would be nice.  Please pardon my
ignorance if not.

----------
assignee: georg.brandl
components: Documentation
messages: 79986
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Can doc index of html version be separately scrollable?
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 00:43:38 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Jan 2009 23:43:38 +0000
Subject: [New-bugs-announce] [issue4966] Improving Lib Doc Sequence Types
	Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Issues and suggestions for Python Standard Library / Built-in Types /
"Sequence Types ? str, bytes, bytearray, list, tuple, range"

1. Put subsections in the same order as in the title and main section. 
In particular, move bytes/bytearray subsection up to follow string
subsection and move range subsection down to bottom of this grouping.

2. String paragraph (the second) ends with the rather wordy sentence
"In addition to the functionality described here, there are also
string-specific methods described in the String Methods section."
where 'String Methods' is a forward link to that subsection.
Add similar possibly less wordy sentence-links for other types.

In particular, end next (byte/bytearray) paragraph with something like
"For specific methods, see String Methods and Bytes and Byte Array
Methods. For bytearrays, also see Mutable Sequence Types."

End the list/tuple paragraph after the Warning with
"For list methods, see Mutable Sequence Types."

After the following range paragraph, the following could be added:
"For more, see Range Type."
However, there is almost nothing more said (perhaps there was before
range objects were stripped down), so I suggest deleting that subsection
and adding anything more that is not duplication to the end of the
beginning section's range paragraph.  If tuples do not need their own
section, range needs one even less.

3. Bytes and Byte Array Method subsection correctly says that bytes and
bytearrays do not have (senseless) .encode but neglects to document the
corresponding inverse .decode method (while it does mention the
specialized .fromhex decoding method).

Also add .isdecimal, .isnumeric, .isprintable, and .maketrans to the
list of exceptions in the first sentence. (Based on dir(str), dir(bytes)
in 3.0)

4. I see three problems with the current documentation of count and
index methods.
a)  They are documented under both String Methods and Mutable Sequences.
 They do not really belong in the latter, which lists "additional
operations that allow in-place modification of the object", because they
do not mutate.
b) Tuples do not have their own a section, but (unlike range objects) do
have a couple of methods: count and index.  Being neither string-like
nor mutable, their having methods is undocumented.
c) Bytearrays, on the other hand, are both string-like and mutable.  So
they are (mis)documented as having two slightly different versions of
these methods. (They actually use the string-like definition, of course.)

Consequently, the definitions of count and index in the Mutable Sequence
subsection are not mutable sequence definitions but are really
list/tuple definitions.  So I suggest one of two variations:
A) In the main section, add the list/tuple version of .count() and
.index() to the table of common sequence operations with a footnote
either explaining the difference for the string group or referring to
String Methods.
B) In the main section, add both versions to the table with footnotes
explaining which is which.

The count/index/tuple doc issue has come up more than once on c.l.p.

----------
assignee: georg.brandl
components: Documentation
messages: 79988
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Improving Lib Doc Sequence Types Section
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 03:36:52 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jan 2009 02:36:52 +0000
Subject: [New-bugs-announce] [issue4967] Bugs in _ssl object read() when a
	buffer is specified
In-Reply-To: <1232159812.52.0.781690409094.issue4967@psf.upfronthosting.co.za>
Message-ID: <1232159812.52.0.781690409094.issue4967@psf.upfronthosting.co.za>


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

The read() method on ssl objects can take a buffer as a parameter, but
the method is buggy in this case:

- it only accepts bytearrays, while it should accept any object
supporting the buffer protocol in write mode
- when the object is not a bytearray, it returns NULL without setting
the current exception
- since it doesn't attempt to get a buffer export from the object, there
is no protection and the buffer could be resized while the method
releases the GIL, leading to a likely crash

This patch solves all three issues. Note that I'm not able to write an
unit test for it, because test_ssl.py is too high-level (it looks more
like functional tests than unit tests). Also, the only reason I
discovered this is that it made some tests fail on the io-in-C branch
(which uses readinto() a lot). I'm a complete SSL newbie.

----------
assignee: janssen
components: Extension Modules
files: ssl-readbuffer.patch
keywords: patch
messages: 79996
nosy: janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Bugs in _ssl object read() when a buffer is specified
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12772/ssl-readbuffer.patch

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

From report at bugs.python.org  Sat Jan 17 04:26:09 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2009 03:26:09 +0000
Subject: [New-bugs-announce] [issue4968] Clarify inspect.is<callable> method
	docs
In-Reply-To: <1232162769.03.0.624026715862.issue4968@psf.upfronthosting.co.za>
Message-ID: <1232162769.03.0.624026715862.issue4968@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

inspect module in 3.0

.isclass: says "Return true if the object is a class." Since the issue
of builtin versus Python coded is involved in all the other methods
below, I would expand this to
"Return true if the object is a class, whether built-in or Python-coded."
to emphasize that this is not an issue for this one.

.isfunction: current "Return true if the object is a Python function or
unnamed (lambda) function." falsely implies that there is such a thing
as 'unnamed (lambda) function; different from 'Python function'.  By
test, it just returns True for 'function' objects. Suggestion:

"Return true for Python-coded functions, including unbound Python-coded
methods." or possibly
"Return true for functions created by def statements and lambda
expressions, including unbound Python-coded methods.

.ismethod: "Return true if the object is a method." should be specified
to something like
"Return true if the object is a bound method written in Python."

.isbuiltin: says "Return true if the object is a built-in function."
but actually tests for membership in class 'builtin_function_or_method'.
 I believe that truth is
"Return true if the object is a built-in function (but not a class) or a
bound built-in non-special method."
It is True, for instance, for [].append but not [].__hash__.  I am
assuming that this behavior is intended and not a bug.

.ismethoddescriptor: "Return true if the object is a method descriptor,
but not if ismethod() or isclass() or isfunction() are true." begs the
question of what a method descriptor is.  I believe the following is
both true and clearer.
"Return true if the object is a built-in method and isbuiltin() is false.

I would follow with
"The methods isclass, isfunction, ismethod, isbuiltin, and
ismethoddescriptor are mutually exclusive."
I believe the following is true, and could be added also.
"Exact one is true for any instance of a built-in callable class."

----------
assignee: georg.brandl
components: Documentation
messages: 79999
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Clarify inspect.is<callable> method docs
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 09:58:42 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 17 Jan 2009 08:58:42 +0000
Subject: [New-bugs-announce] [issue4969] mimetypes on Windows should read
	MIME database from registry (w/patch)
In-Reply-To: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>
Message-ID: <1232182722.74.0.429880551513.issue4969@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

The mimetypes module has a built-in default database, and, in addition, 
reads mime.types files from a list of standard places (/etc/mime.types 
by example)
On Windows, those files usually don't even present; MIME information is 
stored in the registry instead. Until now, the mimetypes module just 
ignored those settings; this patch adds support for reading the MIME 
database from the Windows registry.

----------
components: Library (Lib)
files: mimetypes.diff
keywords: patch
messages: 80007
nosy: gagenellina
severity: normal
status: open
title: mimetypes on Windows should read MIME database from registry (w/patch)
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12774/mimetypes.diff

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

From report at bugs.python.org  Sat Jan 17 12:09:45 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Jan 2009 11:09:45 +0000
Subject: [New-bugs-announce] [issue4970] test_os causes delayed failure on
	x86 gentoo buildbot: Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The x86 gentoo 3.0 and 3.x buildbots have been failing for a while at the test stage, with:

make: *** [buildbottest] Unknown signal 32
program finished with exit code 2

I noticed a common denominator with these failures, which is that they always seem to occur a few tests after 
test_os has been run.  So it looks as though something in test_os is causing this.

Can anyone reproduce this (I can't on any of the machines I have access to), and (e.g., by trial and error) identify 
which of the test_os tests is causing this?

----------
messages: 80009
nosy: marketdickinson
severity: normal
status: open
title: test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 17:13:43 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 17 Jan 2009 16:13:43 +0000
Subject: [New-bugs-announce] [issue4971] Incorrect title case
In-Reply-To: <1232208823.98.0.877639749298.issue4971@psf.upfronthosting.co.za>
Message-ID: <1232208823.98.0.877639749298.issue4971@psf.upfronthosting.co.za>


New submission from Matthew Barnett <python at mrabarnett.plus.com>:

I've found that the following 4 Unicode characters/codepoints don't
behave as I'd expect: ? (U+01C5), ? (U+01C8), ? (U+01CB), ? (U+01F2).

For example, u'\u01C5'.istitle() returns True and
unicodedata.category(u'\u01C5') returns 'Lt', but u'\u01C5'.title()
returns u'\u01C4' (?), which is the uppercase equivalent.

I believe that these 4 codepoints are the only ones where the titlecase
differs from uppercase.

I thought it might be a mistake in the Unicode database. However John
Machin says:

Doesn't look like it. AFAICT it's a mistake in Objects/unicodetype.c,
function _PyUnicode_ToTitlecase.

See
http://svn.python.org/view/python/trunk/Objects/unicodectype.c?rev=66362&view=markup

The code that says:
    if (ctype->title)
        delta = ctype->title;
    else
	delta = ctype->upper;
should IMHO merely be:
    delta = ctype->title;

A value of zero for ctype->title should be interpreted simply as the
offset to add to the ordinal, as it is in the sibling _PyUnicode_To
(Upper|Lower)case functions. See also Tools/unicode/makeunicodedata.py
which treats upper, lower and title identically when preparing the
tables used by those 3 functions.

AFAICT making that change will fix the problem for those four
characters and not ruin any others.

The error that you noticed occurs as far back as I've looked (2.1) and
also occurs in 3.0.

----------
components: Unicode
messages: 80020
nosy: mrabarnett
severity: normal
status: open
title: Incorrect title case
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 18:28:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 17 Jan 2009 17:28:58 +0000
Subject: [New-bugs-announce] [issue4972] let's equip ftplib.FTP with
	__enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

In a program, I naturally wrote:

    >>> from ftplib import FTP
    >>> with FTP('ftp.somewhere.com') as ftp:
    ...     ftp.login('someone', 'pass')
    ...     ...

Until I realized this class is not equipped with __enter__ and __exit__,

I think it could be a simple and pleasant enhancement to add it.

----------
components: Library (Lib)
messages: 80026
nosy: tarek
severity: normal
status: open
title: let's equip ftplib.FTP with __enter__ and __exit__
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 18:57:54 2009
From: report at bugs.python.org (Michael Newman)
Date: Sat, 17 Jan 2009 17:57:54 +0000
Subject: [New-bugs-announce] [issue4973] calendar formatyearpage returns
	bytes, not str
In-Reply-To: <1232215074.9.0.340477624129.issue4973@psf.upfronthosting.co.za>
Message-ID: <1232215074.9.0.340477624129.issue4973@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

formatyearpage is returning "bytes", not "str"

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import calendar
>>> calendar.HTMLCalendar().formatyearpage(2009)[0:50]
b'<?xml version="1.0" encoding="utf-8"?>\n<!DOCTYPE h'
>>> type(calendar.HTMLCalendar().formatyearpage(2009)[0:50])
<class 'bytes'>

# For the time being, to fix it I can use "decode"...
>>> calendar.HTMLCalendar().formatyearpage(2009).decode("utf-8")[0:50]
'<?xml version="1.0" encoding="utf-8"?>\n<!DOCTYPE h'
>>> type(calendar.HTMLCalendar().formatyearpage(2009).decode("utf-8")[0:50])
<class 'str'>

----------
components: Extension Modules
messages: 80030
nosy: mnewman
severity: normal
status: open
title: calendar formatyearpage returns bytes, not str
versions: Python 3.0

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

From report at bugs.python.org  Sat Jan 17 21:52:28 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 17 Jan 2009 20:52:28 +0000
Subject: [New-bugs-announce] [issue4974] Redundant mention of lists and
	tuples at start of Sequence Types documentation
In-Reply-To: <1232225548.25.0.868641329064.issue4974@psf.upfronthosting.co.za>
Message-ID: <1232225548.25.0.868641329064.issue4974@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Under Built-in Types in the Library documentation the section on "Sequence 
Types" begins with the paragraph:

There are five sequence types: strings, byte sequences, byte arrays, 
lists, tuples, and range objects. (For other containers see the built-in 
dict, list, set, and tuple classes, and the collections module.)

list and tuple "classes" shouldn't be in that second sentence, should 
they? They are already in the first.

----------
assignee: georg.brandl
components: Documentation
messages: 80046
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Redundant mention of lists and tuples at start of Sequence Types documentation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 22:33:00 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Jan 2009 21:33:00 +0000
Subject: [New-bugs-announce] [issue4975] 3.0 base64 doc examples lack bytes
	'b' indicator
In-Reply-To: <1232227980.99.0.219231642791.issue4975@psf.upfronthosting.co.za>
Message-ID: <1232227980.99.0.219231642791.issue4975@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

This unconverted example in the 3.1a doc needs a 'b' for 'bytes' added
before the three input and output string literals.

>>> import base64
>>> encoded = base64.b64encode('data to be encoded') # here
>>> encoded
'ZGF0YSB0byBiZSBlbmNvZGVk' # here
>>> data = base64.b64decode(encoded)
>>> data
'data to be encoded' #and here

Otherwise,
TypeError: expected bytes, not str

----------
assignee: georg.brandl
components: Documentation
messages: 80048
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: 3.0 base64 doc examples lack bytes 'b' indicator

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

From report at bugs.python.org  Sat Jan 17 22:50:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 17 Jan 2009 21:50:26 +0000
Subject: [New-bugs-announce] [issue4976] Documentation of the set
	intersection and difference operators is inaccurate
In-Reply-To: <1232229026.33.0.903700187167.issue4976@psf.upfronthosting.co.za>
Message-ID: <1232229026.33.0.903700187167.issue4976@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

A quibble about the documentation of sets in the library documentation: 
the union and intersection operators are shown with ellipsis, as is the 
difference operator. However, they inaccurately refer to "both sets" in 
their documentation. They should refer to "all sets" or "the others" the 
way the set difference operator documentation does.

----------
assignee: georg.brandl
components: Documentation
messages: 80051
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of the set intersection and difference operators is inaccurate
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 17 23:01:00 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 17 Jan 2009 22:01:00 +0000
Subject: [New-bugs-announce] [issue4977] test_maxint64 fails on 32-bit
	systems due to assumption that 64-bit fits into "long"
In-Reply-To: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>
Message-ID: <1232229660.32.0.518084727508.issue4977@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

the assumption is made that the result will fit into a PyInt.
obviously, on a 32-bit system, where SIZEOF_LONG is 4 bytes,
that ain't happening.

a complex test would be something like this:

if len <= 9: it's an int, definitely.
if len > 10: it's a long, definitely.
if len == 10, and first char is a "-", it's an int, definitely
if len == 10, and first char is 5,6,7,8,9, it's a long, definitely.
if len == 10, and first char is 0,1,2,3, it's an int, definitely.
if len == 10, and first char is 4, it _might_ be a long, but it might
also be an int, so... uh... let's assume it's a long!

and you know what?  xxxx that for a game of soldiers: just use
"if len >= 10" assume it's a long :)




diff --git a/Modules/cPickle.c b/Modules/cPickle.c
index 537276c..e56f8e5 100644
--- a/Modules/cPickle.c
+++ b/Modules/cPickle.c
@@ -3143,7 +3143,15 @@ load_int(Unpicklerobject *self)
    errno = 0;
    l = strtol(s, &endptr, 0);

-   if (errno || (*endptr != '\n') || (endptr[1] != '\0')) {
+   if (errno || (*endptr != '\n') || (endptr[1] != '\0')
+#if SIZEOF_LONG == 4
+        /* integers of 10 chars or over could be bigger than 32-bit.
+         * just keep it simple: 10 or more chars, it goes into
+         * a PyLong.
+         */
+        || (len >= 10)
+#endif
+       ) {
        /* Hm, maybe we've got something long.  Let's try reading
           it as a Python long object. */
        errno = 0;

----------
components: Build
messages: 80052
nosy: lkcl
severity: normal
status: open
title: test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into "long"
versions: Python 2.5

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

From report at bugs.python.org  Sun Jan 18 00:07:25 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 17 Jan 2009 23:07:25 +0000
Subject: [New-bugs-announce] [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

This allows unicode arguments to be passed as keywords to functions to
help "from __future__ import unicode_literals". See
http://mail.python.org/pipermail/python-dev/2009-January/085113.html.

----------
components: Library (Lib)
messages: 80060
nosy: benjamin.peterson
severity: normal
status: open
title: allow unicode keyword args
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 18 01:03:18 2009
From: report at bugs.python.org (Max Hailperin)
Date: Sun, 18 Jan 2009 00:03:18 +0000
Subject: [New-bugs-announce] [issue4979] random.uniform can return its upper
	limit
In-Reply-To: <1232236998.05.0.906555449746.issue4979@psf.upfronthosting.co.za>
Message-ID: <1232236998.05.0.906555449746.issue4979@psf.upfronthosting.co.za>


New submission from Max Hailperin <max at gustavus.edu>:

The documentation for random.uniform says that random.uniform(a,b) 
should return a number strictly less than b, assuming a<b.  (The result 
should be strictly less than a if a>b.)  Thus both of the following 
expressions should always evaluate to False:

a<b and b in [random.uniform(a,b) for i in range(20)]
a<b and b in [random.uniform(b,a) for i in range(20)]

Yet both of them evaluate to True (except, presumably, one time in a 
million) after doing the following assignments:

a = 1.0
b = 1.0 + 2.0**-52

Other values of a and b also exist for which random.uniform will 
sometimes return its upper limit.  (For example, the -52 can be 
increased to -51, -50, etc., with correspondingly less frequent 
violations of the spec.)

Because this is a case where the code is violating an explicit 
specification in the documentation, I'm reporting it as a behavior bug.  
But perhaps the behavior is as intended and the documentation is at 
fault.  For that reason, I'm also emailing docs at python.org.
 
The documentation would in any case need a little touching up, in that 
it has a self-contradictory specification for the case where a=b.  There 
is no value N for which a<=N<b, given a=b.  That minor touch-up could be 
combined with allowing the behavior described in this bug report, if 
that behavior is in fact desired.

----------
components: Library (Lib)
messages: 80062
nosy: hailperin
severity: normal
status: open
title: random.uniform can return its upper limit
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Jan 18 01:42:54 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jan 2009 00:42:54 +0000
Subject: [New-bugs-announce] [issue4980] Documentation for "y#" does not
	mention PY_SSIZE_T_CLEAN
In-Reply-To: <1232239374.34.0.275487506145.issue4980@psf.upfronthosting.co.za>
Message-ID: <1232239374.34.0.275487506145.issue4980@psf.upfronthosting.co.za>


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

Documentation for "y#" does not mention PY_SSIZE_T_CLEAN, it lets
believe that the length result is unconditionally int-sized.
(in http://docs.python.org/3.0/c-api/arg.html)

----------
assignee: georg.brandl
components: Documentation
messages: 80065
nosy: georg.brandl, pitrou
severity: normal
status: open
title: Documentation for "y#" does not mention PY_SSIZE_T_CLEAN
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 18 02:06:15 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 18 Jan 2009 01:06:15 +0000
Subject: [New-bugs-announce] [issue4981] Incorrect statement regarding
	mutable sequences in datamodel Reference
In-Reply-To: <1232240775.28.0.564077407765.issue4981@psf.upfronthosting.co.za>
Message-ID: <1232240775.28.0.564077407765.issue4981@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Early in the datamodel document in the Reference documentation is the 
statement:

      There is currently a single intrinsic mutable sequence type:

This statement is followed by the documentation of Lists and Byte Arrays. 
The statement should read "There are currently two intrinsic mutable 
sequence types".

----------
assignee: georg.brandl
components: Documentation
messages: 80067
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Incorrect statement regarding mutable sequences in datamodel Reference
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 18 02:42:56 2009
From: report at bugs.python.org (William Stevenson)
Date: Sun, 18 Jan 2009 01:42:56 +0000
Subject: [New-bugs-announce] [issue4982] Running python 3 as Non-admin User
	requests the Runtime to terminate in an unusual way.
In-Reply-To: <1232242976.03.0.32299361581.issue4982@psf.upfronthosting.co.za>
Message-ID: <1232242976.03.0.32299361581.issue4982@psf.upfronthosting.co.za>


New submission from William Stevenson <yhvh2000 at googlemail.com>:

AMD64 msi install seemed to work fine when running python3.0 as admin 
but fails immediately as any other user.

Command Line output:
C:\Python30>python.exe
Fatal Python error: Py_Initialize: can't initialize sys standard streams
  File "C:\Python25\Lib\encodings\__init__.py", line 120
    raise CodecRegistryError,\
                            ^
SyntaxError: invalid syntax

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.

C:\Python30>


GUI output:
---------------------------
Visual Studio Just-In-Time Debugger
---------------------------
An unhandled win32 exception occurred in python.exe [2028]. Just-In-Time 
debugging this exception failed with the following error: No installed 
debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-
Time debugging can be enabled from Tools/Options/Debugging/Just-In-Time.

Check the documentation index for 'Just-in-time debugging, errors' for 
more information.
---------------------------
OK   
---------------------------

----------
components: Installation, Windows
messages: 80070
nosy: yhvh
severity: normal
status: open
title: Running python 3 as Non-admin User requests the Runtime to terminate in an unusual way.
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sun Jan 18 05:01:40 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 18 Jan 2009 04:01:40 +0000
Subject: [New-bugs-announce] [issue4983] Spurious reference to "byte
	sequences" in Library stdtypes sequence documentation
In-Reply-To: <1232251300.25.0.53795146873.issue4983@psf.upfronthosting.co.za>
Message-ID: <1232251300.25.0.53795146873.issue4983@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The first sentence under "Sequence Types" in the Library stdtypes document 
is:

There are five sequence types: strings, byte sequences, byte arrays, 
lists, tuples, and range objects

However, subsequent discussion, as well as reality, use the term "bytes" 
not "byte sequences".

----------
assignee: georg.brandl
components: Documentation
messages: 80074
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Spurious reference to "byte sequences" in Library stdtypes sequence documentation
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 18 05:09:20 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 18 Jan 2009 04:09:20 +0000
Subject: [New-bugs-announce] [issue4984] Inconsistent count of sequence
	types in Library stdtypes document
In-Reply-To: <1232251760.56.0.36573894326.issue4984@psf.upfronthosting.co.za>
Message-ID: <1232251760.56.0.36573894326.issue4984@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Sorry I didn't notice all the problems I've reported today about this 
paragraph at one time so I could have submitted only one report. Anyway, 
here's another problem with the first sentence of the Sequence Types 
section of the library stdtypes document. The sentence:

There are five sequence types: strings, byte sequences, byte arrays, 
lists, tuples, and range objects

lists six types but says their are five.

----------
assignee: georg.brandl
components: Documentation
messages: 80076
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Inconsistent count of sequence types in Library stdtypes document
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 18 06:27:53 2009
From: report at bugs.python.org (Romeo Victor Dellarocco)
Date: Sun, 18 Jan 2009 05:27:53 +0000
Subject: [New-bugs-announce] [issue4985] Idle hangs when given a nonexistent
	filename.
In-Reply-To: <1232256473.01.0.852239057685.issue4985@psf.upfronthosting.co.za>
Message-ID: <1232256473.01.0.852239057685.issue4985@psf.upfronthosting.co.za>


New submission from Romeo Victor Dellarocco <della1rv at gmail.com>:

Idle hangs when given the name of a nonexistent file. The idle window
briefly appears, then disappears, the process hangs and has to be
terminated.

Platform:
  Linux 2.6.22-16-rt #1 SMP PREEMPT RT Mon Nov 24 21:03:25 GMT 2008 i686
GNU/Linux
  Ubuntu 7.10
  Python3.0 Final built from source.
  tk8.4
  I upgraded to tk8.5, idle still does the same thing.

To recreate type:
  rm foo.py
  idle foo.py
  # The idle window briefly appears, then disappears, the process hangs
  # and has to be terminated.

In previous versions of idle any nonexistent files would be created by
idle. This is what one would expect.

I have a patch for idlelib/PyShell.py that will make idle create any
nonexisting files.

----------
components: IDLE
files: idle_create_file_if_not_exist.python3_0.patch
keywords: patch
messages: 80079
nosy: della1rv
severity: normal
status: open
title: Idle hangs when given a nonexistent filename.
versions: Python 3.0
Added file: http://bugs.python.org/file12783/idle_create_file_if_not_exist.python3_0.patch

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

From report at bugs.python.org  Sun Jan 18 14:45:51 2009
From: report at bugs.python.org (andrew cooke)
Date: Sun, 18 Jan 2009 13:45:51 +0000
Subject: [New-bugs-announce] [issue4986] Augmented Assignment / Operations
	Confusion in Documentation
In-Reply-To: <1232286351.49.0.0947913998579.issue4986@psf.upfronthosting.co.za>
Message-ID: <1232286351.49.0.0947913998579.issue4986@psf.upfronthosting.co.za>


New submission from andrew cooke <andrew at acooke.org>:

There's a small confusion in terminology in the documentation related to
methods that implement augmented assignment.

The "Expressions" section of the language reference ("Simple
statements") refers to augmented assignment -
http://docs.python.org/3.0/reference/simple_stmts.html#augmented-assignment-statements
- and this seems to be a carefully chosen (and correct) phrase because
the parsing is related to assignments, which are augmented with various
operators.

It is important to note that augmented assignments ("+=" etc) are *not*
parsed as operators.  It is syntax error to use them in many places
where an operator would be accepted.

In the "Data Model" section, however, things are less clear
http://docs.python.org/3.0/reference/datamodel.html#emulating-numeric-types
.  The methods used to implement augmented assignment are grouped near
those used to implement arithmetic operators.  That seems natural.  But
the text confuses the two more than is strictly necessary.  In
particular there is the phrase "augmented arithmetic operations".

As I have already tried to make clear, these are not operations.  They
are augmented assignments.  Calling them operations is misleading,
because they cannot be used in the same places as "real" operations -
the parser simply will not accept them.

Apart from changing "augmented arithmetic operations" to "augmented
assignments" it might be worth adding some kind of note that explains to
the user that the parser calls those methods to implement assignment,
and that they are not valid in the same syntax as operations.

I am not sure the following will help, but it does illustrate the
confusion caused -
http://groups.google.com/group/comp.lang.python/browse_thread/thread/f1322928300b2b71

Cheers, Andrew

----------
assignee: georg.brandl
components: Documentation
messages: 80098
nosy: acooke, georg.brandl
severity: normal
status: open
title: Augmented Assignment / Operations Confusion in Documentation
versions: Python 3.0

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

From report at bugs.python.org  Sun Jan 18 16:18:23 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 18 Jan 2009 15:18:23 +0000
Subject: [New-bugs-announce] [issue4987] update distutils.README
In-Reply-To: <1232291903.8.0.000403573304081.issue4987@psf.upfronthosting.co.za>
Message-ID: <1232291903.8.0.000403573304081.issue4987@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

This file is out of date (6 years old), let's update it

http://www.python.org/community/sigs/current/distutils-sig/ needs to be
revamped too.

----------
assignee: tarek
components: Distutils, Documentation
messages: 80106
nosy: tarek
severity: normal
status: open
title: update distutils.README
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Jan 18 17:39:29 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 18 Jan 2009 16:39:29 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue4988=5D_A_link_to_=22What?=
	=?utf-8?q?=E2=80=99s_New_in_Python_2=2E0=22_on_=22The_Python_Tutor?=
	=?utf-8?q?ial=22_release_2=2E6?=
In-Reply-To: <1232296769.88.0.210431601252.issue4988@psf.upfronthosting.co.za>
Message-ID: <1232296769.88.0.210431601252.issue4988@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

It might be not a bug, but I think it's weird to see
an ancient What's New link on the new Python tutorial page.
http://docs.python.org/tutorial/

----------
assignee: georg.brandl
components: Documentation
messages: 80109
nosy: akitada, georg.brandl
severity: normal
status: open
title: A link to "What?s New in Python 2.0" on "The Python Tutorial" release 2.6

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

From report at bugs.python.org  Sun Jan 18 20:36:52 2009
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Pasternak?=)
Date: Sun, 18 Jan 2009 19:36:52 +0000
Subject: [New-bugs-announce] [issue4989] 'calendar' module is crummy and
	should be removed
In-Reply-To: <1232307412.23.0.393188506109.issue4989@psf.upfronthosting.co.za>
Message-ID: <1232307412.23.0.393188506109.issue4989@psf.upfronthosting.co.za>


New submission from Micha? Pasternak <michal.dtz at gmail.com>:

I was looking for some library to handle calendar events. Something PIM-
style, something useful, that could check if, for example, 2 weekly 
repeated events that start on Monday morning and last until December 
conflict with each other.

Then I found 'calendar' module in the standard library.

My question: how this thing ever made it to the standard library?

Maybe it was useful back in the days, if somebody could not get BSD or 
GNU sources for cal(1) . Nowadays, even if it is able to print HTML 
calendars, lets face it - who will use that functionality? You can 
easily find HTML calendars with a lot of JavaScript support, that can be 
customised in a thousands of ways.

I suggest we delete this module completly.

----------
components: None
messages: 80115
nosy: dotz
severity: normal
status: open
title: 'calendar' module is crummy and should be removed
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 18 21:27:02 2009
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Sun, 18 Jan 2009 20:27:02 +0000
Subject: [New-bugs-announce] [issue4990]
	test_codeccallbacks.CodecCallbackTest.test_badhandlerresult
	is not testing anything
In-Reply-To: <1232310422.76.0.435302840888.issue4990@psf.upfronthosting.co.za>
Message-ID: <1232310422.76.0.435302840888.issue4990@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

the reason is that it of course raises TypeError, since number of args
is wrong.

----------
files: out.diff
keywords: patch
messages: 80121
nosy: fijal
severity: normal
status: open
title: test_codeccallbacks.CodecCallbackTest.test_badhandlerresult is not testing anything
Added file: http://bugs.python.org/file12786/out.diff

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

From report at bugs.python.org  Sun Jan 18 22:02:03 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 18 Jan 2009 21:02:03 +0000
Subject: [New-bugs-announce] [issue4991] os.fdopen doesn't raise on invalid
	file descriptors
In-Reply-To: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>
Message-ID: <1232312523.23.0.0634822781495.issue4991@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Since os.fdopen is now implemented with io.open, it doesn't use fdopen
and check for invalid file descriptors. This isn't a huge issue since
subsequent actions on the file will raise an error.

----------
components: Library (Lib)
messages: 80125
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: os.fdopen doesn't raise on invalid file descriptors
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 18 23:55:12 2009
From: report at bugs.python.org (Petr Viktorin)
Date: Sun, 18 Jan 2009 22:55:12 +0000
Subject: [New-bugs-announce] [issue4992] yield's documentation not updated
In-Reply-To: <1232319312.46.0.667626052793.issue4992@psf.upfronthosting.co.za>
Message-ID: <1232319312.46.0.667626052793.issue4992@psf.upfronthosting.co.za>


New submission from Petr Viktorin <encukou at gmail.com>:

In the yield statement documentation
(http://docs.python.org/3.0/reference/simple_stmts.html#the-yield-statement),
the old way of calling generators is used:

"The body of the generator function is executed by calling the
generator?s next() method repeatedly until it raises an exception."

This should be changed to something like:

"The body of the generator function is executed by calling the next()
function on the generator repeatedly until it raises an exception."

Or just replace next() with __next__(), and fix the next paragraph as well.

----------
assignee: georg.brandl
components: Documentation
messages: 80134
nosy: En-Cu-Kou, georg.brandl
severity: normal
status: open
title: yield's documentation not updated
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan 19 01:34:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jan 2009 00:34:42 +0000
Subject: [New-bugs-announce] [issue4993] Typo in importlib
In-Reply-To: <1232325282.91.0.864148022751.issue4993@psf.upfronthosting.co.za>
Message-ID: <1232325282.91.0.864148022751.issue4993@psf.upfronthosting.co.za>


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

In importlib/_bootstrap.py, line 435 reads:

        with closing(_fileio_FileIO(source_path, 'r')) as file:

which whould probably be:

        with closing(_fileio._FileIO(source_path, 'r')) as file:

----------
assignee: brett.cannon
messages: 80139
nosy: brett.cannon, pitrou
severity: normal
status: open
title: Typo in importlib
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jan 19 02:52:27 2009
From: report at bugs.python.org (simonbcn)
Date: Mon, 19 Jan 2009 01:52:27 +0000
Subject: [New-bugs-announce] [issue4994] subprocess (Popen) doesn't works
	properly
In-Reply-To: <1232329947.27.0.222828544087.issue4994@psf.upfronthosting.co.za>
Message-ID: <1232329947.27.0.222828544087.issue4994@psf.upfronthosting.co.za>


New submission from simonbcn <simonbcn at gmail.com>:

Python 2.5.2
Ubuntu 8.04.1 64 bits
**************************************************************
-- ATTEMPT 1 --

Python:

Popen(['mplayer','/tvixhd2/Pelis para montar/00049.m2ts','-msglevel
all=4','-vo null','-ao null','-vf cropdetect','-vid 4113','-frames 500'])

stdout & stderr:

Option vf cropdetect: unknown postfix  cropdetect
Supported postfixes are:
  vf-add
 Append the given list to the current list
  vf-pre
 Prepend the given list to the current list
  vf-del x,y,...
 Remove the given elements. Take the list element index (starting from 0).
 Negative index can be used (i.e. -1 is the last element)
  vf-clr
 Clear the current list.
Error analizando la opci?n en la l?nea de comandos: -msglevel all=4
MPlayer dev-SVN-r28340-4.2.4 (C) 2000-2009 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz (Family: 6, Model:
23, Stepping: 10)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compilado para CPU x86 con extensiones: MMX MMX2 SSE SSE2

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

In this first example, I get severals errors from ?python? and then
python executes mplayer without parameters ??

**************************************************************
-- ATTEMPT 2 --

Python:

Popen(args=['/tvixhd2/Pelis para montar/00049.m2ts','-msglevel
all=4','-vo null','-ao null','-vf cropdetect','-vid 4113','-frames
500'], executable='mplayer')

stdout & stderr:

Option vf cropdetect: unknown postfix  cropdetect
Supported postfixes are:
  vf-add
 Append the given list to the current list
  vf-pre
 Prepend the given list to the current list
  vf-del x,y,...
 Remove the given elements. Take the list element index (starting from 0).
 Negative index can be used (i.e. -1 is the last element)
  vf-clr
 Clear the current list.
Error analizando la opci?n en la l?nea de comandos: -msglevel all=4
MPlayer dev-SVN-r28340-4.2.4 (C) 2000-2009 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz (Family: 6, Model:
23, Stepping: 10)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compilado para CPU x86 con extensiones: MMX MMX2 SSE SSE2
---------------------------------------------------------

The same result

**************************************************************
-- ATTEMPT 3 --

Python:

Popen('mplayer /tvixhd2/Pelis para montar/00049.m2ts -msglevel all=4 -vo
null -ao null -vf cropdetect -vid 4113 -frames 500')

stdout & stderr:

Traceback (most recent call last):
  File ".../temp/eclipse-workspace/gConvM2TS/src/gConvM2TS.py", line
858, in <lambda>
    xml.signal_connect('on_btnCrop_pressed', lambda w:
calcularCrop(ficheroEntrada))
  File ".../temp/eclipse-workspace/gConvM2TS/src/gConvM2TS.py", line
810, in calcularCrop
    Popen('mplayer /tvixhd2/Pelis para montar/00049.m2ts -msglevel all=4
-vo null -ao null -vf cropdetect -vid 4113 -frames 500')
  File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
    errread, errwrite)
  File "/usr/lib/python2.5/subprocess.py", line 1147, in _execute_child
    raise child_exception
OSError: [Errno 2] No existe el fichero ? directorio
---------------------------------------------------------

The error is now: "No such file or directory", What!? I don't understand
nothing!

**************************************************************
-- ATTEMPT 4 --

Python:

Popen(args='/tvixhd2/Pelis para montar/00049.m2ts -msglevel all=4 -vo
null -ao null -vf cropdetect -vid 4113 -frames 500', executable='mplayer')

stdout & stderr:

MPlayer dev-SVN-r28340-4.2.4 (C) 2000-2009 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz (Family: 6, Model:
23, Stepping: 10)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compilado para CPU x86 con extensiones: MMX MMX2 SSE SSE2
---------------------------------------------------------

No error, but the command mplayer is executed without parameters, ??

This subprocess Module really works?

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

Python:

Popen(args='mplayer "/tvixhd2/Pelis para montar/00049.m2ts" -msglevel
all=4 -vo null -ao null -vf cropdetect -vid 4113 -frames 500', shell=True)

With "shell=True" it works but I don't want to execute it in this
manner, because thus Python creates two subprocess and it returns the
PID of the open shell but not of the real process of Mplayer.

----------
components: Library (Lib)
messages: 80141
nosy: simonbcn
severity: normal
status: open
title: subprocess (Popen) doesn't works properly
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Jan 19 03:12:55 2009
From: report at bugs.python.org (Muayyad Alsadi)
Date: Mon, 19 Jan 2009 02:12:55 +0000
Subject: [New-bugs-announce] [issue4995] sqlite3 module gives SQL logic
	error only in transactions
In-Reply-To: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>
Message-ID: <1232331175.8.0.107838460484.issue4995@psf.upfronthosting.co.za>


New submission from Muayyad Alsadi <alsadi at ojuba.org>:

when I use transactions I got errors I won't get with sqlite3 cli

[alsadi at pc1 ~]$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cn=sqlite3.connect(':memory:')
>>> c=cn.cursor()
>>> c.execute('BEGIN TRANSACTION')
<sqlite3.Cursor object at 0xb7efada0>
>>> c.execute('create temp table tmp_main (id integer, b text)')
<sqlite3.Cursor object at 0xb7efada0>
>>> c.execute('insert into tmp_main (id) values (10);')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
sqlite3.OperationalError: SQL logic error or missing database
>>> 


[alsadi at pc1 ~]$ sqlite3 ':memory:'
SQLite version 3.5.9
Enter ".help" for instructions
sqlite> BEGIN TRANSACTION;
sqlite> create temp table tmp_main (id integer, b text);
sqlite> insert into tmp_main (id) values (10);
sqlite> select * from tmp_main;
10|
sqlite> 

and if the transaction line removed I get no error

[alsadi at pc1 ~]$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cn=sqlite3.connect(':memory:')
>>> c=cn.cursor()
>>> c.execute('create temp table tmp_main (id integer, b text)')
<sqlite3.Cursor object at 0xb7ff6da0>
>>> c.execute('insert into tmp_main (id) values (10);')
<sqlite3.Cursor object at 0xb7ff6da0>
>>>

----------
components: Extension Modules
messages: 80143
nosy: alsadi
severity: normal
status: open
title: sqlite3 module gives SQL logic error only in transactions
versions: Python 2.5

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

From report at bugs.python.org  Mon Jan 19 11:09:56 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Mon, 19 Jan 2009 10:09:56 +0000
Subject: [New-bugs-announce] [issue4996] io.TextIOWrapper calls
	buffer.read1()
In-Reply-To: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>
Message-ID: <1232359796.19.0.280451086656.issue4996@psf.upfronthosting.co.za>


New submission from HiroakiKawai <kawai at apache.org>:

The documentation says io.TextIOWrapper wraps io.BufferedIOBase raw 
stream. In the code, io.TextIOWrapper.read(), 
io.TextIOWrapper._read_chunk() calls buffer.read1() which seems 
expecting buffer to be an instance of io.BufferedReader. I'm not sure 
which is correct right now.

----------
components: Library (Lib)
messages: 80152
nosy: kawai
severity: normal
status: open
title: io.TextIOWrapper calls buffer.read1()
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan 19 11:35:57 2009
From: report at bugs.python.org (HiroakiKawai)
Date: Mon, 19 Jan 2009 10:35:57 +0000
Subject: [New-bugs-announce] [issue4997] xml.sax.saxutils.XMLGenerator
	should write to io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>


New submission from HiroakiKawai <kawai at apache.org>:

xml.sax.saxutils.XMLGenerator._write tests the argument by 
isinstance(text, str), but this is problematic in Python 3.0. 
XMLGenerator accepts encoding and the produced file is encoded by that 
encoding, i.e., the XML is a binary sequence. So IMHO, the XMLGenerator 
constructor argument should be a subclass of io.RawIOBase.

----------
components: Library (Lib), XML
messages: 80155
nosy: kawai
severity: normal
status: open
title: xml.sax.saxutils.XMLGenerator should write to io.RawIOBase.
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan 19 13:41:22 2009
From: report at bugs.python.org (Somelauw)
Date: Mon, 19 Jan 2009 12:41:22 +0000
Subject: [New-bugs-announce] [issue4998] fractions are mutable
In-Reply-To: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>
Message-ID: <1232368882.79.0.616892747667.issue4998@psf.upfronthosting.co.za>


New submission from Somelauw <Somelauw at yahoo.com>:

>>> f = Fraction()
>>> f.a = 5
>>> f.__slots__
('_numerator', '_denominator')
>>> f.a
5
>>> f.__dict__
{}

When I create my own object, this doesn't happen.

>>> class Slots:
	__slots__ = ("slot1", "slot2")

	
>>> a = Slots()
>>> a.slot3 = 6
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    a.slot3 = 6
AttributeError: 'Slots' object has no attribute 'slot3'
>>> 

In python2 this only happens when __slots__ is a tuple. (When __slots__ 
is a list, it works correctly)
>>> class Slots:
	__slots__ = ("slot1", "slot2")

	
>>> a = Slots()
>>> a.slot3 = 8
>>> 

Here is a copy-paste from the python3 documentation:
Without a __dict__ variable, instances cannot be assigned new variables 
not listed in the __slots__ definition. Attempts to assign to an 
unlisted variable name raises AttributeError. If dynamic assignment of 
new variables is desired, then add '__dict__' to the sequence of strings 
in the __slots__ declaration.

Any non-string iterable may be assigned to __slots__. Mappings may also 
be used; however, in the future, special meaning may be assigned to the 
values corresponding to each key.

----------
components: Library (Lib)
messages: 80161
nosy: Somelauw
severity: normal
status: open
title: fractions are mutable
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan 19 13:57:25 2009
From: report at bugs.python.org (=?utf-8?q?Fr=C3=A9d=C3=A9ric_Sagnes?=)
Date: Mon, 19 Jan 2009 12:57:25 +0000
Subject: [New-bugs-announce] [issue4999] multiprocessing.Queue does not
	order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>


New submission from Fr?d?ric Sagnes <speedup+python at gmail.com>:

Objects contained in a multiprocessing.Queue object are not comming out
of the queue in the same order as they went in. For instance, if I put
in object1, object2 and object3 in this very time sequence from multiple
processes, they can end up comming out of the queue as object2, object1
then object3 instead of the original order.

When using the threading module instead of multiprocessing everything is
fine.

The provided test script adds strings to the queue with timestamps.
These messages are not ordered by timestamp when they are printed. This
is an output of the test script with format "[pid at time] message":

[2120 at 00406] Got lock
[2120 at 02424] Released lock
[2121 at 02426] Got lock
[2121 at 04439] Released lock
[...]
[2121 at 16459] Released lock
[2120 at 16461] Got lock
[2121 at 18464] Got lock
[2120 at 18462] Released lock
[2121 at 20466] Released lock

Using print to print the message immediatly prints the messages in the
right order.

See this mailing-list thread for details:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/11a5c4ce4ff4382d/033dcd3607eacbf9

----------
components: Extension Modules
files: testthreads.py
messages: 80162
nosy: ndfred
severity: normal
status: open
title: multiprocessing.Queue does not order objects
versions: Python 2.6
Added file: http://bugs.python.org/file12793/testthreads.py

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

From report at bugs.python.org  Mon Jan 19 14:50:52 2009
From: report at bugs.python.org (0x666)
Date: Mon, 19 Jan 2009 13:50:52 +0000
Subject: [New-bugs-announce] [issue5000] multiprocessing - Pool.map() slower
	about 5 times than map() on 2 cores machine
In-Reply-To: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>
Message-ID: <1232373052.48.0.519652663771.issue5000@psf.upfronthosting.co.za>


New submission from 0x666 <vasiliauskas.agnius at gmail.com>:

I think something wrong with implementation of multiprocessing module.
I`ve run this very simple test on my machine (core 2, vista):
import multiprocessing as mul
from time import time

def f(x):
    return x*x

if __name__ == '__main__':
    print "-------- testing multiprocessing on ",mul.cpu_count(),"cores
----------"
    print ""

    elements = 100000

    pool = mul.Pool(processes=mul.cpu_count())
    t1 = time()
    res_par = pool.map(f, range(elements))
    t2 = time()
    res_seq = map(f, range(elements))
    t3 = time()
    res_app = [pool.apply_async(f,(x,)) for x in range(elements)]
    res_app = [result.get() for result in res_app]
    t4 = time()

    print len(res_seq),"elements","map() time",(t3-t2),"s"
    print len(res_par),"elements","pool.map() time",(t2-t1),"s"
    print len(res_app),"elements","pool.apply_async() time", (t4-t3),"s"
    
    print
    raw_input("press enter to exit...")
__________________________________________
Results:
-------- testing multiprocessing on  2 cores -----------

100000 elements map() time 0.0269 s
100000 elements pool.map() time 0.108 s
100000 elements pool.apply_async() time 10.567 s
--------------------------------------------------------

IMHO, execution on 2 cores should be 1.x - 2 times faster than compared
with non-parallel execution. (at least in simple cases).
If you dont believe in this, check http://www.parallelpython.com/
module (demo example sum_primes.py), which fits very well this idea.

So how it can be that parallel pool.map() method executes in about 5
times SLOWER, than ordinary map() function ?
So please correct multiprocessing package to work in more-less
perfomance predictable way (like parallelpython).

----------
components: Library (Lib)
messages: 80168
nosy: 0x666
severity: normal
status: open
title: multiprocessing - Pool.map() slower about 5 times than map() on 2 cores machine
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 19 17:32:42 2009
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 19 Jan 2009 16:32:42 +0000
Subject: [New-bugs-announce] [issue5001] Remove assertion-based checking in
	multiprocessing
In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>
Message-ID: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>


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

Right now, the multiprocessing code is littered with statements like:

        assert self._popen is None, 'cannot start a process twice'
        assert self._parent_pid == os.getpid(), \
               'can only start a process object created by current 
process'
        assert not _current_process._daemonic, \
               'daemonic processes are not allowed to have children'

These will obviously be stripped out if running in optimized mode - 
however its not cool to rely on these anyway, the code should be 
refactored to proper checks, e.g.:

    if not hasattr(lock, 'acquire'):
        raise AttributeError("'%r' has no method 'acquire'" % lock)

----------
assignee: jnoller
components: Library (Lib)
messages: 80192
nosy: jnoller
priority: normal
severity: normal
status: open
title: Remove assertion-based checking in multiprocessing
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Jan 19 20:14:43 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 19 Jan 2009 19:14:43 +0000
Subject: [New-bugs-announce] [issue5002] multiprocessing/pipe_connection.c
	compiler warning (conn_poll)
In-Reply-To: <1232392483.91.0.505084549833.issue5002@psf.upfronthosting.co.za>
Message-ID: <1232392483.91.0.505084549833.issue5002@psf.upfronthosting.co.za>


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

I got compiler warning "conn_poll takes too many arguments".
I hope the attached patch is right fix.

----------
components: Library (Lib)
files: pipe_connection_c.patch
keywords: patch
messages: 80204
nosy: ocean-city
severity: normal
status: open
title: multiprocessing/pipe_connection.c compiler warning (conn_poll)
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file12800/pipe_connection_c.patch

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

From report at bugs.python.org  Mon Jan 19 21:26:33 2009
From: report at bugs.python.org (Sravani Gogineni)
Date: Mon, 19 Jan 2009 20:26:33 +0000
Subject: [New-bugs-announce] [issue5003] Error while installing Python-3
In-Reply-To: <1232396793.72.0.127068504094.issue5003@psf.upfronthosting.co.za>
Message-ID: <1232396793.72.0.127068504094.issue5003@psf.upfronthosting.co.za>


New submission from Sravani Gogineni <goginenis at corning.com>:

i was trying to install python 3 using the folowing command 
$ python setup.py --home=~/python3

and i got the below error:

  File "setup.py", line 232
    except (CCompilerError, DistutilsError) as why:
                                             ^
SyntaxError: invalid syntax

Could anyone please help me with the problem?

Thanks,
Vani

----------
components: Installation
messages: 80207
nosy: goginenis at corning.com
severity: normal
status: open
title: Error while installing Python-3
versions: Python 3.0

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

From report at bugs.python.org  Mon Jan 19 23:29:02 2009
From: report at bugs.python.org (Daniel Frnake)
Date: Mon, 19 Jan 2009 22:29:02 +0000
Subject: [New-bugs-announce] [issue5004] socket.getfqdn() doesn't cope
	properly with purely DNS-based setups
In-Reply-To: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za>
Message-ID: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za>


New submission from Daniel Frnake <dfranke at wellohorld.com>:

On Linux and presumably on other POSIX-like systems, socket.getfqdn()
doesn't work if a system resolves its own FQDN using DNS rather than
/etc/hosts.

My system's FQDN is 'fugue.tank.wellohorld.com'.  My /etc/hosts is empty
except for loopback entries, and /etc/resolv.conf contains the line
'domain tank.wellohorld.com'.  This is sufficient for 'hostname -f' to
do the Right Thing, but socket.getfqdn() simply returns 'fugue':

dfranke at fugue:~/Python-2.6.1$ hostname
fugue
dfranke at fugue:~/Python-2.6.1$ hostname -f
fugue.tank.wellohorld.com
dfranke at fugue:~/Python-2.6.1$ ./python
Python 2.6.1 (r261:67515, Jan 19 2009, 13:56:59)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn()
'fugue'
>>>
dfranke at fugue:~/Python-2.6.1$ echo -e '$a\n172.17.0.120
fugue.tank.wellohorld.com fugue\n.\nwq' | sudo ed /etc/hosts
305
350
dfranke at fugue:~/Python-2.6.1$ ./python
Python 2.6.1 (r261:67515, Jan 19 2009, 13:56:59)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn()
'fugue.tank.wellohorld.com'
>>>
dfranke at fugue:~/Python-2.6.1$

----------
components: Library (Lib)
messages: 80216
nosy: dfranke
severity: normal
status: open
title: socket.getfqdn() doesn't cope properly with purely DNS-based setups
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 20 00:15:10 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Jan 2009 23:15:10 +0000
Subject: [New-bugs-announce] [issue5005] 3.0 sqlite doc: most refers to
	pysqlite2, use 2.x syntax.
In-Reply-To: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>
Message-ID: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

1. Several examples start with
>>> from pysqlite2 import dbapi2 as sqlite3

Traceback (most recent call last):
  File "<pyshell#23>", line 1, in <module>
    from pysqlite2 import dbapi2 as sqlite3
ImportError: No module named pysqlite2

I presume that should be just 'import sqlite3'.

2. Print statements need conversion and future import deleted (2to3?).

3. Cut and paste crashes due to 'bad' blank line.  For instance,
# A minimal SQLite shell for experiments
...
>>> while True:
...     line = raw_input()
...     if line == "":
...         break
...     buffer += line
...     if sqlite3.complete_statement(buffer):
...         try:
...             buffer = buffer.strip()
...             cur.execute(buffer)
...
  File "<stdin>", line 10

    ^
IndentationError: unexpected unindent
>>>             if buffer.lstrip().upper().startswith("SELECT"):
  File "<stdin>", line 1
    if buffer.lstrip().upper().startswith("SELECT"):
    ^
IndentationError: unexpected indent

----------
messages: 80218
nosy: tjreedy
severity: normal
status: open
title: 3.0 sqlite doc: most refers to pysqlite2, use 2.x syntax.

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

From report at bugs.python.org  Tue Jan 20 00:24:35 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Jan 2009 23:24:35 +0000
Subject: [New-bugs-announce] [issue5006] Duplicate UTF-16 BOM if a file is
	open in append mode
In-Reply-To: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>
Message-ID: <1232407475.88.0.821271875363.issue5006@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Copy/paste of message79330 from the issue #4862:
--------------
>>> f = open('utf16.txt', 'w', encoding='utf-16')
>>> f.write('abc')
3
>>> f.close()

>>> f = open('utf16.txt', 'a', encoding='utf-16')
>>> f.write('def')
3
>>> f.close()
>>> open('utf16.txt', 'r', encoding='utf-16').read()
'abc\ufeffdef'
--------------

----------
messages: 80221
nosy: haypo
severity: normal
status: open
title: Duplicate UTF-16 BOM if a file is open in append mode
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jan 20 00:45:10 2009
From: report at bugs.python.org (ak)
Date: Mon, 19 Jan 2009 23:45:10 +0000
Subject: [New-bugs-announce] [issue5007] urllib2 HTTPS connection failure
	(BadStatusLine Exception)
In-Reply-To: <1232408710.01.0.641128080754.issue5007@psf.upfronthosting.co.za>
Message-ID: <1232408710.01.0.641128080754.issue5007@psf.upfronthosting.co.za>


New submission from ak <aktests at gmail.com>:

https://www.orange.sk/ is served by an Oracle HTTPS server, and works
with firefox or opera but not urllib2.

code snippet:

--------
import cookiejar
import urllib2

cookiejar = cookielib.LWPCookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
url = 'https://www.orange.sk/'
req = urllib2.Request(url, None)
s=opener.open(req)
-------- 

Here's some output with debuglevel=1 :

>>> opener.open(urllib2.Request('http://www.orange.sk/', None, headers))

reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Mon, 19 Jan 2009 21:44:03 GMT
header: Server: Oracle-Application-Server-10g/10.1.3.1.0 Oracle-HTTP-
Server
header: Set-Cookie:
JSESSIONID=0a19055a30d630c427bda71d4e26a37ca604b9f590dc.e3eNaNiRah4Pe3aSch8Sc3yOc40;
path=/web
header: Expires: Mon, 19 Jan 2009 21:44:13 GMT
header: Surrogate-Control: max-age="10"
header: Content-Type: text/html; charset=ISO-8859-2
header: X-Cache: MISS from www.orange.sk
header: Connection: close
header: Transfer-Encoding: chunked
<addinfourl at 137417292 whose fp = <socket._fileobject object at
0x831348c>>

>>> opener.open(urllib2.Request('https://www.orange.sk/', None, headers))

reply: ''
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/urllib2.py", line 381, in open
    response = self._open(req, data)
  File "/usr/lib/python2.5/urllib2.py", line 399, in _open
    '_open', req)
  File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.5/urllib2.py", line 1115, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.5/urllib2.py", line 1080, in do_open
    r = h.getresponse()
  File "/usr/lib/python2.5/httplib.py", line 928, in getresponse
    response.begin()
  File "/usr/lib/python2.5/httplib.py", line 385, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.5/httplib.py", line 349, in _read_status
    raise BadStatusLine(line)
httplib.BadStatusLine 

As you can see the reply from the server seems empty (which results in
the BadStatusLine exception)

----------
components: Library (Lib)
messages: 80224
nosy: ak
severity: normal
status: open
title: urllib2 HTTPS connection failure (BadStatusLine Exception)
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jan 20 01:49:30 2009
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Jan 2009 00:49:30 +0000
Subject: [New-bugs-announce] [issue5008] Wrong tell() result for a file
	opened in append mode
In-Reply-To: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>
Message-ID: <1232412570.35.0.0224734536413.issue5008@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code must display 3 instead of 0:
---
with open("x", "w") as f:
    f.write("xxx")
with open("x", "a") as f:
    print(f.tell())
---

The example works with Python 2.x, because file object is implemented 
using the FILE structure (fopen, ftell, etc.). fopen() "fixes" the 
offset if the file is opened in append mode, whereas open() doesn't do 
this for us :
---
import os
with open("x", "w") as f:
    f.write("xxx")
fd = os.open("x", os.O_RDONLY | os.O_APPEND)
print(os.lseek(fd, 0, 1))
---
display 0 instead of 3 on Python 2.x and 3.x.

It becomes a little bit more weird when you write something :-)
---
with open("x", "w") as f:
    f.write("xxx")
with open("x", "a") as f:
    f.write("y")
    print(f.tell())
---
displays... 4 (the correct position) on Python 2.x and 3.x.

I see (in GNU libc source code) that fopen() call lseek(fd, 0, 
SEEK_END) if the file is opened in append mode.

----------
messages: 80230
nosy: haypo
severity: normal
status: open
title: Wrong tell() result for a file opened in append mode
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jan 20 10:22:52 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 20 Jan 2009 09:22:52 +0000
Subject: [New-bugs-announce] [issue5009] multiprocessing: failure in
	manager._debug_info()
In-Reply-To: <1232443372.05.0.683507657371.issue5009@psf.upfronthosting.co.za>
Message-ID: <1232443372.05.0.683507657371.issue5009@psf.upfronthosting.co.za>


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

http://mail.python.org/pipermail/python-checkins/2009-January/077474.html
probably indicates some other error in the manager's shared objects, but
the debug_info() function fails to display anything.

It seems that most keys in id_to_obj are strings ('%x' % id(obj)) except
the first one which is zero. And since python 3, you cannot compare 0
and '1' anymore...

Patch attached. I'm not sure whether this zero is used elsewhere...
and BTW, what is it useful for?

----------
assignee: jnoller
files: mp_zeroid.patch
keywords: needs review, patch
messages: 80239
nosy: amaury.forgeotdarc, jnoller
severity: normal
status: open
title: multiprocessing: failure in manager._debug_info()
versions: Python 3.0
Added file: http://bugs.python.org/file12809/mp_zeroid.patch

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

From report at bugs.python.org  Tue Jan 20 12:12:18 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Tue, 20 Jan 2009 11:12:18 +0000
Subject: [New-bugs-announce] [issue5010] repoened "test_maxint64 fails on
	32-bit systems due to assumption that 64-bit fits into
	"long"" due to it being closed without asking me whether
	there was anything else involved
In-Reply-To: <1232449938.32.0.409064545439.issue5010@psf.upfronthosting.co.za>
Message-ID: <1232449938.32.0.409064545439.issue5010@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this is reopening http://bugs.python.org/issue4977 because it was closed
without asking whether there was any further information or anything
else that required investigation.

there is no way for me to reopen the bug so i am forced to open a
new one.

mark - don't do that again, please.

the suggestion to use PyOS_strtol was a good one: you should have
left the bug as-is after that suggestion, and WAITED until i had
tested that.

the bug involves 64-bit zip files.

the fact that a 32-bit int is being returned, as -4932893211 (whatever)
instead of 44951 (whatever) is causing the problem.

so will you be kind enough and courteous enough to wait until
i have provided full information and investigated this issue?

or do you not want me to bother?

----------
components: Build
messages: 80241
nosy: lkcl, marketdickinson
severity: normal
status: open
title: repoened "test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into "long"" due to it being closed without asking me whether there was anything else involved
versions: Python 2.5

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

From report at bugs.python.org  Tue Jan 20 12:12:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 11:12:51 +0000
Subject: [New-bugs-announce] [issue5011] issue4428 - make io.BufferedWriter
	observe max_buffer_size limits
In-Reply-To: <0016e644ddec7c678f0460e81ef8@google.com>
Message-ID: <0016e644ddec7c678f0460e81ef8@google.com>


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

http://codereview.appspot.com/12470/diff/1/2
File Lib/io.py (right):

http://codereview.appspot.com/12470/diff/1/2#newcode1055
Line 1055: # b is an iterable of ints, it won't always support len().
There is no reason for write() to accept arbitrary iterable of ints,
only bytes-like and buffer-like objects. It will make the code simpler.

http://codereview.appspot.com/12470/diff/1/2#newcode1060
Line 1060: # No buffer API?  Make intermediate slice copies instead.
Objects without the buffer API shouldn't be supported at all.

http://codereview.appspot.com/12470/diff/1/2#newcode1066
Line 1066: while chunk and len(self._write_buf) > self.buffer_size:
What if buffer_size == max_buffer_size? Is everything still written ok?

http://codereview.appspot.com/12470/diff/1/2#newcode1070
Line 1070: written += e.characters_written
e.characters_written can include bytes which were already part of the
buffer before write() was called, but the newly raised BlockingIOError
should only count those bytes which were part of the object passed to
write().

http://codereview.appspot.com/12470/diff/1/3
File Lib/test/test_io.py (right):

http://codereview.appspot.com/12470/diff/1/3#newcode496
Line 496: def testWriteNoLengthIterable(self):
This shouldn't work at all. If it works right now, it is only a
side-effect of the implementation.
(it won't work with FileIO, for example)

http://codereview.appspot.com/12470

----------
messages: 80242
nosy: gregory.p.smith, pitrou
severity: normal
status: open
title: issue4428 - make io.BufferedWriter observe max_buffer_size limits

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

From report at bugs.python.org  Tue Jan 20 16:18:59 2009
From: report at bugs.python.org (Sravani Gogineni)
Date: Tue, 20 Jan 2009 15:18:59 +0000
Subject: [New-bugs-announce] [issue5012] How to test python 3 was installed
	properly in my directory?
In-Reply-To: <1232464739.45.0.206650125051.issue5012@psf.upfronthosting.co.za>
Message-ID: <1232464739.45.0.206650125051.issue5012@psf.upfronthosting.co.za>


New submission from Sravani Gogineni <goginenis at corning.com>:

Hello,

I am a beginner and i installed python 3 in my Home directory. i want 
to test that the installation was done properly. is their a test suite 
to see the installation was good? Could anyone please help me with the 
problem? Also could i have both gcc and icc as compilers in python 3? 
if yes how do i use them in python3?

Thanks,
Vani

----------
components: Tests
messages: 80256
nosy: vani
severity: normal
status: open
title: How to test python 3 was installed properly in my directory?
versions: Python 3.0

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

From report at bugs.python.org  Tue Jan 20 17:21:22 2009
From: report at bugs.python.org (Fons Dijkstra)
Date: Tue, 20 Jan 2009 16:21:22 +0000
Subject: [New-bugs-announce] [issue5013] Problems with delay parm of
	logging.handlers.RotatingFileHandler
In-Reply-To: <1232468482.31.0.912117314029.issue5013@psf.upfronthosting.co.za>
Message-ID: <1232468482.31.0.912117314029.issue5013@psf.upfronthosting.co.za>


New submission from Fons Dijkstra <fdij at xs4all.nl>:

When you set the delay parameter of the 
logging.handlers.RotatingFileHandler.__init__() function to True, two 
things go wrong:

1) A previously set formatter is reset (to None) upon lazy creating the 
StreamHandler. That means in practice that you always will have the 
default formatter which just formats the message.

2) Upon a roll-over, the delay parm does not seem to be used anymore as, 
even if there are no records to log, the new current logfile is always 
created.

----------
components: Library (Lib)
messages: 80258
nosy: pycurry
severity: normal
status: open
title: Problems with delay parm of logging.handlers.RotatingFileHandler
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 20 18:52:33 2009
From: report at bugs.python.org (pb)
Date: Tue, 20 Jan 2009 17:52:33 +0000
Subject: [New-bugs-announce] [issue5014] Kernel Protection Failure
In-Reply-To: <1232473953.43.0.830370266834.issue5014@psf.upfronthosting.co.za>
Message-ID: <1232473953.43.0.830370266834.issue5014@psf.upfronthosting.co.za>


New submission from pb <peterbraden at peterbraden.co.uk>:

No idea if it's been fixed or not - I'm using the stock OS X build of
python, but I get a repeatable Kernel Protection Failure using the
prealpha django build with MySQL.

I suspect the bug lies in the mysql library, but lack any knowledge of
the domain. 


OS X Traceback follows:
Process:         Python [3213]
Path:           
/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  Python [3212]

Date/Time:       2009-01-20 17:45:04.277 +0000
OS Version:      Mac OS X 10.5.6 (9G55)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000b0000ffc
Crashed Thread:  1

Thread 0:
0   libSystem.B.dylib             	0x901b36f2 select$DARWIN_EXTSN + 10
1   org.python.python             	0x0018d806 PyEval_EvalFrameEx + 17116
2   org.python.python             	0x0018d9e8 PyEval_EvalFrameEx + 17598
3   org.python.python             	0x0018d9e8 PyEval_EvalFrameEx + 17598
4   org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
5   org.python.python             	0x0018da85 PyEval_EvalFrameEx + 17755
6   org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
7   org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
8   org.python.python             	0x0011fd3d PyObject_Call + 50
9   org.python.python             	0x0018dfb8 PyEval_EvalFrameEx + 19086
10  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
11  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
12  org.python.python             	0x0011fd3d PyObject_Call + 50
13  org.python.python             	0x0018dfb8 PyEval_EvalFrameEx + 19086
14  org.python.python             	0x0018d9e8 PyEval_EvalFrameEx + 17598
15  org.python.python             	0x0018d9e8 PyEval_EvalFrameEx + 17598
16  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
17  org.python.python             	0x0018da85 PyEval_EvalFrameEx + 17755
18  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
19  org.python.python             	0x0018f548 PyEval_EvalCode + 87
20  org.python.python             	0x001a69ec PyErr_Display + 1896
21  org.python.python             	0x001a7016 PyRun_FileExFlags + 135
22  org.python.python             	0x001a8982 PyRun_SimpleFileExFlags + 421
23  org.python.python             	0x001b3c03 Py_Main + 3095
24  org.python.pythonapp          	0x00001fca 0x1000 + 4042

Thread 1 Crashed:
0   org.python.python             	0x0014d2b1 PyObject_Malloc + 12
1   org.python.python             	0x001b50d7 _PyObject_GC_Malloc + 32
2   org.python.python             	0x001b5195 _PyObject_GC_NewVar + 41
3   org.python.python             	0x001387d2 PyFrame_New + 461
4   org.python.python             	0x0018eeba PyEval_EvalCodeEx + 197
5   org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
6   org.python.python             	0x0011fd3d PyObject_Call + 50
7   org.python.python             	0x0011fe0c PyObject_Call + 257
8   org.python.python             	0x0011fe7b PyObject_CallFunction + 74
9   org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
10  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
11  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
12  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
13  org.python.python             	0x0011fd3d PyObject_Call + 50
14  org.python.python             	0x0011fe0c PyObject_Call + 257
15  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
16  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
17  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
18  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
19  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
20  org.python.python             	0x0011fd3d PyObject_Call + 50
21  org.python.python             	0x0011fe0c PyObject_Call + 257
22  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
23  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
24  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
25  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
26  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
27  org.python.python             	0x0011fd3d PyObject_Call + 50
28  org.python.python             	0x0011fe0c PyObject_Call + 257
29  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
30  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
31  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
32  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
33  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
34  org.python.python             	0x0011fd3d PyObject_Call + 50
35  org.python.python             	0x0011fe0c PyObject_Call + 257
36  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
37  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
38  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
39  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
40  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
41  org.python.python             	0x0011fd3d PyObject_Call + 50
42  org.python.python             	0x0011fe0c PyObject_Call + 257
43  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
44  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
45  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
46  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
47  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
48  org.python.python             	0x0011fd3d PyObject_Call + 50
49  org.python.python             	0x0011fe0c PyObject_Call + 257
50  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
51  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
52  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
53  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
54  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
55  org.python.python             	0x0011fd3d PyObject_Call + 50
56  org.python.python             	0x0011fe0c PyObject_Call + 257
57  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
58  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
59  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
60  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
61  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
62  org.python.python             	0x0011fd3d PyObject_Call + 50
63  org.python.python             	0x0011fe0c PyObject_Call + 257
64  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
65  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
66  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
67  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
68  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
69  org.python.python             	0x0011fd3d PyObject_Call + 50
70  org.python.python             	0x0011fe0c PyObject_Call + 257
71  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
72  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
73  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
74  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
75  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
76  org.python.python             	0x0011fd3d PyObject_Call + 50
77  org.python.python             	0x0011fe0c PyObject_Call + 257
78  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
79  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
80  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
81  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
82  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
83  org.python.python             	0x0011fd3d PyObject_Call + 50
84  org.python.python             	0x0011fe0c PyObject_Call + 257
85  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
86  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
87  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
88  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
89  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
90  org.python.python             	0x0011fd3d PyObject_Call + 50
91  org.python.python             	0x0011fe0c PyObject_Call + 257
92  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
93  org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
94  org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
95  org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
96  org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
97  org.python.python             	0x0011fd3d PyObject_Call + 50
98  org.python.python             	0x0011fe0c PyObject_Call + 257
99  org.python.python             	0x0011fe7b PyObject_CallFunction + 74
100 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
101 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
102 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
103 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
104 org.python.python             	0x0011fd3d PyObject_Call + 50
105 org.python.python             	0x0011fe0c PyObject_Call + 257
106 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
107 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
108 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
109 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
110 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
111 org.python.python             	0x0011fd3d PyObject_Call + 50
112 org.python.python             	0x0011fe0c PyObject_Call + 257
113 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
114 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
115 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
116 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
117 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
118 org.python.python             	0x0011fd3d PyObject_Call + 50
119 org.python.python             	0x0011fe0c PyObject_Call + 257
120 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
121 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
122 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
123 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
124 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
125 org.python.python             	0x0011fd3d PyObject_Call + 50
126 org.python.python             	0x0011fe0c PyObject_Call + 257
127 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
128 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
129 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
130 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
131 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
132 org.python.python             	0x0011fd3d PyObject_Call + 50
133 org.python.python             	0x0011fe0c PyObject_Call + 257
134 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
135 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
136 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
137 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
138 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
139 org.python.python             	0x0011fd3d PyObject_Call + 50
140 org.python.python             	0x0011fe0c PyObject_Call + 257
141 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
142 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
143 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
144 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
145 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
146 org.python.python             	0x0011fd3d PyObject_Call + 50
147 org.python.python             	0x0011fe0c PyObject_Call + 257
148 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
149 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
150 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
151 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
152 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
153 org.python.python             	0x0011fd3d PyObject_Call + 50
154 org.python.python             	0x0011fe0c PyObject_Call + 257
155 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
156 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
157 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
158 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
159 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
160 org.python.python             	0x0011fd3d PyObject_Call + 50
161 org.python.python             	0x0011fe0c PyObject_Call + 257
162 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
163 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
164 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
165 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
166 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
167 org.python.python             	0x0011fd3d PyObject_Call + 50
168 org.python.python             	0x0011fe0c PyObject_Call + 257
169 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
170 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
171 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
172 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
173 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
174 org.python.python             	0x0011fd3d PyObject_Call + 50
175 org.python.python             	0x0011fe0c PyObject_Call + 257
176 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
177 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
178 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
179 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
180 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
181 org.python.python             	0x0011fd3d PyObject_Call + 50
182 org.python.python             	0x0011fe0c PyObject_Call + 257
183 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
184 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
185 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
186 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
187 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
188 org.python.python             	0x0011fd3d PyObject_Call + 50
189 org.python.python             	0x0011fe0c PyObject_Call + 257
190 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
191 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
192 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
193 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
194 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
195 org.python.python             	0x0011fd3d PyObject_Call + 50
196 org.python.python             	0x0011fe0c PyObject_Call + 257
197 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
198 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
199 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
200 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
201 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
202 org.python.python             	0x0011fd3d PyObject_Call + 50
203 org.python.python             	0x0011fe0c PyObject_Call + 257
204 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
205 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
206 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
207 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
208 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
209 org.python.python             	0x0011fd3d PyObject_Call + 50
210 org.python.python             	0x0011fe0c PyObject_Call + 257
211 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
212 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
213 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
214 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
215 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
216 org.python.python             	0x0011fd3d PyObject_Call + 50
217 org.python.python             	0x0011fe0c PyObject_Call + 257
218 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
219 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
220 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
221 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
222 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
223 org.python.python             	0x0011fd3d PyObject_Call + 50
224 org.python.python             	0x0011fe0c PyObject_Call + 257
225 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
226 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
227 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
228 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
229 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
230 org.python.python             	0x0011fd3d PyObject_Call + 50
231 org.python.python             	0x0011fe0c PyObject_Call + 257
232 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
233 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
234 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
235 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
236 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
237 org.python.python             	0x0011fd3d PyObject_Call + 50
238 org.python.python             	0x0011fe0c PyObject_Call + 257
239 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
240 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
241 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
242 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
243 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
244 org.python.python             	0x0011fd3d PyObject_Call + 50
245 org.python.python             	0x0011fe0c PyObject_Call + 257
246 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
247 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
248 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
249 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
250 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
251 org.python.python             	0x0011fd3d PyObject_Call + 50
252 org.python.python             	0x0011fe0c PyObject_Call + 257
253 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
254 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
255 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
256 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
257 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
258 org.python.python             	0x0011fd3d PyObject_Call + 50
259 org.python.python             	0x0011fe0c PyObject_Call + 257
260 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
261 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
262 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
263 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
264 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
265 org.python.python             	0x0011fd3d PyObject_Call + 50
266 org.python.python             	0x0011fe0c PyObject_Call + 257
267 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
268 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
269 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
270 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
271 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
272 org.python.python             	0x0011fd3d PyObject_Call + 50
273 org.python.python             	0x0011fe0c PyObject_Call + 257
274 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
275 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
276 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
277 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
278 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
279 org.python.python             	0x0011fd3d PyObject_Call + 50
280 org.python.python             	0x0011fe0c PyObject_Call + 257
281 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
282 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
283 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
284 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
285 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
286 org.python.python             	0x0011fd3d PyObject_Call + 50
287 org.python.python             	0x0011fe0c PyObject_Call + 257
288 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
289 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
290 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
291 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
292 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
293 org.python.python             	0x0011fd3d PyObject_Call + 50
294 org.python.python             	0x0011fe0c PyObject_Call + 257
295 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
296 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
297 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
298 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
299 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
300 org.python.python             	0x0011fd3d PyObject_Call + 50
301 org.python.python             	0x0011fe0c PyObject_Call + 257
302 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
303 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
304 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
305 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
306 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
307 org.python.python             	0x0011fd3d PyObject_Call + 50
308 org.python.python             	0x0011fe0c PyObject_Call + 257
309 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
310 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
311 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
312 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
313 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
314 org.python.python             	0x0011fd3d PyObject_Call + 50
315 org.python.python             	0x0011fe0c PyObject_Call + 257
316 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
317 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
318 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
319 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
320 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
321 org.python.python             	0x0011fd3d PyObject_Call + 50
322 org.python.python             	0x0011fe0c PyObject_Call + 257
323 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
324 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
325 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
326 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
327 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
328 org.python.python             	0x0011fd3d PyObject_Call + 50
329 org.python.python             	0x0011fe0c PyObject_Call + 257
330 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
331 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
332 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
333 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
334 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
335 org.python.python             	0x0011fd3d PyObject_Call + 50
336 org.python.python             	0x0011fe0c PyObject_Call + 257
337 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
338 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
339 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
340 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
341 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
342 org.python.python             	0x0011fd3d PyObject_Call + 50
343 org.python.python             	0x0011fe0c PyObject_Call + 257
344 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
345 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
346 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
347 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
348 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
349 org.python.python             	0x0011fd3d PyObject_Call + 50
350 org.python.python             	0x0011fe0c PyObject_Call + 257
351 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
352 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
353 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
354 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
355 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
356 org.python.python             	0x0011fd3d PyObject_Call + 50
357 org.python.python             	0x0011fe0c PyObject_Call + 257
358 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
359 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
360 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
361 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
362 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
363 org.python.python             	0x0011fd3d PyObject_Call + 50
364 org.python.python             	0x0011fe0c PyObject_Call + 257
365 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
366 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
367 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
368 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
369 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
370 org.python.python             	0x0011fd3d PyObject_Call + 50
371 org.python.python             	0x0011fe0c PyObject_Call + 257
372 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
373 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
374 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
375 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
376 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
377 org.python.python             	0x0011fd3d PyObject_Call + 50
378 org.python.python             	0x0011fe0c PyObject_Call + 257
379 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
380 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
381 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
382 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
383 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
384 org.python.python             	0x0011fd3d PyObject_Call + 50
385 org.python.python             	0x0011fe0c PyObject_Call + 257
386 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
387 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
388 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
389 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
390 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
391 org.python.python             	0x0011fd3d PyObject_Call + 50
392 org.python.python             	0x0011fe0c PyObject_Call + 257
393 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
394 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
395 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
396 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
397 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
398 org.python.python             	0x0011fd3d PyObject_Call + 50
399 org.python.python             	0x0011fe0c PyObject_Call + 257
400 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
401 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
402 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
403 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
404 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
405 org.python.python             	0x0011fd3d PyObject_Call + 50
406 org.python.python             	0x0011fe0c PyObject_Call + 257
407 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
408 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
409 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
410 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
411 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
412 org.python.python             	0x0011fd3d PyObject_Call + 50
413 org.python.python             	0x0011fe0c PyObject_Call + 257
414 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
415 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
416 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
417 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
418 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
419 org.python.python             	0x0011fd3d PyObject_Call + 50
420 org.python.python             	0x0011fe0c PyObject_Call + 257
421 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
422 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
423 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
424 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
425 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
426 org.python.python             	0x0011fd3d PyObject_Call + 50
427 org.python.python             	0x0011fe0c PyObject_Call + 257
428 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
429 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
430 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
431 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
432 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
433 org.python.python             	0x0011fd3d PyObject_Call + 50
434 org.python.python             	0x0011fe0c PyObject_Call + 257
435 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
436 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
437 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
438 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
439 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
440 org.python.python             	0x0011fd3d PyObject_Call + 50
441 org.python.python             	0x0011fe0c PyObject_Call + 257
442 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
443 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
444 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
445 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
446 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
447 org.python.python             	0x0011fd3d PyObject_Call + 50
448 org.python.python             	0x0011fe0c PyObject_Call + 257
449 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
450 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
451 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
452 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
453 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
454 org.python.python             	0x0011fd3d PyObject_Call + 50
455 org.python.python             	0x0011fe0c PyObject_Call + 257
456 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
457 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
458 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
459 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
460 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
461 org.python.python             	0x0011fd3d PyObject_Call + 50
462 org.python.python             	0x0011fe0c PyObject_Call + 257
463 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
464 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
465 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
466 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
467 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
468 org.python.python             	0x0011fd3d PyObject_Call + 50
469 org.python.python             	0x0011fe0c PyObject_Call + 257
470 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
471 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
472 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
473 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
474 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
475 org.python.python             	0x0011fd3d PyObject_Call + 50
476 org.python.python             	0x0011fe0c PyObject_Call + 257
477 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
478 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
479 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
480 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
481 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
482 org.python.python             	0x0011fd3d PyObject_Call + 50
483 org.python.python             	0x0011fe0c PyObject_Call + 257
484 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
485 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
486 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
487 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
488 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
489 org.python.python             	0x0011fd3d PyObject_Call + 50
490 org.python.python             	0x0011fe0c PyObject_Call + 257
491 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
492 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
493 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
494 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
495 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
496 org.python.python             	0x0011fd3d PyObject_Call + 50
497 org.python.python             	0x0011fe0c PyObject_Call + 257
498 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
499 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
500 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
501 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
502 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
503 org.python.python             	0x0011fd3d PyObject_Call + 50
504 org.python.python             	0x0011fe0c PyObject_Call + 257
505 org.python.python             	0x0011fe7b PyObject_CallFunction + 74
506 org.python.python             	0x0014c076 PyObject_GenericGetAttr + 780
507 org.python.python             	0x0018c8d0 PyEval_EvalFrameEx + 13222
508 org.python.python             	0x0018f45b PyEval_EvalCodeEx + 1638
509 org.python.python             	0x00139c27 PyFunction_SetClosure + 2646
510 org.python.python             	0x0011fd3d PyObject_Call + 50
511 org.python.python             	0x0011fe0c PyObject_Call + 257

Thread 1 crashed with X86 Thread State (32-bit):
  eax: 0x00000154  ebx: 0x001b50c8  ecx: 0x00000000  edx: 0x00000002
  edi: 0x00000002  esi: 0x00000154  ebp: 0xb0001008  esp: 0xb0000fc0
   ss: 0x0000001f  efl: 0x00010286  eip: 0x0014d2b1   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x0000001f   gs: 0x00000037
  cr2: 0xb0000ffc

Binary Images:
    0x1000 -     0x1ffe  org.python.pythonapp 2.5.0 (2.5.0a0)
<43d1de1392226add5fa1863b1c8f3c38>
/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
   0x49000 -    0x4affc  _locale.so ??? (???)
<224dae28278c0b54038d2f40c4a8bc5e>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_locale.so
   0xa3000 -    0xa5ffd  strop.so ??? (???)
<9ff7c47cc516cacfffffc32394614278>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/strop.so
   0xad000 -    0xaefff  math.so ??? (???)
<2760e468a69da07b8e56d935052cddf3>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/math.so
   0xb2000 -    0xb3fff  _random.so ??? (???)
<d151b9f72aef9ccc27622a2cbab0fe3b>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_random.so
   0xb7000 -    0xb9ffe  itertools.so ??? (???)
<737606f613cf28762e906a1e99747d42>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/itertools.so
   0xbe000 -    0xbeffd  fcntl.so ??? (???)
<0adb3f2f17268872f957c073a653a1a3>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/fcntl.so
  0x118000 -   0x1e3feb  org.python.python 2.5 (2.5)
<24a070f3eb901550011914de7e89c1e1>
/System/Library/Frameworks/Python.framework/Versions/2.5/Python
  0x230000 -   0x232fff  operator.so ??? (???)
<7c060c07f76385060a3bf8a03833c263>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/operator.so
  0x23d000 -   0x23fffb  _struct.so ??? (???)
<93621eae7122da3ebcac8f3ce9b4988b>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_struct.so
  0x243000 -   0x244fff  time.so ??? (???)
<dcfc45df51fc23ca0db7b6d6e3d93ccf>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/time.so
  0x249000 -   0x24efff  _socket.so ??? (???)
<31a07253e3de7d0d95f043eb8630fa95>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_socket.so
  0x255000 -   0x256fff  _ssl.so ??? (???)
<d4b319b42a97f46e4c745183cd60e807>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_ssl.so
  0x260000 -   0x269fff  datetime.so ??? (???)
<2bdc3c2dfcd238e24dba2262bb62287d>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/datetime.so
  0x2b0000 -   0x2b1fff  cStringIO.so ??? (???)
<2db2df1edd8c9ccfaa1f305ed764193e>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/cStringIO.so
  0x2b5000 -   0x2b6fff  collections.so ??? (???)
<a4b114961adea17935f68725d493eefb>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/collections.so
  0x2ba000 -   0x2bbffe  binascii.so ??? (???)
<ee8bd470dc4de28bde3acfeea2c445bb>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/binascii.so
  0x440000 -   0x443ffd  array.so ??? (???)
<97299e359943721e029da1e0b913e0ba>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/array.so
  0x448000 -   0x448ffc  _functools.so ??? (???)
<9a2b2a61043e74763f7c9d444e4cefa2>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_functools.so
  0x44c000 -   0x44cffd  _weakref.so ??? (???)
<08d2e6e9ab02ff11fc23d5d8e9fe1083>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_weakref.so
  0x450000 -   0x451ffd  _hashlib.so ??? (???)
<4a55f4ee934a92a373d99c41345fc85a>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_hashlib.so
  0x538000 -   0x53bffe  _sha256.so ??? (???)
<889bc8b7dca164ca2924718c874a1072>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_sha256.so
  0x53f000 -   0x54cffd  _sha512.so ??? (???)
<08705da617306288bb41a3ae27eab7f0>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_sha512.so
  0x550000 -   0x552ffd  zlib.so ??? (???)
<d21b881e35f6bbc0b9e1fc05e8cc5a50>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/zlib.so
  0x5de000 -   0x5e2ffd +_mysql.so ??? (???)
<3e11fa24ef277a27a4ec91efdd9434ba>
/Users/peterbraden/.python-eggs/MySQL_python-1.2.2-py2.5-macosx-10.5-i386.egg-tmp/_mysql.so
  0x5ee000 -   0x5eeffd  _bisect.so ??? (???)
<4911825102d160156b5d70d93c269cd4>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_bisect.so
  0x5f8000 -   0x602fff  cPickle.so ??? (???)
<851aeb26e480940c425c7c078e73bc99>
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/cPickle.so
 0x1100000 -  0x1187ff7 +libmysqlclient_r.16.dylib ??? (???)
<34c08d42f2fed7b882d58d982029be79>
/usr/local/mysql/lib/libmysqlclient_r.16.dylib
 0x1500000 -  0x153dfff +_imaging.so ??? (???)
<769b1a922a14189fd6665fa4de999cf9>
/Library/Python/2.5/site-packages/PIL/_imaging.so
0x8fe00000 - 0x8fe2db43  dyld 97.1 (???)
<100d362e03410f181a34e04e94189ae5> /usr/lib/dyld
0x90163000 - 0x902caff3  libSystem.B.dylib ??? (???)
<d68880dfb1f8becdbdac6928db1510fb> /usr/lib/libSystem.B.dylib
0x904c5000 - 0x905a5fff  libobjc.A.dylib ??? (???)
<400e943f9e8a678eea22a1d1205490ee> /usr/lib/libobjc.A.dylib
0x90ab6000 - 0x90beeff7  libicucore.A.dylib ??? (???)
<18098dcf431603fe47ee027a60006c85> /usr/lib/libicucore.A.dylib
0x93a3f000 - 0x93b72fff  com.apple.CoreFoundation 6.5.5 (476.17)
<4a70c8dbb582118e31412c53dc1f407f>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x93ea7000 - 0x93ed2fe7  libauto.dylib ??? (???)
<2e44c523b851e8e25f05d13a48070a58> /usr/lib/libauto.dylib
0x955ab000 - 0x95608ffb  libstdc++.6.dylib ??? (???)
<f75e5133d72769de5ce6c06153fc65f6> /usr/lib/libstdc++.6.dylib
0x956f6000 - 0x956fdfe9  libgcc_s.1.dylib ??? (???)
<e280ddf3f5fb3049e674edcb109f389a> /usr/lib/libgcc_s.1.dylib
0x95a4a000 - 0x95a6efeb  libssl.0.9.7.dylib ??? (???)
<d04156c610530ca44979c899834fc24d> /usr/lib/libssl.0.9.7.dylib
0x95a6f000 - 0x95a73fff  libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
0x95c1a000 - 0x95cccffb  libcrypto.0.9.7.dylib ??? (???)
<75b80bff0d5cfaf10b6b6fe982da3578> /usr/lib/libcrypto.0.9.7.dylib
0x95e07000 - 0x95e15ffd  libz.1.dylib ??? (???)
<a98b3b221a72b54faf73ded3dd7000e5> /usr/lib/libz.1.dylib
0xfffe8000 - 0xfffebfff  libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???)
/usr/lib/libSystem.B.dylib

----------
components: Macintosh
messages: 80260
nosy: pb
severity: normal
status: open
title: Kernel Protection Failure
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Wed Jan 21 00:23:53 2009
From: report at bugs.python.org (Kylotan)
Date: Tue, 20 Jan 2009 23:23:53 +0000
Subject: [New-bugs-announce] [issue5015] The Py_SetPythonHome C API function
	is undocumented
In-Reply-To: <1232493833.95.0.946934351035.issue5015@psf.upfronthosting.co.za>
Message-ID: <1232493833.95.0.946934351035.issue5015@psf.upfronthosting.co.za>


New submission from Kylotan <kylotan at gmail.com>:

I found out recently that Py_SetPythonHome() might solve my problem with
embedding Python in a C++ app. I felt a bit stupid for not finding this
myself in the documentation, until I noticed that it's not in the
documentation. :)  I would expect to find it at
http://docs.python.org/c-api/init.html but it is absent.

----------
assignee: georg.brandl
components: Documentation
messages: 80291
nosy: Kylotan, georg.brandl
severity: normal
status: open
title: The Py_SetPythonHome C API function is undocumented
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 21 00:38:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Jan 2009 23:38:38 +0000
Subject: [New-bugs-announce] [issue5016] FileIO.seekable() can return False
In-Reply-To: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>
Message-ID: <1232494718.16.0.105569040712.issue5016@psf.upfronthosting.co.za>


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

FileIO.seekable() can return False if we first seek to a position such
that, when truncated to a signed int, it becomes negative:

>>> f = open('largefile', 'wb', buffering=0)
>>> f.seek(2**31, 0)
2147483648
>>> f.write(b'x')
1
>>> f.close()
>>> f = open('largefile', 'rb', buffering=0)
>>> f.seek(0, 2)
2147483649
>>> f.seekable()
False

----------
components: Extension Modules
messages: 80295
nosy: pitrou
severity: normal
status: open
title: FileIO.seekable() can return False
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Jan 21 02:36:41 2009
From: report at bugs.python.org (Peter Bobroff)
Date: Wed, 21 Jan 2009 01:36:41 +0000
Subject: [New-bugs-announce] [issue5017] import suds help( suds ) fails
In-Reply-To: <1232501801.2.0.242744979679.issue5017@psf.upfronthosting.co.za>
Message-ID: <1232501801.2.0.242744979679.issue5017@psf.upfronthosting.co.za>


New submission from Peter Bobroff <pjb253 at gmail.com>:

Python Interactive Shell 2.6.1 r261:67517
easy_install suds  #seemed to succeed
import suds
help( suds ) fails in Python26\lib\inspect.py with index out of range
I fixed the obvious problem, then failed on another. After fixing 3 0r 4 
it worked but there is probably one correct fix to the problem.

A bit beyond my present competence to fix it properly.

----------
components: Demos and Tools
messages: 80306
nosy: pjb
severity: normal
status: open
title: import suds help( suds ) fails
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 21 02:54:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 21 Jan 2009 01:54:26 +0000
Subject: [New-bugs-announce] [issue5018] Overly general claim about sequence
	unpacking in tutorial
In-Reply-To: <1232502866.59.0.0196070815621.issue5018@psf.upfronthosting.co.za>
Message-ID: <1232502866.59.0.0196070815621.issue5018@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The datastructures section of the tutorial states with respect to 
"sequence unpacking" that "there is a small bit of asymmetry here: packing 
multiple values always creates a tuple, and unpacking works for any 
sequence". This is too general, as shown by the definition of assignment 
statement target in the simple_stmts section of the reference shows: 
tuples and lists are the only kinds of sequences that can appear on the 
left-hand side of an assignment statement.

----------
assignee: georg.brandl
components: Documentation
messages: 80307
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Overly general claim about sequence unpacking in tutorial
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Jan 21 03:00:39 2009
From: report at bugs.python.org (Robin Dunn)
Date: Wed, 21 Jan 2009 02:00:39 +0000
Subject: [New-bugs-announce] [issue5019] Specifying common controls DLL in
	manifest
In-Reply-To: <1232503239.64.0.982507078752.issue5019@psf.upfronthosting.co.za>
Message-ID: <1232503239.64.0.982507078752.issue5019@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

This may have already been discussed but my searches didn't turn up
anything concrete other than issue 4120 which is a similar but different
problem.  The problem I'm facing is that wxPython requires that version
6 of the common controls DLL be loaded in order for the GUI applications
to use the themed version of the widgets on XP+ platforms, but it
appears that this can only be done reliably if the manifest for the .exe
is the one that specifies that version of the common controls assembly.

Prior to 2.6 I was able to install python[w].exe.manifest files next to
the python executables from my installer and it would work fine, but now
that Python 2.6 is built with MSVC9 and it has its own manifest that
does not always work.  Initial testing seems to indicate that using an
external manifest still works ok on 32-bit platforms, but not on the
64-bit versions of Windows.  

I've tried ensuring that the wxPython .pyd's and the wxWidgets DLLs have
an internal manifest that specifies the common controls assembly but
that has not helped.  The only thing I've been able to find that works
for both 32 and 64 bit is to replace the internal manifest in python.exe
with a new one that specifies both the CRT and the Common Controls
assemblies, but that is obviously a Bad Thing for the install of an
extension module to do, so I'm opening this issue to look for alternatives.

So, does anybody have any experience or ideas on how to enable the
wxPython extensions to load the new common controls assembly without
needing to change the stock Python executables' manifest?  If not, are
there any objections to adding the common controls assembly to the stock
manifest used for python.exe and pythonw.exe?

----------
components: Build, Windows
messages: 80308
nosy: robind
severity: normal
status: open
title: Specifying common controls DLL in manifest
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 21 06:52:36 2009
From: report at bugs.python.org (sleepyfish)
Date: Wed, 21 Jan 2009 05:52:36 +0000
Subject: [New-bugs-announce] [issue5020] Regex Expression Error
In-Reply-To: <1232517156.3.0.804486335225.issue5020@psf.upfronthosting.co.za>
Message-ID: <1232517156.3.0.804486335225.issue5020@psf.upfronthosting.co.za>


New submission from sleepyfish <huangpeng1126 at gmail.com>:

import re
re.match(r'[/- ]','/') crash, but re.match(r'[ /-]','/'), or
re.match(r'[/ -]','/'), or re.match(r'[ -/]','/') ...

only when the match pattern is r'[/-]', the program crash

I run it in version 2.6.1 and version 3.0, both having the same problem

----------
components: Regular Expressions
messages: 80317
nosy: sleepyfish
severity: normal
status: open
title: Regex Expression Error
type: crash
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Jan 21 13:23:07 2009
From: report at bugs.python.org (Tom Lynn)
Date: Wed, 21 Jan 2009 12:23:07 +0000
Subject: [New-bugs-announce] [issue5021] doctest.testfile should set
	__name__, can't use namedtuple
In-Reply-To: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>
Message-ID: <1232540587.99.0.985129988543.issue5021@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

This file fails when run with doctest.testfile::

  >>> print __name__
  __builtin__
  >>> print globals()['__name__']  # fails with KeyError: __name__
  __builtin__

"__builtin__" is probably not a good value, but more importantly, this 
means that you can't use namedtuples in text file doctests, since 
namedtuple() inspects the calling frame::

  >>> from namedtuple import namedtuple
  >>> t = namedtuple('fred', 'x')  # fails

(I presume this is the same for "from collections import namedtuple", 
but I've not tested with 2.6+.)

A workaround is to add this line at the start of the test::

   >>> __name__ = 'test'

----------
components: Library (Lib)
messages: 80322
nosy: tlynn
severity: normal
status: open
title: doctest.testfile should set __name__, can't use namedtuple
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Wed Jan 21 13:27:42 2009
From: report at bugs.python.org (Tom Lynn)
Date: Wed, 21 Jan 2009 12:27:42 +0000
Subject: [New-bugs-announce] [issue5022] doctest should allow running tests
	with "python -m doctest"
In-Reply-To: <1232540862.78.0.478308305039.issue5022@psf.upfronthosting.co.za>
Message-ID: <1232540862.78.0.478308305039.issue5022@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

It would be good to be able to do something like::

  $ python -m doctest foo.py
  $ python -m doctest --text foo.txt bar.txt

(or preferably some command line options design which could handle 
both .py and .txt files).

----------
components: Library (Lib)
messages: 80323
nosy: tlynn
severity: normal
status: open
title: doctest should allow running tests with "python -m doctest"
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Wed Jan 21 17:44:45 2009
From: report at bugs.python.org (Eric Wald)
Date: Wed, 21 Jan 2009 16:44:45 +0000
Subject: [New-bugs-announce] [issue5023] Segfault in
	datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>


New submission from Eric Wald <pythonista at brainshell.org>:

Execution of "make test" for Python 2.6.1 halts with a segmentation 
fault on line 2198 of Python-2.6.1/Lib/test/test_datetime.py; also 
occurs using the attached script, narrowing it down to the %z sequence 
in the format argument to datetime.time.strftime(), but only when the 
time object has a non-None tzinfo.  The segfault disappears when I 
comment out line 1133 of Python-2.6.1/Modules/datetimemodule.c:

PyOS_snprintf(buf, buflen, "%c%02d%s%02d", sign, hours, sep, minutes);

Compiled with GCC 3.4.3 with Smashing Stack Protector on LFS 5.1.1 
(Linux 2.6.11.12 and glibc 2.3.5 with ssp patches).  Using BASECFLAGS=-
fno-stack-protector has no effect on the segfault.  All other Python 
tests pass.  HAVE_SNPRINTF has been defined to 1 in pyconfig.h by the 
config script.

I have not yet compiled gdb, but I can if requested.

----------
components: Library (Lib)
files: zone_failure.py
messages: 80332
nosy: eswald
severity: normal
status: open
title: Segfault in datetime.time.strftime("%z")
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12825/zone_failure.py

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

From report at bugs.python.org  Wed Jan 21 18:19:42 2009
From: report at bugs.python.org (Robert Pyle)
Date: Wed, 21 Jan 2009 17:19:42 +0000
Subject: [New-bugs-announce] [issue5024] sndhdr.whathdr returns -1 for WAV
	file frame count
In-Reply-To: <1232558382.92.0.547995552561.issue5024@psf.upfronthosting.co.za>
Message-ID: <1232558382.92.0.547995552561.issue5024@psf.upfronthosting.co.za>


New submission from Robert Pyle <rpyle at post.harvard.edu>:

Seems like test_wav() could easily return the actual frame count by 
calling wave.py just as test_aifc() uses aifc.py.

----------
components: Library (Lib)
messages: 80333
nosy: rpyle
severity: normal
status: open
title: sndhdr.whathdr returns -1 for WAV file frame count
type: feature request

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

From report at bugs.python.org  Wed Jan 21 18:58:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Jan 2009 17:58:18 +0000
Subject: [New-bugs-announce] [issue5025] test_kqueue failure on OS X
In-Reply-To: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>
Message-ID: <1232560698.61.0.164909424783.issue5025@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I just got a one-off, non-reproducible test_kqueue failure, during a 'make 
test' of the trunk, on OS X 10.5.6.  Here's the output:

test_kqueue
test test_kqueue failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python_source/trunk/Lib/test/test_kqueue.py", line 
136, in test_queue_event
    (server.fileno(), select.KQ_FILTER_READ, flags)])
AssertionError: [(5L, -2, 5L), (6L, -2, 5L), (6L, -1, 5L)] != [(5, -2, 5), 
(5, -1, 5), (6, -2, 5), (6, -1, 5)]

Looking at the test_queue.py file just before line 136, I see:

        events = kq.control(None, 4, 1)
        # We may need to call it several times
        for i in range(5):
            if len(events) == 4:
                break
            events = kq.control(None, 4, 1)

Would adding a time.sleep(1.0) to the for loop make this test more robust?

My first impression was that the '1' in 'kq.control(None, 4, 1)' already 
did this;  i.e., that it meant that the kq.control function would wait up 
to 1 second for a response, but that doesn't seem to be true.  I tried 
replacing the 1 with 1000000 and the test still runs nearly 
instantaneously, even in the case where the kq.control call doesn't get 4 
events first time around.

Out of curiosity, *why* is there a need to call this several times? I 
fully believe there *is* such a need;  I just don't know what it is.  
Something to do with waiting for the socket send calls to complete, I 
assume?

----------
assignee: christian.heimes
components: Tests
messages: 80335
nosy: christian.heimes, marketdickinson
severity: normal
status: open
title: test_kqueue failure on OS X
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 21 20:08:24 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 21 Jan 2009 19:08:24 +0000
Subject: [New-bugs-announce] [issue5026] [reopening] native build of python
	win32 using msys under wine.
In-Reply-To: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>
Message-ID: <1232564904.43.0.416803942759.issue5026@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

reopening a new bug with the exact same title due to #4954 having
been unilaterally closed without discussion, nor reasons specified.

simple courtesy would dictate that some sort of dialog is entered
into especially when someone is putting in significant amounts of
work in developing python, and has plans to forward-port the patch
to python2.6 and trunk, merge it with #3844 and much more.

----------
components: Build
files: f
messages: 80339
nosy: lkcl
severity: normal
status: open
title: [reopening] native build of python win32 using msys under wine.
versions: Python 2.5
Added file: http://bugs.python.org/file12827/f

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

From report at bugs.python.org  Wed Jan 21 21:59:42 2009
From: report at bugs.python.org (Soren Roug)
Date: Wed, 21 Jan 2009 20:59:42 +0000
Subject: [New-bugs-announce] [issue5027] xml namespace not understood by
	xml.sax.saxutils.XMLGenerator
In-Reply-To: <1232571582.02.0.360824752482.issue5027@psf.upfronthosting.co.za>
Message-ID: <1232571582.02.0.360824752482.issue5027@psf.upfronthosting.co.za>


New submission from Soren Roug <soren.roug at eea.europa.eu>:

The 'xml' namespace in XML files is special in that it need not be
declared. When xml.sax.saxutils.XMLGenerator is used with the namespace
feature it does not know how to handle it.

Example. The code:

import xml.sax, xml.sax.saxutils
parser = xml.sax.make_parser()
parser.setFeature(xml.sax.handler.feature_namespaces, 1)
c = xml.sax.saxutils.XMLGenerator()
parser.setContentHandler(c)
parser.parse('testfile.xml')

executed on the testfile.xml with this content:

<?xml version="1.0"?>
<a:greetings xmlns:a="http://example.com/ns">
  <a:greet xml:lang="en">Hello world</a:greet>
</a:greetings>

will produce this error:
...
  File "/usr/lib/python2.5/xml/sax/saxutils.py", line 149, in startElementNS
    self._write(' %s=%s' % (self._qname(name), quoteattr(value)))
  File "/usr/lib/python2.5/xml/sax/saxutils.py", line 107, in _qname
    prefix = self._current_context[name[0]]
KeyError: u'http://www.w3.org/XML/1998/namespace'


It can be fixed by making an exception for the xml namespace (as
required by W3C - See http://www.w3.org/XML/1998/namespace) in
xml/sax/saxutils.py. The _qname method could then look like this:

    def _qname(self, name):
        """Builds a qualified name from a (ns_url, localname) pair"""
        if name[0]:
            if name[0] == u'http://www.w3.org/XML/1998/namespace':
                return u'xml' + ":" + name[1]
            # The name is in a non-empty namespace
            prefix = self._current_context[name[0]]
            if prefix:
                # If it is not the default namespace, prepend the prefix
                return prefix + ":" + name[1]
        # Return the unqualified name
        return name[1]

----------
components: Library (Lib), XML
messages: 80346
nosy: roug
severity: normal
status: open
title: xml namespace not understood by xml.sax.saxutils.XMLGenerator
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Jan 22 02:39:03 2009
From: report at bugs.python.org (Duncan Findlay)
Date: Thu, 22 Jan 2009 01:39:03 +0000
Subject: [New-bugs-announce] [issue5028] tokenize.generate_tokens doesn't
	always return logical line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>


New submission from Duncan Findlay <duncf at apache.org>:

According to the documentation for tokenize.generate_tokens:

"The generator produces 5-tuples with these members: the token type; the
token string; a 2-tuple (srow, scol) of ints specifying the row and
column where the token begins in the source; a 2-tuple (erow, ecol) of
ints specifying the row and column where the token ends in the source;
and the line on which the token was found. The line passed (the last
tuple item) is the logical line; continuation lines are included."

It seems though that the "logical line" -- the last element of the tuple
is the physical line unless the token being returned spans beyond the
end of the line. As an example, consider a test file test.py:

foo = """
%s """ % 'bar'

>>> import pprint, tokenize
>>> pprint.pprint(list(tokenize.generate_tokens(open('test.py').readline)))
[(1, 'foo', (1, 0), (1, 3), 'foo = """\n'),
 (51, '=', (1, 4), (1, 5), 'foo = """\n'),
 (3, '"""\n%s """', (1, 6), (2, 6), 'foo = """\n%s """ % \'bar\'\n'),
 (51, '%', (2, 7), (2, 8), '%s """ % \'bar\'\n'),
 (3, "'bar'", (2, 9), (2, 14), '%s """ % \'bar\'\n'),
 (4, '\n', (2, 14), (2, 15), '%s """ % \'bar\'\n'),
 (0, '', (3, 0), (3, 0), '')]
>>> 

Since there is only one logical line, I would expect the first 6 tokens
to have the same 5th element.

----------
components: Library (Lib)
messages: 80353
nosy: duncf
severity: normal
status: open
title: tokenize.generate_tokens doesn't always return logical line
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 22 03:01:14 2009
From: report at bugs.python.org (=?utf-8?q?Dinko_Galeti=C4=87?=)
Date: Thu, 22 Jan 2009 02:01:14 +0000
Subject: [New-bugs-announce] [issue5029] Odd slicing behaviour
In-Reply-To: <1232589674.41.0.799165802013.issue5029@psf.upfronthosting.co.za>
Message-ID: <1232589674.41.0.799165802013.issue5029@psf.upfronthosting.co.za>


New submission from Dinko Galeti? <dinko.galetic at gmail.com>:

#the following code should return an empty list, but returns the 0th
member of the list

>>> foo = [1, 2, 3]
>>> foo[0::-1]
[1]

----------
components: Regular Expressions
messages: 80354
nosy: dgaletic
severity: normal
status: open
title: Odd slicing behaviour
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 22 03:19:16 2009
From: report at bugs.python.org (David Schultz)
Date: Thu, 22 Jan 2009 02:19:16 +0000
Subject: [New-bugs-announce] [issue5030] Typo in class
	tkinter.filedialog.Directory prevents compilation
In-Reply-To: <1232590756.63.0.287799731331.issue5030@psf.upfronthosting.co.za>
Message-ID: <1232590756.63.0.287799731331.issue5030@psf.upfronthosting.co.za>


New submission from David Schultz <ringhome at cox.net>:

class tkinter.filedialog.Directory incorrectly derives from Dialog instead 
of _Dialog.  Adding the "_" allows the code to compile and run as 
expected.

This also explains why tkinter.filedialog.askdirectory() doesn't work.

----------
components: Tkinter
messages: 80355
nosy: ringhome
severity: normal
status: open
title: Typo in class tkinter.filedialog.Directory prevents compilation
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Thu Jan 22 10:26:30 2009
From: report at bugs.python.org (steve21)
Date: Thu, 22 Jan 2009 09:26:30 +0000
Subject: [New-bugs-announce] [issue5031] Thread.daemon docs
In-Reply-To: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>
Message-ID: <1232616390.21.0.0351753883552.issue5031@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

In the threading module the Thread.daemon documentation says:

"The thread?s daemon flag. This must be set before start() is called,
otherwise RuntimeError is raised.

    The initial value is inherited from the creating thread.

    The entire Python program exits when no alive non-daemon threads are
left."

I think the docs should state Thread.daemon's type (boolean, or integer,
or something else?) and its default value (when you have not set .daemon
in the creating thread.)

----------
assignee: georg.brandl
components: Documentation
messages: 80361
nosy: georg.brandl, steve21
severity: normal
status: open
title: Thread.daemon docs
versions: Python 3.0

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

From report at bugs.python.org  Thu Jan 22 14:14:31 2009
From: report at bugs.python.org (steve21)
Date: Thu, 22 Jan 2009 13:14:31 +0000
Subject: [New-bugs-announce] [issue5032] itertools.count step
In-Reply-To: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>
Message-ID: <1232630071.89.0.921140735063.issue5032@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

I'd like to request a 'step' argument be added for itertools.count. It
would be useful in the same way that step is useful for the 'range'
function.

('range' and 'count' are very similar - 'count' could even be merged into
'range', for example by making 'range(None)' equivalent to 'count()')

----------
components: None
messages: 80368
nosy: steve21
severity: normal
status: open
title: itertools.count step
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Thu Jan 22 17:23:26 2009
From: report at bugs.python.org (blahblahwhat)
Date: Thu, 22 Jan 2009 16:23:26 +0000
Subject: [New-bugs-announce] [issue5033] setup.py crashes if sqlite version
	contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>


New submission from blahblahwhat <blahblah57 at mailinator.com>:

When I try to 'make' Python 2.6.1:

Traceback (most recent call last):
  File "./setup.py", line 1880, in <module>
    main()
  File "./setup.py", line 1875, in main
    'Lib/smtpd.py']
  File "/home/apps/Python-2.6.1/Lib/distutils/core.py", line 152, in 
setup
    dist.run_commands()
  File "/home/apps/Python-2.6.1/Lib/distutils/dist.py", line 975, in 
run_commands
    self.run_command(cmd)
  File "/home/apps/Python-2.6.1/Lib/distutils/dist.py", line 995, in 
run_command
    cmd_obj.run()
  File "/home/apps/Python-2.6.1/Lib/distutils/command/build.py", line 
134, in run
    self.run_command(cmd_name)
  File "/home/apps/Python-2.6.1/Lib/distutils/cmd.py", line 333, in 
run_command
    self.distribution.run_command(command)
  File "/home/apps/Python-2.6.1/Lib/distutils/dist.py", line 995, in 
run_command
    cmd_obj.run()
  File "/home/apps/Python-2.6.1/Lib/distutils/command/build_ext.py", 
line 343, in run
    self.build_extensions()
  File "./setup.py", line 103, in build_extensions
    missing = self.detect_modules()
  File "./setup.py", line 915, in detect_modules
    for x in sqlite_version.split(".")])
ValueError: invalid literal for int() with base 10: '1beta'

This was solved by replacing

  m = re.search(r'\s*.*#\s*.*define\s.*SQLITE_VERSION\W*"(.*)"', incf)

with

  m = re.search(r'\s*.*#\s*.*define\s.*SQLITE_VERSION\W*"([\d\.]*)"', 
incf)

on line 911

----------
components: Build
messages: 80370
nosy: blahblahwhat
severity: normal
status: open
title: setup.py crashes if sqlite version contains 'beta'
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 22 19:18:41 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 22 Jan 2009 18:18:41 +0000
Subject: [New-bugs-announce] [issue5034] itertools.fixlen
In-Reply-To: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>
Message-ID: <1232648321.61.0.976878851499.issue5034@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

As raised recently on python-ideas [1]_, an itertools method fixing
iterators to a certain length might be handy (where fixing is either
cutting elements off or appending values).

I appended a patch implementing this feature in Python/C, unit tests and
documentation included.

.. [1] http://thread.gmane.org/gmane.comp.python.ideas/2472/focus=2479

----------
components: Library (Lib)
files: fixlen.patch
keywords: patch
messages: 80372
nosy: lehmannro
severity: normal
status: open
title: itertools.fixlen
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12833/fixlen.patch

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

From report at bugs.python.org  Thu Jan 22 22:24:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Jan 2009 21:24:22 +0000
Subject: [New-bugs-announce] [issue5035] Compilation --without-threads fails
In-Reply-To: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>
Message-ID: <1232659462.88.0.743482431545.issue5035@psf.upfronthosting.co.za>


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

libpython2.7.a(object.o): In function `_PyObject_Dump':
/home/antoine/cpython/__svn__/Objects/object.c:341: undefined reference
to `PyGILState_Ensure'
/home/antoine/cpython/__svn__/Objects/object.c:343: undefined reference
to `PyGILState_Release'

----------
messages: 80379
nosy: jnoller, pitrou
priority: normal
severity: normal
status: open
title: Compilation --without-threads fails
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 23 04:52:21 2009
From: report at bugs.python.org (Takeshi Matsuyama)
Date: Fri, 23 Jan 2009 03:52:21 +0000
Subject: [New-bugs-announce] [issue5036] xml.parsers.expat make a dictionary
	which keys are broken if buffer_text is False.
In-Reply-To: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>
Message-ID: <1232682741.27.0.537890243141.issue5036@psf.upfronthosting.co.za>


New submission from Takeshi Matsuyama <tksmashiw at gmail.com>:

When I make a dictionary by parsing "legacy-icon-mapping.xml"(which is a
part of
icon-naming-utils[http://tango.freedesktop.org/Tango_Icon_Library]) with
the following script, the three keys of the dictionary are collapsed if
the "buffer_text" attribute is False.

=====================
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from __future__ import with_statement
import sys
from xml.parsers.expat import ParserCreate
import codecs

class Database:
  """Make a dictionary which is accessible by Databese.dict"""
  def __init__(self, buffer_text):
    self.cnt = None
    self.name = None
    self.data = None
    self.dict = {}
    p = ParserCreate()
    p.buffer_text = buffer_text

    p.StartElementHandler = self.start_element
    p.EndElementHandler = self.end_element
    p.CharacterDataHandler = self.char_data

    with open("/usr/share/icon-naming-utils/legacy-icon-mapping.xml",
'r') as f:
      p.ParseFile(f)

  def start_element(self, name, attrs):
    if name == 'context':
      self.cnt = attrs["dir"]
    if name == 'icon':
      self.name = attrs["name"]
  
  def end_element(self, name):
    if name == 'link':
      self.dict[self.data] = (self.cnt, self.name)

  def char_data(self, data):
    self.data = data.strip()

def print_set(aset):
  for e in aset:
    print '\t' + e

if __name__ == '__main__':
  sys.stdout = codecs.getwriter('utf_8')(sys.stdout)
  map_false_dict = Database(False).dict
  map_true_dict = Database(True).dict
  print "The keys which exist if buffer_text=False but don't exist if
buffer_text=True are"
  print_set(set(map_false_dict.keys()) - set(map_true_dict.keys()))
  print "The keys which exist if buffer_text=True but don't exist if
buffer_text=False are"
  print_set(set(map_true_dict.keys()) - set(map_false_dict.keys()))
=====================

The result of running this script is
======================
The keys which exist if buffer_text=False but don't exist if
buffer_text=True are
	rt-descending
	ock_text_right
	lc
The keys which exist if buffer_text=True but don't exist if
buffer_text=False are
	stock_text_right
	gnome-mime-application-vnd.stardivision.calc
	gtk-sort-descending
======================
I confirmed it in Python-2.5.2 on Fedora 10.

----------
components: XML
messages: 80398
nosy: tksmashiw
severity: normal
status: open
title: xml.parsers.expat make a dictionary which keys are broken if buffer_text is False.
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jan 23 16:03:31 2009
From: report at bugs.python.org (Taldor)
Date: Fri, 23 Jan 2009 15:03:31 +0000
Subject: [New-bugs-announce] [issue5037] unexpected unicode behavior for
	proxy objects
In-Reply-To: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>
Message-ID: <1232723011.79.0.257405867279.issue5037@psf.upfronthosting.co.za>


New submission from Taldor <tinusvl at skynet.be>:

Calling the unicode function on a proxy object, doesn't use the proxi-ed
object's __unicode__ method, but its __str__ method.

>>> class A(object):
...   def __str__(self):
...     return "str"    
...   def __unicode__(self):
...     return "unicode"    
...                         
>>> a = A()
>>> unicode(a)
u'unicode'
>>> import weakref
>>> b = weakref.proxy(a)
>>> unicode(b)
u'str'

I expected the last result to be u'unicode'. I did get u'unicode' in
Python 2.5 (but not in 2.6).

----------
components: None
messages: 80416
nosy: Taldor
severity: normal
status: open
title: unexpected unicode behavior for proxy objects
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 23 18:07:19 2009
From: report at bugs.python.org (jan matejek)
Date: Fri, 23 Jan 2009 17:07:19 +0000
Subject: [New-bugs-announce] [issue5038] urrlib2/httplib doesn't reset file
	position between requests
In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>
Message-ID: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>


New submission from jan matejek <jmatejek at suse.cz>:

since 2.6 httplib supports reading from file-like objects.

Now consider the following situation:
There are two handlers in urrlib2, first is plain http, second is basic
auth.
I want to POST a file to a service, and pass the open file object as
data parameter to urllib2.urlopen.
First handler is invoked, it sends the file data, but gets 401
Unauthorized return code and fails with that.
Second handler in chain is invoked (at least that's how i understand
urrlib2, please correct me if i'm talking rubbish). At that point the
open file is at EOF, so empty data is sent.

furthermore, the obvious solution "you can't do this through urllib so
go read the file yourself" doesn't apply that well - the file object in
question is actually a mmap.mmap instance.
This code is in production since python 2.4. Until file object support
in httplib was introduced, it worked fine, handling the mmap'ed file as
a string. Now it is picked up as read()-able and this problem occurs.
Only workaround to restore pre-2.6 behavior that comes to mind is
building a wrapper class for the mmap object that hides its read() method.

----------
components: Library (Lib)
messages: 80419
nosy: matejcik
severity: normal
status: open
title: urrlib2/httplib doesn't reset file position between requests
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan 24 01:11:59 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Jan 2009 00:11:59 +0000
Subject: [New-bugs-announce] [issue5039] Adjust reference-counting note
In-Reply-To: <1232755919.64.0.595244867135.issue5039@psf.upfronthosting.co.za>
Message-ID: <1232755919.64.0.595244867135.issue5039@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Language / Data model / Objects, values and types (2.6-3.1)
third paragraph, has the following note:

"(Implementation note: the current implementation uses a
reference-counting scheme with (optional) delayed detection of
cyclically linked garbage, which collects most objects as soon as they
become unreachable, but is not guaranteed to collect garbage containing
circular references. See the documentation of the gc module for
information on controlling the collection of cyclic garbage.)"

There are two issues here: there are now other implementations that act
differently; CPython may change (as GvR reiterated strongly today in the
PyDev thread "__del__ and tp_dealloc in the IO lib", in response to a
request that the current behavior be defined and documented as not
permanent).  So I suggest:
change 'the current implementation' to 'CPython currently'
add "Other implementations act differently and CPython may change." (at
the end)

----------
assignee: georg.brandl
components: Documentation
messages: 80424
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Adjust reference-counting note
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Jan 24 11:19:54 2009
From: report at bugs.python.org (Wayne Huang)
Date: Sat, 24 Jan 2009 10:19:54 +0000
Subject: [New-bugs-announce] [issue5040] Bug of CGIXMLRPCRequestHandler
In-Reply-To: <1232792394.35.0.81811153867.issue5040@psf.upfronthosting.co.za>
Message-ID: <1232792394.35.0.81811153867.issue5040@psf.upfronthosting.co.za>


New submission from Wayne Huang <WayneHuang.public at gmail.com>:

I met a bug of CGIXMLRPCRequestHandler in Python3.0. Because of the bug,
I couldn't use RPC in Apache CGI.

The version of my Python 3.0 is "Python 3.0 (r30:67507, Dec  3 2008,
20:14:27) [MSC v.1500 32 bit (Intel)] win32".

The code of my client is follow.

s = xmlrpc.client.ServerProxy('http://localhost/cgi-bin/rpc.py')
print(s.system.listMethods())

The code of my server in Apache's cgi-bin is follow

#!C:/Python30/python.exe

from xmlrpc.server import *

handler=CGIXMLRPCRequestHandler()
handler.register_introspection_functions()
handler.handle_request()

When I run the client code,some error of parser raise.

I found it is the matter of 'Content-Length' in the HTTP Response of
CGIXMLRPCRequestHandler,it is a wrong number.

----------
components: Library (Lib)
messages: 80440
nosy: WayneHuang
severity: normal
status: open
title: Bug of CGIXMLRPCRequestHandler
type: performance
versions: Python 3.0

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

From report at bugs.python.org  Sat Jan 24 15:31:52 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 24 Jan 2009 14:31:52 +0000
Subject: [New-bugs-announce] [issue5041] Memory leak in imp.find_module
In-Reply-To: <1232807512.09.0.43179112168.issue5041@psf.upfronthosting.co.za>
Message-ID: <1232807512.09.0.43179112168.issue5041@psf.upfronthosting.co.za>


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

I found memory leak related to "es" on PyArg_ParseTuple.

----------
components: Extension Modules
files: py3k_memory_leak.patch
keywords: easy, needs review, patch
messages: 80452
nosy: ocean-city
severity: normal
status: open
title: Memory leak in imp.find_module
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file12844/py3k_memory_leak.patch

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

From report at bugs.python.org  Sat Jan 24 17:04:19 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 24 Jan 2009 16:04:19 +0000
Subject: [New-bugs-announce] [issue5042] Structure sub-subclass does not
	initialize with base class positional arguments
In-Reply-To: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>
Message-ID: <1232813059.45.0.979222906271.issue5042@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

When trying to create a sub-subclass of a ctypes.Structure, the behavior
is not as expected.

An executable example that describes the problem in detail and
demonstrates the issue is available at
http://paste.turbogears.org/paste/29555 and also attached.

The failing behavior is near the beginning, following the description.

Three unsuccessful workarounds follow.

The expected behavior is found at the end, where a final workaround has
been implemented.

Can this behavior be improved in subsequent releases of ctypes?  If not,
can ctypes at least support the workaround natively (perhaps by
providing a method in the Structure class that performs the workaround
and can be called by a sub-subclass during __init__)?

----------
assignee: theller
components: ctypes
files: ctypes subclassing issues.py
messages: 80457
nosy: jaraco, theller
severity: normal
status: open
title: Structure sub-subclass does not initialize with base class positional arguments
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file12845/ctypes subclassing issues.py

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

From report at bugs.python.org  Sat Jan 24 18:50:50 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 24 Jan 2009 17:50:50 +0000
Subject: [New-bugs-announce] [issue5043] get_msvcr() returns None rather
	than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

def get_msvcr():
    """Include the appropriate MSVC runtime library if Python was built
    with MSVC 7.0 or later.
    """
    msc_pos = sys.version.find('MSC v.')
    if msc_pos != -1:
        msc_ver = sys.version[msc_pos+6:msc_pos+10]
        if msc_ver == '1300':
            # MSVC 7.0
            return ['msvcr70']
        elif msc_ver == '1310':
            # MSVC 7.1
            return ['msvcr71']
        elif msc_ver == '1400':
            # VS2005 / MSVC 8.0
            return ['msvcr80']
        elif msc_ver == '1500':
            # VS2008 / MSVC 9.0
            return ['msvcr90']
        else:
            raise ValueError("Unknown MS Compiler version %i " % msc_Ver)

    return [] <<<<<<<<-----

----------
components: Build
messages: 80466
nosy: lkcl
severity: normal
status: open
title: get_msvcr() returns None rather than []
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan 24 19:49:07 2009
From: report at bugs.python.org (Frank Henigman)
Date: Sat, 24 Jan 2009 18:49:07 +0000
Subject: [New-bugs-announce] [issue5044] name not found in generator in
	eval()
In-Reply-To: <1232822947.1.0.133791034087.issue5044@psf.upfronthosting.co.za>
Message-ID: <1232822947.1.0.133791034087.issue5044@psf.upfronthosting.co.za>


New submission from Frank Henigman <fjhenigman at cgl.uwaterloo.ca>:

# works
>>> eval( "sum( [ a[0]=='a' for j in 'a' ] )", {}, dict(a='a'))
# take out the square brackets
>>> eval( "sum(   a[0]=='a' for j in 'a'   )", {}, dict(a='a'))
NameError: global name 'a' is not defined

----------
components: Interpreter Core
messages: 80469
nosy: fjhpy
severity: normal
status: open
title: name not found in generator in eval()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan 24 22:17:41 2009
From: report at bugs.python.org (Branden Moore)
Date: Sat, 24 Jan 2009 21:17:41 +0000
Subject: [New-bugs-announce] [issue5045] imaplib should remove length of
	literal strings
In-Reply-To: <1232831861.1.0.505003833235.issue5045@psf.upfronthosting.co.za>
Message-ID: <1232831861.1.0.505003833235.issue5045@psf.upfronthosting.co.za>


New submission from Branden Moore <bmoore-python at forkit.org>:

IMAP Literals are a tricky subject.  Currently, if IMAP returns:

* text text text {5}\r\n
12345more text

imaplib will return 2 data items:
[("text text text {5}", '12345'), "more text"]

This forces users of imaplib to then parse out and remove the '{5}' from
the first part of the tuple before appending the literal string.  It
would be nice to have imaplib strip the '{size}' portion of the string
in the first part of the tuple, so that the return value would be:
[("text text text ", '12345'), "more text"]

Though, because this entire response from the IMAP server should be
interpreted as a single line, it would be even better to return a
response such that 'data' is:
[(("text text text ", '12345'), "more text")]

a.k.a., a single 'data' item (only one IMAP response per data item) that
contains either a string or a tuple.  The tuple will contain either more
tuples and/or more strings.  Each sub-tuple here would contain two
strings, text, and the IMAP Literal String.

This would make parsing the responses from imaplib much more simple.  It
demarks obviously where IMAP Literal Strings are, and doesn't require
additional string parsing on the side of the imaplib user.

Thanks!

----------
components: Library (Lib)
messages: 80480
nosy: bmoore
severity: normal
status: open
title: imaplib should remove length of literal strings
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Jan 24 22:37:51 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 24 Jan 2009 21:37:51 +0000
Subject: [New-bugs-announce] [issue5046] native win32 and wine mingw+msys
	build of python2.7
In-Reply-To: <1232833071.31.0.670571476989.issue5046@psf.upfronthosting.co.za>
Message-ID: <1232833071.31.0.670571476989.issue5046@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

this is an update of the mingw+msys port for native win32,
with the aim of being both compiled and used under both
wine-win32 and native-win32.

it is not a cross-compile patch.  it does not require -lwine.
it does not require a unix system.  it does not require cygwin.
(repeat the previous four sentences for both build _and_ use
of the resultant python.exe).  this information is specifically
given and stated [so blandly] because several people have been
extremely confused by what this patch achieves, due to the
tools being utilised to achieve it [wine].

the patch is against svn trunk r68884.

as of 2 hours ago, the following tests failed:
22 tests failed:
    test_cmath test_cmd_line_script test_compiler test_ctypes
    test_decimal test_distutils test_file test_logging test_mailbox
    test_math test_ntpath test_os test_parser test_posixpath test_pwd
    test_smtplib test_startfile test_tempfile test_transformer
    test_winsound test_zipfile test_zipimport_support

since then, several have been corrected.  test_pwd should not be
being tested.  several of the tests (test_tempfile) are fails due
to use of native wine msvcrt (it gets better when win32 msvcrt
is used).

this is work-in-progress for those people interested.

builds with --enable-msvcr9build are possible.

incorporation of roumen's cross-compile work is ongoing.

----------
components: Build
files: python-2.7a0-r68884-mingw-msys.patch
keywords: patch
messages: 80481
nosy: lkcl
severity: normal
status: open
title: native win32 and wine mingw+msys build of python2.7
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file12849/python-2.7a0-r68884-mingw-msys.patch

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

From report at bugs.python.org  Sat Jan 24 22:40:47 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 24 Jan 2009 21:40:47 +0000
Subject: [New-bugs-announce] [issue5047] Remove Monterey support from
	configure.in
In-Reply-To: <20090124214044.37BA7D56A89@montanaro.dyndns.org>
Message-ID: <20090124214044.37BA7D56A89@montanaro.dyndns.org>


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

The attached patch removes vestiges of Monterey compiler support from
configure.in.  Apparently Monterey was some ill-conceived 64-bit SCO/IBM
operating system which died in 2000.  Can't see why we need to support it.

Skip

===File ~/src/python/trunk/configure.in.diff================
Index: configure.in
===================================================================
--- configure.in        (revision 68905)
+++ configure.in        (working copy)
@@ -216,7 +216,7 @@
 if test -z "$MACHDEP"
 then
        ac_sys_system=`uname -s`
-       if test "$ac_sys_system" = "AIX" -o "$ac_sys_system" = "Monterey64" \
+       if test "$ac_sys_system" = "AIX" \
        -o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
                ac_sys_release=`uname -v`
        else
@@ -438,9 +438,6 @@
                AR="\$(srcdir)/Modules/ar_beos"
                RANLIB=:
                ;;
-    Monterey*)
-        RANLIB=:
-        without_gcc=;;
        *)      without_gcc=no;;
        esac])
 AC_MSG_RESULT($without_gcc)
@@ -562,10 +559,6 @@
     case $CC in
     cc|*/cc) CC="$CC -Ae";;
     esac;;
-Monterey*)
-    case $CC in
-    cc) CC="$CC -Wl,-Bexport";;
-    esac;;
 SunOS*)
     # Some functions have a prototype only with that define, e.g. confstr
     AC_DEFINE(__EXTENSIONS__, 1, [Defined on Solaris to see additional function prototypes.])
@@ -626,8 +619,6 @@
               exp_extra="."
           fi
           LINKCC="\$(srcdir)/Modules/makexp_aix Modules/python.exp $exp_extra \$(LIBRARY); $LINKCC";;
-       Monterey64*)
-          LINKCC="$LINKCC -L/usr/lib/ia64l64";;
        QNX*)
           # qcc must be used because the other compilers do not
           # support -N.
@@ -855,15 +846,6 @@
        OPT="-O"
        ;;
     esac
-
-    # The current (beta) Monterey compiler dies with optimizations
-    # XXX what is Monterey? Does it still die w/ -O? Can we get rid of this?
-    case $ac_sys_system in
-       Monterey*)
-           OPT=""
-           ;;
-    esac
-
 fi

 AC_SUBST(BASECFLAGS)
@@ -1709,7 +1691,6 @@
                else LDSHARED='$(CC) -G'
                fi;;
        SCO_SV*) LDSHARED='$(CC) -Wl,-G,-Bexport';;
-       Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport -L/usr/lib/ia64l64";;
        CYGWIN*) LDSHARED="gcc -shared -Wl,--enable-auto-image-base";;
        atheos*) LDSHARED="gcc -shared";;
        *)      LDSHARED="ld";;
@@ -1746,7 +1727,6 @@
                then CCSHARED="-fPIC"
                else CCSHARED="-Kpic -belf"
                fi;;
-       Monterey*) CCSHARED="-G";;
        IRIX*/6*)  case $CC in
                   *gcc*) CCSHARED="-shared";;
                   *) CCSHARED="";;
============================================================

----------
messages: 80482
nosy: skip.montanaro
severity: normal
status: open
title: Remove Monterey support from configure.in

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

From report at bugs.python.org  Sun Jan 25 03:05:04 2009
From: report at bugs.python.org (Konrad)
Date: Sun, 25 Jan 2009 02:05:04 +0000
Subject: [New-bugs-announce] [issue5048] Extending itertools.combinations
In-Reply-To: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>
Message-ID: <1232849104.35.0.603860748572.issue5048@psf.upfronthosting.co.za>


New submission from Konrad <konryd at gmail.com>:

The function itertools.combinations might benefit from making
the 'r' (length of the combinations) argument optionally a sequence.

With that change one could call combinations(sequence, [2, 3]) in
order to get all combinations of length 2 and 3.
In particular, one could call combinations(sequence,
range(len(sequence)) in order to get *all* combinations of given
sequence.

The change would be backwards compatible as it would check for
sequential arguments.

----------
components: Library (Lib)
messages: 80492
nosy: konryd, rhettinger
severity: normal
status: open
title: Extending itertools.combinations
type: feature request

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

From report at bugs.python.org  Sun Jan 25 03:52:28 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 25 Jan 2009 02:52:28 +0000
Subject: [New-bugs-announce] [issue5049] ctypes unwilling to allow pickling
	wide character array
In-Reply-To: <1232851948.05.0.0363189700044.issue5049@psf.upfronthosting.co.za>
Message-ID: <1232851948.05.0.0363189700044.issue5049@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Using Python 2.6.1, I'm unable to pickle a simple object with an array
of wide characters.

import ctypes, pickle

class MyStruct(ctypes.Structure):
  _fields_ = [('name', ctypes.c_wchar*2)]

s = MyStruct('DC')

pickle.dumps(s) # raises ValueError.

Replace ctypes.c_wchar with ctypes.c_char and the pickling works fine.

----------
assignee: theller
components: ctypes
messages: 80493
nosy: jaraco, theller
severity: normal
status: open
title: ctypes unwilling to allow pickling wide character array
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Sun Jan 25 06:40:40 2009
From: report at bugs.python.org (Yu-Jie Lin)
Date: Sun, 25 Jan 2009 05:40:40 +0000
Subject: [New-bugs-announce] [issue5050] unicode(C) invokes C.__unicode__
	when __unicode__ is defined
In-Reply-To: <1232862040.08.0.372338675263.issue5050@psf.upfronthosting.co.za>
Message-ID: <1232862040.08.0.372338675263.issue5050@psf.upfronthosting.co.za>


New submission from Yu-Jie Lin <livibetter at gmail.com>:

Run the following code

class A:
  def __str__(self):
    return "__str__"
  def __unicode__(self):
    return "__unicode__"

a = A()

print str(a), unicode(a)
print str(A), unicode(A)

----

Results on Python 2.5.4 (r254:67916):
__str__ __unicode__
__main__.A
Traceback (most recent call last):
  File "/home/livibetter/tmp/unicode_classobj.py", line 14, in <module>
    print str(A), unicode(A)
TypeError: unbound method __unicode__() must be called with A instance
as first argument (got nothing instead)

Results on Python 2.6.1 (r261:67515):
__str__ __unicode__
__main__.A __main__.A

----

I was expecting the same result as on 2.6.1. By my observation,
unicode(C) tries to invoke C.__unicode__ if __unicode__ is defined in C,
where C is a class object.

I believe this behavior is incorrect.

----------
messages: 80496
nosy: livibetter
severity: normal
status: open
title: unicode(C) invokes C.__unicode__ when __unicode__ is defined
versions: Python 2.5

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

From report at bugs.python.org  Sun Jan 25 12:39:18 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 25 Jan 2009 11:39:18 +0000
Subject: [New-bugs-announce] [issue5051] test_update2 in test_os.py invalid
	due to os.environ.clear() followed by reliance on environ COMSPEC
In-Reply-To: <1232883558.71.0.175097990327.issue5051@psf.upfronthosting.co.za>
Message-ID: <1232883558.71.0.175097990327.issue5051@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

class EnvironTests(mapping_tests.BasicTestMappingProtocol):
    """check that os.environ object conform to mapping protocol"""
    type2test = None
    def _reference(self):
        return {"KEY1":"VALUE1", "KEY2":"VALUE2", "KEY3":"VALUE3"}
    def _empty_mapping(self):
                   vvvvvv
        os.environ.clear() <<<<<---------- *******
                   ^^^^^^
        return os.environ
    def setUp(self):
        self.__save = dict(os.environ)
        os.environ.clear()
    def tearDown(self):
        os.environ.clear()
        os.environ.update(self.__save)

    # Bug 1110478
    def test_update2(self):
        if os.path.exists("/bin/sh"):
            os.environ.update(HELLO="World")
                       vvvvv
            value = os.popen("/bin/sh -c 'echo $HELLO'").read().strip()
                       ^^^^^ finds os.environ['COMSPEC'] to be empty! 
            self.assertEquals(value, "World")


this test will obviously fail, see _PyPopenCreateProcess in
posixmodule.c.

    if (i = GetEnvironmentVariable("COMSPEC",NULL,0)) {
        char *comshell;

    }
    /* Could be an else here to try cmd.exe / command.com in the path
       Now we'll just error out.. */
    else {
        PyErr_SetString(PyExc_RuntimeError,
            "Cannot locate a COMSPEC environment variable to "
            "use as the shell");
        return FALSE;
    }


the environment variables having been destroyed, there _is_ no
COMSPEC to obtain a working cmd.exe or command.com in order to
execute the /bin/sh (or /bin/sh.exe in the case of having installed
msys and created a symlink from c:/msys/bin to c:/bin).

----------
components: Tests
messages: 80502
nosy: lkcl
severity: normal
status: open
title: test_update2 in test_os.py invalid due to os.environ.clear() followed by reliance on environ COMSPEC
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 25 14:18:38 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 13:18:38 +0000
Subject: [New-bugs-announce] [issue5052] "This module should be kept
	compatible with Python 2.1." in distutils code
In-Reply-To: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>
Message-ID: <1232889518.53.0.767329174887.issue5052@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

In distutils package, there are many files that saying
"This module should be kept compatible with Python 2.1."

According to Tarek Ziad?, this is not valid statement anymore.

----------
components: Distutils
messages: 80507
nosy: akitada
severity: normal
status: open
title: "This module should be kept compatible with Python 2.1." in distutils code
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 25 16:24:33 2009
From: report at bugs.python.org (Mike Watkins)
Date: Sun, 25 Jan 2009 15:24:33 +0000
Subject: [New-bugs-announce] [issue5053]
	http.client.HTTPMessage.getallmatchingheaders()
In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>
Message-ID: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za>


New submission from Mike Watkins <python at mikewatkins.ca>:

HTTPMessage.getallmatchingheaders() stopped working sometime after 
Python 3.0 release. In a recent (1 day ago) svn update the 
implementation says the method was copied from rfc822.message; the 
Python 3.x implementation is broken (iterates through self.keys instead 
of header values). I've not looked back to see where the change was 
introduced but I do know that it broke post 3.0 release.

But more importantly than the flaw in this method, the functionality is 
duplicated elsewhere in Python 3.x.

I propose either deprecating getallmatchingheaders() or if it is to be 
kept for compatibility, the fix can be simply replacing the method body 
with:

self.get_all(name)

The docstring for get_all (defined in email.message) affirms that its 
output is indeed compatible with that which was intended for 
getallmatchingheaders().

get_all(self, name, failobj=None) method of client.HTTPMessage instance
    Return a list of all the values for the named field.
    
    These will be sorted in the order they appeared in the original
    message, and may contain duplicates.  Any fields deleted and
    re-inserted are always appended to the header list.
    
    If no such fields exist, failobj is returned (defaults to None).

I've tested the use of get_all against one web server (QP) which runs on 
both Python 2.x and 3.x.

As a result of the broken getallmatchingheaders() the QP web server now 
uses for the same purpose as getallmatchingheaders() instead: 
get_all(name) (defined in email.message.Message in Py3k and 
getheaders(name) (defined in rfc822.Message).

See also issues on documentation and changed API in #4773, #3428

----------
components: Library (Lib)
messages: 80509
nosy: mwatkins
severity: normal
status: open
title: http.client.HTTPMessage.getallmatchingheaders()
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 25 16:30:03 2009
From: report at bugs.python.org (Mike Watkins)
Date: Sun, 25 Jan 2009 15:30:03 +0000
Subject: [New-bugs-announce] [issue5054] CGIHTTPRequestHandler.run_cgi()
	HTTP_ACCEPT improperly parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>


New submission from Mike Watkins <python at mikewatkins.ca>:

There appears to have been a bug in how HTTP_ACCEPT is parsed living in 
run_cgi() for eons, perhaps from the time it was written. Perhaps not 
many are using this code (I'm not either) but recent (post 3.0 Release) 
Python 3.x appear to have broken something in getallmatchingheaders() 
(which originates in Message) and I happened to stumble upon this 
condition while searching through the stdlib code.

>From Line 980 of http.server

        accept = []
        for line in self.headers.getallmatchingheaders('accept'):
            if line[:1] in "\t\n\r ":
                accept.append(line.strip())
            else:
                accept = accept + line[7:].split(',')
        env['HTTP_ACCEPT'] = ','.join(accept)


line[:1] in '\t\n\r' clearly was meant to to be line[-1].

However that doesn't fix completely this chunk of code as it makes some 
assumptions about what getallmatchingheaders() delivers which aren't 
accurate. The following behaves as expected and feels safer:

        accept = []
        for line in self.headers.getallmatchingheaders('accept'):
            if line.lower().startswith("accept:"):
                line = line[7:]
            for part in line.split(','):
                part = part.strip()
                if part:
                    accept.append(part)
        env['HTTP_ACCEPT'] = ','.join(accept)


Note that post Python 3.0 release, 
http.client.HTTPMessage.getallmatchingheaders() was broken. I've 
reported this just now and proposed a fix in #5053.

----------
components: Library (Lib)
messages: 80510
nosy: mwatkins
severity: normal
status: open
title: CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Sun Jan 25 16:51:32 2009
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 25 Jan 2009 15:51:32 +0000
Subject: [New-bugs-announce] [issue5055] Distutils-SIG page needs to be
	updated
In-Reply-To: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>
Message-ID: <1232898692.96.0.502384561785.issue5055@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Distutils-SIG page [1] and links there are considerably outdated.
They need to be updated to reflect current situation.

[1] http://www.python.org/community/sigs/current/distutils-sig/

----------
assignee: georg.brandl
components: Distutils, Documentation
messages: 80512
nosy: akitada, georg.brandl
severity: normal
status: open
title: Distutils-SIG page needs to be updated

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

From report at bugs.python.org  Sun Jan 25 17:08:14 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 25 Jan 2009 16:08:14 +0000
Subject: [New-bugs-announce] [issue5056] PyAPI assumes OS can access shared
	data in loadable modules (windows can't)
In-Reply-To: <1232899694.31.0.93225965153.issue5056@psf.upfronthosting.co.za>
Message-ID: <1232899694.31.0.93225965153.issue5056@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

an assumption has been made in the python core api that all operating
systems "dynamic module loading" can access data segments.  windows
_cannot_ do this.

the "workaround" has been to statically link absolutely _everything_
into a single whopping great dll.

the proper solution is to provide "accesser" functions:

PyAPI_FUNC(PyObject *)
PyErr_GetPyExc_OSError(void)
{
    return (PyObject*)PyExc_OSError;
}

PyAPI_FUNC(char*) _PyStructSequence_Get_UnnamedField(void)
{   
    return PyStructSequence_UnnamedField;
}

... actually the _best_ solution is to have everything that's needed in
a vector-table [discussed on python-dev mailing list]

----------
components: Build
messages: 80513
nosy: lkcl
severity: normal
status: open
title: PyAPI assumes OS can access shared data in loadable modules (windows can't)
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 25 17:16:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Jan 2009 16:16:12 +0000
Subject: [New-bugs-announce] [issue5057] Unicode-width dependent
	optimization leads to non-portable pyc file
In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>
Message-ID: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za>


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

The peephole optimizer can optimize indexed access to an unicode
constant which does not give the same result in UCS-2 and UCS-4 builds.
As a result, the pyc file is not portable across those builds.

This is something I witnessed when recompiling in UCS-2 rather than
UCS-4 mode, and having a strange failure in test_multibytecodec. Erasing
test_multibytecodec.pyc suppressed the failure.

Here is a small demonstration of the problem:

>>> def f():
...  return '\U00012345'[0]
... 
>>> import dis
>>> dis.dis(f)
  2           0 LOAD_CONST               3 ('\ud808') 
              3 RETURN_VALUE         


For reference, here is the error I had in test_multibytecodec:

======================================================================
FAIL: test_gb18030 (test.test_multibytecodec.Test_StreamWriter)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_multibytecodec.py",
line 185, in test_gb18030
    self.assertEqual(s.getvalue(), b'123\x907\x959')
AssertionError: b'123\x907\x959\x907\x959' != b'123\x907\x959'

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

----------
components: Interpreter Core
messages: 80514
nosy: pitrou, rhettinger
severity: normal
status: open
title: Unicode-width dependent optimization leads to non-portable pyc file
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Jan 25 19:15:01 2009
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 25 Jan 2009 18:15:01 +0000
Subject: [New-bugs-announce] [issue5058] stop pgen.exe from generating
	CRLF-ended files and causing mayhem with win32-based patch
	submissions
In-Reply-To: <1232907301.06.0.0381974721982.issue5058@psf.upfronthosting.co.za>
Message-ID: <1232907301.06.0.0381974721982.issue5058@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

diff --git a/Parser/pgenmain.c b/Parser/pgenmain.c
index fc27a2c..a4d4911 100644
--- a/Parser/pgenmain.c
+++ b/Parser/pgenmain.c
@@ -49,7 +49,7 @@ main(int argc, char **argv)
        graminit_h = argv[2];
        graminit_c = argv[3];
        g = getgrammar(filename);
-       fp = fopen(graminit_c, "w");
+       fp = fopen(graminit_c, "wb");
        if (fp == NULL) {
                perror(graminit_c);
                Py_Exit(1);
@@ -58,7 +58,7 @@ main(int argc, char **argv)
                printf("Writing %s ...\n", graminit_c);
        printgrammar(g, fp);
        fclose(fp);
-       fp = fopen(graminit_h, "w");
+       fp = fopen(graminit_h, "wb");
        if (fp == NULL) {
                perror(graminit_h);
                Py_Exit(1);
@@ -79,7 +79,7 @@ getgrammar(char *filename)
        grammar *g0, *g;
        perrdetail err;
        
-       fp = fopen(filename, "r");
+       fp = fopen(filename, "rb");
        if (fp == NULL) {
                perror(filename);
                Py_Exit(1);

----------
components: Build
messages: 80517
nosy: lkcl
severity: normal
status: open
title: stop pgen.exe from generating CRLF-ended files and causing mayhem with win32-based patch submissions
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 25 20:45:56 2009
From: report at bugs.python.org (Attila Babo)
Date: Sun, 25 Jan 2009 19:45:56 +0000
Subject: [New-bugs-announce] [issue5059] Policy.DomainStrict in cookielib
	example code
In-Reply-To: <1232912756.19.0.0105064644084.issue5059@psf.upfronthosting.co.za>
Message-ID: <1232912756.19.0.0105064644084.issue5059@psf.upfronthosting.co.za>


New submission from Attila Babo <attila.babo at gmail.com>:

Example code at the bottom of cookielib documentation has an error:
policy = DefaultCookiePolicy(
    rfc2965=True, strict_ns_domain=Policy.DomainStrict,
    blocked_domains=["ads.net", ".ads.net"])

The corrected version is
policy = DefaultCookiePolicy(
    rfc2965=True, strict_ns_domain= DefaultCookiePolicy.DomainStrict,
    blocked_domains=["ads.net", ".ads.net"])

----------
assignee: georg.brandl
components: Documentation
messages: 80535
nosy: babo, georg.brandl
severity: normal
status: open
title: Policy.DomainStrict in cookielib example code
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sun Jan 25 21:18:38 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 25 Jan 2009 20:18:38 +0000
Subject: [New-bugs-announce] [issue5060] gcc profile guided optimization
In-Reply-To: <1232914718.3.0.0101941779254.issue5060@psf.upfronthosting.co.za>
Message-ID: <1232914718.3.0.0101941779254.issue5060@psf.upfronthosting.co.za>


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

The make target "run_profile_task" fail as executable cannot load shared
library. Patch attached.

----------
files: py-issue-profile.patch
keywords: patch
messages: 80537
nosy: rpetrov
severity: normal
status: open
title: gcc profile guided optimization
Added file: http://bugs.python.org/file12859/py-issue-profile.patch

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

From report at bugs.python.org  Mon Jan 26 00:41:42 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 25 Jan 2009 23:41:42 +0000
Subject: [New-bugs-announce] [issue5061] Inadequate documentation of the
	built-in function open
In-Reply-To: <1232926902.91.0.899964022103.issue5061@psf.upfronthosting.co.za>
Message-ID: <1232926902.91.0.899964022103.issue5061@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Documentation of the mode parameter of the built-in function open is 
insufficient with respect to what values are acceptable.

(1) Right after the mode table, it states "For binary random access, the 
mode 'w+b' opens and truncates the file to 0 bytes, while 'r+b' opens 
the file without truncation." This is true of text random access too -- 
w+ or r+. Furthermore, the possibility of a+, while meaningful, is not 
mentioned.

(2) The documentation does not, but should, say that while w/r/a with or 
without the plus can appear without a 'b' or 't', a plain 'b' as the 
mode valuable raises an error that r/w/a wasn't specified.

(3) The documentation does not, but should, say that + cannot stand on 
its own -- the mode must also include an r, w, or a. The table listing 
the meanings of each value just says + means "open a disk file for 
updating (reading and writing)". Suggested rewording is to put the 
phrase "in conjunction with 'r', 'w', or 'a', open a disk file...". 
Alternatively, add a note to that table entry and explain below that the 
plus must accompany a r/w/a.

----------
assignee: georg.brandl
components: Documentation
messages: 80549
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Inadequate documentation of the built-in function open
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Mon Jan 26 02:28:58 2009
From: report at bugs.python.org (Carl Johnson)
Date: Mon, 26 Jan 2009 01:28:58 +0000
Subject: [New-bugs-announce] [issue5062] Rlcompleter.Completer does not use
	__dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>


New submission from Carl Johnson <carl at carlsensei.com>:

The documentation at http://docs.python.org/library/rlcompleter.html
claims that

Completer.complete(text, state)?

   Return the state*th completion for *text.

   If called for text that doesn?t include a period character ('.'), it
will complete from names currently defined in __main__, __builtin__ and
keywords (as defined by the keyword module).

   If called for a dotted name, it will try to evaluate anything without
obvious side-effects (functions will not be evaluated, but it can
generate calls to __getattr__()) up to the last part, and find matches
for the rest via the dir() function. Any exception raised during the
evaluation of the expression is caught, silenced and None is returned.

In other words, it claims to use dir(obj) as part of the tab completion
process. This is not true (using Python 2.6.1 on OS X):

>>> class B(object):
...  def __dir__(self): return dir(u"") #Makes B objects look like strings
...
>>> b = B()
>>> dir(b)
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__',
'__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__',
'__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__',
'__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
'_formatter_field_name_split', '_formatter_parser', 'capitalize',
'center', 'count', 'decode', 'encode', 'endswith', 'expandtabs', 'find',
'format', 'index', 'isalnum', 'isalpha', 'isdecimal', 'isdigit',
'islower', 'isnumeric', 'isspace', 'istitle', 'isupper', 'join',
'ljust', 'lower', 'lstrip', 'partition', 'replace', 'rfind', 'rindex',
'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines',
'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']
>>> c = rlcompleter.Completer()
>>> c.complete("b.", 0) #Notice that it does NOT return __add__
u'b.__class__('
>>> c.matches #Notice that this list is completely different from the
list given by dir(b)
[u'b.__class__(', u'b.__delattr__(', u'b.__doc__', u'b.__format__(',
u'b.__getattribute__(', u'b.__hash__(', u'b.__init__(', u'b.__new__(',
u'b.__reduce__(', u'b.__reduce_ex__(', u'b.__repr__(',
u'b.__setattr__(', u'b.__sizeof__(', u'b.__str__(',
u'b.__subclasshook__(', u'b.__class__(', u'b.__class__(',
u'b.__delattr__(', u'b.__dict__', u'b.__dir__(', u'b.__doc__',
u'b.__format__(', u'b.__getattribute__(', u'b.__hash__(',
u'b.__init__(', u'b.__module__', u'b.__new__(', u'b.__reduce__(',
u'b.__reduce_ex__(', u'b.__repr__(', u'b.__setattr__(',
u'b.__sizeof__(', u'b.__str__(', u'b.__subclasshook__(',
u'b.__weakref__', u'b.__class__(', u'b.__delattr__(', u'b.__doc__',
u'b.__format__(', u'b.__getattribute__(', u'b.__hash__(',
u'b.__init__(', u'b.__new__(', u'b.__reduce__(', u'b.__reduce_ex__(',
u'b.__repr__(', u'b.__setattr__(', u'b.__sizeof__(', u'b.__str__(',
u'b.__subclasshook__(']

Suggested course of action: 

* Change the documentation for Python 2.6/3.0.
* Update Completer to use __dir__ in Pythons 2.7/3.1 and revert the
documentation.

See
http://mail.python.org/pipermail/python-dev/2009-January/thread.html#85471

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 80556
nosy: carlj, georg.brandl
severity: normal
status: open
title: Rlcompleter.Completer does not use __dir__ magic method
type: behavior
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Jan 26 04:07:30 2009
From: report at bugs.python.org (Patrick Toal)
Date: Mon, 26 Jan 2009 03:07:30 +0000
Subject: [New-bugs-announce] [issue5063] python-2.6.spec doesn't build
	properly
In-Reply-To: <1232939250.95.0.104379121936.issue5063@psf.upfronthosting.co.za>
Message-ID: <1232939250.95.0.104379121936.issue5063@psf.upfronthosting.co.za>


New submission from Patrick Toal <ptoal at takeflight.ca>:

Attempting to build an RPM with the python-2.6.spec contained in the 
python-2.6.1 distribution tar fails.  The following diff's enabled me to 
cleanly build the rpm's on a standard CentOS 5.1 installation.

----------
components: Build
files: python-2.6.1.spec.diff
keywords: patch
messages: 80558
nosy: ptoal
severity: normal
status: open
title: python-2.6.spec doesn't build properly
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12863/python-2.6.1.spec.diff

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

From report at bugs.python.org  Mon Jan 26 04:25:44 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 26 Jan 2009 03:25:44 +0000
Subject: [New-bugs-announce] [issue5064] compiler.parse raises SyntaxErrors
	without line number information
In-Reply-To: <1232940344.37.0.615917855536.issue5064@psf.upfronthosting.co.za>
Message-ID: <1232940344.37.0.615917855536.issue5064@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

Sometimes a syntax error in source passed to `compiler.parse? causes a
`SyntaxError? with lots of nice information to be raised:

>>> from compiler import parse
>>> try:
...     parse("def f(")
... except SyntaxError, e:
...     pass
...
>>> e
SyntaxError('unexpected EOF while parsing', (None, 1, 6, 'def f('))

But for other syntax errors, only a string message is provided, no
location information:

>>> try:
...     parse("def f(x=10, y): pass")
... except SyntaxError, f:
...     pass
...
>>> f
SyntaxError('non-default argument follows default argument',)
>>> try:
...     parse("f(x=10, y)")
... except SyntaxError, g:
...     pass
...
>>> g
SyntaxError('non-keyword arg after keyword arg',)
>>> 

On the other hand, the built in compiler produces exceptions which do
have this information in these cases.

The absence of the information makes the job of tools trying to operate
on Python source code more difficult (naively written, they'll simply
fail when they encounter one of these less informative exceptions).

----------
components: Library (Lib)
messages: 80559
nosy: exarkun
severity: normal
status: open
title: compiler.parse raises SyntaxErrors without line number information
type: behavior

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

From report at bugs.python.org  Mon Jan 26 04:47:08 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Jan 2009 03:47:08 +0000
Subject: [New-bugs-announce] [issue5065] IDLE improve Subprocess Startup
	Error message
In-Reply-To: <1232941628.82.0.541445606335.issue5065@psf.upfronthosting.co.za>
Message-ID: <1232941628.82.0.541445606335.issue5065@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

When launching IDLE, it reports:

"IDLE's subprocess didn't make connection. Either IDLE can't start a 
subprocess or personal firewall software is blocking the connection."

This should report what needs to be opened on the firewall to allow 
the connection, e.g. "Allow UDP/TCP connections to 127.0.0.1 on ports 
FOO and BAR and try again".

----------
components: IDLE
messages: 80560
nosy: stevenjd
severity: normal
status: open
title: IDLE improve Subprocess Startup Error message
type: feature request

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

From report at bugs.python.org  Mon Jan 26 04:56:57 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Jan 2009 03:56:57 +0000
Subject: [New-bugs-announce] [issue5066] IDLE documentation for Unix
	obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

Documentation for IDLE states:

    Starting IDLE on UNIX 
    On Unix, just type "idle" at a command prompt. This should bring
    up a Window similar to the one above. (If it doesn't, look for
    the "idle" script in the Tools/idle directory in the Python source
    distribution.)

http://www.python.org/idle/doc/idlemain.html

I believe that is obsolete, I cannot see a Tools/idle directory in 
either 2.5 or 2.6. Perhaps better instructions might be:

    (If it doesn't, run "python LOC/idlelib/idle.py" where LOC 
    is the location of your Python source distribution, usually 
    /usr/lib/python*.)

or similar.

----------
assignee: georg.brandl
components: Documentation, IDLE
messages: 80562
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: IDLE documentation for Unix obsolete/incorrect

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

From report at bugs.python.org  Mon Jan 26 07:24:33 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Jan 2009 06:24:33 +0000
Subject: [New-bugs-announce] [issue5067] Error msg from using wrong quotes
	in JSON is unhelpful
In-Reply-To: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za>
Message-ID: <1232951073.6.0.548540602901.issue5067@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

Using the wrong sort of quotes in json gives unhelpful error messages:

>>> json.loads("{'test':'test'}")
Traceback (most recent call last):
  ...
ValueError: Expecting property name: line 1 column 1 (char 1)

Unless you know that strings in JSON must be delimited with 
double-quotes and not single (a very surprising fact to those used to 
Python) this error message is perplexing. I suggest something like:

Single-quoted strings are invalid property names: line 1 column 1 
(char 1)

or 

Parse error, invalid char: line 1, column 1 (char 1)

----------
messages: 80564
nosy: stevenjd
severity: normal
status: open
title: Error msg from using wrong quotes in JSON is unhelpful
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 26 12:08:31 2009
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Mon, 26 Jan 2009 11:08:31 +0000
Subject: [New-bugs-announce] [issue5068] tarfile loops forever on broken
	input
In-Reply-To: <1232968111.2.0.128325452145.issue5068@psf.upfronthosting.co.za>
Message-ID: <1232968111.2.0.128325452145.issue5068@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

I have troubles actually finding such a file, but I encountered it at
least once (file is gone by now though). The lines in question are for
bz2 compression:

in _BZ2Proxy.read:

            try:
                raw = self.fileobj.read(self.blocksize)
                data = self.bz2obj.decompress(raw)
                b.append(data)
            except EOFError:
                break

if it ever goes here (after finishing reading header) and data is
truncated, fileobj.read() will return 0 and data will be '' and
so on forever.

----------
components: Library (Lib)
messages: 80567
nosy: fijal
severity: normal
status: open
title: tarfile loops forever on broken input
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Jan 26 15:18:13 2009
From: report at bugs.python.org (=?utf-8?q?=CE=A7=CF=81=CE=AE=CF=83=CF=84=CE=BF=CF=82_=CE=93=CE=B5=CF=89=CF=81=CE=B3=CE=AF=CE=BF=CF=85_(Christos_Georgiou)?=)
Date: Mon, 26 Jan 2009 14:18:13 +0000
Subject: [New-bugs-announce] [issue5069] Use sets instead of list in
	posixpath._resolve_link
In-Reply-To: <1232979493.22.0.551586556821.issue5069@psf.upfronthosting.co.za>
Message-ID: <1232979493.22.0.551586556821.issue5069@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:

The paths_seen object is a list; a set is more appropriate, since its
main use is a lookup as in "path in paths_seen"

----------
components: Library (Lib)
files: posixpath.diff
keywords: patch
messages: 80570
nosy: tzot
severity: normal
status: open
title: Use sets instead of list in posixpath._resolve_link
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file12867/posixpath.diff

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

From report at bugs.python.org  Mon Jan 26 17:01:06 2009
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 26 Jan 2009 16:01:06 +0000
Subject: [New-bugs-announce] [issue5070] Distutils should create install dir
	if needed
In-Reply-To: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>
Message-ID: <1232985666.7.0.224838813352.issue5070@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

If you attempt to call "python setup.py install --prefix=/foo", and
/foo/lib/pythonX.Y/site-packages does not exist, the installation will
fail, requiring that the directory be made by hand.

Since there is no easy way to know in advance (other than by running
Python to build the version number string) exactly where the install
will go, this can be troublesome for automated build scripts. For this
reason, and also to be more consistent with existing build/install
systems like autotools, I suggest that distutils builds the necessary
portions of the lib directory tree (provided /foo exists). This should
certainly happen (IMHO) if the --force option is given.

----------
components: Distutils
messages: 80573
nosy: andybuckley
severity: normal
status: open
title: Distutils should create install dir if needed
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Mon Jan 26 17:10:21 2009
From: report at bugs.python.org (Andy Buckley)
Date: Mon, 26 Jan 2009 16:10:21 +0000
Subject: [New-bugs-announce] [issue5071] Distutils should not fail if
	install dir is not in PYTHONPATH
In-Reply-To: <1232986221.07.0.343484520205.issue5071@psf.upfronthosting.co.za>
Message-ID: <1232986221.07.0.343484520205.issue5071@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

At present, distutils exits with an error return code if the directory
that modules are being installed into is not in PYTHONPATH. Since the
install path is not easily obtained (it at least requires running Python
to work out the version string, plus some guesswork about "lib" vs.
"lib64", etc. etc.), it would be nice if this was not a blocking
problem... at least when the --force flag is passed to setup.py

(PS. It would be nice if there *is* a way to get the installation path
from distutils before installing, for the reasons mentioned: that way
automatic install scripts like the one I'm managing could work out the
path, make it and add it to the PYTHONPATH, without worrying about
getting it wrong. Am I just missing something that already exists?)

----------
components: Distutils
messages: 80576
nosy: andybuckley
severity: normal
status: open
title: Distutils should not fail if install dir is not in PYTHONPATH
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Mon Jan 26 20:22:54 2009
From: report at bugs.python.org (Olemis Lang)
Date: Mon, 26 Jan 2009 19:22:54 +0000
Subject: [New-bugs-announce] [issue5072] urllib.open sends full URL after
	GET command instead of local path
In-Reply-To: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>
Message-ID: <1232997774.08.0.438260332945.issue5072@psf.upfronthosting.co.za>


New submission from Olemis Lang <olemis at gmail.com>:

Hello ... 

The first thing I have to say is that I searched the open issues and I 
found nothing similar to what I am going to report hereinafter. If this 
ticket is duplicate , I apologize ...

Yesterday I was testing how to access the wiki pages in a 
Trac [1]_ site and I realized that something wrong was happening 
(a bug? ...)

Initially the behavior was as follows :

{{{
#!python
>>> u = urllib.urlopen('http://localhost:8000/trac-dev')
>>> u.read()
'Environment not found'
>>> u.close()
}}}

And tracd reported a line like this 

{{{
127.0.0.1 - - [25/Jan/2009 17:32:08] "GET http://localhost:8000/trac-
dev HTTP/1.0" 404 -
}}}

Which means that a 'Not found' error code was sent back to urllib 
client.

I tried to access the same page from my browser and tracd reported

{{{
127.0.0.1 - - [25/Jan/2009 18:05:44] "GET /trac-dev HTTP/1.0" 200 -
}}}

The problem is obvious ... urllib was sending the full URL after GET
and it should send only the string after the network location.

I applied the following patch to urllib (yours will be better, I am 
sure about that ;)

{{{
#!diff

--- /usr/lib/python2.5/urllib.py        2008-07-31 13:40:40.000000000 
-0500
+++ /media/urllib_unix.py     2009-01-26 09:48:54.000000000 -0500
@@ -270,6 +270,7 @@
     def open_http(self, url, data=None):
         """Use HTTP protocol."""
         import httplib
+        from urlparse import urlparse
         user_passwd = None
         proxy_passwd= None
         if isinstance(url, str):
@@ -312,12 +313,17 @@
         else:
             auth = None
         h = httplib.HTTP(host)
+        target = ''.join(sep + part for sep, part in \
+                                zip(['', ';', '?', '#'], \
+                                    urlparse(selector)[2:]) \
+                                if part)
+        print target
         if data is not None:
-            h.putrequest('POST', selector)
+            h.putrequest('POST', target)
             h.putheader('Content-Type', 'application/x-www-form-
urlencoded')
             h.putheader('Content-Length', '%d' % len(data))
         else:
-            h.putrequest('GET', selector)
+            h.putrequest('GET', target)
         if proxy_auth: h.putheader('Proxy-Authorization', 'Basic %s' % 
proxy_auth)
         if auth: h.putheader('Authorization', 'Basic %s' % auth)
         if realhost: h.putheader('Host', realhost)


}}}

And everithing was ?back? to normal ...

{{{
#!python
>>> u = urllib.urlopen('http://localhost:8000/trac-dev')
>>> u.read()
    ... # Lots of beautiful HTML code ;)
>>> u.close()
}}}

... tracd outputted ...

{{{
127.0.0.1 - - [25/Jan/2009 18:05:44] "GET /trac-dev HTTP/1.0" 200 -
}}}

The same picture is shown when using both Python 2.5.1 and 2.5.2 ...
I have not installed Python 2.6.x so I am not sure about whether this
issue has propagated onto newer versions of Python ... and I don't 
know euther if this issue is also present in urllib2 or not ...

... so further research is needed, but IMO this is a serious bug :(

PD: If this is a bug ... how could it be hidden so far ? Is there any 
    test case written to assert this kind of things ? I checked out 
    `test.test_urllib` and `test.test_urllibnet` modules and I saw
    nothing at all ... 

.. [1] Trac
       (http://trac.edgewall.org)

----------
components: Library (Lib)
messages: 80586
nosy: olemis
severity: normal
status: open
title: urllib.open sends full URL after GET command instead of local path
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Jan 26 21:20:17 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 26 Jan 2009 20:20:17 +0000
Subject: [New-bugs-announce] [issue5073] bsddb/test/test_lock.py sometimes
	fails due to floating point error
In-Reply-To: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>
Message-ID: <1233001217.88.0.560168543661.issue5073@psf.upfronthosting.co.za>


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

time.time() returns floating point, so sometimes folloing assertion in 
LockingTestCase#test03_lock_timeout fails due to floating point 
calculation error.

>self.assertTrue((end_time-start_time) >= 0.1

end_time-start_time becomes 0.0999999046326 for instance. I ran 
test_lock.py 100 times after applied the attached patch, I saw no error.

----------
components: Tests
files: test_lock.patch
keywords: patch
messages: 80589
nosy: ocean-city
severity: normal
status: open
title: bsddb/test/test_lock.py sometimes fails due to floating point error
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12869/test_lock.patch

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

From report at bugs.python.org  Tue Jan 27 04:02:25 2009
From: report at bugs.python.org (Poor Yorick)
Date: Tue, 27 Jan 2009 03:02:25 +0000
Subject: [New-bugs-announce] [issue5074] python3 and ctypes,
	script causes crash
In-Reply-To: <1233025345.07.0.118465005013.issue5074@psf.upfronthosting.co.za>
Message-ID: <1233025345.07.0.118465005013.issue5074@psf.upfronthosting.co.za>


New submission from Poor Yorick <pooryorick at users.sourceforge.net>:

the following script causes python3 to crash on my Windows XP Pro  Machine:

import ctypes

b = ctypes.windll.Kernel32
var1 = 'TEMP'
out = ctypes.create_string_buffer(40) 
c = b.GetEnvironmentVariableW(var1,out,40)
print('ones', c, out, out.raw)
print('two: ', dir(out))

----------
assignee: theller
components: ctypes
messages: 80611
nosy: pooryorick, theller
severity: normal
status: open
title: python3 and ctypes, script causes crash
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Tue Jan 27 06:00:33 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 05:00:33 +0000
Subject: [New-bugs-announce] [issue5075] bdist_wininst should not depend on
	the vc runtime?
In-Reply-To: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>
Message-ID: <1233032433.27.0.524413230524.issue5075@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

After consideration of issue 4120 and issue 4566, it seems to me that
executables created by bdist_wininst will have a manifest referencing
the MSVC9 assembly, and thus will be in a similar position to the .pyd
files in issue 4120 - that unless the assembly is installed globally or
next to the executable itself, the executable will not start.  Note that
I have not verified this, but have verified the final installer
executable references the CRT assembly, and given those other bugs,
expect it to be true.

It seems to me a reasonable solution would be to have the bdist_wininst
stub use a static copy of the C runtime library.  While this means 2
copies of the CRT will eventually be loaded and would otherwise be
considered evil, the way the stub dynamically loads Python and the few
API functions it uses means it might be reasonable in this case.  Would
the trivial patch which achieves this be desired?

----------
assignee: mhammond
components: Distutils
messages: 80620
nosy: mhammond
severity: normal
status: open
title: bdist_wininst should not depend on the vc runtime?
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jan 27 07:03:15 2009
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 27 Jan 2009 06:03:15 +0000
Subject: [New-bugs-announce] [issue5076] bdist_wininst fails on py3k
In-Reply-To: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>
Message-ID: <1233036195.14.0.569948424976.issue5076@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

bdist_wininst installers created by py3k fail due to PySys_SetArgv and
Py_SetProgramName both being passed 'char *' strings instead of wide
strings.

The patch is against the svn trunk as currently Python 2.x and 3.x share
the same bdist_wininst stub.  The patch doesn't change the behaviour on
Python 2.x, and continues to allow the same executable stub to be
shared, as the appropriate signature is determined at runtime based on
the Python version.

The patch does not include the 2 new stub executables required
(wininst-9.0.exe and wininst-9.0-amd64.exe), but the patch *and* the new
stub executables should be merged into whatever py3k branches are
appropriate.  I've tested (pywin32) installers based on the new stub on
python 2.6 32bit, and python 3.0 32 and 64bit.

----------
assignee: mhammond
components: Distutils
files: wininst_py3k.patch
keywords: needs review, patch, patch
messages: 80622
nosy: mhammond
priority: high
severity: normal
stage: commit review
status: open
title: bdist_wininst fails on py3k
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12873/wininst_py3k.patch

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

From report at bugs.python.org  Tue Jan 27 07:13:38 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 27 Jan 2009 06:13:38 +0000
Subject: [New-bugs-announce] [issue5077] 2to3 fixers for the removal of
	operator functions
In-Reply-To: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>
Message-ID: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>


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

This is a 2to3 fixer for the removal of obsolete functions in r68962.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_operator.py
messages: 80624
nosy: alexandre.vassalotti
severity: normal
stage: patch review
status: open
title: 2to3 fixers for the removal of operator functions
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12874/fix_operator.py

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

From report at bugs.python.org  Tue Jan 27 11:33:34 2009
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Tue, 27 Jan 2009 10:33:34 +0000
Subject: [New-bugs-announce] [issue5078] Avoid redundant call to
	FormatError()
In-Reply-To: <1233052414.48.0.581929509045.issue5078@psf.upfronthosting.co.za>
Message-ID: <1233052414.48.0.581929509045.issue5078@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

For a background, see the developers' mailing list from 2009-01-26,
subject "FormatError() in callproc.c under win32". The attached patch
removes the redundant call to FormatError(). It also makes
SetException() a static function, since it is only used locally.

----------
assignee: theller
components: ctypes
files: Python-redundant-FormatError-call.0.patch
keywords: patch
messages: 80641
nosy: eckhardt, theller
severity: normal
status: open
title: Avoid redundant call to FormatError()
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file12876/Python-redundant-FormatError-call.0.patch

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

From report at bugs.python.org  Tue Jan 27 12:09:37 2009
From: report at bugs.python.org (Tom Lynn)
Date: Tue, 27 Jan 2009 11:09:37 +0000
Subject: [New-bugs-announce] [issue5079] time.ctime docs refer to "time
	tuple" for default
In-Reply-To: <1233054577.95.0.996547748761.issue5079@psf.upfronthosting.co.za>
Message-ID: <1233054577.95.0.996547748761.issue5079@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

The docs for time.ctime() (quoted below) seem to have been copied from 
time.asctime(). They refer to a time tuple and localtime(), where they 
should refer to seconds and time().

Current docs::

    ctime(seconds) -> string
    
    Convert a time in seconds since the Epoch to a string in local time.
    This is equivalent to asctime(localtime(seconds)). When the time 
    tuple is not present, current time as returned by localtime() is 
    used.

----------
messages: 80644
nosy: tlynn
severity: normal
status: open
title: time.ctime docs refer to "time tuple" for default

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

From report at bugs.python.org  Tue Jan 27 13:23:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 27 Jan 2009 12:23:57 +0000
Subject: [New-bugs-announce] [issue5080] PyArg_Parse* should raise TypeError
	for float parsed with integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Since Python 2.3, PyArg_ParseTuple and friends give a DeprecationWarning
for floating-point arguments where integers are expected.  From
http://www.python.org/download/releases/2.3/NEWS.txt:

- The PyArg_Parse functions now issue a DeprecationWarning if a float
  argument is provided when an integer is specified (this affects the 'b',
  'B', 'h', 'H', 'i', and 'l' codes).  Future versions of Python will
  raise a TypeError.

Can we turn that DeprecationWarning into a TypeError for 2.7?  (It's
already a TypeError in 3.x.) I'd like to see things like 'range(-0.3)'
and 'itertools.combinations(range(3), 5.1)' raise TypeError.

N.B. The relevant format codes in 2.7 include 'I' and 'n' in addition to
the six codes listed above.

----------
messages: 80649
nosy: marketdickinson
severity: normal
status: open
title: PyArg_Parse* should raise TypeError for float parsed with integer format
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 27 13:51:59 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 27 Jan 2009 12:51:59 +0000
Subject: [New-bugs-announce] [issue5081] Unable to print Unicode characters
	in Python 3 on Windows
In-Reply-To: <1233060719.46.0.922217803692.issue5081@psf.upfronthosting.co.za>
Message-ID: <1233060719.46.0.922217803692.issue5081@psf.upfronthosting.co.za>


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

While trying to port pyftpdlib to Python 3.x I noticed that Python 3.0
has a serious issue since unable to print certain unicode characters on
stdout:

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('\u20ac')  # euro sign
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python30\lib\io.py", line 1491, in write
    b = encoder.encode(s)
  File "C:\python30\lib\encodings\cp850.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u20ac' in
position
0: character maps to <undefined>
>>>


Note that the same thing works on Python 2.6

Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print unicode('\u20ac')
\u20ac

This same thing is also discussed on python ml:
http://groups.google.it/group/comp.lang.python/browse_thread/thread/fb42765fe7476fc9/f560b4eaf2b0e3f4?hl=it&pli=1

----------
components: None
messages: 80650
nosy: giampaolo.rodola
severity: normal
status: open
title: Unable to print Unicode characters in Python 3 on Windows
type: crash
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Tue Jan 27 17:38:08 2009
From: report at bugs.python.org (Andrea Corbellini)
Date: Tue, 27 Jan 2009 16:38:08 +0000
Subject: [New-bugs-announce] [issue5082] Let frameworks to register
	attributes as builtins
In-Reply-To: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>
Message-ID: <1233074288.69.0.287594397834.issue5082@psf.upfronthosting.co.za>


New submission from Andrea Corbellini <andrea.corbellini at beeseek.org>:

Most of the Python frameworks have some functions and classes that are
widely used. For example a 'log.debug' function will be used in almost
all modules. It is inconvenient to write 'import log' every time.

It would be useful to have a special place (a dict or a special module)
where you can declare attributes that can be used everywhere without
importing anything. Currently, the only way to do this is:

>>> import __builtin__
>>> __builtin__.debug = log.debug

However, I think that this shouldn't be the better solution. Using
something like '__framework__' would be really better, in my opinion.

----------
components: Interpreter Core
messages: 80656
nosy: andrea-bs
severity: normal
status: open
title: Let frameworks to register attributes as builtins

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

From report at bugs.python.org  Tue Jan 27 21:30:21 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 27 Jan 2009 20:30:21 +0000
Subject: [New-bugs-announce] [issue5083] New resource ('gui') for regrtest
In-Reply-To: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>
Message-ID: <1233088221.56.0.688581339016.issue5083@psf.upfronthosting.co.za>


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

I would like to add a 'gui' resource in regrtest, this would be nice for
the ttk module that I'm planning to do add very soon (after I solve
another issue about tests).

----------
components: Tests
files: regrtest_gui_resource.diff
keywords: patch
messages: 80668
nosy: gpolo
severity: normal
status: open
title: New resource ('gui') for regrtest
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file12878/regrtest_gui_resource.diff

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

From report at bugs.python.org  Tue Jan 27 22:52:20 2009
From: report at bugs.python.org (Jake McGuire)
Date: Tue, 27 Jan 2009 21:52:20 +0000
Subject: [New-bugs-announce] [issue5084] unpickling does not intern
	attribute names
In-Reply-To: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>
Message-ID: <1233093140.55.0.0122548653801.issue5084@psf.upfronthosting.co.za>


New submission from Jake McGuire <jake at youtube.com>:

Instance attribute names are normally interned - this is done in 
PyObject_SetAttr (among other places).  Unpickling (in pickle and 
cPickle) directly updates __dict__ on the instance object.  This 
bypasses the interning so you end up with many copies of the strings 
representing your attribute names, which wastes a lot of space, both in 
RAM and in pickles of sequences of objects created from pickles.  Note 
that the native python memcached client uses pickle to serialize 
objects.

>>> import pickle
>>> class C(object):
...   def __init__(self, x):
...     self.long_attribute_name = x
...
>>> len(pickle.dumps([pickle.loads(pickle.dumps(C(None), 
pickle.HIGHEST_PROTOCOL)) for i in range(100)], 
pickle.HIGHEST_PROTOCOL))
3658
>>> len(pickle.dumps([C(None) for i in range(100)], 
pickle.HIGHEST_PROTOCOL))
1441
>>>

Interning the strings on unpickling makes the pickles smaller, and at 
least for cPickle actually makes unpickling sequences of many objects 
slightly faster.  I have included proposed patches to cPickle.c and 
pickle.py, and would appreciate any feedback.

----------
components: Library (Lib)
files: cPickle.c.diff
keywords: patch
messages: 80670
nosy: jakemcguire
severity: normal
status: open
title: unpickling does not intern attribute names
type: resource usage
Added file: http://bugs.python.org/file12879/cPickle.c.diff

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

From report at bugs.python.org  Tue Jan 27 23:33:35 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 27 Jan 2009 22:33:35 +0000
Subject: [New-bugs-announce] [issue5085] distutils/test_sdist failure on
	windows
In-Reply-To: <1233095615.15.0.606843588925.issue5085@psf.upfronthosting.co.za>
Message-ID: <1233095615.15.0.606843588925.issue5085@psf.upfronthosting.co.za>


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

test_sdist fails on windows with following message.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1823/step-test/0

======================================================================
ERROR: test_make_distribution (distutils.tests.test_sdist.sdistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\tests\test_sdist.py", line 119, in 
test_make_distribution
    spawn('tar --help')
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\spawn.py", line 37, in spawn
    _spawn_nt(cmd, search_path, dry_run=dry_run)
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\spawn.py", line 70, in _spawn_nt
    cmd = _nt_quote_args(cmd)
  File "E:\cygwin\home\db3l\buildarea\trunk.bolen-
windows\build\lib\distutils\spawn.py", line 61, in _nt_quote_args
    args[i] = '"%s"' % args[i]
TypeError: 'str' object does not support item assignment

////////////////////////////////////

This can be fixed if replace
  spawn('tar --help')
in Lib/distutils/tests/test_sdist.py with
  spawn(['tar', '--help'])
but, "tar --help" outputs very long message, it is not beautiful.

So I'll push attached patch. (This also checks gzip
which requres to run test)

----------
components: Tests
files: test_sdist_on_win32.patch
keywords: patch
messages: 80674
nosy: ocean-city
severity: normal
status: open
title: distutils/test_sdist failure on windows
versions: Python 2.7
Added file: http://bugs.python.org/file12881/test_sdist_on_win32.patch

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

From report at bugs.python.org  Wed Jan 28 02:24:57 2009
From: report at bugs.python.org (Michael Newman)
Date: Wed, 28 Jan 2009 01:24:57 +0000
Subject: [New-bugs-announce] [issue5086] set_daemon does not exist in Thread
In-Reply-To: <1233105897.35.0.794946960861.issue5086@psf.upfronthosting.co.za>
Message-ID: <1233105897.35.0.794946960861.issue5086@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

This is related to:
http://bugs.python.org/issue3628
http://bugs.python.org/issue4808

I found in the example at the bottom of:
http://docs.python.org/3.0/library/queue.html
"t.set_daemon(True)"
won't work.

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from threading import Thread
>>> t = Thread()
>>> dir(t)
['_Thread__exc_info', '_Thread__initialized', '__class__',
'__delattr__', '__dic
t__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__gt__',
 '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
'__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__
', '__subclasshook__', '__weakref__', '_args', '_block', '_bootstrap',
'_bootstr
ap_inner', '_daemonic', '_delete', '_ident', '_initialized', '_kwargs',
'_name',
 '_note', '_set_daemon', '_started', '_stderr', '_stop', '_stopped',
'_target',
'_verbose', 'daemon', 'getName', 'ident', 'isAlive', 'isDaemon',
'is_alive', 'jo
in', 'name', 'run', 'setDaemon', 'setName', 'start']
>>> t.set_daemon(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Thread' object has no attribute 'set_daemon'
>>> t.daemon
False
# This appears to be the proper method, unless "set_daemon" gets added
in (or setDaemon is used, but that appears to be depreciated syntax):
>>> t.daemon = True
>>> t.daemon
True

Please see the attached "queue_join.py" for my own working example. It
would be helpful to include the line:
>>> from threading import Thread
in the official example.

----------
assignee: georg.brandl
components: Documentation
files: queue_join.py
messages: 80685
nosy: georg.brandl, mnewman
severity: normal
status: open
title: set_daemon does not exist in Thread
versions: Python 3.0
Added file: http://bugs.python.org/file12883/queue_join.py

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

From report at bugs.python.org  Wed Jan 28 02:25:30 2009
From: report at bugs.python.org (Michael Newman)
Date: Wed, 28 Jan 2009 01:25:30 +0000
Subject: [New-bugs-announce] [issue5087] set_daemon does not exist in Thread
In-Reply-To: <1233105930.75.0.986865589873.issue5087@psf.upfronthosting.co.za>
Message-ID: <1233105930.75.0.986865589873.issue5087@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

This is related to:
http://bugs.python.org/issue3628
http://bugs.python.org/issue4808

I found in the example at the bottom of:
http://docs.python.org/3.0/library/queue.html
"t.set_daemon(True)"
won't work.

Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from threading import Thread
>>> t = Thread()
>>> dir(t)
['_Thread__exc_info', '_Thread__initialized', '__class__',
'__delattr__', '__dic
t__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__gt__',
 '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
'__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__
', '__subclasshook__', '__weakref__', '_args', '_block', '_bootstrap',
'_bootstr
ap_inner', '_daemonic', '_delete', '_ident', '_initialized', '_kwargs',
'_name',
 '_note', '_set_daemon', '_started', '_stderr', '_stop', '_stopped',
'_target',
'_verbose', 'daemon', 'getName', 'ident', 'isAlive', 'isDaemon',
'is_alive', 'jo
in', 'name', 'run', 'setDaemon', 'setName', 'start']
>>> t.set_daemon(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Thread' object has no attribute 'set_daemon'
>>> t.daemon
False
# This appears to be the proper method, unless "set_daemon" gets added
in (or setDaemon is used, but that appears to be depreciated syntax):
>>> t.daemon = True
>>> t.daemon
True

Please see the attached "queue_join.py" for my own working example. It
would be helpful to include the line:
>>> from threading import Thread
in the official example.

----------
assignee: georg.brandl
components: Documentation
files: queue_join.py
messages: 80686
nosy: georg.brandl, mnewman
severity: normal
status: open
title: set_daemon does not exist in Thread
versions: Python 3.0
Added file: http://bugs.python.org/file12884/queue_join.py

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

From report at bugs.python.org  Wed Jan 28 11:58:27 2009
From: report at bugs.python.org (Fons Dijkstra)
Date: Wed, 28 Jan 2009 10:58:27 +0000
Subject: [New-bugs-announce] [issue5088] optparse: inconsistent default
	value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>


New submission from Fons Dijkstra <fdij at xs4all.nl>:

Although it is possible to specify a default value for an append action,  
either directly or through the set_default() function, it is not handled 
correctly when this default is overruled by the user. Take for example 
the following code:

  import optparse
  parser = optparse.OptionParser()
  parser.add_option("-o", "--option", action = "append")
  parser.set_defaults(option = ["a"])
  options, args = parser.parse_args()
  print options

When this is called without arguments the following is printed:
  {'option': ['a']} # as expected

But when it is called with for example with -ob the following is 
printed:
  {'option': ['a', 'b']} # expected {'option': ['b']}

So the default option is also appended, even if the option is explicitly defined by the user.

----------
components: Library (Lib)
messages: 80704
nosy: pycurry
severity: normal
status: open
title: optparse: inconsistent default value for append actions
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 28 13:52:50 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 28 Jan 2009 12:52:50 +0000
Subject: [New-bugs-announce] [issue5089] Error in atexit._run_exitfuncs
	[...] Exception expected for value, tuple found
In-Reply-To: <1233147170.33.0.0367863608551.issue5089@psf.upfronthosting.co.za>
Message-ID: <1233147170.33.0.0367863608551.issue5089@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

When running the test-suite (using "make test") for a 32-bit debug build 
of py3k on OS X 10.5/Core 2 Duo, I occasionally (perhaps 1 time in 10) get 
the following output at the end of a (successful) test_run:

...
test_zipimport_support
test_zlib
301 tests OK.
22 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
    test_epoll test_largefile test_nis test_normalization
    test_ossaudiodev test_pep277 test_socketserver test_startfile
    test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
Those skips are all expected on darwin.
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, tuple found
[1264638 refs]


I assume that there's a genuine exception here that we're not seeing;  
i.e., that there's a shallow error (tuple instead of exception) that's 
masking output of information from a deeper error.

----------
components: Tests
messages: 80705
nosy: marketdickinson
severity: normal
status: open
title: Error in atexit._run_exitfuncs [...] Exception expected for value, tuple found
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Jan 28 15:05:25 2009
From: report at bugs.python.org (wang)
Date: Wed, 28 Jan 2009 14:05:25 +0000
Subject: [New-bugs-announce] [issue5090] import tkinter library Visual C++
	Concepts:C Run-Time Error R6034 when embeded python in c++
In-Reply-To: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>
Message-ID: <1233151525.44.0.43046590394.issue5090@psf.upfronthosting.co.za>


New submission from wang <zevboy at gmail.com>:

import tkinter library Visual C++ Concepts:C Run-Time Error R6034 when 
embeded python in c++

----------
components: Tkinter
messages: 80710
nosy: guxianminer
severity: normal
status: open
title: import tkinter library Visual C++ Concepts:C Run-Time Error R6034 when embeded python in c++
versions: Python 3.0

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

From report at bugs.python.org  Wed Jan 28 15:21:07 2009
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 28 Jan 2009 14:21:07 +0000
Subject: [New-bugs-announce] [issue5091] Segfault in PyObject_Malloc(),
	address out of bounds
In-Reply-To: <1233152467.68.0.872773053534.issue5091@psf.upfronthosting.co.za>
Message-ID: <1233152467.68.0.872773053534.issue5091@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

One of our application recently started to segfault in
PyObject_Malloc(). The cause of the problem could be tracked down to an
overflowing internal cache.

However I was astonished that Python was segfaulting instead of raising
a memory exception. I did some post mortem debugging with gdb and found
an address out of bounds problem. I think the issue is caused by the
limited heap of a 32bit Python process.

(gdb) bt
...
#7  <signal handler called>
#8  PyObject_Malloc (nbytes=40) at Objects/obmalloc.c:747
#9  0xb7edfba5 in _PyObject_GC_Malloc (basicsize=28) at
Modules/gcmodule.c:1322
#10 0xb7e79867 in PyType_GenericAlloc (type=0xb7606d40, nitems=0) at
Objects/typeobject.c:454
...

(gdb) up 8
#8  PyObject_Malloc (nbytes=40) at Objects/obmalloc.c:747
747                             if ((pool->freeblock = *(block **)bp) !=
NULL) {
(gdb) print pool
$1 = (poolp) 0x17ecc000
(gdb) print pool->freeblock
$2 = (block *) 0xecc778b7 <Address 0xecc778b7 out of bounds>
(gdb) print bp
$3 = (block *) 0xecc778b7 <Address 0xecc778b7 out of bounds>

Python: 2.5.2 (32bit)
OS: SuSE Linux 2.6.16.60-0.33-bigsmp

----------
components: Interpreter Core
messages: 80711
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: Segfault in PyObject_Malloc(), address out of bounds
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Thu Jan 29 01:13:40 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 29 Jan 2009 00:13:40 +0000
Subject: [New-bugs-announce] [issue5092] weird memory usage in
	multiprocessing module
In-Reply-To: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>
Message-ID: <1233188020.97.0.306560555097.issue5092@psf.upfronthosting.co.za>


New submission from Jerzy <jerzyo at genesilico.pl>:

Hi

I am using the multiprocessing mudule and I found a very weird thing.
It seems that that the result of one fragment of the code depends on the
fragment of the code that is after it, which should not happen. 

My script looks like this

import time
import multiprocessing
import sys

def f():
  sys.stderr.write(str(len(l))+"\n")
  print len(l)
  #del l
  while(True):
    time.sleep(1)
l=[]
for i in range(2*1000*1000):
  l.append(str(i))
process = multiprocessing.Process(target=f)
process.start()

while(True):
  time.sleep(1)

And its output is as expected:
2000000
2000000
but when I uncoment the 'del l' line I get:

  File
"/home/jerzyo/programs/python2.6/Python-2.6.1/Lib/multiprocessing/process.py",
line 231, in _bootstrap
    self.run()
  File
"/home/jerzyo/programs/python2.6/Python-2.6.1/Lib/multiprocessing/process.py",
line 88, in run
    self._target(*self._args, **self._kwargs)
  File "bin/momory.py", line 6, in f
    sys.stderr.write(str(len(l))+"\n")
UnboundLocalError: local variable 'l' referenced before assignment


How is that? The line that deletes l is after the printing line. How
python interpreter knows that l will be deleted. This is a very anomalus
behaviour and should never happen.

By the way. Is there any way to free some parts of memory in child
process. Suppose I wand to create 100 child processes that do not use
the l list. How can I avoid making 100 copies of l in child processes.

That is my firs post and won't come here very often, so please answer
also to my email (if it is not automaic). I am running python 2.6.1 on
ubuntu 8.04 32bit.

jerzy

----------
messages: 80731
nosy: Orlowski
severity: normal
status: open
title: weird memory usage in multiprocessing module
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 29 01:29:58 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Jan 2009 00:29:58 +0000
Subject: [New-bugs-announce] [issue5093] 2to3 with a pipe on non-ASCII script
In-Reply-To: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>
Message-ID: <1233188998.2.0.237730602839.issue5093@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If Python output is redirected to a pipe, sys.stdout encoding is 
ASCII. So "2to3 script.py|cat" will write the patch in ASCII. If the 
script contains a non-ASCII character, 2to3 fails with:
  ...
  File ".../lib2to3/refactor.py", line 238, in refactor_file
    self.processed_file(str(tree)[:-1], filename, write=write)
  File ".../lib2to3/refactor.py", line 342, in processed_file
    self.print_output(diff_texts(old_text, new_text, filename))
  File ".../main.py", line 48, in print_output
    print(line)
UnicodeEncodeError: 'ascii' codec can't encode character '\xfb' in 
position 11: ordinal not in range(128)

Should we consider the input file and stdout as binary files? 
Workaround: modify the files in place (-w option) but don't write the 
patch to stdout (no such option yet).

A project may contain scripts in ASCII, Latin-1 and UTF-8 (eg. Python 
source code ;-)).

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 80733
nosy: haypo
severity: normal
status: open
title: 2to3 with a pipe on non-ASCII script

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

From report at bugs.python.org  Thu Jan 29 01:52:43 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Jan 2009 00:52:43 +0000
Subject: [New-bugs-announce] [issue5094] datetime lacks concrete tzinfo
	impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

When you call datetime.datetime.utcnow() you get back a naive datetime
object. But why? You asked for UTC as the timezone based on what method
call you made. And UTC is a very concrete timezone that never changes.

It would be nice to have a concrete UTC tzinfo class that utcnow() uses
so that at least those datetime instances are non-naive.

If people have no issues with making this happen I will write the code
for the concrete UTC tzinfo instance and make the appropriate changes to
utcnow().

----------
components: Extension Modules
messages: 80735
nosy: brett.cannon
severity: normal
status: open
title: datetime lacks concrete tzinfo impl. for UTC
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Jan 29 04:05:50 2009
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 29 Jan 2009 03:05:50 +0000
Subject: [New-bugs-announce] [issue5095] msi missing from "bdist
	--help-formats"
In-Reply-To: <1233198350.56.0.182108150047.issue5095@psf.upfronthosting.co.za>
Message-ID: <1233198350.56.0.182108150047.issue5095@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

The bdist_msi command is documented in the distutils reference:

http://docs.python.org/distutils/apiref.html#module-distutils.command.bdist_msi

But it does not show up with "bdist --help-formats"

$ python setup.py bdist --help-formats
List of available distribution formats:
  --formats=rpm      RPM distribution
  --formats=gztar    gzip'ed tar file
  --formats=bztar    bzip2'ed tar file
  --formats=ztar     compressed tar file
  --formats=tar      tar file
  --formats=wininst  Windows executable installer
  --formats=zip      ZIP file

This probably exists in 3.0 too, but I haven't checked.

----------
components: Distutils
messages: 80743
nosy: bethard
severity: normal
stage: needs patch
status: open
title: msi missing from "bdist --help-formats"
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Jan 29 12:42:55 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Thu, 29 Jan 2009 11:42:55 +0000
Subject: [New-bugs-announce] [issue5096] strange thing after call
	PyObject_CallMethod
In-Reply-To: <1233229375.88.0.463699429869.issue5096@psf.upfronthosting.co.za>
Message-ID: <1233229375.88.0.463699429869.issue5096@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

When unhandled in python code exception occurs in PyObject_CallMethod 
frame_dealloc() (Objects/frameobject.c:422) 
not called. Even if I call PyErr_Print(). 

But if I call PyErr_Clear() then all okay. Documentation says that both 
this functions doing same work(http://docs.python.org/3.0/c-api/
exceptions.html). As we see thats not true or not all nuances documented.

Examples and more on this mailing list:
http://groups.google.com/group/comp.lang.python/browse_thread/
thread/19316b3effa37d2d

----------
components: Interpreter Core
messages: 80757
nosy: exe
severity: normal
status: open
title: strange thing after call PyObject_CallMethod
type: behavior
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Jan 29 14:20:35 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Thu, 29 Jan 2009 13:20:35 +0000
Subject: [New-bugs-announce] [issue5097] asyncore.dispatcher_with_send
	undocumented
In-Reply-To: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>
Message-ID: <1233235235.33.0.24123597522.issue5097@psf.upfronthosting.co.za>


New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:

Hello!

asyncore.dispatcher_with_send undocumented in all python versions

----------
assignee: georg.brandl
components: Documentation
messages: 80763
nosy: exe, georg.brandl
severity: normal
status: open
title: asyncore.dispatcher_with_send undocumented

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

From report at bugs.python.org  Thu Jan 29 15:41:59 2009
From: report at bugs.python.org (Stuart Axon)
Date: Thu, 29 Jan 2009 14:41:59 +0000
Subject: [New-bugs-announce] [issue5098] Environ doesn't escape spaces
	properly
In-Reply-To: <1233240119.96.0.34005552843.issue5098@psf.upfronthosting.co.za>
Message-ID: <1233240119.96.0.34005552843.issue5098@psf.upfronthosting.co.za>


New submission from Stuart Axon <stu.axon at gmail.com>:

os.environ doesn't escape spaces, but does backslashes and others

In the windows python interpreter I echo'd the variable 'ProgramFiles',
then in the commandprompt.

>>> from os import environ
>>> environ['ProgramFiles']
'C:\\Program Files'
>>> ^Z

[C:\]echo %ProgramFiles%
C:\Program Files

This 'half' escapping seems odd, and is annoying when building file
paths for instance, probably the space should also be escaped.

----------
components: None
messages: 80765
nosy: stuaxo
severity: normal
status: open
title: Environ doesn't escape spaces properly
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Jan 29 17:00:08 2009
From: report at bugs.python.org (Mary Stern)
Date: Thu, 29 Jan 2009 16:00:08 +0000
Subject: [New-bugs-announce] [issue5099] subprocess.POpen.__del__()
	AttribuetError (os module == None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>


New submission from Mary Stern <marystern at yahoo.com>:

I was getting this error (while running my unit tests):

Exception exceptions.AttributeError: "'NoneType' object has no attribute
'error'" in <bound method Popen.__del__ of <subprocess.Popen object at
0x8a2596c>> ignored

which I tracked down to the os module being set to None (yes really!) in
POpen._internal_poll() when called from Popen.__del__, so this line:

                    except os.error:

was generating the error.

I guess that the module is getting unloaded earlier somehow (maybe a
race condition)?

----------
components: Extension Modules
messages: 80771
nosy: marystern
severity: normal
status: open
title: subprocess.POpen.__del__() AttribuetError (os module == None!)
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 29 21:05:22 2009
From: report at bugs.python.org (Jeroen Dirks)
Date: Thu, 29 Jan 2009 20:05:22 +0000
Subject: [New-bugs-announce] [issue5100] ElementTree.iterparse and
	Element.tail confusion
In-Reply-To: <1233259522.5.0.311608999465.issue5100@psf.upfronthosting.co.za>
Message-ID: <1233259522.5.0.311608999465.issue5100@psf.upfronthosting.co.za>


New submission from Jeroen Dirks <jeroen.dirks at oracle.com>:

I am using cElementTree.iterparse in order to parse through a huge XML
document and filter out sections of interest.

The usage pattern is that I wait for an "end" event for a element of
interest and then if it matches a some criterium I write it out using
cElementTree.tostring().

My code had bug in it because the cElementTree.tostring methods prints
the element including its tail. The element retreived from the iterparse
iterator sometimes contains the tail by the time it emits the end event
but sometimes it does not.

In my document the tail just consisted of the newline '\n' character and
about 98% of the time it was attached to the element during its end event.

This is rather confusing behavior. 

Could ElementTree/cElementTree.iterparse be changed so that if you
respond to the end event for an element its tail is never set?

----------
components: XML
messages: 80783
nosy: jeroen.dirks
severity: normal
status: open
title: ElementTree.iterparse and Element.tail confusion
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 29 22:04:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Jan 2009 21:04:18 +0000
Subject: [New-bugs-announce] [issue5101] test_funcattrs truncated during
	unittest conversion
In-Reply-To: <1233263058.35.0.644658374842.issue5101@psf.upfronthosting.co.za>
Message-ID: <1233263058.35.0.644658374842.issue5101@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

It looks as though a few of the tests in test_funcattrs disappeared in the 
conversion to unittest, committed in r60522.  (The first one I noticed was 
test_empty_cell, but there are others missing too.)

Question for Georg (who did the checkin): do you know whether these tests 
were removed deliberately?  Or should they be reintroduced if possible?

----------
components: Tests
messages: 80785
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: test_funcattrs truncated during unittest conversion

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

From report at bugs.python.org  Thu Jan 29 23:35:01 2009
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 29 Jan 2009 22:35:01 +0000
Subject: [New-bugs-announce] [issue5102] urllib2.py timeouts do not
	propagate across redirects for 2.6.1 (and 3.x?)
In-Reply-To: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>
Message-ID: <1233268501.09.0.849179242722.issue5102@psf.upfronthosting.co.za>


New submission from Jacques Grove <jacques at tripitinc.com>:

When doing a urllib2 fetch of a url that results in a redirect, the
connection to the redirect does not pass along the timeout of the
original url opener.  The result is that the redirected url fetch (which
is a new request) will get the default socket timeout, instead of the
timeout that the user requested originally.  This is obviously a bug.

So we have in urllib2.py in 2.6.1:

def http_error_302(self, req, fp, code, msg, headers):
.....
    return self.parent.open(new)

this should be:
    return self.parent.open(new, timeout=req.timeout)

or something in that vein.


Of course, to be 100% correct, you should probably keep track of how
much time has elapsed since the original url fetch went out, and reduce
the timeout based on this, but I'm not asking for miracles :-)


Jacques

----------
components: Library (Lib)
messages: 80787
nosy: jacques
severity: normal
status: open
title: urllib2.py timeouts do not propagate across redirects for 2.6.1 (and 3.x?)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 29 23:44:27 2009
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 29 Jan 2009 22:44:27 +0000
Subject: [New-bugs-announce] [issue5103] ssl.SSLSocket timeout not working
	correctly when remote end is hanging
In-Reply-To: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>
Message-ID: <1233269067.88.0.11384047057.issue5103@psf.upfronthosting.co.za>


New submission from Jacques Grove <jacques at tripitinc.com>:

In ssl.py of Python 2.6.1 we have this code in  SSLSocket.__init__():

            if do_handshake_on_connect:
                timeout = self.gettimeout()
                try:
                    self.settimeout(None)
                    self.do_handshake()
                finally:
                    self.settimeout(timeout)

The problem is, what happens if the remote end (server) is hanging when
do_handshake() is called?  The result is that the user-requested timeout
will be ignored, and the connection will hang until the TCP socket
timeout expires.

This is easily reproducable with this test code:


import urllib2
urllib2.urlopen("https://localhost:9000/", timeout=2.0)


and running netcat on port 9000, i.e.:

nc -l -p 9000 localhost

If you use "http" instead of "https", the timeout works as expected
(after 2 seconds in this case).

----------
components: Library (Lib)
messages: 80790
nosy: jacques
severity: normal
status: open
title: ssl.SSLSocket timeout not working correctly when remote end is hanging
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 30 00:23:56 2009
From: report at bugs.python.org (Roman Zeyde)
Date: Thu, 29 Jan 2009 23:23:56 +0000
Subject: [New-bugs-announce] [issue5104] getsockaddrarg() casts port number
	from int to short without any warning
In-Reply-To: <1233271436.92.0.964920785544.issue5104@psf.upfronthosting.co.za>
Message-ID: <1233271436.92.0.964920785544.issue5104@psf.upfronthosting.co.za>


New submission from Roman Zeyde <roman.zeyde at gmail.com>:

The following code shouldn't fail without any warning at all:

>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('localhost', 70000))
>>> print(s.getsockname())
('127.0.0.1', 4464)

After looking through socketmodule.c (rev. 68450), it seems that AF_INET
case casts an "int port" into a "short addr->sin_port", and does not
checks for overflows:

	case AF_INET:
	{
		struct sockaddr_in* addr;
		char *host;
		int port, result;
		if (!PyTuple_Check(args)) {
			PyErr_Format(
				PyExc_TypeError,
				"getsockaddrarg: "
				"AF_INET address must be tuple, not %.500s",
				Py_TYPE(args)->tp_name);
			return 0;
		}
		if (!PyArg_ParseTuple(args, "eti:getsockaddrarg",
				      "idna", &host, &port))
			return 0;
		addr=(struct sockaddr_in*)addr_ret;
                result = setipaddr(host, (struct sockaddr *)addr,
                                   sizeof(*addr),  AF_INET);
                PyMem_Free(host);
                if (result < 0)
			return 0;
		addr->sin_family = AF_INET;
		addr->sin_port = htons((short)port);
		*len_ret = sizeof *addr;
		return 1;
	}

----------
components: None
messages: 80794
nosy: roman.zeyde
severity: normal
status: open
title: getsockaddrarg() casts port number from int to short without any warning
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 30 00:53:31 2009
From: report at bugs.python.org (Brandon Adams)
Date: Thu, 29 Jan 2009 23:53:31 +0000
Subject: [New-bugs-announce] [issue5105] sqlite3.Row class,
	handling duplicate column names resulting from a SQL join
In-Reply-To: <1233273211.24.0.156313751238.issue5105@psf.upfronthosting.co.za>
Message-ID: <1233273211.24.0.156313751238.issue5105@psf.upfronthosting.co.za>


New submission from Brandon Adams <sockonafish at gmail.com>:

When using sqlite3.Row as the row_factory for a sqlite3 connection and 
performing a SQL join that returns rows from two or more tables with 
identical column names, the returned sqlite3.Row object contains 
duplicate keys.  Subsequently, when trying to access values by key, only 
the value contained in the lowest numbered index matching the key is 
returned.  Additionally, attempting to use the keys returned to create a 
new table in the database fails due to a duplicate column name error.

A better behavior would be for the sqlite3.Row object's indices to be 
prefixed with table names for cases in which a query produces results 
from two or more tables.

----------
components: Library (Lib)
messages: 80798
nosy: sockonafish
severity: normal
status: open
title: sqlite3.Row class, handling duplicate column names resulting from a SQL join
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 30 04:50:24 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Jan 2009 03:50:24 +0000
Subject: [New-bugs-announce] [issue5106] Update Naming & Binding statement
	for 3.0
In-Reply-To: <1233287424.89.0.100401288129.issue5106@psf.upfronthosting.co.za>
Message-ID: <1233287424.89.0.100401288129.issue5106@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Language / Execution Model / Naming & Binding 
just before example that does not work, 

class A:
    a = 42
    b = list(a + i for i in range(10))

says :
"The scope of names defined in a class block is limited to the class
block; it does not extend to the code blocks of methods ? this includes
generator expressions since they are implemented using a function scope."

As pointed out by Alan Isaacs (clp), in 3.0,
"this includes comprehensions and generator expressions"
would be more complete and not possibly imply that g.e.s are special in
this regard.  In 2.x, 
    c = [a + i for i in range(10)]
works but it fails with same 
"NameError: global name 'a' is not defined"
in 3.0.  In fact, I think 'comprehensions and ' should be added just
because this is a change which people could trip over.

----------
assignee: georg.brandl
components: Documentation
messages: 80810
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Update Naming & Binding statement for 3.0
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Jan 30 06:00:28 2009
From: report at bugs.python.org (John Machin)
Date: Fri, 30 Jan 2009 05:00:28 +0000
Subject: [New-bugs-announce] [issue5107] built-in open(...,
	encoding=vague_default)
In-Reply-To: <1233291628.48.0.339738109946.issue5107@psf.upfronthosting.co.za>
Message-ID: <1233291628.48.0.339738109946.issue5107@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

Docs say """The default encoding is platform dependent""" but don't say
how to find out what that is, or how it is determined. On my Windows XP
SP3 setup, the default is cp1252, but the best/only guess at finding out
without actually opening a file involved sys.defaultencoding() which
produces 'utf-8'. I was pointed at locale.getpreferredencoding(), which
returns 'cp1252' on my machine.

Please add a sentence along these lines: The default encoding is
(obtained by calling|the same as) locale.getpreferredencoding(), not
sys.getdefaultencoding() -- corrected/amplified as necessary.

----------
assignee: georg.brandl
components: Documentation
messages: 80811
nosy: georg.brandl, sjmachin
severity: normal
status: open
title: built-in open(..., encoding=vague_default)
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Jan 30 12:26:58 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jan 2009 11:26:58 +0000
Subject: [New-bugs-announce] [issue5108] Invalid UTF-8 ("%s") length in
	PyUnicode_FromFormatV()
In-Reply-To: <1233314818.25.0.50797871273.issue5108@psf.upfronthosting.co.za>
Message-ID: <1233314818.25.0.50797871273.issue5108@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_FromFormatV() doesn't count correctly the unicode length of 
an UTF-8 string. Commit r57837 "Change %s argument for 
PyUnicode_FromFormat to be UTF-8. Fixes #1070." introduced the bug. To 
compute the length, it uses a a complex code to compute the length of 
the UTF-8 string, whereas PyUnicode_DecodeUTF8(p, 
strlen(p), "replace") + Py_UNICODE_COPY() is used to copy the string. 
The problem may comes from the error handling ("replace").

Valgrind show that the error occurs at Py_UNICODE_COPY(): Invalid 
write of size 1. Since it's only one byte, Python does not always 
crash.

To reproduce the crash, use PyUnicode_FromFormatV() or function using 
it: PyUnicode_FromFormat(), PyErr_Format(), ...

Example 1:

    import grp
    
x=["\uDBE7\u8C99", "\u9C31\uF8DC\u3EC5\u1804\u629D\uE748\u68C8\uCF74\u9E63\uF647\uBF7A\uED63"]
    x=str(x)
    grp.getgrnam(x)

Example 2:

    import unicodedata
    x 
= "\\udbe7\u8c99', '\u9c31\\uf8dc\u3ec5\u1804\u629d\\ue748\u68c8\ucf74\u9e63\\uf647\ubf7a\\ued63"
    unicodedata.lookup(x)

I wrote a patch reusing PyUnicode_DecodeUTF8(p, strlen(p), "replace") 
+ PyUnicode_GET_SIZE() to get the real length of the converted UTF-8 
string.

A better patch should reuse code used to convert UTF-8 to Unicode with 
the "replace" error handling.

----------
components: Unicode
messages: 80814
nosy: haypo
severity: normal
status: open
title: Invalid UTF-8 ("%s") length in PyUnicode_FromFormatV()
versions: Python 3.0, Python 3.1

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

From report at bugs.python.org  Fri Jan 30 13:33:26 2009
From: report at bugs.python.org (Malcolm Purvis)
Date: Fri, 30 Jan 2009 12:33:26 +0000
Subject: [New-bugs-announce] [issue5109] array.array constructor very slow
	when passed an array object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>


New submission from Malcolm Purvis <malcolm at purvis.id.au>:

Copying an array.array object via the array constructor is some 100x
slower than using slicing or even converting the array to a string and
then passing that string to the array constructor.

Running the attached program on a 2.2GHz MacBook Pro (OSX 10.5.5, 4GB
RAM) produces this output:

$ python2.6 array_test.py
Constructor:  18.5617749691
Slice:  0.169251918793
String:  0.375015974045

>From a look at arraymodule.c it seems that array_new() does not have a
special case for the array type and therefore uses the generic sequence
copy code rather than using memcpy(), like it can for slicing.

----------
components: Library (Lib)
files: array_test.py
messages: 80815
nosy: malcolmp
severity: normal
status: open
title: array.array constructor very slow when passed an array object.
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file12893/array_test.py

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

From report at bugs.python.org  Fri Jan 30 16:26:49 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Jan 2009 15:26:49 +0000
Subject: [New-bugs-announce] [issue5110] Printing Unicode chars from the
	interpreter in a non-UTF8 terminal (Py3)
In-Reply-To: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>
Message-ID: <1233329209.55.0.55287436123.issue5110@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

In Py2.x
>>> u'\2620'
outputs u'\2620' whereas
>>> print u'\2620'
raises an error.

Instead, in Py3.x, both
>>> '\u2620'
and
>>> print('\u2620')
raise an error if the terminal doesn't use an encoding able to display
the character (e.g. the windows terminal used for these examples).

This is caused by the new string representation defined in the PEP3138[1].

Consider also the following example:
Py2:
>>> [u'\u2620']
[u'\u2620']
Py3:
>>> ['\u2620']
UnicodeEncodeError: 'charmap' codec can't encode character '\u2620' in
position 9: character maps to <undefined>

This means that there is no way to print lists (or other objects) that
contain characters that can't be encoded.
Two workarounds may be:
1) encode all the elements of the list, but it's not practical;
2) use ascii(), but it adds extra "" around the output and escape
backslashes and apostrophes (and it won't be possible to use _[0] in the
next line).
 
Also note that in Py3
>>> ['\ud800']
['\ud800']
>>> _[0]
'\ud800'
works, because U+D800 belongs to the category "Cs (Other, Surrogate)"
and it is escaped[2].

The best solution is probably to change the default error-handler of the
Python3 interactive interpreter to 'backslashreplace' in order to avoid
this behavior, but I don't know if it's possible only for ">>> foo" and
not for ">>> print(foo)" (print() should still raise an error as it does
in Py2).

This proposal has already been refused in the PEP3138[3] but there are
no links to the discussion that led to this decision.

I think this should be rediscussed and possibly changed, because, even
if can't see the "listOfJapaneseStrings"[4], I still prefer to see a
sequence of escaped chars than a UnicodeEncodeError.

[1]: http://www.python.org/dev/peps/pep-3138/
[2]: http://www.python.org/dev/peps/pep-3138/#specification
[3]: http://www.python.org/dev/peps/pep-3138/#rejected-proposals
[4]: http://www.python.org/dev/peps/pep-3138/#motivation

----------
components: Unicode
messages: 80820
nosy: ezio.melotti
severity: normal
status: open
title: Printing Unicode chars from the interpreter in a non-UTF8 terminal (Py3)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Jan 30 17:48:59 2009
From: report at bugs.python.org (Guillaume Desmottes)
Date: Fri, 30 Jan 2009 16:48:59 +0000
Subject: [New-bugs-announce] [issue5111] httplib: wrong Host header when
	connecting to IPv6 loopback
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>


New submission from Guillaume Desmottes <gdesmott at gnome.org>:

To reproduce:
- Launch a HTTP server listening on an Inet6 socket on, say, port 5555
- Try to connect using the IPv6 loopback: 
http = httplib.HTTPConnection('[::1]:5555')
http.request('GET', '/foo')
r = http.getresponse()
print r.status
- You get 400 (bad-request) instead of 404

It seems that's because the HTTP request is wrong. Python sends this header:
Host: ::1:5555
but it should be:
Host: [::1]:5555

I'm using python 2.5.2-1ubuntu1 on Intrepid.

----------
components: Library (Lib)
messages: 80827
nosy: gdesmott
severity: normal
status: open
title: httplib: wrong Host header when connecting to IPv6 loopback
versions: Python 2.5

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

From report at bugs.python.org  Fri Jan 30 19:41:18 2009
From: report at bugs.python.org (Michael Welsh Duggan)
Date: Fri, 30 Jan 2009 18:41:18 +0000
Subject: [New-bugs-announce] [issue5112] Incorrect documentation for
	PyErr_BadInternalCall
In-Reply-To: <1233340878.84.0.440465699769.issue5112@psf.upfronthosting.co.za>
Message-ID: <1233340878.84.0.440465699769.issue5112@psf.upfronthosting.co.za>


New submission from Michael Welsh Duggan <mwd at sei.cmu.edu>:

Documentation says that this call is shorthand for
PyErr_SetString(PyExc_TypeError, message), but is instead shorthand for
PyErr_SetString(PyExc_SystemError, message).

----------
assignee: georg.brandl
components: Documentation
messages: 80831
nosy: georg.brandl, md5i
severity: normal
status: open
title: Incorrect documentation for PyErr_BadInternalCall
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0

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

From report at bugs.python.org  Fri Jan 30 21:12:13 2009
From: report at bugs.python.org (Andreas Kupries)
Date: Fri, 30 Jan 2009 20:12:13 +0000
Subject: [New-bugs-announce] [issue5113] 2.5.4.3 / test_posix failing on
	HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>


New submission from Andreas Kupries <andreask at activestate.com>:

The 'test_posix' of Python's 2.5.4.3 testsuite fails on HPUX. This has
happened on parisc and ia64 systems. On the parisc system failure occurs
for both parisc1.1 and parisc2.0w builds. The HPUX versions are 11.00
(parisc) and 11.22 (ia64).

The attached file contains the output of executing

./apy/bin/python2.5 ./apy/lib/python2.5/test/regrtest.py -v test_posix

----------
components: Tests
files: bug-test_posix-hpux.log
messages: 80835
nosy: andreask
severity: normal
status: open
title: 2.5.4.3 / test_posix failing on HPUX systems
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file12897/bug-test_posix-hpux.log

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

From report at bugs.python.org  Fri Jan 30 21:24:54 2009
From: report at bugs.python.org (Andreas Kupries)
Date: Fri, 30 Jan 2009 20:24:54 +0000
Subject: [New-bugs-announce] [issue5114] 2.5.4.3 / test_threading hangs
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>


New submission from Andreas Kupries <andreask at activestate.com>:

On two machines I have seen test_threading hang in ...
HPUX 11.22 ia64,
Solaris 5.8 sparc

The attached file contains the output of running

./apy/bin/python2.5 ./apy/lib/python2.5/test/regrtest.py -v test_threading

on the problematic machines.

It is necessary to kill one of the subprocesses to force forward
progress. A partial output of 'ps -ef' on the HPUX machine is

andreask 26601 26552  0 12:13:50 pts/1     0:00 ./apy/bin/python2.5
./apy/lib/python2.5/test/regrtest.py -v tes
andreask 26657 26601  0 12:14:26 pts/1     0:00
/home/andreask/tmp/autotest/apy/bin/python2.5 -c if 1:^J
andreask 26658 26657  0 12:14:26 pts/1     0:00
/home/andreask/tmp/autotest/apy/bin/python2.5 -c if 1:^J

And I usually kill the bottom most process.

----------
components: Tests
files: bug-test_threading-hpux-solaris.log
messages: 80836
nosy: andreask
severity: normal
status: open
title: 2.5.4.3 / test_threading hangs
versions: Python 2.5
Added file: http://bugs.python.org/file12898/bug-test_threading-hpux-solaris.log

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

From report at bugs.python.org  Sat Jan 31 03:51:00 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Sat, 31 Jan 2009 02:51:00 +0000
Subject: [New-bugs-announce] [issue5115] Extend subprocess.kill to be able
	to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

It would be really handy to add a way to portably kill process groups of 
a process spawned with subprocess.Popen. My project starts a process, 
which then starts other long running processes. Because of this process 
tree, there's no way for me to portably kill all of those processes. 
Would it be possible to extend subprocess with these features? I did 
find someone who's already implemented this [1], and it's working well 
in my project. There was some discussion about adding this, but it seems 
no one actually committed a patch to implement it.

Anyway, I've attached a patch against python3.0's svn branch that 
implements this. I don't have access to windows, so I'm not able to make 
sure that the TerminateJobObject is correct, and works.

[1]: http://benjamin.smedbergs.us/blog/2006-12-11/killableprocesspy/
[2]: http://mail.python.org/pipermail/python-list/2008-April/487588.html

----------
components: Library (Lib)
files: killpg.patch
keywords: patch
messages: 80850
nosy: erickt
severity: normal
status: open
title: Extend subprocess.kill to be able to kill process groups
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file12899/killpg.patch

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

From report at bugs.python.org  Sat Jan 31 07:52:54 2009
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 31 Jan 2009 06:52:54 +0000
Subject: [New-bugs-announce] [issue5116] expose _CrtSetReportMode via the
	msvcrt module
In-Reply-To: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>
Message-ID: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

In bug 4804, there is some debate about how desirable it is for Python
to unconditionally disable all CRT assertions on Windows - however,
there is agreement that exposing the ability to enable and disable these
assertions via the msvcrt module is reasonable - so I'm attaching a
patch for exactly that.  I'd also like to nominate this for the 2.6 and
py3k branches.

----------
assignee: mhammond
files: msvcrt_crtsetreportmode.patch
keywords: needs review, patch, patch
messages: 80858
nosy: mhammond
priority: normal
severity: normal
status: open
title: expose _CrtSetReportMode via the msvcrt module
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12903/msvcrt_crtsetreportmode.patch

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

From report at bugs.python.org  Sat Jan 31 08:25:52 2009
From: report at bugs.python.org (eliben)
Date: Sat, 31 Jan 2009 07:25:52 +0000
Subject: [New-bugs-announce] [issue5117] os.path.relpath problem with root
	drive directory on windows
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>


New submission from eliben <eliben at gmail.com>:

This is correct:

relpath(r'd:\abc\jho', r'd:\abc')
=> 'jho'

But this isn't:
relpath(r'd:\jho', r'd:\\')
=> '..\jho'

Neither is this:
relpath(r'd:\jho', r'd:')
=> '..\..\..\jho'

----------
components: Library (Lib)
messages: 80860
nosy: eliben
severity: normal
status: open
title: os.path.relpath problem with root drive directory on windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan 31 13:57:51 2009
From: report at bugs.python.org (Ultrasick)
Date: Sat, 31 Jan 2009 12:57:51 +0000
Subject: [New-bugs-announce] [issue5118] '%.2f' % 2.545 doesn't round
	correctly
In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>
Message-ID: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za>


New submission from Ultrasick <python at ontheserver.de>:

print '%.2f' % 2.544 // returns 2.54
print '%.2f' % 2.545 // returns 2.54 but should return 2.55
print '%.2f' % 2.546 // returns 2.55

----------
messages: 80868
nosy: Ultrasick
severity: normal
status: open
title: '%.2f' % 2.545 doesn't round correctly
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan 31 21:53:39 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 31 Jan 2009 20:53:39 +0000
Subject: [New-bugs-announce] [issue5119] inconsistent wide character
	parameter handling in 64-bit python
In-Reply-To: <1233435219.37.0.934884464449.issue5119@psf.upfronthosting.co.za>
Message-ID: <1233435219.37.0.934884464449.issue5119@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Using Python 2.5.4 and Python 2.6.1 on 32-bit python, when passing a
regular string to a function expecting pointer to a wide string
(wintypes.LPCWSTR), the function executes without problems.

When calling the same using Python 2.6.1 on 64-bit windows, the called
function appears not to recognize the parameter unless it is first
converted to unicode.

I discovered this when calling the WNetAddConnection2 function.

Assuming a properly-initialized NETRESOURCE, resource.

password = None
username = 'username at domain.com'
flags = 0

val = ctypes.windll.mpr.WNetAddConnection2W(
  ctypes.byref(resource),
  password,
  username,
  flags)

This method works fine on 32-bit python but fails on 64-bit python
unless username=unicode(username).  The error returned is "The specified
password is incorrect", indicating that the username is in fact
incorrect because the correct username does not require a password.

I wish I had a better test case; I'll try to track down one that doesn't
require such a complex underlying API.

I'm not sure what the correct fix is for this, but regardless, I would
expect the behavior to be consistent for the same Python version
independent of word size.

----------
assignee: theller
components: ctypes
messages: 80883
nosy: jaraco, theller
severity: normal
status: open
title: inconsistent wide character parameter handling in 64-bit python
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Jan 31 22:25:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 31 Jan 2009 21:25:50 +0000
Subject: [New-bugs-announce] [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>


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

For some reason the recently added test_ttk_guionly is causing Tcl to
abort on Mac. I would prefer to disable the test for now, except if some
mac owner has the time to fix it.

I would like to know the tcl version being used on the noller-osx86
buildslave too, if possible.

----------
components: Tkinter
messages: 80884
nosy: gpolo
severity: normal
status: open
title: Disabling test_ttk_guionly on mac
type: crash
versions: Python 2.7, Python 3.1

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