From report at bugs.python.org  Mon Mar  1 00:40:32 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sun, 28 Feb 2010 23:40:32 +0000
Subject: [New-bugs-announce] [issue8032] Add gdb7 hooks to make it easier to
	debug Python
In-Reply-To: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>
Message-ID: <1267400432.35.0.113003499435.issue8032@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

gdb 7 can be extended with Python code, allowing the writing of domain-specific pretty-printers and commands.  

I've been working on gdb 7 hooks to make it easier to debug python itself, as mentioned here:
https://fedoraproject.org/wiki/Features/EasierPythonDebugging


I'm attaching a patch for merger with "trunk".  My hope is to be the maintainer of this work, although I do not yet have SVN commit rights (see http://mail.python.org/pipermail/python-committers/2010-February/000711.html )

The code is fully compatible with the existing "Misc/gdbinit" macros - you can freely use both as needed.

= Two versions of Python =
This code is intended to run inside gdb.  There are potentially two Python versions involved here: that of the "inferior process" (the one being debugged), and that of the debugger.

As I understand things, gdb only supports embedding Python 2 at the moment.  This code is thus targeting that version of Python.

So far, I've attempted to keep this code so that it will run when the "inferior process" is either Python 2 or Python 3.  I could vary this code in the py3k branch if desired.  The code would then track the "inferior process" version of Python, so that code to debug Python 3 would live in the py3k branch.  That code would still be written for Python 2, though.

= Makefile changes =

The Makefile installs the gdb hooks to -gdb.py relative to the built python (even if you're not using them), which some may find irritating.  It needs to do this for the test_gdb.py selftest to work (and for the gdb hooks to be usable if you're actually using them to debug your build of Python).

Should I write a gdb configuration test to check for the availability of gdb built with python?

I've added the file to .hgignore and .bzrignore.  IIRC, a similar thing can be done to the SVN metadata (I don't think this is expressable as a patch, though).  Alternatively, I could wire up the gdb tests to load the file from its location in the source tree.

However, I intend for this code to be installed to a location alongside the build Python, so that it can be automatically detected and used by gdb.  Typically this means copying it to the path of the ELF file with a -gdb.py file.  In my RPM builds I add an extra copy, locating it relative to the location of the stripped DWARF data (e.g. /usr/lib/debug/usr/lib64/libpython26.so.1.0-gdb.py)

= Selftests =
The selftest runs whatever version of "gdb" is in the path, which then invokes the built version of python, running simple "print" commands and verifying that gdb is corrrectly representing the results in backtraces (even in the face of corrupt data).  I haven't fully tested the error cases yet (e.g. for when gdb is not installed).

The tests take about 14 seconds to run on my box:
[david at brick trunk-gdb]$ time ./python Lib/test/regrtest.py -v -s test_gdb
The CWD is now /tmp/test_python_19369
test_gdb
test_NULL_ob_type (test.test_gdb.DebuggerTests) ... ok
test_NULL_ptr (test.test_gdb.DebuggerTests)
Ensure that a NULL PyObject* is handled gracefully ... ok
test_classic_class (test.test_gdb.DebuggerTests) ... ok
test_corrupt_ob_type (test.test_gdb.DebuggerTests) ... ok
test_corrupt_tp_flags (test.test_gdb.DebuggerTests) ... ok
test_corrupt_tp_name (test.test_gdb.DebuggerTests) ... ok
test_dicts (test.test_gdb.DebuggerTests) ... ok
test_getting_backtrace (test.test_gdb.DebuggerTests) ... ok
test_int (test.test_gdb.DebuggerTests) ... ok
test_lists (test.test_gdb.DebuggerTests) ... ok
test_long (test.test_gdb.DebuggerTests) ... ok
test_modern_class (test.test_gdb.DebuggerTests) ... ok
test_singletons (test.test_gdb.DebuggerTests) ... ok
test_strings (test.test_gdb.DebuggerTests) ... ok
test_subclassing_list (test.test_gdb.DebuggerTests) ... ok
test_subclassing_tuple (test.test_gdb.DebuggerTests)
This should exercise the negative tp_dictoffset code in the ... ok
test_tuples (test.test_gdb.DebuggerTests) ... ok
test_unicode (test.test_gdb.DebuggerTests) ... ok

----------------------------------------------------------------------
Ran 18 tests in 13.233s

OK
1 test OK.
[36833 refs]

real	0m13.599s
user	0m11.771s
sys	0m1.384s

= Platform support =
I don't have access to anything other than Linux, so I've no idea how well this stuff works on other platforms.  My testing so far has been on Fedora, though I've heard of successful usage of this on Debian.

= Legal stuff =

Earlier versions of this code were licensed under the LGPL 2.1
I'm relicensing the code to be "under the same license as Python itself", assuming that's legally OK.  Do I need to state that in the file header, or is that redundant?

I'm in the process of doing the PSF Contributor Agreement paperwork (as an individual); waiting to get my hands on a fax machine.  My employer, Red Hat, has agreed for me to retain copyright on all contributions I make to Python.

----------
components: Demos and Tools
messages: 100226
nosy: dmalcolm
severity: normal
status: open
title: Add gdb7 hooks to make it easier to debug Python
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  1 03:03:11 2010
From: report at bugs.python.org (Fred Fettinger)
Date: Mon, 01 Mar 2010 02:03:11 +0000
Subject: [New-bugs-announce] [issue8033] sqlite: broken long integer
	handling for arguments to	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>


New submission from Fred Fettinger <fettinge at gmail.com>:

Handling of long integers is broken for arguments to sqlite functions created with the create_function api. Integers passed to a sqlite function are always converted to int instead of long, which produces an incorrect value for integers outside the range of a int32 on a 32 bit machine. These failures cannot be reproduced on a 64 bit machine, since sizeof(long) == sizeof(long long).

I attached a program that demonstrates the failure. This program reports failures on a 32 bit machine, and all tests pass on a 64 bit machine.

----------
components: Library (Lib)
files: sqlite_long_test.py
messages: 100235
nosy: BinaryMan32
severity: normal
status: open
title: sqlite: broken long integer handling for arguments to user-defined functions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16404/sqlite_long_test.py

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

From report at bugs.python.org  Mon Mar  1 12:02:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Mar 2010 11:02:02 +0000
Subject: [New-bugs-announce] [issue8034] logging: Improve error handing
	in	RotatingFileHandler.doRollover()
In-Reply-To: <1267441322.05.0.291147290559.issue8034@psf.upfronthosting.co.za>
Message-ID: <1267441322.05.0.291147290559.issue8034@psf.upfronthosting.co.za>


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

My server is running as root and is writing logs into /var/log/nucentral.log. I tried to run it under a different user ("nucentral"), and I changed /var/log/nucentral.log file permissions.

I'm using:
   MAX_LOG_FILESIZE = 5 * 1024 * 1024
   MAX_LOG_FILES = 10   # including .log, so last file prefix is .log.9

   handler = RotatingFileHandler('/var/log/nucentral.log', 'a',
      maxBytes=MAX_LOG_FILESIZE, backupCount=(MAX_LOG_FILES - 1),
      encoding='utf8')

The problems start at the next rollover: the user is not allowed to write into /var/log, and so rename /var/log/nucentral.log to /var/log/nucentral.log.1 (and /var/log/nucentral.log.2 to /var/log/nucentral.log.3) fails. We have here a new problem: doRollover() starts by closing the log file and then rename files. If rename fails, the stream is closed and no new stream is opened. But my server catchs any exception and write them into /var/log/nucentral.log. The rename exception will be written... in the log file, but writing in a closed file raise a new exception! The log system is completly broken and go into an evil recursion loop :-)

I can fix my code responsible to log any exception to avoid the recursion, and avoid the directory permission by writing into /var/log/nucentral/. But there is still the problem of closing the stream before renaming the log files.

I propose to close the stream *after* renaming old log files. Attached patch closes the stream just before reopening it. It works correctly on Linux.

I don't know if it's possible on Windows to rename a file which is currently open :-/ Anyway, the goal is to ensure that the stream is open when exiting the doRollover() function. Another idea would be to use the following pattern:
  stream.close()
  try:
     ...
  except:
     self.stream = self._open()
     raise
  else:
     self._mode = 'w'
     self.stream = self._open()

----------
components: Library (Lib)
files: logging_rotate.patch
keywords: patch
messages: 100252
nosy: haypo
severity: normal
status: open
title: logging: Improve error handing in RotatingFileHandler.doRollover()
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16406/logging_rotate.patch

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

From report at bugs.python.org  Mon Mar  1 23:20:06 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Mon, 01 Mar 2010 22:20:06 +0000
Subject: [New-bugs-announce] [issue8037] multiprocessing.Queue's put() not
	atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>


New submission from Vilnis Termanis <vilnis.termanis at googlemail.com>:

If an object, which as been put() in the multiprocessing.Queue is changed immediately after the put() call then changed version may be added to the queue which I assume is not the expected behaviour:

>>> from multiprocessing import Queue
>>> q = Queue()
>>> obj = [[i for i in xrange(j * 10, (j * 10) + 10)] for j in xrange(0,10)]
>>> q.put(obj); obj[-1][-1] = None
>>> obj2 = q.get()
>>> print obj2[-1][-1]
None

Note: This also happens if the queue is called form a child process like in the attached example.

----------
components: Library (Lib)
files: queue_example.py
messages: 100278
nosy: vilnis.termanis
severity: normal
status: open
title: multiprocessing.Queue's put() not atomic thread wise
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16409/queue_example.py

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

From report at bugs.python.org  Tue Mar  2 14:57:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Mar 2010 13:57:46 +0000
Subject: [New-bugs-announce] [issue8038] Not all the new assert*
	unittest.TestCase methods have	negative (not) equivalents
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Originally reported as a bug against unittest2: http://code.google.com/p/unittest-ext/issues/detail?id=3

There are some assert* methods that don't have their assertNot* 
counterparts. There's assertDictEqual, assertSequenceEqual, 
assertRegexpMatches, but no assertDictNotEqual, assertSequenceNotEqual, 
assertRegexpNotMatches, for example.

They should be present for the sake of completeness (I don't like to have to look into the docs to check if a method has a negative counterpart), but also because they ask for a custom output. For example, the error accompanying assertRegexpNotMatches could show the matching part of the text, which is the part that really interests me. assert_(re.match(...)) will only tell me that None is not true...

----------
assignee: michael.foord
components: Library (Lib)
messages: 100291
nosy: michael.foord
severity: normal
status: open
title: Not all the new assert* unittest.TestCase methods have negative (not) equivalents
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Mar  2 15:26:06 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 02 Mar 2010 14:26:06 +0000
Subject: [New-bugs-announce] [issue8039] precedence rules for ternary
	operator
In-Reply-To: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>
Message-ID: <1267539966.16.0.161002317755.issue8039@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

So http://docs.python.org/reference/expressions.html doesn't currently mention the ternary operator as far as I can see. Maybe this is trivial, but it would be nice to know where it fits into the hierarchy.

(I.e., my co-worker just came up to me asking when he needed the parentheses around the entire expression and when he didn't, and I couldn't give him a good answer.)

----------
assignee: georg.brandl
components: Documentation
messages: 100294
nosy: djc, georg.brandl
severity: normal
status: open
title: precedence rules for ternary operator
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Mar  2 16:30:45 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 02 Mar 2010 15:30:45 +0000
Subject: [New-bugs-announce] [issue8040] It would be nice if documentation
	pages linked to other	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Currently, trying to use a web search engine to find something in the Python docs often returns the documentation for only one version of Python.  Something a very old version like 2.3.

It would be nice if the documentation pages on docs.python.org included links to older and later versions of the same documentation page, if one exists.  That would make it much easier to navigate to the desired version of a page.  The extra links could be placed on the sidebar on the left side, perhaps below the Quick Search box.

Additionally, it might help search engines find and index the documentation for the other versions.

Microsoft does this for their .NET documentation and it's very handy (e.g., http://msdn.microsoft.com/en-us/library/system.windows.forms.control.aspx)

----------
assignee: georg.brandl
components: Documentation
messages: 100297
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: It would be nice if documentation pages linked to other versions of the same document
type: feature request

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

From report at bugs.python.org  Tue Mar  2 16:34:58 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 02 Mar 2010 15:34:58 +0000
Subject: [New-bugs-announce] [issue8041] No documentation for
	Py_TPFLAGS_HAVE_STACKLESS_EXTENSION	or Py_TPFLAGS_HAVE_VERSION_TAG.
In-Reply-To: <1267544098.65.0.440493208051.issue8041@psf.upfronthosting.co.za>
Message-ID: <1267544098.65.0.440493208051.issue8041@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The documentation for Py_TPFLAGS_DEFAULT mentions Py_TPFLAGS_HAVE_STACKLESS_EXTENSION and Py_TPFLAGS_HAVE_VERSION_TAG, but neither of them is documented.  They aren't mentioned in the 2.6 documentation (presumably because they were introduced in 3.x?).

http://docs.python.org/dev/py3k/c-api/typeobj.html?highlight=py_tpflags_have_gc#Py_TPFLAGS_DEFAULT

----------
assignee: georg.brandl
components: Documentation
messages: 100298
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: No documentation for Py_TPFLAGS_HAVE_STACKLESS_EXTENSION or Py_TPFLAGS_HAVE_VERSION_TAG.
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Mar  2 22:26:06 2010
From: report at bugs.python.org (Matt Gattis)
Date: Tue, 02 Mar 2010 21:26:06 +0000
Subject: [New-bugs-announce] [issue8042] mmap buffer implementation does not
	respect seek pos
In-Reply-To: <1267565166.19.0.574774228876.issue8042@psf.upfronthosting.co.za>
Message-ID: <1267565166.19.0.574774228876.issue8042@psf.upfronthosting.co.za>


New submission from Matt Gattis <gattis at gmail.com>:

If you do:

import io,mmap

b = io.BytesIO("abc")
m = mmap.mmap(-1,10)
m.seek(5)
b.readinto(m)

M is now:
'abc\x00\x00\x00\x00\x00\x00\x00'

Basically there is no way to readinto/recv_into an arbitary position in an mmap object without creating a middle-man string.

----------
messages: 100308
nosy: Matt.Gattis
severity: normal
status: open
title: mmap buffer implementation does not respect seek pos
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar  2 23:52:05 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 02 Mar 2010 22:52:05 +0000
Subject: [New-bugs-announce] [issue8043] ntpath.realpath munges os.devnull
In-Reply-To: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>
Message-ID: <1267570325.23.0.596578144082.issue8043@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

On Python 2.6 and Python 2.7a, calling ntpath.realpath(os.devnull) returns '\\\\nul' (two backslashes followed by nul), which is not a valid filename.

This appears to have been fixed in Python 3.1, as on 3.1.1, ntpath.realpath(os.devnull) returns '\\\\.\\nul' which apparently is the absolute path to the NULL file handle.

----------
components: Windows
messages: 100314
nosy: jaraco
severity: normal
status: open
title: ntpath.realpath munges os.devnull
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Mar  3 03:23:04 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 03 Mar 2010 02:23:04 +0000
Subject: [New-bugs-announce] [issue8044] Py_EnterRecursiveCall and
	Py_LeaveRecursiveCall are	undocumented
In-Reply-To: <1267582984.0.0.0717168026591.issue8044@psf.upfronthosting.co.za>
Message-ID: <1267582984.0.0.0717168026591.issue8044@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Here's the original message proposing the addition of these routines to the C API, which might serve as the basis of documentation:

http://mail.python.org/pipermail/python-dev/2003-October/039445.html

----------
assignee: georg.brandl
components: Documentation
messages: 100325
nosy: georg.brandl, stutzbach
severity: normal
status: open
title: Py_EnterRecursiveCall and Py_LeaveRecursiveCall are undocumented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Mar  3 03:33:53 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Mar 2010 02:33:53 +0000
Subject: [New-bugs-announce] [issue8045] test_tcl aborts on OS X 10.6 with
	"The application with	bundle ID org.python.python is running
	setugid(), which is not allowed."
In-Reply-To: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>
Message-ID: <1267583633.65.0.420297951623.issue8045@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

potential 2.6.5 release blocker

The changes introduced for Issue7999 in r78546, r78547, r78548, r78549 cause test_tcl to fail when it is run after test_os, as is normal under regrtest.  The problem is that the posixmodule was modified to accept values of -1 for setreuid and setregid and, although the tests added for them claim that they do nothing, on OS X 10.6 (in a framework build at least) they do have a side effect.  A simplified test case demonstrates:

$ ./python
Python 2.6.5rc1 (release26-maint, Mar  2 2010, 15:22:31) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import Tcl
>>> Tcl().loadtk()  # Tk window opens
>>> ^D
$ ./python
Python 2.6.5rc1 (release26-maint, Mar  2 2010, 15:22:31) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import Tcl
>>> import os
>>> os.getuid(), os.geteuid()
(501, 501)
>>> os.setreuid(-1, -1)
>>> os.getuid(), os.geteuid()
(501, 501)
>>> Tcl().loadtk()
2010-03-02 18:20:28.375 Python[21147:60f] The application with bundle ID org.python.python is running setugid(), which is not allowed.
$ ./python
Python 2.6.5rc1 (release26-maint, Mar  2 2010, 15:22:31) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import Tcl
>>> import os
>>> os.getgid(), os.getegid()
(20, 20)
>>> os.setregid(-1, -1)
>>> os.getgid(), os.getegid()
(20, 20)
>>> Tcl().loadtk()
2010-03-02 18:25:15.952 Python[21163:60f] The application with bundle ID org.python.python is running setugid(), which is not allowed.

Searching the web for "running setugid(), which is not allowed" shows various programs affected by this change in OS X 10.6, apparently to close a security hole.

Unfortunately, the module and test changes cause the standard python regression test to abort at test_tcl. For 2.6.5 at least, suggest disabling the two new -1, -1 tests on OS X.  (I assume that the other branches exhibit the same behavior but I haven't explicitly tested them yet.)

----------
messages: 100326
nosy: barry, gregory.p.smith, ned.deily, ronaldoussoren
severity: normal
status: open
title: test_tcl aborts on OS X 10.6 with "The application with bundle ID org.python.python is running setugid(), which is not allowed."
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Mar  3 04:39:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 03 Mar 2010 03:39:53 +0000
Subject: [New-bugs-announce] [issue8046] mmap.mmap as a context manager
In-Reply-To: <1267587593.82.0.663403244999.issue8046@psf.upfronthosting.co.za>
Message-ID: <1267587593.82.0.663403244999.issue8046@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Most file or file-like objects operate as context managers, except for mmap (and maybe a few others?). Attached is a patch with tests and documentation.

The patch also introduces an additional attribute to mmap, "closed".

----------
components: Library (Lib)
files: mmap_context_mgr.diff
keywords: needs review, patch, patch
messages: 100331
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: mmap.mmap as a context manager
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16420/mmap_context_mgr.diff

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

From report at bugs.python.org  Wed Mar  3 08:15:25 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 03 Mar 2010 07:15:25 +0000
Subject: [New-bugs-announce] [issue8047] Serialiser in ElementTree returns
	unicode strings in Py3k
In-Reply-To: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>
Message-ID: <1267600525.56.0.547982490868.issue8047@psf.upfronthosting.co.za>


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

The xml.etree.ElementTree package in the Python 3.x standard library breaks compatibility with existing ET 1.2 code. The serialiser returns a unicode string when no encoding is passed. Previously, the serialiser was guaranteed to return a byte string. By default, the string was 7-bit ASCII compatible.

This behavioural change breaks all code that relies on the default behaviour of ElementTree. Since there is no longer a default encoding in Python 3, unicode strings are incompatible with byte strings, which means that the result of the serialisation can no longer be written to a file, for example.

XML is well defined as a stream of bytes. Redefining it as a unicode string *by default* is hard to understand at best.

Finally, it would have been good to look at the other ET implementation before introducing such a change. The lxml.etree package has had support for serialising XML into a unicode string for years, and does so in a clear, safe and explicit way. It requires the user to pass the 'unicode' (Py3 'str') type as encoding parameter, e.g.

    tree.tostring(encoding=str)

which is explicit enough to make it clear that this is different from a normal encoding.

----------
components: Library (Lib)
messages: 100333
nosy: scoder
severity: normal
status: open
title: Serialiser in ElementTree returns unicode strings in Py3k
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Mar  3 09:17:35 2010
From: report at bugs.python.org (Noam Raphael)
Date: Wed, 03 Mar 2010 08:17:35 +0000
Subject: [New-bugs-announce] [issue8048] doctest assumes sys.displayhook
	hasn't been touched
In-Reply-To: <1267604255.42.0.0975325931502.issue8048@psf.upfronthosting.co.za>
Message-ID: <1267604255.42.0.0975325931502.issue8048@psf.upfronthosting.co.za>


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

Hello,

This bug is the cause of a bug reported about DreamPie: https://bugs.launchpad.net/bugs/530969

DreamPie (http://dreampie.sourceforge.net) changes sys.displayhook so that values will be sent to the parent process instead of being printed in stdout. This causes doctest to fail when run from DreamPie, because it implicitly assumes that sys.displayhook writes the values it gets to sys.stdout. This is why doctest replaces sys.stdout with its own file-like object, which is ready to receive the printed values.

The solution is simply to replace sys.displayhook with a function that will do the expected thing, just like sys.stdout is replaced. The patch I attach does exactly this.

Thanks,
Noam

----------
components: Library (Lib)
files: doctest.py.diff
keywords: patch
messages: 100334
nosy: noam
severity: normal
status: open
title: doctest assumes sys.displayhook hasn't been touched
type: behavior
Added file: http://bugs.python.org/file16421/doctest.py.diff

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

From report at bugs.python.org  Wed Mar  3 10:10:51 2010
From: report at bugs.python.org (dawton)
Date: Wed, 03 Mar 2010 09:10:51 +0000
Subject: [New-bugs-announce] [issue8049] Wrong calculation result
In-Reply-To: <1267607451.17.0.432380400907.issue8049@psf.upfronthosting.co.za>
Message-ID: <1267607451.17.0.432380400907.issue8049@psf.upfronthosting.co.za>


New submission from dawton <dawton at centrum.cz>:

I'm using Python 2.3 and today I found out, that Python gives following result:
>>> 2.05*60
122.99999999999999

while
>>> 2.05*10*6
123.0

Is there some explanation or is it a bug?
Thanks for answer!

----------
messages: 100335
nosy: dawton
severity: normal
status: open
title: Wrong calculation result
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Mar  3 16:00:17 2010
From: report at bugs.python.org (Allison Vollmann)
Date: Wed, 03 Mar 2010 15:00:17 +0000
Subject: [New-bugs-announce] [issue8050] smtplib SMTP.sendmail (TypeError:
	expected string or	buffer)
In-Reply-To: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>
Message-ID: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>


New submission from Allison Vollmann <allisonvoll at gmail.com>:

When call SMTP.sendmail (with simple sendmail local sent and with smtp auth), the follow exception be raised (with debug output):

send: 'mail FROM:<xxx> size=5\r\n'
reply: '250 2.1.0 Ok\r\n'
reply: retcode (250); Msg: 2.1.0 Ok
send: 'rcpt TO:<xxx>\r\n'
reply: '250 2.1.5 Ok\r\n'
reply: retcode (250); Msg: 2.1.5 Ok
send: 'data\r\n'
reply: '354 End data with <CR><LF>.<CR><LF>\r\n'
reply: retcode (354); Msg: End data with <CR><LF>.<CR><LF>
data: (354, 'End data with <CR><LF>.<CR><LF>')

Traceback (most recent call last):
  File "<pyshell#14>", line 1, in <module>
    s.sendmail(to, to, msg)
  File "C:\Python26\lib\smtplib.py", line 710, in sendmail
    (code,resp) = self.data(msg)
  File "C:\Python26\lib\smtplib.py", line 474, in data
    q = quotedata(msg)
  File "C:\Python26\lib\smtplib.py", line 157, in quotedata
    re.sub(r'(?:\r\n|\n|\r(?!\n))', CRLF, data))
  File "C:\Python26\lib\re.py", line 151, in sub
    return _compile(pattern, 0).sub(repl, string, count)
TypeError: expected string or buffer

This error appear because 'data' isn't an string object, just replacing "q = quotedata(msg)" for "q = quotedata(str(msg))" (in Python26\lib\smtplib.py:474) solves the problem, but i can't understand how this simple mistake does not be noticed

Teste in: 
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2,
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32

----------
components: Regular Expressions
messages: 100346
nosy: Allison.Vollmann
severity: normal
status: open
title: smtplib SMTP.sendmail (TypeError: expected string or buffer)
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar  4 02:31:23 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Thu, 04 Mar 2010 01:31:23 +0000
Subject: [New-bugs-announce] [issue8051] Python 2.7 alpha 4 show wrong
	version number on osx
In-Reply-To: <1267666283.13.0.780019714346.issue8051@psf.upfronthosting.co.za>
Message-ID: <1267666283.13.0.780019714346.issue8051@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

Python 2.7 alpha 4 (trunk 78643) upon being invoked on terminal shows wrong version number.Since it is no longer alpha 3, it should show 'Python 2.7a4+' as version

Shashwat-Anands-MacBook-Pro:Misc l0nwlf$ python2.7
Python 2.7a3+ (trunk:78643, Mar  4 2010, 06:44:41) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse    # to verify this is python 2.7 alpha 4
>>>

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100368
nosy: l0nwlf, ronaldoussoren
severity: normal
status: open
title: Python 2.7 alpha 4 show wrong version number on osx
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar  4 08:24:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Mar 2010 07:24:44 +0000
Subject: [New-bugs-announce] [issue8053] test_thread fails on Windows
In-Reply-To: <1267687484.02.0.101944239252.issue8053@psf.upfronthosting.co.za>
Message-ID: <1267687484.02.0.101944239252.issue8053@psf.upfronthosting.co.za>


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

test_thread currently fails, then hangs on Windows with this output:

test_thread
Unhandled exception in thread started by <function thread1 at 0x0182E4F0>
Traceback (most recent call last):
  File "C:\Python26\lib\test\test_thread.py", line 180, in thread1
    pid = os.fork() # fork in a thread
AttributeError: 'module' object has no attribute 'fork'

I believe the logic in r78551 is reverted: the test should be executed if the sys.platform does *not* start with "win". Negating the condition makes test_thread pass on Windows.

----------
assignee: gregory.p.smith
messages: 100378
nosy: barry, gregory.p.smith, loewis
priority: release blocker
severity: normal
status: open
title: test_thread fails on Windows
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar  4 09:24:55 2010
From: report at bugs.python.org (Dongying Zhang)
Date: Thu, 04 Mar 2010 08:24:55 +0000
Subject: [New-bugs-announce] [issue8054] "as_string" method in email's mime
	objects encode text	segmentedly
In-Reply-To: <1267691095.13.0.237646934918.issue8054@psf.upfronthosting.co.za>
Message-ID: <1267691095.13.0.237646934918.issue8054@psf.upfronthosting.co.za>


New submission from Dongying Zhang <zhangdongying1986 at gmail.com>:

The as_string method in mime classes in module email.mime use base64 to encode the text, but segmentedly while the text contents non-acsii characters and is in type of unicode. This behavior confuse some of the email servers.
For example:
===================================================================
#-*- coding: utf-8 -*-
import base64
from email.mime.text import MIMEText
content = u'''Hello:
    ????????.
   Please remove this message after reading,
   and I hope this won't bother you for a long time
'''
m = MIMEText(content, 'plain', 'utf-8')
print m.as_string()
m = MIMEText(content.encode('utf-8'), 'plain', 'utf-8')
print m.as_string()
print base64.encodestring(content.encode('utf-8'))
===================================================================
The first as_string method gives:
-------------------------------------------------------------------
SGVsbG86CiAgICDov5nmmK/kuIDlsIHmtYvor5Xpgq7ku7YuCiAgIFBsZWFzZSByZW1vdmUgdGhpcyBtZXNzYWdlIGFmdGVyIA==
cmVhZGluZywKICAgYW5kIEkgaG9wZSB0aGlzIHdvbid0IGJvdGhlciB5b3UgZm9yIGEgbG9uZyB0
aW1lCg==
-------------------------------------------------------------------
Please notice that there is a '==' at the end of the first line.
The output of both the second as_string and base64.encodestring method maybe more appropriate, which is:
-------------------------------------------------------------------
SGVsbG86CiAgICDov5nmmK/kuIDlsIHmtYvor5Xpgq7ku7YuCiAgIFBsZWFzZSByZW1vdmUgdGhp
cyBtZXNzYWdlIGFmdGVyIHJlYWRpbmcsCiAgIGFuZCBJIGhvcGUgdGhpcyB3b24ndCBib3RoZXIg
eW91IGZvciBhIGxvbmcgdGltZQo=

----------
components: IO
files: test.py
messages: 100380
nosy: zhangdongying
severity: normal
status: open
title: "as_string" method in email's mime objects encode text segmentedly
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16428/test.py

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

From report at bugs.python.org  Thu Mar  4 13:19:16 2010
From: report at bugs.python.org (Knut Eldhuset)
Date: Thu, 04 Mar 2010 12:19:16 +0000
Subject: [New-bugs-announce] [issue8055] Sleeping after acquiring RLock
	causes acquire to block in	other thread
In-Reply-To: <1267705156.46.0.257665685005.issue8055@psf.upfronthosting.co.za>
Message-ID: <1267705156.46.0.257665685005.issue8055@psf.upfronthosting.co.za>


New submission from Knut Eldhuset <knut.eldhuset at gmail.com>:

In essence I have the following loop running in thread A:

while True:
    with self.lock:
        time.sleep(0.1)

I then try to acquire the lock in thread B. This blocks forever on Linux, but runs fine on Windows XP.

The following modification makes the code behave as expected on Linux:

while True:
    time.sleep(0.001)
    with self.lock:
        time.sleep(0.1)

See the attached file for the full example. Python versions are:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15)
[GCC 4.4.1] on linux2

and

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32

----------
components: Library (Lib)
files: threadtest.py
messages: 100383
nosy: knutel
severity: normal
status: open
title: Sleeping after acquiring RLock causes acquire to block in other thread
versions: Python 2.6
Added file: http://bugs.python.org/file16430/threadtest.py

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

From report at bugs.python.org  Thu Mar  4 16:27:08 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Thu, 04 Mar 2010 15:27:08 +0000
Subject: [New-bugs-announce] [issue8056] Piped parent's
	multiprocessing.Process children cannot	write to stdout
In-Reply-To: <1267716428.75.0.581894623963.issue8056@psf.upfronthosting.co.za>
Message-ID: <1267716428.75.0.581894623963.issue8056@psf.upfronthosting.co.za>


New submission from Vilnis Termanis <vilnis.termanis at googlemail.com>:

Affects Win32 only (tested under Ubuntu 9.10-64 and XP-32 with v2.6.4). If script output is piped, child processes created via multiprocessing.Process cannot write to stdout. Also, trying to call stdout.flush() in child processes causes IOError.

Normal behaviour
----------------
C:\>stdout.py
[Parent] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
[Parent] message via stdout

[Child] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
[Child] message via stdout

Piped behaviour (same result if redirecting to file)
---------------
C:\>stdout.py | cat
[Parent] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
[Parent] message via stdout

[Child] stdout: <open file '<stdout>', mode 'w' at 0x00A54070>
Process Process-1:
Traceback (most recent call last):
  File "C:\Python26\lib\multiprocessing\process.py", line 232, in _bootstrap
    self.run()
  File "C:\Python26\lib\multiprocessing\process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "C:\stdout.py", line 18, in child
    stdout.flush()
IOError: [Errno 9] Bad file descriptor

----------
components: Library (Lib), Windows
files: stdout.py
messages: 100390
nosy: vilnis.termanis
severity: normal
status: open
title: Piped parent's multiprocessing.Process children cannot write to stdout
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16432/stdout.py

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

From report at bugs.python.org  Thu Mar  4 17:46:33 2010
From: report at bugs.python.org (Andreas Poisel)
Date: Thu, 04 Mar 2010 16:46:33 +0000
Subject: [New-bugs-announce] [issue8057] Impreciseness in bz2 module
	documentation?
In-Reply-To: <1267721193.52.0.548079190906.issue8057@psf.upfronthosting.co.za>
Message-ID: <1267721193.52.0.548079190906.issue8057@psf.upfronthosting.co.za>


New submission from Andreas Poisel <ap at acat.cc>:

A string in Python 3 is a sequence of unicode characters, right?  The
documentation of the bz2 module says:

8<------------------------------------------------------------------
class bz2.BZ2File(filename, mode='r', buffering=0, compresslevel=9)
[...]
write(data)
    Write string data to file. Note that due to buffering, close() may be
    needed before the file on disk reflects the data written.
[...]
8<------------------------------------------------------------------

So the documentation wants me to pass a "string data" to the write() method:

8<------------------------------------------------------------------
>>> import bz2
>>> with bz2.BZ2File('test.bz2', mode='w') as cfh:
...     cfh.write('Test')
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: must be bytes or buffer, not str
8<------------------------------------------------------------------

So what write() really wants is a byte array or an encoded string:

8<------------------------------------------------------------------
>>> with bz2.BZ2File('test.bz2', mode='w') as cfh:
...     cfh.write(bytes('Test', encoding='iso-8859-1'))
... 
>>> with bz2.BZ2File('test.bz2', mode='w') as cfh:
...     cfh.write('Test'.encode('iso-8859-1'))
... 
8<------------------------------------------------------------------

Is this an inaccuracy of the documentation or did I get something wrong?

----------
messages: 100397
nosy: Haudegen
severity: normal
status: open
title: Impreciseness in bz2 module documentation?
versions: Python 3.1

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

From report at bugs.python.org  Thu Mar  4 17:57:09 2010
From: report at bugs.python.org (daz)
Date: Thu, 04 Mar 2010 16:57:09 +0000
Subject: [New-bugs-announce] [issue8058] incorrect behavior of
	get_filename() method in email pkg
In-Reply-To: <1267721829.4.0.200487956077.issue8058@psf.upfronthosting.co.za>
Message-ID: <1267721829.4.0.200487956077.issue8058@psf.upfronthosting.co.za>


New submission from daz <admin at dazadi.com>:

get_filename() does not parse the Content-Type header for a "name" parameter. This is the old-style RFC 1341 header. Example:

Content-Type: application/octet-stream;
 name="somefile.pdf"
Content-Transfer-Encoding: base64

The email package documentation states:

get_filename([failobj])
    Return the value of the filename parameter of the Content-Disposition header of the message. If the header does not have a filename parameter, this method falls back to looking for the name parameter. If neither is found, or the header is missing, then failobj is returned...

As documented, get_filename() falls back to looking for the "name"
parameter in the Content-Disposition header. Instead, it should fall
back to looking for the "name" parameter in the Content-Type header.

----------
components: Library (Lib)
messages: 100399
nosy: daz
severity: normal
status: open
title: incorrect behavior of get_filename() method in email pkg
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu Mar  4 21:12:48 2010
From: report at bugs.python.org (steven Michalske)
Date: Thu, 04 Mar 2010 20:12:48 +0000
Subject: [New-bugs-announce] [issue8060] PEP 3101 string formatting missing
	engineering	presentation type for floating point
In-Reply-To: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>
Message-ID: <1267733568.91.0.590819765764.issue8060@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

I started using the .format() on strings and was surprised that it was lacking an built in format specifier for engineering notation.

For those unfamiliar with engineering notation it puts the exponent of the number in modulo 3 so that it is in alignment with SI prefixes  such as kilo, micro, milli, etc...

11,000 in engineering notation would be 11.000e3

At this time if i want engineering notation I need to use a function to convert it to a string and then print the string.  Most inconvenient for a standard formatting used in the engineering fields.

----------
messages: 100413
nosy: hardkrash
severity: normal
status: open
title: PEP 3101 string formatting missing engineering presentation type for floating point
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Mar  4 22:46:46 2010
From: report at bugs.python.org (steven Michalske)
Date: Thu, 04 Mar 2010 21:46:46 +0000
Subject: [New-bugs-announce] [issue8062] PEP 3101 string formatting missing
	hexadecimal separator	_ for every 4 hex digits
In-Reply-To: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>
Message-ID: <1267739206.12.0.0725020069518.issue8062@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

It is a common practice to separate hex digits with a "thousands" separator every 4 hex digits.

0x1234_abcd

Although python does not accept the _ as a thousands separator in hex notation, neither is the thousands separator in base 10


Snippet that prints hex thousands with a _ separator

number = 0xef5678abcd1234

def hex_thousands(number):
    txt="{0:X}".format(number)
    txt_out = ""
    i = range(-4,-1 * (len(txt) + 4), -4)
    ii = i[:]
    ii.insert(0, None)
    for (j, k) in zip(i, ii):
        if txt_out:
            txt_out = "_" + txt_out
        txt_out = txt[j:k] + txt_out
    return txt_out

print hex_thousands(number)

----------
messages: 100422
nosy: hardkrash
severity: normal
status: open
title: PEP 3101 string formatting missing hexadecimal separator _ for every 4 hex digits
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Mar  5 00:09:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Mar 2010 23:09:57 +0000
Subject: [New-bugs-announce] [issue8063] Call _PyGILState_Init() earlier in
	Py_InitializeEx()
In-Reply-To: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>
Message-ID: <1267744197.1.0.664779918218.issue8063@psf.upfronthosting.co.za>


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

_PyGILState_Init() initialize autoInterpreterState variable. This variable have to be set before the first call to PyGILState_Ensure().

The problem is that _PyGILState_Init() is called late: at the end of Py_InitializeEx(). It's called after initsite(), whereas initsite() may need to call _PyGILState_Init().

Example: add the following lines at the end of site.py:
---
import readline
import rlcompleter
readline.parse_and_bind("tab: complete")
raw_input("press TAB")
---
Run an interpreter and press TAB:
---
$ ./python
press TABpython: Python/pystate.c:595: PyGILState_Ensure: Assertion `autoInterpreterState' failed.
Abandon
---

Other example of functiions using _PyGILState_Init(): _PyObject_Dump() (useful for debug), sqlite module, os.popen*(), ctypes Python callbacks, etc.

I don't know the right place for _PyGILState_Init() in Py_InitializeEx(). _PyGILState_Init() calls the following functions:
 - PyThread_get_thread_ident()
 - PyThread_allocate_lock()
 - PyThread_acquire_lock()
 - PyThread_release_lock()
 - Py_FatalError() (on error)

None of these function use Python functions, so _PyGILState_Init() can be called very early. The earliest position is just after the call to PyThreadState_New(), before PyThreadState_Swap(). It tested it and it works correctly.

If _PyGILState_Init() is called before PyThreadState_Swap(), PyThreadState_Swap() can be simplified (it doesn't need to check if GIL is initialized or not). Attached patch implement that.

--

I hit this bug when I was debuging Python: I added a call to _PyObject_Dump() which stopped Python (assertion error) because the GIL was not initialized :-/

I already hitted this bug some weeks ago when I was working on the thread state preallocation when creating a new thread: #7544.

----------
files: gil_state_init-trunk.patch
keywords: patch
messages: 100432
nosy: haypo
severity: normal
status: open
title: Call _PyGILState_Init() earlier in Py_InitializeEx()
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16439/gil_state_init-trunk.patch

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

From report at bugs.python.org  Fri Mar  5 00:14:46 2010
From: report at bugs.python.org (Oliver Sturm)
Date: Thu, 04 Mar 2010 23:14:46 +0000
Subject: [New-bugs-announce] [issue8064] Large regex handling very slow on
	Linux
In-Reply-To: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>
Message-ID: <1267744486.0.0.0927459766822.issue8064@psf.upfronthosting.co.za>


New submission from Oliver Sturm <oliver at sturmnet.org>:

The code in regextest.py (attached) uses a large regex to analyze a piece of text. I have tried this test program on two Macs, using the standard Python distributions.

On a MacBook, 2.4 GHz dual core, Snow Leopard with Python 2.6.1, it takes 0.08 seconds
On a MacPro, 2.something GHz 8 core, Leopard with Python 2.5.1, it takes 0.09 seconds

Now I've also tried it on several Linux machines, all of them running Ubuntu. They are all extremely slow. The machine I've been testing with now is a 2.0 GHz dual core machine with Python 2.5.2. A test run of the program takes 97.5 (that's not a typo) seconds on this machine, 1200 times as long as on the Macs.

----------
components: Regular Expressions
files: regextest.py
messages: 100434
nosy: michael.foord, olivers
severity: normal
status: open
title: Large regex handling very slow on Linux
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file16440/regextest.py

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

From report at bugs.python.org  Fri Mar  5 11:38:58 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2010 10:38:58 +0000
Subject: [New-bugs-announce] [issue8066] OS X installer: readline module
	breaks when targeting on	10.5 or 10.6
In-Reply-To: <1267785538.67.0.674687139029.issue8066@psf.upfronthosting.co.za>
Message-ID: <1267785538.67.0.674687139029.issue8066@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

2.6.5 release blocker

Changes for Issue6877 to enable the readline module to use the
native OS X editline library instead of GNU readline introduce
a problem for OS X installer builds or other builds using
MACOSX_DEPLOYMENT_TARGET.  The test in setup.py to determine
whether to search for a non-system library is based solely 
on the OS level of the build system and not the minimum
deployment target level.  Without this patch to setup.py,
10.3- or 10.4-targeted installer builds on 10.5 or 10.6
will fail to search for the installer-supplied GNU readline
*and* will be dynamically linked with the crippled
10.4u SDK version of editline, thereby causing the readline
module to crash on all levels of OS X.  (The installer build
needs to continue to supply GNU readline because of the broken
10.4 editline).

Symptoms vary by OS level and arch but include bus errors and
test failures such as:

test_readline failed --  line 29, in testHistoryUpdates
    self.assertEqual(readline.get_current_history_length(), 2)
AssertionError: 8448056 != 2
[10.5]: Python(71826,0xa0c18820) malloc: *** error for object 0x80e994: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
[10.6]: Python(25154,0xa0b73500) malloc: *** error for object 0x80df94: pointer being freed was not allocated
[10.4]: test_readline skipped -- dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/readline.so, 2): Symbol not found: _rl_free_line_state


Patches supplied for 26, trunk(27), and py3k(32), but *not*
31 as the readline changes have not been backported to 31.

The trunk and 2.6 versions of the patch also correct a version
test in setup.py that causes builds on 10.6 to be flooded with
OS X deprecation warnings.

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-sl-setup-26.txt
messages: 100463
nosy: barry, ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X installer: readline module breaks when targeting on 10.5 or 10.6
type: crash
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16448/issue-sl-setup-26.txt

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

From report at bugs.python.org  Fri Mar  5 12:02:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2010 11:02:57 +0000
Subject: [New-bugs-announce] [issue8067] OS X Installer: build errors on
	10.6 when targeting 10.4	and earlier
In-Reply-To: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>
Message-ID: <1267786977.51.0.168741783501.issue8067@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When building on 10.6 with a deployment target of 10.3 or 10.4,
various build errors occur, like:
    warning: 'struct winsize' declared inside parameter list
    error: 'struct rusage' has no member named 'ru_maxrss'

The problem is a test in configure.in that isn't prepared to handle
a two-digit Darwin kernel version: OS X 10.6 is Darwin 10.  The
patches backport the fix from trunk(2.7) to 2.6, 3.1, and py3k(3.2).
(As usual, autoconf needs to be run after applying to update configure.)

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-sl-configure-26.txt
messages: 100465
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X Installer: build errors on 10.6 when targeting 10.4 and earlier
type: compile error
versions: Python 2.6, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16451/issue-sl-configure-26.txt

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

From report at bugs.python.org  Fri Mar  5 12:35:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Mar 2010 11:35:18 +0000
Subject: [New-bugs-announce] [issue8068] OS X Installer: merge python2 and
	python3	build-installer.py script
In-Reply-To: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>
Message-ID: <1267788918.05.0.336335013502.issue8068@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Since the split of Python3, the OS X installer build scripts in the
four active source trees have diverged due to multiple edits at
different times such that most changes can no longer be easily
merged across branches without significant hand editing, even
though the scripts differ only trivially in functionality.

The attached patches for the 26, trunk(27), 31, and py3k(31) trees result in an identical build script across all four with execution
tests for the following python3 differences:
    1. Installer packages "PythonProfileChanges" and
       "PythonSystemFixes" default to "not selected for install"
    2. Include "--with-computed-gotos" on configure.
    3. Do not change Framework/Current link during install.

Also included is another patch which, if applied, would restore the change made to trunk in r77030 to change the default installation
state of the UNIX Tools Package from "selected" to "not selected",
thus by default not installing any symlinks in /usr/local/bin. 
It's not clear why this change should be made and only to trunk,
at that.  If it is applied, it should be accompanied by appropriate
NEWS and Installer README changes as it would affect how many users currently access python on OS X.

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-sl-installer-26.txt
messages: 100467
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X Installer: merge python2 and python3 build-installer.py script
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16454/issue-sl-installer-26.txt

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

From report at bugs.python.org  Fri Mar  5 13:44:46 2010
From: report at bugs.python.org (Jeremy Sanders)
Date: Fri, 05 Mar 2010 12:44:46 +0000
Subject: [New-bugs-announce] [issue8069] struct documentation problem and
	suggestion to add fixed	size formats
In-Reply-To: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>
Message-ID: <1267793086.76.0.824912742034.issue8069@psf.upfronthosting.co.za>


New submission from Jeremy Sanders <jeremy at jeremysanders.net>:

The struct documentation at http://docs.python.org/library/struct.html says:

Standard size and alignment are as follows: no alignment is required for any type (so you have to use pad bytes); short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) is 8 bytes; float and double are 32-bit and 64-bit IEEE floating point numbers, respectively. _Bool is 1 byte.

long on linux x86-64 is not 4 bytes. It is 8 bytes long:

xpc1:~:$ python
Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57) 
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.calcsize('L')
8
>>> struct.calcsize('l')
8

It is 4 bytes on i386, however. The documentation should say that long is 8 bytes on linux x86-64.

Also, would it not be a good idea to add struct sizes with specific data sizes, e.g. 1 byte, 2 bytes, 4 bytes, 8 bytes, so that it is easier to write cross-platform code?

----------
components: Library (Lib)
messages: 100470
nosy: jeremysanders
severity: normal
status: open
title: struct documentation problem and suggestion to add fixed size formats
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar  5 15:22:52 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Mar 2010 14:22:52 +0000
Subject: [New-bugs-announce] [issue8071] test message
In-Reply-To: <19345.5047.713471.759783@montanaro.dyndns.org>
Message-ID: <19345.5047.713471.759783@montanaro.dyndns.org>


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

I don't know where this will go given that it's not a response to an
existing bug report.  I'm looking to see if the SpamBayes instance on
mail.python.org processes this message.

Someone please respond to let me know if this address is working properly
again w.r.t. spam filtering.

Thanks,

Skip

----------
messages: 100480
nosy: skip.montanaro
severity: normal
status: open
title: test message

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

From report at bugs.python.org  Fri Mar  5 15:47:09 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 05 Mar 2010 14:47:09 +0000
Subject: [New-bugs-announce] [issue8072] Test #2
In-Reply-To: <19345.6502.784963.115969@montanaro.dyndns.org>
Message-ID: <19345.6502.784963.115969@montanaro.dyndns.org>


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

After training a bunch of mail held for python-bugs-list I'm trying another
post to see how well SpamBayes likes it.

Skip

----------
messages: 100482
nosy: skip.montanaro
severity: normal
status: open
title: Test #2

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

From report at bugs.python.org  Fri Mar  5 17:07:35 2010
From: report at bugs.python.org (Chris Lieb)
Date: Fri, 05 Mar 2010 16:07:35 +0000
Subject: [New-bugs-announce] [issue8073] Test fail for sha512
In-Reply-To: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>
Message-ID: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>


New submission from Chris Lieb <chris.lieb.hotmail+python at gmail.com>:

I am building Python 2.6.4 with GCC 4.2.1 (SUSE Linux, kernel  2.6.22.19-0.4-default) on a shared server and am encountering test
failures in test_hashlib.py and test_hmac.py, specifically concerning
sha512.  I recompiled Python with --with-pydebug and CLFAGS=CPPFLAGS="-
g" and ran the tests in GDB and got the following results:

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

GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-suse-linux"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run test_hashlib.py
Starting program: /export/users1/chris.lieb/packages/python/bin/
python2.6 test_hashlib.py
test_case_md5_0 (__main__.HashLibTestCase) ... ok
test_case_md5_1 (__main__.HashLibTestCase) ... ok
test_case_md5_2 (__main__.HashLibTestCase) ... ok
test_case_md5_huge (__main__.HashLibTestCase) ... ok
test_case_md5_uintmax (__main__.HashLibTestCase) ... ok
test_case_sha1_0 (__main__.HashLibTestCase) ... ok
test_case_sha1_1 (__main__.HashLibTestCase) ... ok
test_case_sha1_2 (__main__.HashLibTestCase) ... ok
test_case_sha1_3 (__main__.HashLibTestCase) ... ok
test_case_sha224_0 (__main__.HashLibTestCase) ... ok
test_case_sha224_1 (__main__.HashLibTestCase) ... ok
test_case_sha224_2 (__main__.HashLibTestCase) ... ok
test_case_sha224_3 (__main__.HashLibTestCase) ... ok
test_case_sha256_0 (__main__.HashLibTestCase) ... ok
test_case_sha256_1 (__main__.HashLibTestCase) ... ok
test_case_sha256_2 (__main__.HashLibTestCase) ... ok
test_case_sha256_3 (__main__.HashLibTestCase) ... ok
test_case_sha384_0 (__main__.HashLibTestCase) ... ok
test_case_sha384_1 (__main__.HashLibTestCase) ... ok
test_case_sha384_2 (__main__.HashLibTestCase) ... ok
test_case_sha384_3 (__main__.HashLibTestCase) ... ok
test_case_sha512_0 (__main__.HashLibTestCase) ... FAIL
test_case_sha512_1 (__main__.HashLibTestCase) ... FAIL
test_case_sha512_2 (__main__.HashLibTestCase) ... FAIL
test_case_sha512_3 (__main__.HashLibTestCase) ... FAIL
test_hexdigest (__main__.HashLibTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00002ba86ffbb463 in ?? ()
(gdb) bt
#0  0x00002ba86ffbb463 in ?? ()
#1  0x000000000046993d in PyString_FromStringAndSize (
    str=0x7fff71c67800 " \203 5~? T(P m\200\a \005\vW
\025 \203 ! l G <]
\205                                                    5
\203\030 \207~ /c 1 GAz\201 82z ' > x q \177",
size=1054484473)
    at Objects/stringobject.c:90
#2  0x00002ba87030d59a in ?? ()
#3  0x0000000000000000 in ?? ()

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

GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-suse-linux"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run test_hmac.py
Starting program: /export/users1/chris.lieb/packages/python/bin/
python2.6 test_hmac.py
test_legacy_block_size_warnings (__main__.TestVectorsTestCase) ... ok
test_md5_vectors (__main__.TestVectorsTestCase) ... ok
test_sha224_rfc4231 (__main__.TestVectorsTestCase) ... ok
test_sha256_rfc4231 (__main__.TestVectorsTestCase) ... ok
test_sha384_rfc4231 (__main__.TestVectorsTestCase) ... ok
test_sha512_rfc4231 (__main__.TestVectorsTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00002b483844e4c7 in ?? ()
(gdb) bt
#0  0x00002b483844e4c7 in ?? ()
#1  0x000000000046993d in PyString_FromStringAndSize (
    str=0x7ffff84f6730 "\026C3D \235D\t \025 [ G
\032bG? ~ \235\t\233aP",
    size=4108309188) at Objects/stringobject.c:90
#2  0x00002b48387e159a in ?? ()
#3  0x0000000000000000 in ?? ()

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

In the case of test_hashlib.py, it segfaulted on the first sha512 test
when I didn't have the debugging options enabled.  Only after enabling
debugging did I get FAIL's for the sha512 tests.

Does anyone know what is causing these failures? 

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

CPUINFO

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 246
stepping        : 8
cpu MHz         : 1992.106
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips        : 3988.23
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 246
stepping        : 8
cpu MHz         : 1992.106
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips        : 3990.71
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts ttp

----------
components: Tests
messages: 100488
nosy: frohman
severity: normal
status: open
title: Test fail for sha512
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar  5 18:32:24 2010
From: report at bugs.python.org (Cliff Dyer)
Date: Fri, 05 Mar 2010 17:32:24 +0000
Subject: [New-bugs-announce] [issue8074] Fail-fast behavior for unittest
In-Reply-To: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>
Message-ID: <1267810344.12.0.537474527773.issue8074@psf.upfronthosting.co.za>


New submission from Cliff Dyer <jcd at sdf.lonestar.org>:

When a long suite of tests is running, it would be nice to be able to exit out early to see the results of the tests that have run so far.  

I would like to see a couple of features included in `unittest` to this effect that have recently been implemented in django's test runner.  The first exits gracefully on `^C`, the second allows the user to specify a `--failfast` option, which causes the test runner to exit after the first failure or error, rather than proceeding with the 

If you hit `^C`, rather than exit with a stack trace of whatever was happening at the time, `unittest` should complete the current test, and then exit with the results to that point.  A second `^C` would be treated as a normal `KeyboardInterrupt`, in case that last test were somehow running on too long.

{{{
  $ python test_module.py
..F.s.^C <Test run halted by Ctrl-C> x
======================================================================
FAIL: test_multiline_equal (__main__.MyTest)
Unicode objects return diffs on failure
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_test.py", line 39, in test_multiline_equal
    self.assertEqual(original, revised)
AssertionError: 
- Lorem ipsum dolor sit amet, 
?             ^
+ Lorem ipsum color sit amet, 
?             ^
              consectetur adipisicing elit, 
+             that's the way the cookie crumbles,
              sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

----------------------------------------------------------------------
Ran 7 tests in 12.010s

FAILED (failures=1, skipped=1, expected failures=1)
}}}

A `failfast` option could be specified as a keyword argument to `unittest.main()`, or `unittest.main()` could read it off the command line, according to the same mechanism used by, e.g., the `verbosity` option.

----------
components: Library (Lib)
messages: 100493
nosy: jcd
severity: normal
status: open
title: Fail-fast behavior for unittest
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Mar  6 00:43:42 2010
From: report at bugs.python.org (Eugene Baranov)
Date: Fri, 05 Mar 2010 23:43:42 +0000
Subject: [New-bugs-announce] [issue8075] Windows (Vista/7) install error
	when choosing to compile	.py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>


New submission from Eugene Baranov <eug.baranov at gmail.com>:

I tried installing Python 2.6.4 into Program Files in Windows 7 and choose to compile .py files after install.

Installer correctly asks for a elevation and copies all fixes but it looks like compile batch are being started from initial, unelevated context. (It displays access denied messages)

The issues does not appear when starting installer from already elevated command prompt.

----------
components: Installation
messages: 100504
nosy: Regent
severity: normal
status: open
title: Windows (Vista/7) install error when choosing to compile .py files
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar  6 01:47:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Mar 2010 00:47:15 +0000
Subject: [New-bugs-announce] [issue8076] sys.setfilesystemencoding('foo')
	causes segmentation fault
In-Reply-To: <1267836435.93.0.217920799547.issue8076@psf.upfronthosting.co.za>
Message-ID: <1267836435.93.0.217920799547.issue8076@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

>>> import sys
>>> sys.setfilesystemencoding('foo')
>>> open('something')
Segmentation Fault

----------
components: Interpreter Core
messages: 100507
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: sys.setfilesystemencoding('foo') causes segmentation fault
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Mar  6 02:43:40 2010
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 06 Mar 2010 01:43:40 +0000
Subject: [New-bugs-announce] [issue8077] cgi handling of POSTed files is
	broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>


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

I am reluctant to post this because (a) I might have made some dumb mistake in my code, simple as it is, and (b) the problem might be well-known or even hopeless because the cgi module may not be WSGI compliant, but if this isn't going to be fixed then at least the problem should be described in the cgi module documentation.

I run an HTTPServer with a CGIHTTPRequestHandler.
I open an HTML file with a trivial form that simply POSTs an upload of a single file.
I browse, select a file, and click submit.
The web request never completes -- the browser just waits for a response.
Interrupting the server with ^C^C produces a backtrace that indicates it is stuck trying to decode the file contents.

The attached zip file contains:
    cgi-server.py
    cgi-post.html
    cgi-bin/cgi-test.py
    exception.txt
The latter is the backtrace output from when I interrupt the server.

This is on OS X 10.5 with either Python3.1 or Python3.2 from the repository.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
files: cgi-post-broken.zip
messages: 100509
nosy: MLModel, georg.brandl
severity: normal
status: open
title: cgi handling of POSTed files is broken
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16465/cgi-post-broken.zip

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

From report at bugs.python.org  Sat Mar  6 05:26:42 2010
From: report at bugs.python.org (Jon Smirl)
Date: Sat, 06 Mar 2010 04:26:42 +0000
Subject: [New-bugs-announce] [issue8078] add more baud constants to termios
In-Reply-To: <1267849602.5.0.0627386493701.issue8078@psf.upfronthosting.co.za>
Message-ID: <1267849602.5.0.0627386493701.issue8078@psf.upfronthosting.co.za>


New submission from Jon Smirl <jonsmirl at gmail.com>:

termios doesn't have the constants defined for higher baud rates on Linux.

According to my bits/termios.h:
#define  B57600   0010001
#define  B115200  0010002
#define  B230400  0010003
#define  B460800  0010004
#define  B500000  0010005
#define  B576000  0010006
#define  B921600  0010007
#define  B1000000 0010010
#define  B1152000 0010011
#define  B1500000 0010012
#define  B2000000 0010013
#define  B2500000 0010014
#define  B3000000 0010015
#define  B3500000 0010016
#define  B4000000 0010017

----------
messages: 100515
nosy: jonsmirl
severity: normal
status: open
title: add more baud constants to termios
type: feature request

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

From report at bugs.python.org  Sat Mar  6 07:40:30 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Sat, 06 Mar 2010 06:40:30 +0000
Subject: [New-bugs-announce] [issue8079] make install fails with -j8 with
	python2.6/config on	FreeBSD
In-Reply-To: <1267857630.87.0.870938560397.issue8079@psf.upfronthosting.co.za>
Message-ID: <1267857630.87.0.870938560397.issue8079@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

When attempting to install and deinstall lang/python26 to run some unit tests for a change I was going to provide to the maintainer, I ran into this issue:

install -o root -g wheel -m 444 ./../Include/ucnhash.h /usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/unicodeobject.h /usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/warnings.h /usr/local/include/python2.6
install -o root -g wheel -m 444 ./../Include/weakrefobject.h /usr/local/include/python2.6
install  -o root -g wheel -m 444 pyconfig.h /usr/local/include/python2.6/pyconfig.h
Creating directory /usr/local/lib/python2.6/config
install: /usr/local/lib/python2.6/config exists but is not a directory
*** Error code 71

Stop in /scratch/freebsd/ports/lang/python26/work/Python-2.6.4/portbld.static.
*** Error code 1

Stop in /scratch/freebsd/ports/lang/python26.
*** Error code 1

The problem was caused by an incomplete install into ${prefix} [which I will take up with the FreeBSD project], but manifests itself because the -j value I specified, was too high. I say this because of another comment placed in a top-level Makefile at a previous job about compiling Python 2.4.2 with this particular goal (installing the modules) and race conditions.

I would provide a patch but I'm not sure what the issue could stem from, other than a race conditions with a busted install-sh and incomplete dependencies specified in Makefile.pre.in.

I'll provide more info if needed.

Reproducible via the following on FreeBSD, given a fast enough machine:

cd lang/python26; make deinstall clean; make -j8 all; make -j8 install

[gcooper at bayonetta /scratch/freebsd/ports/lang/python26]$ uname -a
FreeBSD bayonetta.localdomain 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Thu Mar  4 13:16:39 PST 2010     gcooper at bayonetta.localdomain:/usr/obj/usr/src/sys/BAYONETTA  amd64
[gcooper at bayonetta /scratch/freebsd/ports/lang/python26]$ sysctl -a hw.model
hw.model: Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz

[From top(1)]

Mem: 43M Active, 10G Inact, 870M Wired, 76M Cache, 1237M Buf, 537M Free
Swap: 20G Total, 108K Used, 20G Free

----------
components: Build
messages: 100518
nosy: yaneurabeya
severity: normal
status: open
title: make install fails with -j8 with python2.6/config on FreeBSD
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Mar  6 16:08:30 2010
From: report at bugs.python.org (Stuart Axon)
Date: Sat, 06 Mar 2010 15:08:30 +0000
Subject: [New-bugs-announce] [issue8080] os.uname failing in windows
In-Reply-To: <1267888110.18.0.792415161987.issue8080@psf.upfronthosting.co.za>
Message-ID: <1267888110.18.0.792415161987.issue8080@psf.upfronthosting.co.za>


New submission from Stuart Axon <stu.axon at gmail.com>:

I'm not sure why this is happening, but os.uname() is failing on my computer in XP Home 32bit.  Tested in the normal shell and MSys

The code in platform.py looks like it should work to me.


[C:\usr\Python26\Lib]python
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.uname()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'uname'
>>>

----------
components: Library (Lib), Windows
messages: 100531
nosy: stuaxo
severity: normal
status: open
title: os.uname failing in windows
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar  6 23:26:16 2010
From: report at bugs.python.org (hamish farrant)
Date: Sat, 06 Mar 2010 22:26:16 +0000
Subject: [New-bugs-announce] [issue8081] a.append appends reference ,
	causing unexpected behaviour
In-Reply-To: <1267914376.13.0.68612661566.issue8081@psf.upfronthosting.co.za>
Message-ID: <1267914376.13.0.68612661566.issue8081@psf.upfronthosting.co.za>


New submission from hamish farrant <farrantino at gmail.com>:

Causes modification of an list object to change the values of the object already inside the list.

Example code :

import random
a  =[]
b = [1 , 2 , 3 , 4]
for i in range (15):
    random.shuffle(b)
    a.append(b)
for j in a:
    print j

Expected Behaviour : the list referenced by b , should be appended to a , creating a list of random permutations of b.

----------
components: Interpreter Core
messages: 100548
nosy: hamish.farrant
severity: normal
status: open
title: a.append appends reference , causing unexpected behaviour
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar  7 00:31:36 2010
From: report at bugs.python.org (Daniel Eloff)
Date: Sat, 06 Mar 2010 23:31:36 +0000
Subject: [New-bugs-announce] [issue8082] Misleading exception when raising
	an object
In-Reply-To: <1267918296.69.0.231519686618.issue8082@psf.upfronthosting.co.za>
Message-ID: <1267918296.69.0.231519686618.issue8082@psf.upfronthosting.co.za>


New submission from Daniel Eloff <dan.eloff at gmail.com>:

>>> class Foo(object):
...     pass
...     
>>> raise Foo()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: exceptions must be classes or instances, not Foo
>>> class Foo(Exception):
...     pass
...     
>>> raise Foo()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
Foo
>>> class Foo(BaseException):
...     pass
...     
>>> raise Foo()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
Foo

It seems exceptions can only be subclasses of BaseException, the error message is confusing and false.

----------
messages: 100551
nosy: Daniel.Eloff
severity: normal
status: open
title: Misleading exception when raising an object
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar  7 12:22:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 11:22:54 +0000
Subject: [New-bugs-announce] [issue8083] urllib proxy interface is too
	limited
In-Reply-To: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za>
Message-ID: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za>


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

The proxy support code in urllib is imho too specific and cannot easily support dynamic proxy configuration using a proxy.pac file.

That is, the code assumes that there is at most one proxy per protocol, while this is not quite true in practice.  A proxy.pac can refer different URLs to different proxies (or exclude some from proxying).

This could be solved by adding a new proxy hook to urllib, something like:

def getproxies_for_url(url) -> [info, ...]

That is, the argument is the string for an URL, the result is a list of proxies that can be used to fetch the URL.

This hook would allow us to provide a hook on OSX that enables python scripts to use the system proxy settings, even when those are complex (such as by using proxy autoconfiguration).

----------
components: Library (Lib)
messages: 100573
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: urllib proxy interface is too limited
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Mar  7 13:29:11 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Mar 2010 12:29:11 +0000
Subject: [New-bugs-announce] [issue8084] pep-0370 on osx duplicates existing
	functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>


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

The implementation of pep-0370 treats OSX like any other unix platform. 

This is problemantic for two reasons: first of all OSX already had a per-user directory before pep-0370 was implement: ~/Library/Python/X.Y, which means there are now two per-user directories on OSX. Secondly the pep-0370  per-user directory does not honor platform conventions.

I therefore propose to change pep-0370 behavior on OSX: 
* remove ~/.local as the user-base
* upgrade ~/Library/Python/X.Y to a pep-0370 compatible directory
  (that is: introduce the additional subdirectories that are used
   in pep-0370)
* upgrade /Library/Python/X.Y to the same structure

----------
assignee: ronaldoussoren
components: Installation, Library (Lib), Macintosh
keywords: needs review
messages: 100577
nosy: ronaldoussoren
severity: normal
status: open
title: pep-0370 on osx duplicates existing functionality
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Mar  7 14:29:51 2010
From: report at bugs.python.org (Florian Weimer)
Date: Sun, 07 Mar 2010 13:29:51 +0000
Subject: [New-bugs-announce] [issue8085] PyObject_GC_VarNew should be
	PyObject_GC_NewVar
In-Reply-To: <1267968591.92.0.119791187903.issue8085@psf.upfronthosting.co.za>
Message-ID: <1267968591.92.0.119791187903.issue8085@psf.upfronthosting.co.za>


New submission from Florian Weimer <fw at deneb.enyo.de>:

The manual mentions the wrong C function (Var and New are transposed).

----------
assignee: georg.brandl
components: Documentation
messages: 100580
nosy: fw, georg.brandl
severity: normal
status: open
title: PyObject_GC_VarNew should be PyObject_GC_NewVar
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sun Mar  7 18:56:30 2010
From: report at bugs.python.org (Chris)
Date: Sun, 07 Mar 2010 17:56:30 +0000
Subject: [New-bugs-announce] [issue8086] ssl.get_server_certificate new line
	missing
In-Reply-To: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>
Message-ID: <1267984590.29.0.627477441275.issue8086@psf.upfronthosting.co.za>


New submission from Chris <chris0wj at gmail.com>:

I'm using ssl.get_server_certificate function. It returns a pem string. For each server I try, I get the string, but it is missing a newline "\n" before the -----END CERTIFICATE----- text. Any subsequent use of the string makes openssl throw up with a "bad end line" error.

ssl.PEM_cert_to_DER_cert can be used, and, subsequently the der string can be used elsewhere.

Example:
>>> fncert = ssl.get_server_certificate(("freenode.net", 443), 3)
>>> fncert
'-----BEGIN CERTIFICATE-----\nMIICFTCCAX6gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMRswGQYDVQQKExJBcGFj\naGUgSFRUUCBTZXJ2ZXIxIjAgBgNVBAsTGUZvciB0ZXN0aW5nIHB1cnBvc2VzIG9u\nbHkxEjAQBgNVBAMTCWxvY2FsaG9zdDAeFw0wNzA1MDkxODM2MjVaFw0wODA1MDgx\nODM2MjVaMEwxGzAZBgNVBAoTEkFwYWNoZSBIVFRQIFNlcnZlcjEZMBcGA1UECxMQ\nVGVzdCBDZXJ0aWZpY2F0ZTESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3\nDQEBAQUAA4GNADCBiQKBgQDYqJO6X9uwU0AyJ6H1WgYCZOqpZvdI96/LaDumT4Tl\nD6QvmXzAbM4okSHU3FEuSqR/tNv+eT5IZJKHVsXh0CiDduIYkLdqkLhEAbixjX/1\nfdCtGL4X0l42LqhK4TMFT5AxxsP1qFDXDvzl/yjxo9juVuZhCeqFr1YDKBffCIAn\ncwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAG0zi/KyzHxSsLHfrwTFh9330TaGj/3H\nuvhmBUPC3FOxbIH2y5CG/Ddg46756cfaxKKiqJV3I4dAgatQybE65ELc3wOWgs4v\n4VDGsFKbkmBLuCgnFaY+p4xvr2XL+bJmpm8+IQqW5Ob/OUSl7Vj4btHhF6VK29CI\n+DexDLRI0KqZ-----END CERTIFICATE-----\n'

Notice no "\n" before -----END CERTIFICATE-----\n

Platform: 
Linux x64
python 2.6.4

----------
messages: 100595
nosy: offero
severity: normal
status: open
title: ssl.get_server_certificate new line missing
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar  7 20:40:09 2010
From: report at bugs.python.org (Diego Mascialino)
Date: Sun, 07 Mar 2010 19:40:09 +0000
Subject: [New-bugs-announce] [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>


New submission from Diego Mascialino <dmascialino at gmail.com>:

Example:

---------------- mod.py ----------------
def f():
    a,b,c = 1,2
    print b
----------------------------------------

If i do:

>>> import mod
>>> mod.f()

I get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mod.py", line 2, in f
    a,b,c = 1,2
ValueError: need more than 2 values to unpack


If i fix the source:

---------------- mod.py ----------------
def f():
    a,b,c = 1,2,3
    print b
----------------------------------------

And do:

>>> mod.f()

I get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mod.py", line 2, in f
    a,b,c = 1,2,3
ValueError: need more than 2 values to unpack

The problem is that the source shown is updated, but the executed code is old, because it wasn't reloaded.

Feature request:

If the source code shown was modified after import time and it wasn't reloaded, a warning message should be shown.

Example:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mod.py", line 2, in f      WARNING: Modified after import!
    a,b,c = 1,2,3
ValueError: need more than 2 values to unpack

or something like that. Maybe "use reload()" might appear.

----------
components: Interpreter Core
messages: 100600
nosy: dmascialino, jjconti
severity: normal
status: open
title: Unupdated source file in traceback
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  8 17:36:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Mar 2010 16:36:41 +0000
Subject: [New-bugs-announce] [issue8088] assertSameElements fails with
	sequences that contain	unorderable types
In-Reply-To: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>
Message-ID: <1268066201.72.0.876952664172.issue8088@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

assertSameElements fails with sequences that contain unorderable types such as [2j, 5j, set(), frozenset()].

See also msg98744 in #7837.

----------
assignee: flox
messages: 100654
nosy: ezio.melotti, flox, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: assertSameElements fails with sequences that contain unorderable types
type: behavior

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

From report at bugs.python.org  Mon Mar  8 21:20:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 08 Mar 2010 20:20:44 +0000
Subject: [New-bugs-announce] [issue8089] 2.6/3.1 32-bit/64-bit universal
	builds always run in	64-bit on 10.6
In-Reply-To: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>
Message-ID: <1268079644.6.0.644038820262.issue8089@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

2.6.5 release blocker
3.1.2 release blocker

For 10.6, new universal build options were added to reflect the dropping of support in 10.6 for the ppc64 arch.  The new options:

  --universal-archs=3-way -> -arch {i386,x86_64,ppc)
  --universal-archs=intel -> -arch {i386,x86_64}

however do not add the executables and symlinks to select a "-32" or
"-64" variant like the existing "--universal-archs=all" does and so
these new build variants always run in 64-bit with no way to override
it. A simple test in configure.in needs to be changed to recognize
these new options.

Trunk (2.7) and py3k (3.2) use a new execution-time mechanism to select 32- vs 64-bit execution and so do not exhibit this problem.

(Ronald and I agree this should be a release-blocker. Patch to follow.)

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100663
nosy: barry, benjamin.peterson, ned.deily, ronaldoussoren
severity: normal
status: open
title: 2.6/3.1 32-bit/64-bit universal builds always run in 64-bit on 10.6
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Mon Mar  8 22:51:36 2010
From: report at bugs.python.org (Sjoerd Mullender)
Date: Mon, 08 Mar 2010 21:51:36 +0000
Subject: [New-bugs-announce] [issue8090] PEP 4 should say something about
	the standard library
In-Reply-To: <1268085096.1.0.884411338226.issue8090@psf.upfronthosting.co.za>
Message-ID: <1268085096.1.0.884411338226.issue8090@psf.upfronthosting.co.za>


New submission from Sjoerd Mullender <sjoerd at acm.org>:

When a module or feature is deprecated, all uses of the deprecated module/feature should be removed from the non-deprecated part of the distribution (and, I would argue, also from the other deprecated modules).
I think PEP 4 should say something to this effect.

I suggest adding a sentence to the section "Procedure for declaring a module deprecated", something like:  "The proposal MUST include patches to remove any use of the deprecated module from the standard library."

----------
assignee: georg.brandl
components: Documentation
messages: 100671
nosy: georg.brandl, sjoerd
severity: normal
status: open
title: PEP 4 should say something about the standard library

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

From report at bugs.python.org  Mon Mar  8 23:08:16 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Mar 2010 22:08:16 +0000
Subject: [New-bugs-announce] [issue8091] TypeError at the end of 'make test'
In-Reply-To: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>
Message-ID: <1268086096.01.0.605996854785.issue8091@psf.upfronthosting.co.za>


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

'make test' on Ubuntu 10.04 alpha produces:

328 tests OK.
1 test failed:
    test_readline
37 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gl test_imageop test_imgfile test_kqueue
    test_linuxaudiodev test_macos test_macostools test_normalization
    test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages
    test_smtpnet test_socketserver test_startfile test_sunaudiodev
    test_timeout test_urllib2net test_urllibnet test_winreg
    test_winsound test_zipfile64
1 skip unexpected on linux2:
    test_bsddb
Exception TypeError: TypeError("'NoneType' object is not callable",) in <bound method Popen.__del__ of <subprocess.Popen object at 0x5d63650>> ignored
make: *** [test] Error 1

The readline failure is reported elsewhere.  It's the TypeError at the end that's the problem here.  I think this does not happen on Ubuntu 9.10.

----------
messages: 100674
nosy: barry
priority: release blocker
severity: normal
status: open
title: TypeError at the end of 'make test'
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar  9 00:21:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Mar 2010 23:21:07 +0000
Subject: [New-bugs-announce] [issue8092] utf8,
	backslashreplace and surrogates
In-Reply-To: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>
Message-ID: <1268090467.51.0.427647969669.issue8092@psf.upfronthosting.co.za>


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

utf8 encoder doesn't work in backslashreplace error handler:

>>> "\uDC80".encode("utf8", "backslashreplace")
TypeError: error handler should have returned bytes

----------
components: Unicode
messages: 100678
nosy: haypo
severity: normal
status: open
title: utf8, backslashreplace and surrogates
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar  9 00:21:31 2010
From: report at bugs.python.org (paul stadfeld)
Date: Mon, 08 Mar 2010 23:21:31 +0000
Subject: [New-bugs-announce] [issue8093] IDLE processes don't close
In-Reply-To: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>
Message-ID: <1268090491.77.0.977887093309.issue8093@psf.upfronthosting.co.za>


New submission from paul stadfeld <mensanator at aol.com>:

So I started 3.1.2...

Python 3.1.2rc1 (r312rc1:78742, Mar  7 2010, 07:49:40) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> 

And monitored Windows Task Manager (XP):

Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld   00    11,120 K
pythonw.exe   paul_stadfeld   00    16,816 K

I assume this is normal.

I deliberately do something stupid:

>>> a = 222222222222222222222222222
>>> b = 5555555555555555555555555555 
>>> a**b

Ok, that will run for a while, long enough for me to watch the Task Manager:

Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld  ~55   ~30,548 K (constantly changing)
pythonw.exe   paul_stadfeld   00    16,828 K

So I do [Restart Shell] from IDLE's [Shell] menu:

>>> ================================ RESTART ================================

And try it again.

>>> a = 222222222222222222222222222
>>> b = 5555555555555555555555555555 
>>> a**b

But now it's different:

Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld   00    13,716
pythonw.exe   paul_stadfeld  ~50   ~30,548 K (constantly changing)
pythonw.exe   paul_stadfeld  ~48   ~45,548 K (constantly changing)
pythonw.exe   paul_stadfeld   00    16,892 K

Looks like the previous process was never stopped.

Trying to Restart Shell again and running same creates a 5th instance
of pythonw.exe.

>>> ================================ RESTART ================================
>>> a = 222222222222222222222222222
>>> b = 5555555555555555555555555555 
>>> a**b


Image Name    User Name       CPU   Mem Usage
---------------------------------------------
pythonw.exe   paul_stadfeld   00    13,716
pythonw.exe   paul_stadfeld  ~50   ~54,548 K (constantly changing)
pythonw.exe   paul_stadfeld  ~25   ~42,548 K (constantly changing)
pythonw.exe   paul_stadfeld  ~25   ~54,548 K (constantly changing)
pythonw.exe   paul_stadfeld   00    16,892 K


Only this time I got an error trying to re-start.

    IDLE's subprocess didn't make connection. Either IDLE can't start a 
    subprocess or personal firewall software is blocking the connection

Now I'm stuck, so I close the "Python Shell" window.

But closing the window only stopped one of the pythonw.exe instances.
The three active processes are still running full tilt (the one quiescent
process remains quiescent.)

This appears to be a process leak in addition to it being a memory leak.

Also, had one of the processes that won't stop opened a script from a USB
port, then Windows would refuse to eject the USB drive as it correctly 
thinks some process is still using it. Of course, since the application 
is closed, there's not suppoed to be any such process, so it's
not obvious where the problem is unless you look at the process table
in Windows Task Manager and manually halt all the renegade pythonw.exe
processes that are still running. At which point Windows will allow the 
USB to be ejected.

----------
components: IDLE
messages: 100679
nosy: mensanator
severity: normal
status: open
title: IDLE processes don't close
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar  9 10:01:54 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Tue, 09 Mar 2010 09:01:54 +0000
Subject: [New-bugs-announce] [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

Hi,

The following code results in an infinite loop -->

# ----
import multiprocessing

def f(m):
	print(m)

p = multiprocessing.Process(target=f, args=('pouet',))
p.start()
# ----

I've firstly think about an issue in my code when Python loads this module so I've added a "if __name__ == '__main__':" and it works well. But, with the following code Python enters in the same infinite loop -->

proc.py:

# ----
import multiprocessing

def f(m):
	print(m)

class P:
	def __init__(self, msg):
		self.msg = msg
	
	def start(self):
		p = multiprocessing.Process(target=f, args=(self.msg,))
		p.start()
# ----

my_script.py:
# ----
from proc import P

p = P("pouet")
p.start()
# ----

It's like Python loads all parent's process memory space before starting process which issues in an infinite call to Process.start() ...

----------
components: Library (Lib)
messages: 100707
nosy: Kain94
severity: normal
status: open
title: Multiprocessing infinite loop
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar  9 10:53:40 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 09:53:40 +0000
Subject: [New-bugs-announce] [issue8095] test_urllib2 crashes on OS X 10.3
	attempting to retrieve	network proxy configuration
In-Reply-To: <1268128420.33.0.487140127067.issue8095@psf.upfronthosting.co.za>
Message-ID: <1268128420.33.0.487140127067.issue8095@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

The current mechanism for urllib and urllib2 on OS X to retrieve network proxy information is to call _scproxy.c to query the OS X SystemConfiguration Framework.  _scproxy.c uses a schema key, kSCPropNetProxiesExcludeSimpleHostnames, that was introduced in OS X 10.4.  Building on 10.3 results in a compile error.  Current python.org OS X installers are built using the 10.4u SDK with a deployment target of 10.3 to allow running on OS X 10.3.9.  When such pythons are installed on 10.3, attempts to use proxy support, such as is tested in test_urllib2, result in a crash:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   _scproxy.so       	0x000a77ac get_proxy_settings + 0x6c

Whether this is worth fixing is debatable, considering that 10.3 has not been supported by Apple for many years and that the use of network proxy  servers has likely been declining.  At a minimum, it would be better for it to fail without a crash but perhaps a README item would suffice.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100708
nosy: ned.deily, orsenthil, ronaldoussoren
severity: normal
status: open
title: test_urllib2 crashes on OS X 10.3 attempting to retrieve network proxy configuration
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Mar  9 11:04:54 2010
From: report at bugs.python.org (Marcel Tschopp)
Date: Tue, 09 Mar 2010 10:04:54 +0000
Subject: [New-bugs-announce] [issue8096] locale.format_string fails on
	mapping keys
In-Reply-To: <1268129094.64.0.519298864609.issue8096@psf.upfronthosting.co.za>
Message-ID: <1268129094.64.0.519298864609.issue8096@psf.upfronthosting.co.za>


New submission from Marcel Tschopp <mts at polynorm.ch>:

locale.format_string doesn't return same result as a normal "string" % format directive, but raises a TypeError.

>>> locale.format_string('%(key)s', {'key': 'Test'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/locale.py", line 225, in format_string
    val[key] = format(perc.group(), val[key], grouping)
  File "/usr/local/lib/python2.6/locale.py", line 182, in format
    formatted = percent % value
TypeError: format requires a mapping

----------
components: Library (Lib)
messages: 100709
nosy: mtschopp
severity: normal
status: open
title: locale.format_string fails on mapping keys
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar  9 11:27:39 2010
From: report at bugs.python.org (Andreas Pfeiffer)
Date: Tue, 09 Mar 2010 10:27:39 +0000
Subject: [New-bugs-announce] [issue8097] bug in modulefinder: import_hook()
	got an unexpected	keyword argument 'level'
In-Reply-To: <1268130459.3.0.847669819977.issue8097@psf.upfronthosting.co.za>
Message-ID: <1268130459.3.0.847669819977.issue8097@psf.upfronthosting.co.za>


New submission from Andreas Pfeiffer <andreas.pfeiffer at cern.ch>:

Hi,

  the attached file (moduleFinderBug.py) crashes in python 2.6 on
linux (RedHat EL 5) and Mac OS X (10.6) with the traceback below.

A possible fix for this would be in modulefinder.py:
323c323
<             self.import_hook(name, caller, level=level)
---
>             self.import_hook(name, caller=caller, level=level)

Please let me know if you need any further information.

Thanks,
   cheers, andreas



$> python moduleFinderBug.py
Traceback (most recent call last):
  File "work/cms/moduleFinderBug.py", line 17, in <module>
    modulefinder.run_script(filename)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 114, in run_script
    self.load_module('__main__', fp, pathname, stuff)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 305, in load_module
    self.scan_code(co, m)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 414, in scan_code
    self._safe_import_hook(name, m, fromlist, level=level)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/modulefinder.py", line 323, in _safe_import_hook
    self.import_hook(name, caller, level=level)
TypeError: import_hook() got an unexpected keyword argument 'level'

----------
components: Extension Modules
files: moduleFinderBug.py
messages: 100711
nosy: andreas
severity: normal
status: open
title: bug in modulefinder: import_hook() got an unexpected keyword argument 'level'
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file16509/moduleFinderBug.py

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

From report at bugs.python.org  Tue Mar  9 11:47:25 2010
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 09 Mar 2010 10:47:25 +0000
Subject: [New-bugs-announce] [issue8098] PyImport_ImportModuleNoBlock() may
	solve problems but	causes others.
In-Reply-To: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>
Message-ID: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

Back in time, the function PyImport_ImportModuleNoBlock() was introduced and used in modules such as the time module to supposedly avoid deadlocks when using threads. It may well have solved that problem, but only served to cause other problems.

To illustrate the problem consider the test code:


import imp
import thread
import time

def run1():
   print 'acquire'
   imp.acquire_lock()
   time.sleep(5)
   imp.release_lock()
   print 'release'

thread.start_new_thread(run1, ())

time.sleep(2)

print 'strptime'
time.strptime("", "")
print 'exit'


The output of running this is


grumpy:~ grahamd$ python noblock.py 
acquire
strptime
Traceback (most recent call last):
  File "noblock.py", line 17, in <module>
    time.strptime("", "")
ImportError: Failed to import _strptime because the import lockis held by another thread.


It is bit silly that code executing in one thread could fail because at the time that it tries to call time.strptime() a different thread has the global import lock.

This problem may not arise in applications which preload all modules, but it will where importing of modules is deferred until later within execution of a thread and where there may be concurrent threads running doing work that requires modules imported by that new C function.

Based on old discussion at:

http://groups.google.com/group/comp.lang.python/browse_frm/thread/dad73ac47b81a744

my expectation is that this issue will be rejected as not being a problem with any remedy being pushed to the application developer. Personally I don't agree with that and believe that the real solution is to come up with an alternate fix for the original deadlock that doesn't introduce this new detrimental behaviour. This may entail structural changes to modules such as the time module to avoid issue.

Unfortunately since the PyImport_ImportModuleNoBlock() function has been introduced, it is starting to be sprinkled like fairy dust across modules in the standard library and in third party modules. This is only going to set up future problems in multithreaded applications, especially where third party module developers don't appreciate what problems they are potentially introducing by using this function.

Anyway, not optimistic from what I have seen that this will be changed, so view this as a protest against this behaviour. :-)

FWIW, issue in mod_wsgi issue tracker about this is:

http://code.google.com/p/modwsgi/issues/detail?id=177

I have known about this issue since early last year though.

----------
components: Interpreter Core
messages: 100713
nosy: grahamd
severity: normal
status: open
title: PyImport_ImportModuleNoBlock() may solve problems but causes others.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Mar  9 17:10:36 2010
From: report at bugs.python.org (Estroms)
Date: Tue, 09 Mar 2010 16:10:36 +0000
Subject: [New-bugs-announce] [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>


New submission from Estroms <tuomas.engstrom at gmail.com>:

I downloaded Python 3.1 yesterday. I can open the Python command line, but when i press IDLE(Python GUI)shortcut no window or program opens.

i typed to command promt C:\Python31\lib\idlelib\idle.py and got an error message. It's too long to write to here, but in the end of it, it said that "This probably means that Tcl wasn't installed properly". What should I do?

----------
components: IDLE
messages: 100734
nosy: Estroms
severity: normal
status: open
title: IDLE(Python GUI) Doesn't open
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar  9 18:59:40 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 09 Mar 2010 17:59:40 +0000
Subject: [New-bugs-announce] [issue8100] `configure` incorrectly handles
	empty OPT variable
In-Reply-To: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>
Message-ID: <1268157580.83.0.209888621209.issue8100@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

The comment in configure.in says that some changes aren't applied to OPT variable when OPT variable has been set by the user, but they are applied when empty OPT has been explicitly set. The attached patch fixes this problem.

----------
components: Build
files: python-OPT.patch
keywords: patch
messages: 100736
nosy: Arfrever
severity: normal
status: open
title: `configure` incorrectly handles empty OPT variable
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16511/python-OPT.patch

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

From report at bugs.python.org  Tue Mar  9 20:37:11 2010
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 09 Mar 2010 19:37:11 +0000
Subject: [New-bugs-announce] [issue8101] w32-shared-ptr.c assertion on
	Windows 7 with 2.6.4
In-Reply-To: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>
Message-ID: <1268163431.89.0.605397654881.issue8101@psf.upfronthosting.co.za>


New submission from Ned Batchelder <nedbat at users.sourceforge.net>:

2.6.4 had been working fine for me.  Today, though, it will not stay up.  I run the Django development server on Windows 7, and 2.6.4 is repeatedly crashing on me:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Validating models...
Assertion failed: w32_sharedptr->size == sizeof(W32_EH_SHARED), file ../../gcc-3.4.5/gcc/config/i386/w32-shared-ptr.c, line 247

I have no idea what's changed between yesterday and today.

----------
components: None
messages: 100739
nosy: nedbat
severity: normal
status: open
title: w32-shared-ptr.c assertion on Windows 7 with 2.6.4
type: crash
versions: Python 2.6

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

From martin at v.loewis.de  Tue Mar  9 21:22:11 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 09 Mar 2010 21:22:11 +0100
Subject: [New-bugs-announce] [issue8099] IDLE(Python GUI) Doesn't open
In-Reply-To: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
References: <1268151036.98.0.14000256331.issue8099@psf.upfronthosting.co.za>
Message-ID: <4B96ADF3.4020808@v.loewis.de>

> What should I do?

Unset the the TCL_LIBRARY and TK_LIBRARY environment variables, and
report whether it helped.

From report at bugs.python.org  Tue Mar  9 21:26:34 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Mar 2010 20:26:34 +0000
Subject: [New-bugs-announce] [issue8102] test_distutils fails on 2.6.5rc1:
	"No module named	setuptools_build_ext"
In-Reply-To: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>
Message-ID: <1268166394.12.0.878303622913.issue8102@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Current 2.6.5rc1+ building on OS X:

======================================================================
ERROR: test_setuptools_compat (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/test_build_ext.py", line 350, in test_setuptools_compat
    from setuptools_build_ext import build_ext as setuptools_build_ext
ImportError: No module named setuptools_build_ext

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

----------
assignee: tarek
components: Distutils
messages: 100743
nosy: barry, ned.deily, tarek
severity: normal
status: open
title: test_distutils fails on 2.6.5rc1: "No module named setuptools_build_ext"
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar  9 21:43:00 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Tue, 09 Mar 2010 20:43:00 +0000
Subject: [New-bugs-announce] [issue8103] threading.start() : unable to
	restart thread
In-Reply-To: <1268167380.27.0.436221808692.issue8103@psf.upfronthosting.co.za>
Message-ID: <1268167380.27.0.436221808692.issue8103@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

Hi,

I've found a bug in threading module. "self._started" event is never cleared when thread terminates. So, at line 452, in start() function, the test "if self._started.is_set():" prevents any restart.

PS: I saw this bug in Python 3.1.1 32 bit on a Windows 7 platform.

----------
components: Library (Lib)
messages: 100749
nosy: Kain94
severity: normal
status: open
title: threading.start() : unable to restart thread
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Mar 10 01:30:00 2010
From: report at bugs.python.org (Matt Gattis)
Date: Wed, 10 Mar 2010 00:30:00 +0000
Subject: [New-bugs-announce] [issue8104] socket.recv_into doesn't support a
	memoryview as an	argument
In-Reply-To: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>
Message-ID: <1268181000.19.0.928948348228.issue8104@psf.upfronthosting.co.za>


New submission from Matt Gattis <gattis at gmail.com>:

>>> view = memoryview(bytearray(bufsize))
>>> while len(view):
...    view = view[sock.recv_into(view,1024):]
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: recv_into() argument 1 must be pinned buffer, not memoryview

----------
components: IO
messages: 100773
nosy: Matt.Gattis
severity: normal
status: open
title: socket.recv_into doesn't support a memoryview as an argument
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 10 01:42:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Mar 2010 00:42:25 +0000
Subject: [New-bugs-announce] [issue8105] mmap crash on Windows with out of
	range file descriptor
In-Reply-To: <1268181745.97.0.225501329213.issue8105@psf.upfronthosting.co.za>
Message-ID: <1268181745.97.0.225501329213.issue8105@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Creating an mmap object can crash the interpreter on Windows if a file descriptor is passed in which is outside of the range for _get_osfhandle. I noticed the crash possibility while reviewing the Modules/mmapmodule.c code for work on another issue related to the consistency of the exceptions which mmap raises.

This can be tested by creating a mmap object with the file descriptor for a socket. This is not a valid way to create an mmap, but it represents a valid file descriptor which is out of range. For example, I created a socket with a file descriptor of 124, and _get_osfhandle expects the descriptor to be between 0 and 23.

Patch against trunk, with a test.

Note that this does not seem to affect 2.6 (not sure why, yet).

----------
components: Library (Lib), Windows
files: mmap_crash.diff
keywords: patch
messages: 100774
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: mmap crash on Windows with out of range file descriptor
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16515/mmap_crash.diff

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

From report at bugs.python.org  Wed Mar 10 02:20:52 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 10 Mar 2010 01:20:52 +0000
Subject: [New-bugs-announce] [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Current SSL module doesn't manage SSL sessions, so any connection must do the full SSL handshake.

SSL/TLS support session restarting, when an old SSL context is used in a new connection, so you don't need to do the full SSL handshake.

This is a huge performance improvement.

I think SSL module should keep a small pool of sessions in core, to reuse. Better yet:

a) In SSL sockets, a method should be added to get the SSL context.

b) When creating a SSL socket, in client mode, a new optional parameter should be accepted, for a SSL context.

c) When creating a SSL socket, in server mode, we have two options: a) provide a dictionary or similar, with different contexts for possible clients connections or, better b) provide a callback the SSL module will call when getting an incoming connection, with a session ID as a parameter. The callback can provide a session SSL state or "None". This second approach allow for session management, like expiration or persistence to disk.

(the second option is equivalent to the first if the dict-like object includes this logic inside)

What do you think?.

----------
components: Extension Modules
messages: 100777
nosy: jcea
severity: normal
status: open
title: SSL session management
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Mar 10 09:20:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 10 Mar 2010 08:20:20 +0000
Subject: [New-bugs-announce] [issue8107] test_distutils fails on Windows in
	2.6.5rc2
In-Reply-To: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>
Message-ID: <1268209220.96.0.437139733461.issue8107@psf.upfronthosting.co.za>


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

test_distutils fails like this:

test test_distutils crashed -- <type 'exceptions.TypeError'>: object of type 'NoneType' has no len()
Traceback (most recent call last):
  File "Lib\test\regrtest.py", line 560, in runtest_inner
    indirect_test()
  File "c:\Python26\lib\test\test_distutils.py", line 13, in test_main
    test.test_support.run_unittest(distutils.tests.test_suite())
  File "c:\Python26\lib\distutils\tests\__init__.py", line 30, in test_suite
    suite.addTest(module.test_suite())
  File "c:\Python26\lib\distutils\tests\test_build_ext.py", line 391, in test_suite
    src = _get_source_filename()
  File "c:\Python26\lib\distutils\tests\test_build_ext.py", line 22, in _get_sou
rce_filename
    return os.path.join(srcdir, 'Modules', 'xxmodule.c')
  File "c:\Python26\lib\ntpath.py", line 96, in join
    assert len(path) > 0
TypeError: object of type 'NoneType' has no len()

Not sure whether this is a regression from 2.6.4.

----------
assignee: tarek
components: Distutils
messages: 100779
nosy: barry, loewis, tarek
severity: normal
status: open
title: test_distutils fails on Windows in 2.6.5rc2
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 10 14:44:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 10 Mar 2010 13:44:39 +0000
Subject: [New-bugs-announce] [issue8108] test_ftplib fails with OpenSSL
	0.9.8m
In-Reply-To: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>
Message-ID: <1268228679.44.0.26304365082.issue8108@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

There's such failure on trunk and py3k when openssl 0.9.8m is installed.
(Debian platform)
No failure with 0.9.8k.

test_ftplib
Exception in thread Thread-40:
Traceback (most recent call last):
  File "./Lib/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "./Lib/test/test_ftplib.py", line 223, in run
    asyncore.loop(timeout=0.1, count=1)
  File "./Lib/asyncore.py", line 211, in loop
    poll_fun(timeout, map)
  File "./Lib/asyncore.py", line 154, in poll
    write(obj)
  File "./Lib/asyncore.py", line 88, in write
    obj.handle_error()
  File "./Lib/asyncore.py", line 84, in write
    obj.handle_write_event()
  File "./Lib/test/test_ftplib.py", line 290, in handle_write_event
    super(SSLConnection, self).handle_write_event()
  File "./Lib/asyncore.py", line 440, in handle_write_event
    self.handle_write()
  File "./Lib/asynchat.py", line 174, in handle_write
    self.initiate_send()
  File "./Lib/asynchat.py", line 215, in initiate_send
    self.handle_close()
  File "./Lib/test/test_ftplib.py", line 43, in handle_close
    self.close()
  File "./Lib/test/test_ftplib.py", line 316, in close
    self.socket.unwrap()
  File "./Lib/ssl.py", line 272, in unwrap
    s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1367: The operation did not complete (read)

----------
components: Extension Modules
messages: 100782
nosy: flox
priority: high
severity: normal
stage: test needed
status: open
title: test_ftplib fails with OpenSSL 0.9.8m
type: crash
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Mar 10 16:14:07 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 10 Mar 2010 15:14:07 +0000
Subject: [New-bugs-announce] [issue8109] Support for TLS Server Name
	Indication extension
In-Reply-To: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za>
Message-ID: <1268234047.5.0.702223567094.issue8109@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

SSL sockets should support SNI, both as servers and clients: http://en.wikipedia.org/wiki/Server_Name_Indication

After that, libraries that support SSL/TLS should be upgraded to take advantage of it.

Any interest in supporting this?.

----------
components: Extension Modules
messages: 100787
nosy: jcea
priority: normal
severity: normal
status: open
title: Support for TLS Server Name Indication extension
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Mar 10 16:57:13 2010
From: report at bugs.python.org (Dave Fugate)
Date: Wed, 10 Mar 2010 15:57:13 +0000
Subject: [New-bugs-announce] [issue8110] subprocess.py doesn't correctly
	detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>


New submission from Dave Fugate <dfugate at microsoft.com>:

subprocess.py contains the following line (380 in CPython 2.6.3):
    mswindows = (sys.platform == "win32")

which only correctly detects CPython on Windows.  This line should be changed to:
    mswindows = (sys.platform == "win32" or sys.platform == "cli" or sys.platform == "silverlight")

so subprocess can be utilized from IronPython as well.

This bug should be trivial to fix.

----------
components: Library (Lib)
messages: 100788
nosy: midnightdf
severity: normal
status: open
title: subprocess.py doesn't correctly detect Windows machines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Mar 10 17:31:49 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 10 Mar 2010 16:31:49 +0000
Subject: [New-bugs-announce] [issue8111] docs.python.org/download.html
	unhelpful.
In-Reply-To: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>
Message-ID: <1268238709.78.0.814085341989.issue8111@psf.upfronthosting.co.za>


New submission from Thomas Wouters <thomas at python.org>:

docs.python.org is showing the docs for 2.6.5c2. As its most obvious bad consequence, docs.python.org/download.html doesn't offer any actual downloads, and there are no obvious (to newbies looking to download docs) links to working downloads.

----------
assignee: georg.brandl
components: Documentation
messages: 100797
nosy: georg.brandl, twouters
severity: normal
status: open
title: docs.python.org/download.html unhelpful.

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

From report at bugs.python.org  Wed Mar 10 18:37:52 2010
From: report at bugs.python.org (tormen)
Date: Wed, 10 Mar 2010 17:37:52 +0000
Subject: [New-bugs-announce] [issue8112] xmlrpc.server:
	ServerHTMLDoc.docroutine uses (since 3.0)	depricated function
	"inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>


New submission from tormen <tormen at gmx.net>:

This throws an exception and crashes your DocXMLRPCServer when using registered python functions that use function annotations.

Seems inconsistent to me.
Or is there a reason for this?

----------
messages: 100800
nosy: tormen
severity: normal
status: open
title: xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) depricated function "inspect.getargspec()"
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Wed Mar 10 23:30:29 2010
From: report at bugs.python.org (Lorenz Quack)
Date: Wed, 10 Mar 2010 22:30:29 +0000
Subject: [New-bugs-announce] [issue8113] PyUnicode_AsUnicode doesn't check
	for NULL pointer
In-Reply-To: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>
Message-ID: <1268260229.51.0.443920217604.issue8113@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

The C-API function "PyUnicode_AsUnicode(PyObject *unicode)" does not check the argument for NULL pointers. 
It passes it directly to the macro "PyUnicode_Check(op)" which then crashes when trying to access "Py_TYPE(op)".

I marked this as Python 2.7 because I checked this on trunk but I assume that this bug is present in all versions.

The attached patch fixes this issue.

----------
files: PyUnicode_AsUnicode.patch
keywords: patch
messages: 100809
nosy: donlorenzo
severity: normal
status: open
title: PyUnicode_AsUnicode doesn't check for NULL pointer
versions: Python 2.7
Added file: http://bugs.python.org/file16520/PyUnicode_AsUnicode.patch

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

From report at bugs.python.org  Thu Mar 11 00:08:06 2010
From: report at bugs.python.org (Vivek Anand)
Date: Wed, 10 Mar 2010 23:08:06 +0000
Subject: [New-bugs-announce] [issue8114] python 2.6.4 installation is not
	working for the single	user mode in vista.
Message-ID: <1268262486.45.0.509985990928.issue8114@psf.upfronthosting.co.za>


Changes by Vivek Anand <anand.vivek13 at gmail.com>:


----------
components: Windows
nosy: insidevivek
severity: normal
status: open
title: python 2.6.4 installation is not working for the single user mode in vista.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 11 02:07:42 2010
From: report at bugs.python.org (Riccardo Rotondo)
Date: Thu, 11 Mar 2010 01:07:42 +0000
Subject: [New-bugs-announce] [issue8115] Pyojbc on Snow Leopard
In-Reply-To: <1268269662.95.0.833333019817.issue8115@psf.upfronthosting.co.za>
Message-ID: <1268269662.95.0.833333019817.issue8115@psf.upfronthosting.co.za>


New submission from Riccardo Rotondo <riccardo.rotondo at ct.infn.it>:

Hello, I'm having trouble with pyobj since I have installed Python 2.6.4 by official dmg download here. 
Befor I used python pre-installed in Snow Leopard and everything worked ok. Now I can't import pyobjc.
I tried to perform easy_install pyobjc but I can't still import objc. 
The strangest thing is that it works for previos version!
Here some log:
rmacbpro:~ riccardorotondo$ python
Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) 
http://GCC 4.0.1 (Apple Inc. build 5493) on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Foundation
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named Foundation
>>> exit()
rrmacbpro:~ riccardorotondo$ python2.5
Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24) 
http://GCC 4.2.1 (Apple Inc. build 5646) on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Foundation
>>> exit()

Thanks for help
Bye

Riccardo

----------
assignee: ronaldoussoren
components: Macintosh
messages: 100823
nosy: RiccardoR, ronaldoussoren
severity: normal
status: open
title: Pyojbc on Snow Leopard
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 11 11:36:10 2010
From: report at bugs.python.org (=?utf-8?q?Ale=C5=A1_Drinovec?=)
Date: Thu, 11 Mar 2010 10:36:10 +0000
Subject: [New-bugs-announce] [issue8116] Addition problem
In-Reply-To: <1268303770.93.0.756891541973.issue8116@psf.upfronthosting.co.za>
Message-ID: <1268303770.93.0.756891541973.issue8116@psf.upfronthosting.co.za>


New submission from Ale? Drinovec <ales.drinovec at gmail.com>:

*** Python 3.1.2rc1 (r312rc1:78742, Mar  7 2010, 07:49:40) [MSC v.1500 32 bit (Intel)] on win32. ***
>>> 5.1+3.8
8.899999999999999
>>> 4.1+4.8
8.899999999999999
>>> 

Tested in IDLE and in PyScripter

----------
components: Interpreter Core
messages: 100842
nosy: sailoral
severity: normal
status: open
title: Addition problem
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Mar 11 13:34:04 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Thu, 11 Mar 2010 12:34:04 +0000
Subject: [New-bugs-announce] [issue8117] TimedRotatingFileHandler doesn't
	rotate log file at	startup.
In-Reply-To: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>
Message-ID: <1268310844.09.0.779235952938.issue8117@psf.upfronthosting.co.za>


New submission from Yuriy Taraday <yorik.sar at gmail.com>:

Screnario:
 - start logging, log something;
 - stop logging (stop application, for example);
 - start logging again after rotate interval passes.

log4j's RotatingFileAppender's behavior:
After restart, logfile is rotated if nessesary.

TimedRotatingFileHandler's behavior:
After restart do no checks on existing logs.

I thing, log4j's behavior is more intuitive. Patch adds necessary check to constructor.

----------
components: Library (Lib)
files: python-logging.diff
keywords: patch
messages: 100845
nosy: yorik.sar
severity: normal
status: open
title: TimedRotatingFileHandler doesn't rotate log file at startup.
type: behavior
Added file: http://bugs.python.org/file16524/python-logging.diff

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

From report at bugs.python.org  Thu Mar 11 16:38:24 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Mar 2010 15:38:24 +0000
Subject: [New-bugs-announce] [issue8118] PYTHON_API_VERSION needs to be
	bumped?
In-Reply-To: <1268321904.88.0.141264356939.issue8118@psf.upfronthosting.co.za>
Message-ID: <1268321904.88.0.141264356939.issue8118@psf.upfronthosting.co.za>


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

If I understand the code correct Python 2.6 has the same value for PYTHON_API_VERSION, even though extensions are not compatible.

In particular: when you compile an extension that uses PyInt_Check with python2.6 and load that extension with python 2.5 you will not get a version warning from Py_InitModule4 and you will also not get the right answers from PyInt_Check.

This due to PyType_FastSubclass (in python 2.6) which tests flags in the type structure that are not initiazed in 2.5.  That is a change in the ABI and hence should be accompanied by increasing PYTHON_API_VERSION.

 
This is technically a bug in 2.6, but I'm not selecting that version in the list because increasing PYTHON_API_VERSION in 2.6.x would break existing installations when they upgrade.

----------
components: Extension Modules, Interpreter Core
messages: 100867
nosy: ronaldoussoren
priority: high
severity: normal
status: open
title: PYTHON_API_VERSION needs to be bumped?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 11 16:53:41 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Mar 2010 15:53:41 +0000
Subject: [New-bugs-announce] [issue8119] Minor comment error in configure.in
	("malloc support"	appears twice)
In-Reply-To: <1268322821.23.0.828766306245.issue8119@psf.upfronthosting.co.za>
Message-ID: <1268322821.23.0.828766306245.issue8119@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

A minor nit: configure.in has this comment twice:
"Check for Python-specific malloc support"

c.f.:

# Check for Python-specific malloc support
AC_MSG_CHECKING(for --with-tsc)

(snip)

# Check for Python-specific malloc support
AC_MSG_CHECKING(for --with-pymalloc)



Clearly the first one should read something like:
# Determine if the bytecode evaluation loop should be instrumented using the CPU timestamp-counter
or somesuch.

Seems to affect both trunk and py3k

----------
components: Interpreter Core
messages: 100869
nosy: dmalcolm
severity: normal
status: open
title: Minor comment error in configure.in  ("malloc support" appears twice)
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Mar 12 09:15:36 2010
From: report at bugs.python.org (Hamed J.I)
Date: Fri, 12 Mar 2010 08:15:36 +0000
Subject: [New-bugs-announce] [issue8120] Py_Initialize: Can't initialize
	system standard streams
In-Reply-To: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>
Message-ID: <1268381736.56.0.066995297894.issue8120@psf.upfronthosting.co.za>


New submission from Hamed J.I <hamed.ji at gmail.com>:

While try to run Python.exe version 3.1 or 3.2 RC2 on
Windows 7 or Windows XP SP2 get the following error:

Py_Initialize: Can't initialize system standard streams
Lookup Error: unknown encoding: cp720

after download and install cp720.py to lib/encodings get the following error:

Py_Initialize: Can't initialize system standard streams
TypeError: 'NoneType' object is not callable

this is while IDLE works fine

----------
components: Installation
messages: 100904
nosy: Hamed.ji
severity: normal
status: open
title: Py_Initialize: Can't initialize system standard streams
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri Mar 12 11:14:46 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 12 Mar 2010 10:14:46 +0000
Subject: [New-bugs-announce] [issue8121] Typo in cStringIO
In-Reply-To: <1268388886.16.0.669780610332.issue8121@psf.upfronthosting.co.za>
Message-ID: <1268388886.16.0.669780610332.issue8121@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

There is a malformed string in the module cStringIO.

StringI <--> StringIO


>>> sys.version
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
>>> StringIO.StringIO('123')
<StringIO.StringIO instance at 0x02D230D0>
>>> cStringIO.StringIO('123')
<cStringIO.StringI object at 0x0183ECB0>
>>>

----------
components: None
messages: 100920
nosy: jmfauth
severity: normal
status: open
title: Typo in cStringIO
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar 12 11:59:17 2010
From: report at bugs.python.org (oliv)
Date: Fri, 12 Mar 2010 10:59:17 +0000
Subject: [New-bugs-announce] [issue8122] re.sub doesn't handle properly
	matches with yes-pattern	no-pattern
In-Reply-To: <1268391557.94.0.848119216158.issue8122@psf.upfronthosting.co.za>
Message-ID: <1268391557.94.0.848119216158.issue8122@psf.upfronthosting.co.za>


New submission from oliv <o_medoc at yahoo.fr>:

Using python 2.6.4 on Arch Linux

The regular expression syntax in python indicate: 

(?(id/name)yes-pattern|no-pattern)
Will try to match with yes-pattern  if the group with given id or name exists, and with no-pattern  if it doesn?t.

I used that functionnality but the code doesn't works anymore:
import re
myre = re.compile('(?P<port>[0-9]+/(tcp|udp))\s+(?P<status>\S+)\s+(?P<service>[a-zA-Z0-9_-]+)\s*(?P<details>.*)')
myre.sub('(?(<details>)\g<details>|\g<service>)',"443/tcp open  ssl      Microsoft IIS SSL")

> The output is:
'(?(<details>)Microsoft IIS SSL|ssl)'
Instead of:
Microsoft IIS SSL

It looks like a bug as it was working earlier...

----------
components: Build
messages: 100926
nosy: oliv
severity: normal
status: open
title: re.sub doesn't handle properly matches with yes-pattern no-pattern
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar 12 16:37:45 2010
From: report at bugs.python.org (Dmitry Jemerov)
Date: Fri, 12 Mar 2010 15:37:45 +0000
Subject: [New-bugs-announce] [issue8123] TypeError in urllib when trying to
	use HTTP authentication
In-Reply-To: <1268408265.34.0.392057078834.issue8123@psf.upfronthosting.co.za>
Message-ID: <1268408265.34.0.392057078834.issue8123@psf.upfronthosting.co.za>


New submission from Dmitry Jemerov <intelliyole at gmail.com>:

I'm trying to download a file from a site using HTTP authentication. I'm subclassing FancyURLOpener, returning my credentials from the prompt_user_passwd() method, and using opener.retrieve() to download the file. I get the following error:

  File "C:/JetBrains/IDEA/build/eap/downandup.py", line 36, in download
    opener.retrieve(url, os.path.join(target_path, name))
  File "C:\Python31\lib\urllib\request.py", line 1467, in retrieve
    fp = self.open(url, data)
  File "C:\Python31\lib\urllib\request.py", line 1435, in open
    return getattr(self, name)(url)
  File "C:\Python31\lib\urllib\request.py", line 1609, in open_http
    return self._open_generic_http(http.client.HTTPConnection, url, data)
  File "C:\Python31\lib\urllib\request.py", line 1605, in _open_generic_http
    response.status, response.reason, response.msg, data)
  File "C:\Python31\lib\urllib\request.py", line 1621, in http_error
    result = method(url, fp, errcode, errmsg, headers)
  File "C:\Python31\lib\urllib\request.py", line 1859, in http_error_401
    return getattr(self,name)(url, realm)
  File "C:\Python31\lib\urllib\request.py", line 1931, in retry_http_basic_auth
    return self.open(newurl)
  File "C:\Python31\lib\urllib\request.py", line 1435, in open
    return getattr(self, name)(url)
  File "C:\Python31\lib\urllib\request.py", line 1609, in open_http
    return self._open_generic_http(http.client.HTTPConnection, url, data)
  File "C:\Python31\lib\urllib\request.py", line 1571, in _open_generic_http
    auth = base64.b64encode(user_passwd).strip()
  File "C:\Python31\lib\base64.py", line 56, in b64encode
    raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str

The problem happens because _open_generic_http extracts the user password from the string URL, and passes the string to the b64encode method, which only accepts bytes and not strings. The problem happens with Python 3.1.1 for me, but as far as I can see it's still not fixed in the py3k branch as of now.

----------
components: Library (Lib)
messages: 100938
nosy: Dmitry.Jemerov
severity: normal
status: open
title: TypeError in urllib when trying to use HTTP authentication
versions: Python 3.1

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

From report at bugs.python.org  Fri Mar 12 17:08:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Mar 2010 16:08:39 +0000
Subject: [New-bugs-announce] [issue8124] mywrite() ignores
	PyFile_WriteString() errors
In-Reply-To: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>
Message-ID: <1268410119.59.0.322464622688.issue8124@psf.upfronthosting.co.za>


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

PyFile_WriteString() calls PyObject_Str() which calls PyErr_CheckSignals(). If a signal was catched, the signal handler is called. If the signal handler raises an error, PyObject_Str() and then PyFile_WriteString() return NULL.

mywrite() ignores all PyFile_WriteString() errors. It should maybe only ignores errors from the file (except IOError: ...) and not any error.

Another problem: mywrite() is called from PySys_WriteStdout() and PySys_WriteStderr() which are procedures. PySys_WriteStdout()/PySys_WriteStderr() caller cannot detect the error. There are 65 calls to PySys_WriteStd...

----------
components: Interpreter Core
messages: 100939
nosy: haypo
severity: normal
status: open
title: mywrite() ignores PyFile_WriteString() errors
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Mar 12 17:25:07 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Fri, 12 Mar 2010 16:25:07 +0000
Subject: [New-bugs-announce] [issue8125] shutil.copytree behavior is
	inconsistent with copyfile
In-Reply-To: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>
Message-ID: <1268411107.29.0.36566852086.issue8125@psf.upfronthosting.co.za>


New submission from joseph.h.garvin <joseph.h.garvin at gmail.com>:

shutil.copyfile's behavior is to replace the dst file if it already exists. shutil.copytree requires that the destination not already exist, and throws an OSError if it does. I see 3 problems with this behavior:

1. It's inconsistent with copyfile

2. It's inconsistent with 'cp', which is what users would be using if they were writing shell script. Given shutil's namesake I assume it's supposed to help make python a viable shell script replacement.

3. It makes it difficult to use copytree with tempfile.mkdtemp(). If I want to make a temporary directory and copy a folder into it, I need to copytree to a nonexist subfolder then move all the files down a level or resort to other unpythonic hacks. In my project I copy unit test resources to a temp folder because they're manipulated throughout the test and I want to keep the originals. I imagine that this is a common use case.

That said, if anyone depended on shutil.copytree failing to test whether or not a folder exists, changing this would break compatibility, so if it can't be changed, maybe a shutil.mergetree would be appropriate.

----------
components: Library (Lib)
messages: 100943
nosy: joseph.h.garvin
severity: normal
status: open
title: shutil.copytree behavior is inconsistent with copyfile
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 12 18:40:08 2010
From: report at bugs.python.org (Palluat de Besset)
Date: Fri, 12 Mar 2010 17:40:08 +0000
Subject: [New-bugs-announce] [issue8126] Python 3.1.2rc1 doesn't compile
	using the 10.4 sdk on a	10.6 Mac
In-Reply-To: <1268415608.25.0.26520414202.issue8126@psf.upfronthosting.co.za>
Message-ID: <1268415608.25.0.26520414202.issue8126@psf.upfronthosting.co.za>


New submission from Palluat de Besset <marc.palluatdebesset at sophos.com>:

/usr/bin/gcc-4.0 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPYTHONFRAMEWORK='"Python"' -o pythonw ./Tools/pythonw.c -I.. -I./../Include ../Python.framework/Versions/3.2/Python
./Tools/pythonw.c:22:19:./Tools/pythonw.c:22:19: error: spawn.h: No such file or directory
 error: spawn.h: No such file or directory
./Tools/pythonw.c:91: error: syntax error before ?*? token./Tools/pythonw.c:91: error: syntax error before ?*? token
./Tools/pythonw.c: In function ?setup_spawnattr?:
./Tools/pythonw.c:95: error: ?cpu_type_t? undeclared (first use in this function)
./Tools/pythonw.c:95: error: (Each undeclared identifier is reported only once
./Tools/pythonw.c:95: error: for each function it appears in.)
./Tools/pythonw.c:95: error: syntax error before ?cpu_types?
./Tools/pythonw.c:101: error: ?spawnattr? undeclared (first use in this function)
./Tools/pythonw.c:122: error: ?cpu_types? undeclared (first use in this function)
./Tools/pythonw.c:122: error: ?CPU_TYPE_X86? undeclared (first use in this function)
./Tools/pythonw.c:142: error: ?POSIX_SPAWN_SETEXEC? undeclared (first use in this function)
./Tools/pythonw.c: In function ?main?:
./Tools/pythonw.c:158: error: ?posix_spawn? undeclared (first use in this function)
./Tools/pythonw.c:159: error: ?posix_spawnattr_t? undeclared (first use in this function)
./Tools/pythonw.c:159: error: syntax error before ?spawnattr?
./Tools/pythonw.c:161: error: ?spawnattr? undeclared (first use in this function)

./Tools/pythonw.c: In function ?setup_spawnattr?:
./Tools/pythonw.c:95: error: ?cpu_type_t? undeclared (first use in this function)
./Tools/pythonw.c:95: error: (Each undeclared identifier is reported only once
./Tools/pythonw.c:95: error: for each function it appears in.)
./Tools/pythonw.c:95: error: syntax error before ?cpu_types?
./Tools/pythonw.c:101: error: ?spawnattr? undeclared (first use in this function)
./Tools/pythonw.c:120: error: ?cpu_types? undeclared (first use in this function)
./Tools/pythonw.c:120: error: ?CPU_TYPE_POWERPC? undeclared (first use in this function)
./Tools/pythonw.c:142: error: ?POSIX_SPAWN_SETEXEC? undeclared (first use in this function)
./Tools/pythonw.c: In function ?main?:
./Tools/pythonw.c:158: error: ?posix_spawn? undeclared (first use in this function)
./Tools/pythonw.c:159: error: ?posix_spawnattr_t? undeclared (first use in this function)
./Tools/pythonw.c:159: error: syntax error before ?spawnattr?
./Tools/pythonw.c:161: error: ?spawnattr? undeclared (first use in this function)
lipo: can't figure out the architecture type of: /var/tmp//cct0zueu.out
make[1]: *** [pythonw] Error 1
make: *** [frameworkinstallapps] Error 2

----------
components: Build
messages: 100949
nosy: mpalluat
severity: normal
status: open
title: Python 3.1.2rc1 doesn't compile using the 10.4 sdk on a 10.6 Mac
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Fri Mar 12 20:02:03 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 12 Mar 2010 19:02:03 +0000
Subject: [New-bugs-announce] [issue8127] Add link to PortingPythonToPy3k to
	What's New	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

The What's New documentation for Python 3.0 and 3.1 have sections called "Porting to Python 3.0".  It would be great to add a link to the Python wiki page about porting Python to Python 3:

http://wiki.python.org/moin/PortingPythonToPy3k

----------
assignee: georg.brandl
components: Documentation
messages: 100956
nosy: amcnabb, georg.brandl
severity: normal
status: open
title: Add link to PortingPythonToPy3k to What's New documentation
versions: Python 3.1

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

From report at bugs.python.org  Sat Mar 13 03:47:34 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 13 Mar 2010 02:47:34 +0000
Subject: [New-bugs-announce] [issue8128] String interpolation with unicode
	subclass fails to call	__str__
In-Reply-To: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>
Message-ID: <1268448454.93.0.643768410132.issue8128@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

String interpolation % operates on unicode strings directly without calling the __str__ method. In Python 2.5 and 2.6:

>>> class K(unicode):
...     def __str__(self): return "Surprise!"
...
>>> u"%s" % K("some text")
u'some text'

but subclasses of str do call __str__:

>>> class K(str):
...     def __str__(self): return "Surprise!"
...
>>> "%s" % K("some text")
'Surprise!'

In Python 3.1, the above example for subclassing str operates like the unicode example, i.e. it fails to call __str__.

The documentation for string interpolation states that str() is called for all Python objects.

http://docs.python.org/library/stdtypes.html#string-formatting-operations

If the behaviour for unicode (2.5/2.6, str in 3.1) is considered correct, then the documentation should be updated to say that unicode is an exception to the rule. Otherwise the behaviour is incorrect, and it should call __str__ the same as everything else.

----------
messages: 100984
nosy: stevenjd
severity: normal
status: open
title: String interpolation with unicode subclass fails to call __str__
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Mar 13 04:13:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Mar 2010 03:13:41 +0000
Subject: [New-bugs-announce] [issue8129] Wrong arguments in
	sqlite3.connect() documentation
In-Reply-To: <1268450021.57.0.736036682608.issue8129@psf.upfronthosting.co.za>
Message-ID: <1268450021.57.0.736036682608.issue8129@psf.upfronthosting.co.za>


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

Python documentation has the prototype:

sqlite3.connect(database[, timeout, isolation_level, detect_types, factory])

http://docs.python.org/library/sqlite3.html#sqlite3.connect

Source code:

 - sqlite.rst: .. function:: connect(database[, timeout, isolation_level, detect_types, factory])
 - connect() documentation: connect(database[, 
timeout, isolation_level, detect_types, factory])
 - module_connect(): char *kwlist[] = {"database", "timeout", "detect_types", "isolation_level", "check_same_thread", "factory", "cached_statements", NULL, NULL};
 - pysqlite_connection_init(): char *kwlist[] = {"database", "timeout", "detect_types", "isolation_level", "check_same_thread", "factory", "cached_statements", NULL, NULL};

module_connect() and pysqlite_connection_init() use the same keyword list, but the documentation invert arguments detect_types and isolation_level, and miss check_same_thread and cached_statements arguments.

--

Example:

>>> import sqlite3
>>> con=sqlite3.connect(':memory:', 2.0, 'DEFER')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required
>>> con=sqlite3.connect(':memory:', 2.0, True)
>>> con=sqlite3.connect(':memory:', 2.0, isolation_level='DEFER')

The third argument is a boolean, it's the detect_types option (not the isolation level, a string).

----------
assignee: georg.brandl
components: Documentation
messages: 100987
nosy: georg.brandl, haypo
severity: normal
status: open
title: Wrong arguments in sqlite3.connect() documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Mar 13 08:32:38 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 13 Mar 2010 07:32:38 +0000
Subject: [New-bugs-announce] [issue8130] except-as in Py3 eats variables
In-Reply-To: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>
Message-ID: <1268465558.4.0.902303954365.issue8130@psf.upfronthosting.co.za>


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

Python 3.2a0 (py3k:78205M, Feb 16 2010, 17:32:08)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> e = None
[50279 refs]
>>> e
[50279 refs]
>>> try: raise ValueError
... except ValueError as e: pass
...
[50277 refs]
>>> e
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'e' is not defined
[50277 refs]


Same for 3.1.1. Note how the refcount is going down after the try-except.

----------
components: Interpreter Core
messages: 100993
nosy: scoder
severity: normal
status: open
title: except-as in Py3 eats variables
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Mar 13 10:35:50 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 13 Mar 2010 09:35:50 +0000
Subject: [New-bugs-announce] [issue8131] Delivery Status Notification
	(Failure)
In-Reply-To: <0016e6d778afb63ed90481ab4e69@google.com>
Message-ID: <a4f83ee11003130135q676eb9c9k5aa59bc4f1aae829@mail.gmail.com>


New submission from reynaldo <renben77 at gmail.com>:

www.google.com/chromebeta/what a browser

---------- Forwarded message ----------
From: "Mail Delivery Subsystem" <mailer-daemon at googlemail.com>
Date: Mar 13, 2010 1:31 AM
Subject: Delivery Status Notification (Failure)
To: <renben77 at gmail.com>

Delivery to the following recipient failed permanently:

    homepagewebsitebrowser at gmail.com

Technical details of permanent failure:
The email account that you tried to reach does not exist. Please try
double-checking the recipient's email address for typos or unnecessary
spaces. Learn more at
http://mail.google.com/support/bin/answer.py?answer=6596

----- Original message -----

Return-Path: <renben77 at gmail.com>
Received-SPF: pass (google.com: domain of renben77 at gmail.com designates
10.216.85.9 as permitted sender) client-ip=10.216.85.9;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
renben77 at gmail.com designates 10.216.85.9 as permitted sender) smtp.mail=
renben77 at gmail.com; dkim=pass header.i=renben77 at gmail.com
Received: from mr.google.com ([10.216.85.9])
       by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666728 (num_hops
= 1);
       Sat, 13 Mar 2010 01:31:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
       d=gmail.com; s=gamma;
       h=domainkey-signature:mime-version:received:in-reply-to:references
        :date:message-id:subject:from:to:content-type;
       bh=e95TaoJEoSEO0fI8PxX3gWmPAWk7MpFGuxo5WXR7c5s=;
       b=ryAtBQKbrkyqTmY9I7u9+8+TU18Nn0sUpEQdUKNMv9qLD4DcFTgrs5+Cl9yajGzLRR
        blBWEtQT7JePAJSXemEJWH+qwSlpv0j/MHONzSYvtImdpxUAH5m5ROAIb2syRtJ3MsC0
        6Z6VTwMh9+3tlrGMKddmKV0w7EuEVGvWLM1BA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
       d=gmail.com; s=gamma;
       h=mime-version:in-reply-to:references:date:message-id:subject:from:to
        :content-type;
       b=PopzoxmDZC0tp09qENK/OV5l98fQkpgX8A/ZezTstyFIONBDDC6ky9PGrzUk17u1zq
        v1DYZ5TdIpXdC+/hyA9QNW7XfEST/yG7jqSBeVA12Fmly1EZ7VRps+MBCWVBXFyZvnhR
        uihbsR+Wn2fR+8kPZplTiwSfHE/5J0fnA/hyY=
MIME-Version: 1.0
Received: by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666716; Sat,
13
       Mar 2010 01:31:06 -0800 (PST)
In-Reply-To: <a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com>
References: <a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com>
Date: Sat, 13 Mar 2010 01:31:06 -0800
Message-ID: <a4f83ee11003130131o12d5386ft2393da2951edc2c2 at mail.gmail.com>
Subject: Fwd: Re: Few tweaks

From: reynaldo bendijo <renben77 at gmail.com>
To: homepagewebsitebrowser at gmail.com
Content-Type: multipart/alternative; boundary=0016e6d778afb50bc50481ab4e58

www.google.com/chromebeta/what a browser

---------- Forwarded message ----------
From: "reynaldo b...

----------
files: unnamed
messages: 100998
nosy: renben
severity: normal
status: open
title: Delivery Status Notification (Failure)
Added file: http://bugs.python.org/file16531/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8131>
_______________________________________
-------------- next part --------------
<p></p>
<p><a href="http://www.google.com/chromebeta/what">www.google.com/chromebeta/what</a> a browser</p>
<p><blockquote type="cite">---------- Forwarded message ----------<br>From: &quot;Mail Delivery Subsystem&quot; &lt;<a href="mailto:mailer-daemon at googlemail.com">mailer-daemon at googlemail.com</a>&gt;<br>Date: Mar 13, 2010 1:31 AM<br>
Subject: Delivery Status Notification (Failure)<br>To:  &lt;<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>&gt;<br><br>Delivery to the following recipient failed permanently:<br>
<br>
 ?? ?? <a href="mailto:homepagewebsitebrowser at gmail.com">homepagewebsitebrowser at gmail.com</a><br>
<br>
Technical details of permanent failure:<br>
The email account that you tried to reach does not exist. Please try double-checking the recipient&#39;s email address for typos or unnecessary spaces. Learn more at <a href="http://mail.google.com/support/bin/answer.py?answer=6596" target="_blank">http://mail.google.com/support/bin/answer.py?answer=6596</a><br>

<br>
----- Original message -----<br>
<br>
Return-Path: &lt;<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>&gt;<br>
Received-SPF: pass (<a href="http://google.com" target="_blank">google.com</a>: domain of <a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a> designates 10.216.85.9 as permitted sender) client-ip=10.216.85.9;<br>
Authentication-Results: <a href="http://mr.google.com" target="_blank">mr.google.com</a>; spf=pass (<a href="http://google.com" target="_blank">google.com</a>: domain of <a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a> designates 10.216.85.9 as permitted sender) smtp.mail=<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>; dkim=pass header.i=<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a><br>

Received: from <a href="http://mr.google.com" target="_blank">mr.google.com</a> ([10.216.85.9])<br>
 ?? ?? ?? ??by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666728 (num_hops = 1);<br>
 ?? ?? ?? ??Sat, 13 Mar 2010 01:31:06 -0800 (PST)<br>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;<br>
 ?? ?? ?? ??d=<a href="http://gmail.com" target="_blank">gmail.com</a>; s=gamma;<br>
 ?? ?? ?? ??h=domainkey-signature:mime-version:received:in-reply-to:references<br>
 ?? ?? ?? ?? :date:message-id:subject:from:to:content-type;<br>
 ?? ?? ?? ??bh=e95TaoJEoSEO0fI8PxX3gWmPAWk7MpFGuxo5WXR7c5s=;<br>
 ?? ?? ?? ??b=ryAtBQKbrkyqTmY9I7u9+8+TU18Nn0sUpEQdUKNMv9qLD4DcFTgrs5+Cl9yajGzLRR<br>
 ?? ?? ?? ?? blBWEtQT7JePAJSXemEJWH+qwSlpv0j/MHONzSYvtImdpxUAH5m5ROAIb2syRtJ3MsC0<br>
 ?? ?? ?? ?? 6Z6VTwMh9+3tlrGMKddmKV0w7EuEVGvWLM1BA=<br>
DomainKey-Signature: a=rsa-sha1; c=nofws;<br>
 ?? ?? ?? ??d=<a href="http://gmail.com" target="_blank">gmail.com</a>; s=gamma;<br>
 ?? ?? ?? ??h=mime-version:in-reply-to:references:date:message-id:subject:from:to<br>
 ?? ?? ?? ?? :content-type;<br>
 ?? ?? ?? ??b=PopzoxmDZC0tp09qENK/OV5l98fQkpgX8A/ZezTstyFIONBDDC6ky9PGrzUk17u1zq<br>
 ?? ?? ?? ?? v1DYZ5TdIpXdC+/hyA9QNW7XfEST/yG7jqSBeVA12Fmly1EZ7VRps+MBCWVBXFyZvnhR<br>
 ?? ?? ?? ?? uihbsR+Wn2fR+8kPZplTiwSfHE/5J0fnA/hyY=<br>
MIME-Version: 1.0<br>
Received: by 10.216.85.9 with SMTP id t9mr1284787wee.79.1268472666716; Sat, 13<br>
 ?? ?? ?? ??Mar 2010 01:31:06 -0800 (PST)<br>
In-Reply-To: &lt;<a href="mailto:a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com">a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com</a>&gt;<br>
References: &lt;<a href="mailto:a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com">a4f83ee11003130105m66a12835rba0a25942091778c at mail.gmail.com</a>&gt;<br>
Date: Sat, 13 Mar 2010 01:31:06 -0800<br>
Message-ID: &lt;<a href="mailto:a4f83ee11003130131o12d5386ft2393da2951edc2c2 at mail.gmail.com">a4f83ee11003130131o12d5386ft2393da2951edc2c2 at mail.gmail.com</a>&gt;<br>
Subject: Fwd: Re: Few tweaks<br>
<p><font color="#500050">From: reynaldo bendijo &lt;<a href="mailto:renben77 at gmail.com">renben77 at gmail.com</a>&gt;</font></p>To: <a href="mailto:homepagewebsitebrowser at gmail.com">homepagewebsitebrowser at gmail.com</a><br>
Content-Type: multipart/alternative; boundary=0016e6d778afb50bc50481ab4e58<br>
<p><font color="#500050"><br><a href="http://www.google.com/chromebeta/what">www.google.com/chromebeta/what</a> a browser<br><br>---------- Forwarded message ----------<br>From: &quot;reynaldo b...</font></p></blockquote>
</p>

From report at bugs.python.org  Sat Mar 13 16:29:48 2010
From: report at bugs.python.org (grumetz)
Date: Sat, 13 Mar 2010 15:29:48 +0000
Subject: [New-bugs-announce] [issue8132] email.header.decode_header makes
	mistakes
In-Reply-To: <1268494188.38.0.891731205331.issue8132@psf.upfronthosting.co.za>
Message-ID: <1268494188.38.0.891731205331.issue8132@psf.upfronthosting.co.za>


New submission from grumetz <jpgrumetz at free.fr>:

Examples:

s = '=?UTF-8?B?QWNjdXPDqSBkZSByw6ljZXB0aW9uIChhZmZpY2jDqSkgLSA=?=Arobase !'
decode_header(s) --->
[('=?UTF-8?B?QWNjdXPDqSBkZSByw6ljZXB0aW9uIChhZmZpY2jDqSkgLSA=?=Arobase !', None)]
which seems bad...
but
ss ='=?UTF-8?B?QWNjdXPDqSBkZSByw6ljZXB0aW9uIChhZmZpY2jDqSkgLSA=?= Arobase !'
decode_header(ss) --->
[('Accus\xc3\xa9 de r\xc3\xa9ception (affich\xc3\xa9) - ', 'utf-8'), ('Arobase !', None)]
which seems good...

----------
components: Library (Lib)
messages: 101004
nosy: grmtz
severity: normal
status: open
title: email.header.decode_header makes mistakes
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 13 21:02:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Mar 2010 20:02:25 +0000
Subject: [New-bugs-announce] [issue8133] test_imp fails on OS X 10.6;
	filename normalization issue.
In-Reply-To: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>
Message-ID: <1268510545.68.0.655630748834.issue8133@psf.upfronthosting.co.za>


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

test_issue5604 from test_imp is currently failing on OS X !0.6 (py3k branch), with the following output:

======================================================================
ERROR: test_issue5604 (__main__.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 121, in test_issue5604
    file, filename, info = imp.find_module(temp_mod_name)
ImportError: No module named test_imp_helper_?

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


I think this has something to do with the platform automatically
using NFD normalization for filenames.  Here's an interactive session: 

Python 3.2a0 (py3k:78936, Mar 13 2010, 19:42:52) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp, unicodedata
>>> fname = 'test' + b'\xc3\xa4'.decode('utf-8')
>>> with open(fname+'.py', 'w') as file: file.write('a = 1\n')
... 
6
>>> imp.find_module(fname)   # expected this to succeed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named test?
>>> imp.find_module(unicodedata.normalize('NFD', fname))
(<_io.TextIOWrapper name=4 encoding='utf-8'>, 'test?.py', ('.py', 'U', 1))


In contrast, a simple 'open' doesn't seem to care about normalization:

>>> open(fname+'.py')
<_io.TextIOWrapper name='test?.py' encoding='UTF-8'>
[50305 refs]
>>> open(unicodedata.normalize('NFD', fname)+'.py')
<_io.TextIOWrapper name='test?.py' encoding='UTF-8'>
[50305 refs]

----------
messages: 101018
nosy: ezio.melotti, mark.dickinson
severity: normal
status: open
title: test_imp fails on OS X 10.6; filename normalization issue.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Mar 13 23:11:09 2010
From: report at bugs.python.org (Greg Jednaszewski)
Date: Sat, 13 Mar 2010 22:11:09 +0000
Subject: [New-bugs-announce] [issue8134] collections.defaultdict gives
	KeyError with format()
In-Reply-To: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>
Message-ID: <1268518269.31.0.955944786218.issue8134@psf.upfronthosting.co.za>


New submission from Greg Jednaszewski <jednaszewski at gmail.com>:

Found on 2.6.2 and 2.6.4:

I expect that printing an uninitialized variable from a defaultdict should work.  In fact it does with old-style string formatting.  However, when you try to do it with new-style string formatting, it raises a KeyError.

>>> import collections
>>> d = collections.defaultdict(int)
>>> "{foo}".format(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'foo'
>>> "%(foo)d" % d
'0'

----------
components: Library (Lib)
messages: 101025
nosy: jednaszewski
severity: normal
status: open
title: collections.defaultdict gives KeyError with format()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar 14 09:46:55 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 08:46:55 +0000
Subject: [New-bugs-announce] [issue8135] urllib.unquote doesn't decode
	mixed-case percent escapes
In-Reply-To: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>
Message-ID: <1268556415.98.0.66516345593.issue8135@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

urllib.unquote fails to decode a percent-escape with mixed case. To demonstrate:

>>> unquote("%fc")
'\xfc'
>>> unquote("%FC")
'\xfc'
>>> unquote("%Fc")
'%Fc'
>>> unquote("%fC")
'%fC'

Expected behaviour:

>>> unquote("%Fc")
'\xfc'
>>> unquote("%fC")
'\xfc'

I actually fixed this bug in Python 3, at Guido's request as part of the huge fix to issue 3300. To quote Guido:

> # Maps lowercase and uppercase variants (but not mixed case).
> That sounds like a disaster.  Why would %aa and %AA be correct but
> not %aA and %Aa?  (Even though the old code had the same problem.)

(Indeed, the RFC 3986 allows mixed-case percent escapes.)

I have attached a patch which fixes it simply by removing the dict mapping all lower and uppercase variants to characters, and simply calling int(item[:2], 16). It's slower, but correct. This is the same solution we used in Python 3.

I've also backported a number of test cases from Python 3 which cover this issue, and also legitimate bad percent encoding.

Note: I've also backported the remainder of the 'unquote' test cases from Python 3 but I found another bug, so I will report that separately, with a patch.

----------
components: Library (Lib)
files: urllib-unquote-mixcase.patch
keywords: patch
messages: 101044
nosy: mgiuca
severity: normal
status: open
title: urllib.unquote doesn't decode mixed-case percent escapes
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16540/urllib-unquote-mixcase.patch

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

From report at bugs.python.org  Sun Mar 14 09:48:23 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 14 Mar 2010 08:48:23 +0000
Subject: [New-bugs-announce] [issue8136] urllib.unquote decodes
	percent-escapes with Latin-1
In-Reply-To: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>
Message-ID: <1268556503.05.0.747938740092.issue8136@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

The 'unquote' function has some very strange behaviour on Unicode input. My proposed fix will, I am sure, be contentious, because it could change existing behaviour (only on unicode strings), but I think it's worth it for a sane unquote function.

Some historical context: I already reported this bug in Python 3 as http://bugs.python.org/issue3300 (or part of it). We argued for two months. I rewrote the function, and Guido accepted it. The same bugs are present in Python 2, but less urgent since they only affect 'unicode' strings (whereas in Python 3 they affected all strings).

PROBLEM DESCRIPTION

The basic problem is this:
Current behaviour:
>>> urllib.unquote(u"%CE%A3")
u'\xce\xa3'
(or u'??')

Desired behaviour:
>>> urllib.unquote(u"%CE%A3")
'\xce\xa3'
(Which decodes with UTF-8 to u'?')

Basically, if you give unquote a unicode string, it will give you back a unicode string, with all of the percent-escapes decoded with Latin-1. This behaviour was added in r39728. The following line was added:

res[i] = unichr(int(item[:2], 16)) + item[2:]

It takes a percent-escape (e.g., "CE"), converts it to an int (e.g., 0xCE), then calls unichr to form a Unicode character with that codepoint (e.g., u'\u00ce'). That's totally wrong. A URI percent-escape "is used to represent a data octet" [RFC 3986], not a Unicode code point.

I would argue that the result of unquote should always be a str, no matter the input. Since a URI represents a byte sequence, not a character sequence, unquote of a unicode should return a byte string, which the user can then decode as desired.

Note that in Python 3 we didn't have a choice, since all strings are unicode, we used a much more complicated solution. But we also added a function unquote_to_bytes. Python 2's unquote should behave like Python 3's unquote_to_bytes.

PROPOSED SOLUTION

To that end, my proposed solution is simply to encode the input unicode string with UTF-8, which is exactly what Python 3's unquote_to_bytes function does. I have attached a patch which does this. It is thoroughly tested and documented. However, see the discussion of potential problems later.

WHY THE CURRENT BEHAVIOUR IS BAD

I'll also point out that the patch in r39728 which created this problem also added a test case, still there, which demonstrates just how confusing this behaviour is:

r = urllib.unquote(u'br%C3%BCckner_sapporo_20050930.doc')
self.assertEqual(r, u'br\xc3\xbcckner_sapporo_20050930.doc')

This takes a string, clearly meant to be a UTF-8-encoded percent-escaped string for u'br?ckner_sapporo_20050930.doc', and unquotes it. Because of this bug, it is decoded with Latin-1 to the string 'br??ckner_sapporo_20050930.doc'. And this garbled string is *actually the expected output of the test case*!!

Furthermore, this behaviour is very confusing because it breaks equality of ASCII str and unicode objects. Consider:

>>> "%C3%BC" == u"%C3%BC"
True
>>> urllib.unquote("%C3%BC")
'\xc3\xbc'
>>> urllib.unquote(u"%C3%BC")
u'\xc3\xbc'
>>> urllib.unquote("%C3%BC") == urllib.unquote(u"%C3%BC")
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False

Why should the ASCII str object "%C3%BC" encode to one value, while the ASCII unicode object u"%C3%BC" encode to another? The two inputs represent the same string, so they should produce the same output.

POTENTIAL PROBLEMS

The attached patch will not, to my knowledge, affect any calls to unquote with str input. It only changes unicode input. Since this was buggy anyway, I think it's a legitimate fix.

I am, however, concerned about code breakage for existing code which uses unicode strings and depends upon this behaviour. Some use cases:

1. Unquoting a unicode string which is pure ASCII, with pure ASCII percent-escapes. This previously would produce a pure ASCII unicode string, now produces a pure ASCII str. This shouldn't break anything unless some code specifically checks that strings are of type 'unicode' (e.g., the Storm database library).
2. Unquoting a unicode string with pure ASCII percent-escapes, but non-ASCII characters. This previously would preserve all the unescaped characters; they will now be encoded to UTF-8. Technically this should never happen, as URIs are not allowed to contain non-ASCII characters [RFC 3986].
3. Unquoting a unicode string which is pure ASCII, with non-ASCII percent escapes. Some code may rely on the implicit decoding as Latin-1. However, I think it is more likely that existing code would just break, since most URIs are UTF-8 encoded.

TWO SOLUTIONS

Having gone through the problems, I imagine that we may reach the conclusion that it is too dangerous to "fix" this bug. Therefore, I am proposing an alternate solution (which I will attach in a follow-up comment), which is not to change the code at all. Instead, just fix the broken test case and add lots more test cases, and also document this odd behaviour thoroughly, and recommend that the input to unquote be passed as a string, then decoded as desired.

I will call the patches "urllib-unquote-fix" (which fixes the bug, adding lots of test cases and updating the documentation to describe the new behaviour), and "urllib-unquote-explain" (which adds lots of test cases and updates the documentation to describe the existing behaviour in detail).

Please discuss. :)

Note: I've just simultaneously filed another bug (issue #8135) on unquote relating to mixed case percent-escapes. Between them, these two patches include all relevant 'unquote' test cases from Python 3. I've also backported the 'quote' test cases in a patch for issue #1712522.

----------
components: Library (Lib)
files: urllib-unquote-fix.patch
keywords: patch
messages: 101045
nosy: mgiuca
severity: normal
status: open
title: urllib.unquote decodes percent-escapes with Latin-1
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16541/urllib-unquote-fix.patch

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

From report at bugs.python.org  Sun Mar 14 09:58:30 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sun, 14 Mar 2010 08:58:30 +0000
Subject: [New-bugs-announce] [issue8137] Missing iso-8859-16 codec in the
	docs
In-Reply-To: <1268557110.11.0.0736384603908.issue8137@psf.upfronthosting.co.za>
Message-ID: <1268557110.11.0.0736384603908.issue8137@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

The "codecs ? Codec registry and base classes" part of
the documentions (Python 2.6.4, 2.7.a?, 3.1.1) does not
mention the existence of the iso-8859-16 codec.

----------
assignee: georg.brandl
components: Documentation
messages: 101047
nosy: georg.brandl, jmfauth
severity: normal
status: open
title: Missing iso-8859-16 codec in the docs
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Mar 14 19:08:56 2010
From: report at bugs.python.org (Santiago Gala)
Date: Sun, 14 Mar 2010 18:08:56 +0000
Subject: [New-bugs-announce] [issue8138] wsgiref.simple_server.SimpleServer
	claims to be	multithreaded
In-Reply-To: <1268590136.32.0.519225445448.issue8138@psf.upfronthosting.co.za>
Message-ID: <1268590136.32.0.519225445448.issue8138@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

In python 2.6, a server created with wsgiref.simple_server.make_server will
claim to be multithreaded and multiprocess through it wsgi environ. See  wsgi.multithread in the browser page after launching

  $ python /usr/lib/python2.6/wsgiref/simple_server.py

The bug is due to the default value in the constructor wsgiref.handlers.SimpleHandler, and it is misleading, as the servier is singlethreaded. It gives problems for any app that wants to change behavior or error on singlethreaded.

The problem can be fixed very simply by patching a "multithreaded=False" argument into the ServerHandler constructor in simple_server.

----------
messages: 101058
nosy: sgala
severity: normal
status: open
title: wsgiref.simple_server.SimpleServer claims to be multithreaded
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar 14 20:36:16 2010
From: report at bugs.python.org (Bertrand Janin)
Date: Sun, 14 Mar 2010 19:36:16 +0000
Subject: [New-bugs-announce] [issue8139] ossaudiodev not initializing its
	types
In-Reply-To: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>
Message-ID: <1268595376.1.0.514083582195.issue8139@psf.upfronthosting.co.za>


New submission from Bertrand Janin <tamentis at neopulsar.org>:

With Python 3.1.2-rc1, here is what happens when trying to open a mixer:

    Python 3.1.2rc1 (r312rc1:78737, Mar 14 2010, 15:17:09) 
    [GCC 4.3.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ossaudiodev
    >>> m = ossaudiodev.openmixer()
    >>> m.fileno()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: 'ossaudiodev.oss_mixer_device' object has no attribute 'fileno'

This seems to be due to the fact that the module does not initialize its types with PyType_Ready(), hence the Mixer type never gets its tp_getattro property from its parent type. I attached a small patch to fix this.

----------
components: Extension Modules
files: ossaudiodev.c.patch
keywords: patch
messages: 101063
nosy: tamentis
severity: normal
status: open
title: ossaudiodev not initializing its types
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16547/ossaudiodev.c.patch

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

From report at bugs.python.org  Sun Mar 14 20:41:33 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Mar 2010 19:41:33 +0000
Subject: [New-bugs-announce] [issue8140] extend compileall to compile single
	files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>


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

when byte-compiling files in a deb/rpm package distributed e.g. in a Linux distribution, it is sometimes wanted to only touch the files found in the deb/rpm, which can be a subset of the files in a directory. the attached patch now lets compileall accept files as arguments as well and adds the recognition of @<filelist> and @- to expand the arguments with the contents of the file (@- meaning to read for stdin). Is this ok for 2.7, and a port of that to 3.2?

----------
components: Library (Lib)
files: compileall.py.diff
keywords: patch
messages: 101064
nosy: doko
severity: normal
status: open
title: extend compileall to compile single files
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16548/compileall.py.diff

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

From report at bugs.python.org  Sun Mar 14 22:56:32 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 14 Mar 2010 21:56:32 +0000
Subject: [New-bugs-announce] [issue8141] test_asynchat & test_smtplib
	failures in 2.6 release	branch
In-Reply-To: <1268603792.5.0.509271883407.issue8141@psf.upfronthosting.co.za>
Message-ID: <1268603792.5.0.509271883407.issue8141@psf.upfronthosting.co.za>


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

I svn up'd and rebuild the release26-maint branch today on my Mac (MacBook
Pro, OSX 10.5.8).  test_asynchat and test_smtplib both fail with 
unexpected output:

test test_asynchat produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbecb0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed28> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed50> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbee18> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbed50> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbedf0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbedc8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbecb0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbebc0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbedf0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x1fbee40> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])

**********************************************************************


test test_smtplib produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:54647 at 0x30c2df0> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:54651 at 0x30c2c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:54655 at 0x333fb48> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/skip/src/python/release26-maint/Lib/asyncore.py|readwrite|107] [/Users/skip/src/python/release26-maint/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/skip/src/python/release26-maint/Lib/socket.py|_dummy|165])

Not sure if this is critical.  Assigning to Barry as the release 
manager and marking as a blocker just in case.

S

----------
assignee: barry
components: Library (Lib)
messages: 101067
nosy: barry, skip.montanaro
priority: release blocker
severity: normal
status: open
title: test_asynchat & test_smtplib failures in 2.6 release branch
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 15 00:40:05 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Mar 2010 23:40:05 +0000
Subject: [New-bugs-announce] [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>


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

opening a report to track issues with the update of the internal libffi copy to 3.0.9.  will commit this update to the trunk, and later to the py3k branch.

----------
assignee: theller
components: ctypes
messages: 101072
nosy: doko, theller
severity: normal
status: open
title: libffi update to 3.0.9
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Mar 15 02:06:49 2010
From: report at bugs.python.org (Matt Giuca)
Date: Mon, 15 Mar 2010 01:06:49 +0000
Subject: [New-bugs-announce] [issue8143] urlparse has a duplicate of
	urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

urlparse contains a complete copy of the urllib.unquote function. This is extremely nasty code duplication -- I have two patches pending on urllib.unquote (#8135 and #8136) and I only just realised that I missed urlparse.unquote!

The reason given for this is:
"Cannot use directly from urllib as it would create circular reference.
urllib uses urlparse methods ( urljoin)"

I don't see that as a reason for code duplication. The fix is to make a local import of unquote in parse_qsl, like this:

def parse_qsl(qs, keep_blank_values=0, strict_parsing=0):
    from urllib import unquote

I am aware that this possibly violates PEP 8 (all imports should be at the top of the module), but I'd say this is the lesser of two evils.

A patch is attached. Commit log: "urlparse: Removed duplicate of urllib.unquote. Replaced with a local import."

----------
components: Library (Lib)
files: urlparse-unquote.patch
keywords: patch
messages: 101075
nosy: mgiuca
severity: normal
status: open
title: urlparse has a duplicate of urllib.unquote
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16550/urlparse-unquote.patch

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

From report at bugs.python.org  Mon Mar 15 02:51:06 2010
From: report at bugs.python.org (brandon)
Date: Mon, 15 Mar 2010 01:51:06 +0000
Subject: [New-bugs-announce] [issue8144] muliprocessing shutdown infinite
	loop
In-Reply-To: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za>
Message-ID: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za>


New submission from brandon <drraid at gmail.com>:

Multiprocessing goes into an infinite loop during shutdown, trying to connect to a remote queue - I *think* during finalization. 

The actual loop appears to be the while(1) in connection.py line 251, and I think it is being called initially from manager.py finalization.

I can reliably reproduce but my code base is large and ugly, and I am still trimming down to a nice clean sample to submit.

----------
messages: 101078
nosy: drraid
severity: normal
status: open
title: muliprocessing shutdown infinite loop
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 15 10:01:45 2010
From: report at bugs.python.org (Laszlo Nagy)
Date: Mon, 15 Mar 2010 09:01:45 +0000
Subject: [New-bugs-announce] [issue8145] Documentation about sqlite3
	isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>


New submission from Laszlo Nagy <nagylzs at gmail.com>:

Clarify what isolation_level does, and how to use it, and why connections do not commit/rollback in some cases.

Details here:

http://mail.python.org/pipermail/python-list/2010-March/1239374.html

I'll paste code for ctx_manager_2.py here. This is a new file, I could not include it as a diff:

import sqlite3

class MyConn(sqlite3.Connection):
    def __enter__(self):
        self.execute("BEGIN")
        return self
    def __exit__(self,exc_type,exc_info,traceback):
        if exc_type is None:
            self.execute("COMMIT")
        else:
            self.execute("ROLLBACK")


conn = sqlite3.connect(':memory:',factory=MyConn)
conn.isolation_level = None
with conn:
    conn.execute("create table a ( i integer ) ")
    conn.execute("insert into a values (1)")
try:
    with conn:
        conn.execute("insert into a values (2)")
        conn.execute("savepoint sp1")
        conn.execute("insert into a values (3)")
        conn.execute("rollback to sp1")
        conn.execute("insert into a values (4)")
        print "Before rollback: 1,2,4"
        for row in conn.execute("select * from a"):
            print row[0] # prints 1,2,4
        raise Exception
except:
    pass
print "After rollback: 1"
for row in conn.execute("select * from a"):
    print row[0] # prints 1

----------
assignee: georg.brandl
components: Documentation
files: sqlite3.rst.diff
keywords: patch
messages: 101090
nosy: georg.brandl, nagylzs
severity: normal
status: open
title: Documentation about sqlite3 isolation_level
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file16554/sqlite3.rst.diff

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

From report at bugs.python.org  Mon Mar 15 13:03:00 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 15 Mar 2010 12:03:00 +0000
Subject: [New-bugs-announce] [issue8146] Latest version of Python for
	windows 98
In-Reply-To: <1268654580.81.0.265701964424.issue8146@psf.upfronthosting.co.za>
Message-ID: <1268654580.81.0.265701964424.issue8146@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://www.python.org/download/windows/

This page lacks information about which versions of Python were last supported for Windows 95, Windows 98 and Windows 2000. Which may run even though they are not supported on these platforms anymore.

----------
assignee: georg.brandl
components: Documentation
messages: 101096
nosy: georg.brandl, techtonik
severity: normal
status: open
title: Latest version of Python for windows 98

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

From report at bugs.python.org  Mon Mar 15 13:09:46 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 15 Mar 2010 12:09:46 +0000
Subject: [New-bugs-announce] [issue8147] os.system and standard C function
	system() limitations
In-Reply-To: <1268654986.31.0.580181541721.issue8147@psf.upfronthosting.co.za>
Message-ID: <1268654986.31.0.580181541721.issue8147@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/os.html#os.system

...This is implemented by calling the Standard C function system(), and has the same limitations...

Which limitations?

BTW, is the Windows 98 comment can be dropped.

----------
assignee: georg.brandl
components: Documentation
messages: 101097
nosy: georg.brandl, techtonik
severity: normal
status: open
title: os.system and standard C function system() limitations

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

From report at bugs.python.org  Mon Mar 15 15:03:42 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Mon, 15 Mar 2010 14:03:42 +0000
Subject: [New-bugs-announce] [issue8148] logging.SyslogHandler.emit()
In-Reply-To: <1268661822.53.0.463206600226.issue8148@psf.upfronthosting.co.za>
Message-ID: <1268661822.53.0.463206600226.issue8148@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

Hi,

In SyslogHandler class from logging package, emit() function calls socket.sendto() at line 785. Passing arguments are not in the right order due to flags parameter which is optional (@see http://docs.python.org/py3k/library/socket.html#socket.socket.sendto). It results in a TypeError exception when called -->

Traceback (most recent call last):
  File "C:\PROGRA~2\Python\31\lib\logging\handlers.py", line 785, in emit
    self.socket.sendto(msg, self.address)
TypeError: sendto() takes exactly 3 arguments (2 given)

Thanks.

PS: seen on a Windows 7 with Python 3.1.1

----------
components: Library (Lib)
messages: 101110
nosy: Kain94
severity: normal
status: open
title: logging.SyslogHandler.emit()
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Mar 15 17:33:03 2010
From: report at bugs.python.org (Gustavo Narea)
Date: Mon, 15 Mar 2010 16:33:03 +0000
Subject: [New-bugs-announce] [issue8149] libffi's configure is not executable
In-Reply-To: <1268670783.69.0.0433801915612.issue8149@psf.upfronthosting.co.za>
Message-ID: <1268670783.69.0.0433801915612.issue8149@psf.upfronthosting.co.za>


New submission from Gustavo Narea <gustavonarea at 2degreesnetwork.com>:

Download Python 2.5.5 and run ./configure: "_ctypes.so" won't be compiled because the ./configure file for libffi in ctypes is not executable.

Here's the output:
====
env: Python-2.5.5/Modules/_ctypes/libffi/configure: Permission denied
Failed to configure _ctypes module
building '_ctypes_test' extension
====

----------
assignee: theller
components: ctypes
messages: 101123
nosy: Gustavo.Narea, theller
severity: normal
status: open
title: libffi's configure is not executable
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Mon Mar 15 20:15:06 2010
From: report at bugs.python.org (aalex)
Date: Mon, 15 Mar 2010 19:15:06 +0000
Subject: [New-bugs-announce] [issue8150] urllib needs ability to set METHOD
	for HTTP requests
In-Reply-To: <1268680506.54.0.712056752351.issue8150@psf.upfronthosting.co.za>
Message-ID: <1268680506.54.0.712056752351.issue8150@psf.upfronthosting.co.za>


New submission from aalex <andrewalex at gmail.com>:

urllib.request can not support many standard HTTP 1.1 METHODS including HEAD, PUT, DELETE.

Adding this would be trivial (either as a special header "METHOD") or its own paramater, creating additional use, with little or no drawback.

----------
components: Library (Lib)
messages: 101133
nosy: aalex
severity: normal
status: open
title: urllib needs ability to set METHOD for HTTP requests
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Mar 15 23:29:57 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 15 Mar 2010 22:29:57 +0000
Subject: [New-bugs-announce] [issue8151] [patch] convenience links for
	subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://codereview.appspot.com/577041/show

Index: make.bat
===================================================================
--- make.bat	(revision 78986)
+++ make.bat	(working copy)
@@ -1,4 +1,4 @@
-@@echo off
+ at echo off
 setlocal
 
 set SVNROOT=http://svn.python.org/projects
Index: library/subprocess.rst
===================================================================
--- library/subprocess.rst	(revision 78986)
+++ library/subprocess.rst	(working copy)
@@ -185,7 +185,7 @@
    Run command with arguments.  Wait for command to complete, then return the
    :attr:`returncode` attribute.
 
-   The arguments are the same as for the Popen constructor.  Example::
+   The arguments are the same as for the :class:`Popen` constructor.  Example::
 
       retcode = call(["ls", "-l"])
 
@@ -197,7 +197,7 @@
    :exc:`CalledProcessError` object will have the return code in the
    :attr:`returncode` attribute.
 
-   The arguments are the same as for the Popen constructor.  Example::
+   The arguments are the same as for the :class:`Popen` constructor.  Example::
 
       check_call(["ls", "-l"])

----------
assignee: georg.brandl
components: Documentation
files: subprocess.call.doc.diff
keywords: patch
messages: 101136
nosy: georg.brandl, techtonik
severity: normal
status: open
title: [patch] convenience links for subprocess.call()
Added file: http://bugs.python.org/file16557/subprocess.call.doc.diff

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

From report at bugs.python.org  Tue Mar 16 01:07:45 2010
From: report at bugs.python.org (Francois)
Date: Tue, 16 Mar 2010 00:07:45 +0000
Subject: [New-bugs-announce] [issue8152] Divide error on Windows 7 Home
	Premium 64 bits
In-Reply-To: <1268698065.28.0.380764830973.issue8152@psf.upfronthosting.co.za>
Message-ID: <1268698065.28.0.380764830973.issue8152@psf.upfronthosting.co.za>


New submission from Francois <duf.francois at gmail.com>:

On a freshly installed Python 2.6.4, the division / truncates the result to the lower integer as // should.

This occurs on both the current 32 and 64 bits builds.

This is shown in the attached picture.

----------
components: Interpreter Core, Windows
files: python_interpreter.png
messages: 101140
nosy: f_dufour
severity: normal
status: open
title: Divide error on Windows 7 Home Premium 64 bits
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16559/python_interpreter.png

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

From report at bugs.python.org  Tue Mar 16 07:17:32 2010
From: report at bugs.python.org (Frank Rene Schaefer)
Date: Tue, 16 Mar 2010 06:17:32 +0000
Subject: [New-bugs-announce] [issue8153] 'set' union() fails in specific use
	case
In-Reply-To: <1268720252.06.0.0129228714089.issue8153@psf.upfronthosting.co.za>
Message-ID: <1268720252.06.0.0129228714089.issue8153@psf.upfronthosting.co.za>


New submission from Frank Rene Schaefer <fschaef at gmail.com>:

The union operation fails in the following use case

Python 2.6.4 (r264:75706, Jan 30 2010, 22:50:05) 
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on linux2
>>> def func():
...     a = set([0])
...     a.pop()
...     b = set([1, 2])
...     a.union(b)
...     return a
... 
>>> func()
set([])

Note, that is does *not* fail if it is *not* inside a function, i.e.

>>> a = set([0])
>>> a.pop()
0
>>> b = set([1, 2])
>>> a.union(b)
set([1, 2])
>>>

----------
components: Interpreter Core
messages: 101154
nosy: fschaef2
severity: normal
status: open
title: 'set' union() fails in specific use case
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar 16 13:05:43 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Mar 2010 12:05:43 +0000
Subject: [New-bugs-announce] [issue8154] os.execlp('true') crashes the
	interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>


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

calling os.execlp('true') with the wrong number of arguments (missing 2nd arg), the interpreter crashes. fixed in 3.x, this is a backport of the patch to 2.x

----------
components: Extension Modules
files: p.diff
keywords: patch
messages: 101162
nosy: doko
severity: normal
status: open
title: os.execlp('true') crashes the interpreter on 2.x
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16561/p.diff

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

From report at bugs.python.org  Tue Mar 16 13:45:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Mar 2010 12:45:39 +0000
Subject: [New-bugs-announce] [issue8155] Incompoatible change to
	test.test_support.check_warnings	behaviour
In-Reply-To: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>
Message-ID: <1268743539.11.0.544873836546.issue8155@psf.upfronthosting.co.za>


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

A bug report for the incompatibility I was trying to explain on the checkins list. The test_support module is the only part of the regression test suite that is officially documented, so we can't go changing behaviour that is visible to third parties at will.

Python 2.6.5rc2 (release26-maint:78987, Mar 16 2010, 19:48:42)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from test.test_support import check_warnings
>>> with check_warnings():
...   pass
...
>>>

Python 2.7a4+ (trunk:78987, Mar 16 2010, 19:48:39)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from test.test_support import check_warnings
>>> with check_warnings():
...   pass
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/home/ncoghlan/devel/python/Lib/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/home/ncoghlan/devel/python/Lib/test/test_support.py", line 568, in _filterwarnings
    missing[0])
AssertionError: filter ('', Warning) did not catch any warning
>>>

Third party test suites may want to use check_warnings() for both 2.6 and 2.7 and this change makes it unnecessarily difficult for them to do so.

Fixing this should just be a matter of flipping the default value of the new "quiet" parameter to True and updating the tests and documentation accordingly.

----------
assignee: flox
messages: 101164
nosy: flox, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Incompoatible change to test.test_support.check_warnings behaviour
type: behavior

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

From report at bugs.python.org  Tue Mar 16 14:12:24 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 16 Mar 2010 13:12:24 +0000
Subject: [New-bugs-announce] [issue8156] pybsddb 4.8.3+ integration
In-Reply-To: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>
Message-ID: <1268745144.38.0.358803942523.issue8156@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

This issue tracks the progress of integration of pybsddb 4.8.3+ and centralize related discussion.

I have integrated all bsddb related patches until r78988, in pybsddb 4.8.3+, with the following caveats:

- The new code supports BDB 4.8, but drops support for 4.0. Berkeley DB 4.0 was released in 2001...

- Revert issue6949 (the 2.7 part). This integration work supercedes it.

- issue6462 is not integrated in pybsddb, but will be retained in the code integrated in python. I will try to resolve it in a permanent way after integration.

- issue3892 is not integrated in pybsddb, but will be retained in the code integrated in python. I will try to resolve it in a permanent way after integration.

- issue7975: I can't reproduce this bug with current pybsddb version. I will keep the patch around, but first integration test will not include it, unless we still can reproduce.

Some changes in bsddb testsuite require 2.7/3.2. I have decided to keep the changes, so I have to backport some code and use conditional execution, because I must support python 2.3-2.7 and 3.0-3.2.

----------
assignee: jcea
components: Extension Modules
messages: 101166
nosy: jcea
severity: normal
stage: patch review
status: open
title: pybsddb 4.8.3+ integration
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 16 15:58:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_Duc=C3=A1r?=)
Date: Tue, 16 Mar 2010 14:58:59 +0000
Subject: [New-bugs-announce] [issue8157] test_doctest.py fails with
	unexpected results in	doctest.testfile
In-Reply-To: <1268751539.87.0.456644234876.issue8157@psf.upfronthosting.co.za>
Message-ID: <1268751539.87.0.456644234876.issue8157@psf.upfronthosting.co.za>


New submission from Martin Duc?r <ducarm1 at gmail.com>:

During python regrtest.py i have found that doctest test module does not count with expected output when using testfile test_doctest.txt. Example output of the test:
---------------------------------------------------------------------
File "/usr/lib/python2.6/test/test_doctest.py", line 2146, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt') # doctest: +ELLIPSIS
Expected:
    **********************************************************************
    File "...", line 6, in test_doctest.txt
    Failed example:
        favorite_color
    Exception raised:
        ...
        NameError: name 'favorite_color' is not defined
    **********************************************************************
    1 items had failures:
       1 of   2 in test_doctest.txt
    ***Test Failed*** 1 failures.
    TestResults(failed=1, attempted=2)
Got:
    Trying:
        favorite_color
    Expecting:
        'blue'
    **********************************************************************
    File "/usr/lib/python2.6/test/test_doctest.txt", line 6, in test_doctest.txt
    Failed example:
        favorite_color
    Exception raised:
        Traceback (most recent call last):
          File "/usr/lib/python2.6/doctest.py", line 1241, in __run
            compileflags, 1) in test.globs
          File "<doctest test_doctest.txt[0]>", line 1, in <module>
            favorite_color
        NameError: name 'favorite_color' is not defined
    Trying:
        if 1:
           print 'a'
           print
           print 'b'
    Expecting:
        a
        <BLANKLINE>
        b
    ok
    **********************************************************************
    1 items had failures:
       1 of   2 in test_doctest.txt
    2 tests in 1 items.
    1 passed and 1 failed.
    ***Test Failed*** 1 failures.
    TestResults(failed=1, attempted=2)
---------------------------------------------------------------------
There are two test cases  in that file and it count's only with the output of the one, another similar failed testcases from test_doctest.py are:
---------------------------------------------------------------------
File "/usr/lib/python2.6/test/test_doctest.py", line 2168, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', globs=globs)
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2173, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', globs=globs,
                     extraglobs=extraglobs) # doctest: +ELLIPSIS
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2193, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', globs=globs,
                     module_relative='test')
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2227, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', name='newname')
    # doctest: +ELLIPSIS
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2238, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest.txt', report=False)
    # doctest: +ELLIPSIS
...
File "/usr/lib/python2.6/test/test_doctest.py", line 2264, in test.test_doctest.test_testfile
Failed example:
    doctest.testfile('test_doctest4.txt') # doctest: +ELLIPSIS
---------------------------------------------------------------------



---------------------------------------------------------------------
# cat /usr/lib/python2.6/test/test_doctest.py
This is a sample doctest in a text file.

In this example, we'll rely on a global variable being set for us
already:

  >>> favorite_color
  'blue'

We can make this fail by disabling the blank-line feature.

  >>> if 1:
  ...    print 'a'
  ...    print
  ...    print 'b'
  a
  <BLANKLINE>
  b
---------------------------------------------------------------------

This fails on python version 2.6.4. OS tried Arch linux and OpenSolaris, failed on both the same way. Full log in attachment

Testsuite run with -v argument:
# python2.6 /usr/lib/python2.6/test/test_doctest.py -v

----------
components: Library (Lib)
files: python26_test_doctest.log
messages: 101170
nosy: Martin.Duc?r
severity: normal
status: open
title: test_doctest.py fails with unexpected results in doctest.testfile
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16562/python26_test_doctest.log

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

From report at bugs.python.org  Tue Mar 16 19:21:07 2010
From: report at bugs.python.org (Simon Anders)
Date: Tue, 16 Mar 2010 18:21:07 +0000
Subject: [New-bugs-announce] [issue8158] documentation of 'optparse' module
	incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>


New submission from Simon Anders <anders at embl.de>:

The class optparse.OptionParser supports a number of useful keyword arguments to the initializer, which are not documented in the Python Standard Library documentation, here: http://docs.python.org/library/optparse.html

This is a bit unfortunate. For example, I wanted to add a description to the top of my script's help page and a copyright notice to the foot, and was already about to subclass OptionParser in order to override the format_help method, when I noticed that optional keyword arguments 'description' and 'epilog' are provided for precisely this purpose.

The 'epilog' attribute is at least mentioned in the class's docstring, while the 'description' argument is completely undocumented. I doubt that this was done on purpose.

I'd suggest to go over the documentation page for optparse and fill in the missing bits; at minimum, list all keyword arguments to optparse.OptionParser.__init__.

----------
assignee: georg.brandl
components: Documentation
messages: 101177
nosy: georg.brandl, sanders
severity: normal
status: open
title: documentation of 'optparse' module incomplete
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar 16 22:41:26 2010
From: report at bugs.python.org (Razan Abbass)
Date: Tue, 16 Mar 2010 21:41:26 +0000
Subject: [New-bugs-announce] [issue8159] a11
In-Reply-To: <1268775686.35.0.567013843263.issue8159@psf.upfronthosting.co.za>
Message-ID: <1268775686.35.0.567013843263.issue8159@psf.upfronthosting.co.za>


New submission from Razan Abbass <raz71abb6 at yahoo.ca>:

a11

----------
components: None
messages: 101194
nosy: raz71abb6
severity: normal
status: open
title: a11
type: feature request

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

From report at bugs.python.org  Tue Mar 16 23:38:30 2010
From: report at bugs.python.org (tejas)
Date: Tue, 16 Mar 2010 22:38:30 +0000
Subject: [New-bugs-announce] [issue8160] platform.platform() throws
	exception on modified debian	distribution
In-Reply-To: <1268779110.34.0.121667690396.issue8160@psf.upfronthosting.co.za>
Message-ID: <1268779110.34.0.121667690396.issue8160@psf.upfronthosting.co.za>


New submission from tejas <tejas81 at gmail.com>:

I am calling platform.linux_distribution() and platform.platform() on a modified Debian distribution with Python 2.6.
FWIW the file /etc/debian_version exists on this machine, but is empty.

On calling platform.platform(), it seems to try to read the linux version from /etc/debian_version, but crashes with the following exception:

Python 2.6 (r26:66714, Mar  4 2010, 13:02:59)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.platform()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/platform.py", line 1524, in platform
    distname,distversion,distid = dist('')
  File "/usr/local/lib/python2.6/platform.py", line 361, in dist
    full_distribution_name=0)
  File "/usr/local/lib/python2.6/platform.py", line 333, in linux_distribution
    _distname, _version, _id = _parse_release_file(firstline)
  File "/usr/local/lib/python2.6/platform.py", line 269, in _parse_release_file
    return '', version, id
UnboundLocalError: local variable 'version' referenced before assignment

----------
components: Library (Lib)
messages: 101198
nosy: tejas81
severity: normal
status: open
title: platform.platform() throws exception on modified debian distribution
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 17 10:09:47 2010
From: report at bugs.python.org (Jackson Yang)
Date: Wed, 17 Mar 2010 09:09:47 +0000
Subject: [New-bugs-announce] [issue8161] inconsistency behavior in
	ctypes.c_char_p dereferencing
In-Reply-To: <1268816987.2.0.0650705594073.issue8161@psf.upfronthosting.co.za>
Message-ID: <1268816987.2.0.0650705594073.issue8161@psf.upfronthosting.co.za>


New submission from Jackson Yang <jackson.yang at augmentum.com>:

# Python 3.1.2rc1 (r312rc1:78742, Mar  7 2010, 07:49:40)
# [MSC v.1500 32 bit (Intel)] on win32
import ctypes

class T(ctypes.Structure):
	_fields_ = (
		('member', ctypes.c_char * 16),
	)

# dereference a c_char_Array variable would return <bytes>
print('%r'%((ctypes.c_char * 16)()[:]))
# dereference from a c_char_Array member would return <str>, which is buggy
print('%r'%(T().member[:]))

----------
assignee: theller
components: ctypes
messages: 101214
nosy: nullnil, theller
severity: normal
status: open
title: inconsistency behavior in ctypes.c_char_p dereferencing
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Mar 17 11:06:36 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 17 Mar 2010 10:06:36 +0000
Subject: [New-bugs-announce] [issue8162] logging.disable() incoherency
In-Reply-To: <1268820396.69.0.459147398559.issue8162@psf.upfronthosting.co.za>
Message-ID: <1268820396.69.0.459147398559.issue8162@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

I see some trouble in the semantic of logging.disable(lvl) :
according to the doc (and docstrings), it's the same as a logger.setLevel(lvl) called on all logger, but in reality it doesn't act the same way : when we call logger.setLevel(lvl), log messages at level lvl WILL be logged, whereas with logger.disable(lvl), they will NOT be logged (CF method below from logging/__init__.py).

So maybe the best would be to explain that disable() also disable the target level itself, and to set by default this disabling level to -1 (and not 0 as currently), so that by default ALL messages get loged, even those set to level 0.

    def isEnabledFor(self, level):
        """
        Is this logger enabled for level 'level'?
        """
        if self.manager.disable >= level:
            return 0
        return level >= self.getEffectiveLevel()

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 101215
nosy: georg.brandl, pakal
severity: normal
status: open
title: logging.disable() incoherency
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Mar 17 11:22:49 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 17 Mar 2010 10:22:49 +0000
Subject: [New-bugs-announce] [issue8163] DictionaryServices module broken in
	python2.6 and later
In-Reply-To: <1268821369.91.0.141988307064.issue8163@psf.upfronthosting.co.za>
Message-ID: <1268821369.91.0.141988307064.issue8163@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

I am able to call DictionaryServices module from python2.5 and later. However it works correctly only on python2.5. Below is the stack-trace on using DictionaryServices on python2.5, python2.6 and python2.7

Shashwat-Anands-MacBook-Pro:PyObjCTest l0nwlf$ python2.5
Python 2.5.4 (r254:67916, Jul  7 2009, 23:51:24) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import DictionaryServices
>>> word = "lone wolf"
>>> DictionaryServices.DCSCopyTextDefinition(None, word, (0, len(word))) 
u'noun \na person who prefers to act or be alone. \n'
>>> 

Shashwat-Anands-MacBook-Pro:Desktop l0nwlf$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import DictionaryServices
>>> word = "lone wolf"
>>> DictionaryServices.DCSCopyTextDefinition(None, word, (0, len(word)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: NSRangeException - *** -[OC_PythonString _createSubstringWithRange:]: Range or index out of bounds
>>> 

Shashwat-Anands-MacBook-Pro:Desktop l0nwlf$ python2.7
Python 2.7a4+ (trunk:78750, Mar  7 2010, 08:09:00) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import DictionaryServices
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named DictionaryServices

----------
assignee: ronaldoussoren
components: Macintosh
messages: 101216
nosy: l0nwlf, ronaldoussoren
severity: normal
status: open
title: DictionaryServices module broken in python2.6 and later
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 17 17:28:32 2010
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 17 Mar 2010 16:28:32 +0000
Subject: [New-bugs-announce] [issue8164] (lambda:"foo").func_doc
In-Reply-To: <1268843312.05.0.864222300962.issue8164@psf.upfronthosting.co.za>
Message-ID: <1268843312.05.0.864222300962.issue8164@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

Lambdas are a bit confused about their docstrings.  Usually they don't have any, but:

    >>> (lambda x: "foo"+x).func_doc

    'foo'

----------
keywords: easy
messages: 101233
nosy: arigo
priority: low
severity: normal
status: open
title: (lambda:"foo").func_doc
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 17 20:58:12 2010
From: report at bugs.python.org (Eli Courtwright)
Date: Wed, 17 Mar 2010 19:58:12 +0000
Subject: [New-bugs-announce] [issue8165]
	logging.handlers.RotatingFileHandler fails when
	delay	parameter is set to True
In-Reply-To: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>
Message-ID: <1268855892.12.0.046452887236.issue8165@psf.upfronthosting.co.za>


New submission from Eli Courtwright <eli.courtwright at gmail.com>:

Here's a summary of the issue (also presented at http://stackoverflow.com/questions/2465073)

When I run the following code

{{{
import logging
from logging.handlers import RotatingFileHandler

rfh = RotatingFileHandler("testing.log", delay=True)
logging.getLogger().addHandler(rfh)
logging.warning("Boo!")
}}}

then the last line throws "AttributeError: RotatingFileHandler instance has no attribute 'level'".  So I add the line

{{{
rfh.setLevel(logging.DEBUG)
}}}

before the call to addHandler, and then the last line throws "AttributeError: RotatingFileHandler instance has no attribute 'filters'". So if I manually set filters to be an empty list, then it complains about not having the attribute "lock", etc.

When I remove the delay=True, the problem completely goes away.

So one of the parent __init__ methods somewhere up the class hierarchy isn't getting called when delay is set. Examining the source code to the file logging/__init__.py, I see the following code in the FileHandler.__init__ method:

{{{
if delay:
    self.stream = None
else:
    stream = self._open()
    StreamHandler.__init__(self, stream)
}}}

It looks like the FileHandler.emit method checks for un-opened streams and finishes initialization when logging is performed:

{{{
if self.stream is None:
    stream = self._open()
    StreamHandler.__init__(self, stream)
StreamHandler.emit(self, record)
}}}

So the problem is that in the BaseRotatingHandler.emit method, the shouldRollover and doRollover methods are called before emit-ing the record. This causes methods to be called which themselves assumed that the __init__ process has completed.

Unfortunately, I don't have time right now to submit a patch, though I might be able to find the time within the next few months if no one else gets to it first.  Hopefully this report is detailed enough to easily convey the problem.

----------
components: Library (Lib)
messages: 101242
nosy: Eli.Courtwright
severity: normal
status: open
title: logging.handlers.RotatingFileHandler fails when delay parameter is set to True
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 18 04:53:17 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 03:53:17 +0000
Subject: [New-bugs-announce] [issue8166] hashlib constructors for sha224,
	sha256, sha384, sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
In-Reply-To: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>
Message-ID: <1268884397.35.0.917803379563.issue8166@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

3.1.2 Release Blocker

If Python 3.1.2rc1 is built with openssl 0.9.7 (which lacks support for sha256 and sha512), hashlib is supposed to substitute use of built-in C implementations for them.  With 3.1.2rc1, the "built-in" versions are available via hashlib.new() but not by their "always available" constructor functions.  This causes major test failures in test_hashlib, test_hmac, and test_pep247.  The problem is critical for OS X installer builds because both OS X 10.4 and 10.5 ship with openssl 0.9.7 but the problem should show up on other platforms using 0.9.7 as well.

The following comparison between 2.6.5rc2 and 3.1.2rc1 demonstrates the problem:

Python 2.6.5rc2 (release26-maint, Mar 15 2010, 00:15:31) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.new('sha1')
<sha1 HASH object @ 0xd0560>
>>> hashlib.sha1()
<sha1 HASH object @ 0xd04c0>
>>> hashlib.new('sha512')
<_sha512.sha512 object at 0x6b3a0>
>>> hashlib.sha512()
<_sha512.sha512 object at 0x6b480>
>>> dir(hashlib)
['__builtins__', '__doc__', '__file__', '__get_builtin_constructor', '__hash_new', '__name__', '__package__', '__py_new', '_hashlib', 'md5', 'new', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512']
>>> dir(_hashlib)
['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1', 'openssl_sha224', 'openssl_sha256', 'openssl_sha384', 'openssl_sha512']
 
Python 3.1.2rc1+ (release31-maint, Mar 17 2010, 12:38:35) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.new('sha1')
<sha1 HASH object @ 0x11d740>
>>> hashlib.sha1()
<sha1 HASH object @ 0x11da20>
>>> hashlib.new('sha512')
<_sha512.sha512 object at 0x9d640>
>>> hashlib.sha512()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'sha512'
>>> dir(hashlib)
['__builtins__', '__doc__', '__file__', '__get_builtin_constructor', '__hash_new', '__name__', '__package__', '__py_new', '_hashlib', 'md5', 'new', 'sha1']
>>> dir(_hashlib)
['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1']

It appears the cause of the problem was a mismatch of merges to 3.1.  In response to Issue6281, some major cleanup to hashlib.py went into trunk in r74479 and py3k in r74482 but was not backported to 2.6 or 3.1.  Later, r77608 to trunk added some conditional compilation tests in _hashopenssl.c based on openssl version, which was fine on top of the hashlib.py cleanup.  Still later, r77408 was auto-merged to py3k in r77937 (OK) *and* 3.1 in r77938 which is NOT OK, because the old hashlib.py in (3.1 and 2.6) indirectly depends on all of the openssl_* names being defined in _hashlib.

Probably the best solution for 3.1 at this point is to revert the conditional tests in _hashopenssl.c.

----------
messages: 101251
nosy: benjamin.peterson, gregory.p.smith, ned.deily, ronaldoussoren
severity: normal
status: open
title: hashlib constructors for sha224, sha256, sha384, sha512 missing in Python 3.1.2rc1 with openssl 0.9.7
versions: Python 3.1

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

From report at bugs.python.org  Thu Mar 18 11:20:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 10:20:18 +0000
Subject: [New-bugs-announce] [issue8167] test_tk, test_ttk_guionly,
	and test_ttk_textonly crash when run from install directory
In-Reply-To: <1268907618.55.0.5671075009.issue8167@psf.upfronthosting.co.za>
Message-ID: <1268907618.55.0.5671075009.issue8167@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When installation tests are run on a user system using the OS X installer, the three tests fail with a crash.  Similar results would be expected on other unix-y platforms when tests are run from the install destination, and not the source or build directories (which do not exist on user systems using installers). On 3.1.2rc1 and py3k, each crashes on an import error:

  test test_{tk,ttk_guionly,ttk_textonly} crashed -- <class 'ImportError'>: No module named test

On trunk (2.7), they crash with;
  test test_{tk,ttk_guionly,ttk_textonly} crashed -- <type 'exceptions.ImportError'>: No module named runtktests

The problem is that the test subdirectories are not being installed by the libinstall Makefile target.  For 3.1.2rc1 and py3k, adding the directories to LIBSUBDIRS should get them installed:
  LIBSUBDIRS= tkinter site-packages test test/output test/data \
    tkinter/test tkinter/test/test_tkinter tkinter/test/test_ttk \
    test/decimaltestdata \ {...}
(Trunk is slightly different.)

----------
components: Tests
messages: 101256
nosy: benjamin.peterson, gpolo, ned.deily
severity: normal
status: open
title: test_tk, test_ttk_guionly, and test_ttk_textonly crash when run from install directory
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Mar 18 11:43:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 10:43:01 +0000
Subject: [New-bugs-announce] [issue8168] python3 py_compile does not ignore
	UTF-8 BOM characters
In-Reply-To: <1268908981.24.0.215404983461.issue8168@psf.upfronthosting.co.za>
Message-ID: <1268908981.24.0.215404983461.issue8168@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

$ cat bom3.py
# coding: utf-8
print("BOM BOOM!")
$ file bom3.py 
bom3.py: UTF-8 Unicode (with BOM) text
$ python3.1
Python 3.1.1+ (r311:74480, Jan 20 2010, 00:37:31) 
[GCC 4.4.3 20100108 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bom3
BOM BOOM!
>>> import py_compile
>>> py_compile.compile("bom3.py")
  File "bom3.py", line 1
    ?# coding: utf-8
      ^
SyntaxError: invalid character in identifier

The same test does not fail with python2.6.4.
(Same results on OS X.)

----------
components: Library (Lib)
messages: 101257
nosy: ned.deily
severity: normal
status: open
title: python3 py_compile does not ignore UTF-8 BOM characters
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Mar 18 12:06:08 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Mar 2010 11:06:08 +0000
Subject: [New-bugs-announce] [issue8169] SyntaxError messages during install
	due to compilation of	lib2to3 test files
In-Reply-To: <1268910368.04.0.809949676665.issue8169@psf.upfronthosting.co.za>
Message-ID: <1268910368.04.0.809949676665.issue8169@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

On Python 3.1.2rc1 and py3k, "make install" results in two identical spurious error messages:

Compiling /path/to/lib/python3.1/lib2to3/tests/data/bom.py ...
***   File "/usr/local/lib/python3.1/lib2to3/tests/data/bom.py", line 1
    ?# coding: utf-8
      ^
SyntaxError: invalid character in identifier

The messages are triggered by the libinstall Makefile which calls compileall twice to generate .pyc and .pyo files for all modules in the installed library.  compileall uses py_compile which, due to the problem documented in Issue8168, stumbles over the lib2to3 data file bom.py.  While fixing that issue would make this problem go away, it seems like it would be better to avoid compiling the lib2to3 test files altogether.  Modifying the '-x" regexp on the two relevant calls to compileall in Makefile.pre.in accomplishes this:

-x 'bad_coding|badsyntax|site-packages|py2_test_grammar|crlf|different_encoding|lib2to3/tests' \

A similar change should be considered for trunk and 2.6 as well.

----------
components: Installation
messages: 101258
nosy: benjamin.peterson, ned.deily
severity: normal
status: open
title: SyntaxError messages during install due to compilation of lib2to3 test files
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Mar 18 12:55:33 2010
From: report at bugs.python.org (Robin Becker)
Date: Thu, 18 Mar 2010 11:55:33 +0000
Subject: [New-bugs-announce] [issue8170] Wrong Paths for distutils build
	--plat-name=win-amd64
In-Reply-To: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>
Message-ID: <1268913333.33.0.305416760988.issue8170@psf.upfronthosting.co.za>


New submission from Robin Becker <rgbecker at users.sourceforge.net>:

When building extensions on win32 distutils with --plat-name=win-amd64 adds PCBuild/AMD64 in the wrong place.

This patch ensures the AMD64 location comes first

----------
assignee: tarek
components: Distutils
files: patch.txt
messages: 101259
nosy: rgbecker, tarek
severity: normal
status: open
title: Wrong Paths for distutils build --plat-name=win-amd64
versions: Python 2.6
Added file: http://bugs.python.org/file16574/patch.txt

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

From report at bugs.python.org  Thu Mar 18 13:05:11 2010
From: report at bugs.python.org (Robin Becker)
Date: Thu, 18 Mar 2010 12:05:11 +0000
Subject: [New-bugs-announce] [issue8171] bdist_wininst builds wrongly for
	--plat-name=win-amd64
In-Reply-To: <1268913911.34.0.452575740724.issue8171@psf.upfronthosting.co.za>
Message-ID: <1268913911.34.0.452575740724.issue8171@psf.upfronthosting.co.za>


New submission from Robin Becker <rgbecker at users.sourceforge.net>:

I notice this from win32 setup.py bdist_wininst --plat-name=win-amd64

> running bdist_wininst
> running build
> running build_py
> creating build
> creating build\lib.win32-2.6
> creating build\lib.win32-2.6\reportlab
> copying src\reportlab\rl_config.py -> build\lib.win32-2.6\reportlab
......
> C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nolog

followed by errors related to a missing library (the amd64 version won't work with a win32 build).

I do have the x86_amd64 stuff installed and after applying a patch to fix another small cross compile error I do see a proper build ie

setup.py build --plat-name=win-amd64

and then use

setup.py bdist_wininst --plat-name=win-amd64 --skip-build 

does work. I believe that bdist_wininst is wrongly relying on build to get the right plat_name, but that isn't happening.

The attached patch seems to make things work for me by forcing plat_name down from the top

----------
assignee: tarek
components: Distutils
files: patch.txt
messages: 101260
nosy: rgbecker, tarek
severity: normal
status: open
title: bdist_wininst builds wrongly for --plat-name=win-amd64
versions: Python 2.6
Added file: http://bugs.python.org/file16575/patch.txt

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

From report at bugs.python.org  Thu Mar 18 15:24:35 2010
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 18 Mar 2010 14:24:35 +0000
Subject: [New-bugs-announce] [issue8172] Documentation of Property needs
	example
In-Reply-To: <1268922275.96.0.934351255031.issue8172@psf.upfronthosting.co.za>
Message-ID: <1268922275.96.0.934351255031.issue8172@psf.upfronthosting.co.za>


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

Strangely, the extensive documentation of the property function in the "Built-in Functions" of the documentation has no example of the use of a property. Readers unfamiliar with properties should be told that obj.x invokes the getter, obj.x=value the setter, etc. The lack of parentheses is particularly significant.

----------
assignee: georg.brandl
components: Documentation
messages: 101262
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of Property needs example
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Mar 18 22:49:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Mar 2010 21:49:23 +0000
Subject: [New-bugs-announce] [issue8173] test_subprocess leaks
In-Reply-To: <1268948963.68.0.181763006181.issue8173@psf.upfronthosting.co.za>
Message-ID: <1268948963.68.0.181763006181.issue8173@psf.upfronthosting.co.za>


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

test_subprocess has been leaking since the recent changes in py3k:

test_subprocess leaked [2, 2] references, sum=4

----------
assignee: gregory.p.smith
components: Library (Lib), Tests
messages: 101286
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_subprocess leaks
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Fri Mar 19 02:57:36 2010
From: report at bugs.python.org (George Sakkis)
Date: Fri, 19 Mar 2010 01:57:36 +0000
Subject: [New-bugs-announce] [issue8174] Misleading reported number of given
	arguments on function	call TypeError
In-Reply-To: <1268963856.62.0.386330521193.issue8174@psf.upfronthosting.co.za>
Message-ID: <1268963856.62.0.386330521193.issue8174@psf.upfronthosting.co.za>


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

The following exception message seems misleading, or at least not obvious:

>>> def f(a,b,c): pass
... 
>>> f(c=0,a=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes exactly 3 non-keyword arguments (1 given)

Why "1 given" ? One could argue for either 0 or 2 given arguments but I fail to see how 1 is a reasonable answer.

----------
components: Interpreter Core
messages: 101298
nosy: gsakkis
severity: normal
status: open
title: Misleading reported number of given arguments on function call TypeError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 19 11:10:20 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Mar 2010 10:10:20 +0000
Subject: [New-bugs-announce] [issue8175] 2.6.5 OS X 10.5
	--with-universal-archs=all (4-way) fails	building pythonw-64
In-Reply-To: <1268993420.16.0.372615905731.issue8175@psf.upfronthosting.co.za>
Message-ID: <1268993420.16.0.372615905731.issue8175@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

A change made to Mac/Makefile in r78813 for 2.6.5 does not work correctly
when the --with-universal-archs=all (4-way) framework configure option is selected.  The build of pythonw-64 fails with an incorrect gcc command: "gcc-4.0   64 -arch x86_64".  The attached patch corrects the problem.

Note, as documented in the 2.6.5 Mac/README file, the "all" variant can currently only be built on OS X 10.5.
         
Run autoconf after applying to update configure.

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: issue-universal-archs-all-26.txt
messages: 101318
nosy: barry, ned.deily, ronaldoussoren
severity: normal
status: open
title: 2.6.5 OS X 10.5 --with-universal-archs=all (4-way) fails building pythonw-64
versions: Python 2.6
Added file: http://bugs.python.org/file16583/issue-universal-archs-all-26.txt

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

From report at bugs.python.org  Fri Mar 19 11:41:08 2010
From: report at bugs.python.org (Carlos Ribeiro)
Date: Fri, 19 Mar 2010 10:41:08 +0000
Subject: [New-bugs-announce] [issue8176] Interpreter crash with "double free
	or corruption" message
In-Reply-To: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>
Message-ID: <1268995268.42.0.577572952388.issue8176@psf.upfronthosting.co.za>


New submission from Carlos Ribeiro <carribeiro at gmail.com>:

I was running Django in development mode (python manage.py runserver 0.0.0.0:8002). I saved a python source file; Django automatically detected the change and reloaded the module (that's the usual behavior). Then a backtrace from glibc appeared in the middle of the log. Django web server kept running, so I assume that the bug hit a separate thread. I also assume that this is a Python bug due to the nature of the trace (came from glibc). That's all information that I have.

---- python version ----
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

---- trace ----
Django version 1.1.1, using settings 'camg.settings'
Development server is running at http://0.0.0.0:8002/
Quit the server with CONTROL-C.
[18/Mar/2010 22:50:23] "GET / HTTP/1.1" 200 27012
[18/Mar/2010 22:50:23] "GET /static/css/camg.css HTTP/1.1" 304 0
[18/Mar/2010 22:50:23] "GET /static/images/consorciomg.png HTTP/1.1" 304 0
[18/Mar/2010 22:52:01] "GET /andar/SEC1-3/ HTTP/1.1" 200 6441
[18/Mar/2010 22:52:06] "GET /switch/SEC1-3-3A-SA01/ HTTP/1.1" 200 6546
[18/Mar/2010 22:52:11] "GET /sala/3/ HTTP/1.1" 500 69619
[18/Mar/2010 22:52:13] "GET /switch/SEC1-3-3A-SA01/ HTTP/1.1" 200 6546
*** glibc detected *** /usr/bin/python: double free or corruption (out): 0xb7651b80 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0x17aff1]
/lib/tls/i686/cmov/libc.so.6[0x17c6f2]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x17f7cd]
/usr/bin/python[0x80b9ceb]
/usr/bin/python[0x808e622]
/usr/bin/python[0x808e634]
/usr/bin/python[0x806a42b]
/usr/bin/python[0x808e634]
/usr/bin/python[0x808cf19]
/usr/bin/python(PyDict_SetItem+0x87)[0x808f377]
/usr/bin/python(_PyModule_Clear+0x99)[0x8090c49]
/usr/bin/python(PyImport_Cleanup+0x459)[0x80edaf9]
/usr/bin/python(Py_Finalize+0xa5)[0x80fa305]
/usr/bin/python[0x80f9daf]
/usr/bin/python(PyErr_PrintEx+0x18d)[0x80f9f9d]
/usr/bin/python(PyErr_Print+0x12)[0x80fa1d2]
/usr/bin/python(PyRun_SimpleFileExFlags+0x1ab)[0x80facfb]
/usr/bin/python(Py_Main+0xaa8)[0x805c8d8]
/usr/bin/python(main+0x1b)[0x805baeb]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x126b56]
/usr/bin/python[0x805ba31]
======= Memory map: ========
00110000-0024e000 r-xp 00000000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
0024e000-0024f000 ---p 0013e000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
0024f000-00251000 r--p 0013e000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
00251000-00252000 rw-p 00140000 08:01 553        /lib/tls/i686/cmov/libc-2.10.1.so
00252000-00255000 rw-p 00000000 00:00 0 
00255000-00382000 r-xp 00000000 08:01 3085       /lib/i686/cmov/libcrypto.so.0.9.8
00382000-0038a000 r--p 0012c000 08:01 3085       /lib/i686/cmov/libcrypto.so.0.9.8
0038a000-00397000 rw-p 00134000 08:01 3085       /lib/i686/cmov/libcrypto.so.0.9.8
00397000-0039b000 rw-p 00000000 00:00 0 
0039b000-003bc000 r-xp 00000000 08:01 1749       /usr/lib/libpq.so.5.2
003bc000-003bd000 r--p 00020000 08:01 1749       /usr/lib/libpq.so.5.2
003bd000-003be000 rw-p 00021000 08:01 1749       /usr/lib/libpq.so.5.2
003be000-003c0000 r-xp 00000000 08:01 560        /lib/libcom_err.so.2.1
003c0000-003c1000 r--p 00001000 08:01 560        /lib/libcom_err.so.2.1
003c1000-003c2000 rw-p 00002000 08:01 560        /lib/libcom_err.so.2.1
003c2000-003e8000 r-xp 00000000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003e8000-003e9000 ---p 00026000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003e9000-003ea000 r--p 00026000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003ea000-003eb000 rw-p 00027000 08:01 1307       /usr/lib/libk5crypto.so.3.1
003eb000-003f1000 r-xp 00000000 08:01 914        /usr/lib/libkrb5support.so.0.1
003f1000-003f2000 r--p 00005000 08:01 914        /usr/lib/libkrb5support.so.0.1
003f2000-003f3000 rw-p 00006000 08:01 914        /usr/lib/libkrb5support.so.0.1
003f3000-00400000 r-xp 00000000 08:01 4464       /usr/lib/liblber-2.4.so.2.5.1
00400000-00401000 r--p 0000c000 08:01 4464       /usr/lib/liblber-2.4.so.2.5.1
00401000-00402000 rw-p 0000d000 08:01 4464       /usr/lib/liblber-2.4.so.2.5.1
00402000-0041a000 r-xp 00000000 08:01 4704       /usr/lib/libsasl2.so.2.0.23
0041a000-0041b000 r--p 00017000 08:01 4704       /usr/lib/libsasl2.so.2.0.23
0041b000-0041c000 rw-p 00018000 08:01 4704       /usr/lib/libsasl2.so.2.0.23
0041c000-004bf000 r-xp 00000000 08:01 4258       /usr/lib/libgnutls.so.26.14.10
004bf000-004c3000 r--p 000a2000 08:01 4258       /usr/lib/libgnutls.so.26.14.10
004c3000-004c4000 rw-p 000a6000 08:01 4258       /usr/lib/libgnutls.so.26.14.10
004c4000-004d0000 r-xp 00000000 08:01 328860     /usr/lib/python2.6/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
004d0000-004d1000 r--p 0000b000 08:01 328860     /usr/lib/python2.6/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
004d1000-004d2000 rw-p 0000c000 08:01 328860     /usr/lib/python2.6/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
004d2000-004e5000 r-xp 00000000 08:01 606        /lib/tls/i686/cmov/libnsl-2.10.1.so
004e5000-004e6000 r--p 00012000 08:01 606        /lib/tls/i686/cmov/libnsl-2.10.1.so
004e6000-004e7000 rw-p 00013000 08:01 606        /lib/tls/i686/cmov/libnsl-2.10.1.so
004e7000-004e9000 rw-p 00000000 00:00 0 
004e9000-004f2000 r-xp 00000000 08:01 632        /lib/tls/i686/cmov/libnss_nis-2.10.1.so
004f2000-004f3000 r--p 00008000 08:01 632        /lib/tls/i686/cmov/libnss_nis-2.10.1.so
004f3000-004f4000 rw-p 00009000 08:01 632        /lib/tls/i686/cmov/libnss_nis-2.10.1.so
004f9000-0053a000 r-xp 00000000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053a000-0053b000 ---p 00041000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053b000-0053c000 r--p 00041000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053c000-0053f000 rw-p 00042000 08:01 3086       /lib/i686/cmov/libssl.so.0.9.8
0053f000-005b8000 r-xp 00000000 08:01 581        /lib/libgcrypt.so.11.5.2
005b8000-005b9000 r--p 00078000 08:01 581        /lib/libgcrypt.so.11.5.2
005b9000-005bb000 rw-p 00079000 08:01 581        /lib/libgcrypt.so.11.5.2
005bb000-005d7000 r-xp 00000000 08:01 3077       /lib/libgcc_s.so.1
005d7000-005d8000 r--p 0001b000 08:01 3077       /lib/libgcc_s.so.1
005d8000-005d9000 rw-p 0001c000 08:01 3077       /lib/libgcc_s.so.1
005e9000-005ea000 r-xp 00000000 00:00 0          [vdso]
00639000-00642000 r-xp 00000000 08:01 595        /lib/tls/i686/cmov/libcrypt-2.10.1.so
00642000-00643000 r--p 00008000 08:01 595        /lib/tls/i686/cmov/libcrypt-2.10.1.so
00643000-00644000 rw-p 00009000 08:01 595        /lib/tls/i686/cmov/libcrypt-2.10.1.so
00644000-0066b000 rw-p 00000000 00:00 0 
0068e000-00690000 r-xp 00000000 08:01 10509      /lib/tls/i686/cmov/libutil-2.10.1.so
00690000-00691000 r--p 00001000 08:01 10509      /lib/tls/i686/cmov/libutil-2.10.1.so
00691000-00692000 rw-p 00002000 08:01 10509      /lib/tls/i686/cmov/libutil-2.10.1.so
00697000-00699000 r-xp 00000000 08:01 266595     /usr/lib/python2.6/lib-dynload/_hashlib.so
00699000-0069a000 r--p 00001000 08:01 266595     /usr/lib/python2.6/lib-dynload/_hashlib.so
0069a000-0069b000 rw-p 00002000 08:01 266595     /usr/lib/python2.6/lib-dynload/_hashlib.so
00774000-00788000 r-xp 00000000 08:01 681        /lib/libz.so.1.2.3.3
00788000-00789000 r--p 00013000 08:01 681        /lib/libz.so.1.2.3.3
00789000-0078a000 rw-p 00014000 08:01 681        /lib/libz.so.1.2.3.3
00841000-00851000 r-xp 00000000 08:01 658        /lib/tls/i686/cmov/libresolv-2.10.1.so
00851000-00852000 r--p 00010000 08:01 658        /lib/tls/i686/cmov/libresolv-2.10.1.so
00852000-00853000 rw-p 00011000 08:01 658        /lib/tls/i686/cmov/libresolv-2.10.1.so
00853000-00855000 rw-p 00000000 00:00 0 
0089f000-008a1000 r-xp 00000000 08:01 597        /lib/tls/i686/cmov/libdl-2.10.1.so
008a1000-008a2000 r--p 00001000 08:01 597        /lib/tls/i686/cmov/libdl-2.10.1.so
008a2000-008a3000 rw-p 00002000 08:01 597        /lib/tls/i686/cmov/libdl-2.10.1.so
008ea000-00905000 r-xp 00000000 08:01 67         /lib/ld-2.10.1.so
00905000-00906000 r--p 0001a000 08:01 67         /lib/ld-2.10.1.so
00906000-00907000 rw-p 0001b000 08:01 67         /lib/ld-2.10.1.so
00940000-00950000 r-xp 00000000 08:01 4761       /usr/lib/libtasn1.so.3.1.5

----------
components: Interpreter Core
messages: 101320
nosy: Carlos.Ribeiro
severity: normal
status: open
title: Interpreter crash with "double free or corruption" message
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar 19 16:51:20 2010
From: report at bugs.python.org (Ghislain Hivon)
Date: Fri, 19 Mar 2010 15:51:20 +0000
Subject: [New-bugs-announce] [issue8177] Incoherent error with keyword
	argument follow by	unpacking argument lists
In-Reply-To: <1269013880.37.0.355293155822.issue8177@psf.upfronthosting.co.za>
Message-ID: <1269013880.37.0.355293155822.issue8177@psf.upfronthosting.co.za>


New submission from Ghislain Hivon <jahed_g at hotmail.com>:

Take a fonction with a parameter and  *args
def foo(bar, args*)
  pass

then call it like this
myargs = [1, 2, 3, 4, 5]
foo(bar=1, *myargs)

The call produce this error : 
TypeError: foo() got multiple values for keyword argument 'bar'

Sould the error be more like : 
SyntaxError: non-keyword arg after keyword arg

the same error if foo was called like this : 
foo(bar=1, myargs)
or
foo(bar=1, 1, 2, 3, 4, 5)

----------
components: Interpreter Core
messages: 101332
nosy: GhislainHivon
severity: normal
status: open
title: Incoherent error with  keyword argument follow by unpacking argument lists
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Mar 20 00:54:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Mar 2010 23:54:56 +0000
Subject: [New-bugs-announce] [issue8178] test_thread fails on POSIX
In-Reply-To: <1269042896.82.0.574285527551.issue8178@psf.upfronthosting.co.za>
Message-ID: <1269042896.82.0.574285527551.issue8178@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The test fails randomly on POSIX platforms since r78527 (fixing issue #7242).
The failure is in the new TestCase: TestForkInThread.


 $ ./python -m test.regrtest -uall -R :: test_thread
test_thread
beginning 9 repetitions
123456789
Unhandled exception in thread started by <function thread1 at 0x26c3f78>
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 218, in thread1
    os.close(self.write_fd)
OSError: [Errno 9] Bad file descriptor
.Unhandled exception in thread started by <function thread1 at 0x2863ae0>
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 218, in thread1
    os.close(self.write_fd)
OSError: [Errno 9] Bad file descriptor
test test_thread failed -- Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 120, in test__count
    self.assertEquals(thread._count(), orig + 1)
AssertionError: 1 != 2

1 test failed:
    test_thread
Unhandled exception in thread started by 
Error in sys.excepthook:

Original exception was:

----------
components: Library (Lib), Tests
messages: 101350
nosy: flox, gregory.p.smith, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_thread fails on POSIX
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 20 03:53:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 02:53:17 +0000
Subject: [New-bugs-announce] [issue8179] Test failure in test_macpath.py
	test_realpath (Mac OS X)
In-Reply-To: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>
Message-ID: <1269053597.52.0.210703953489.issue8179@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

On Mac OS X 10.6.2


======================================================================
ERROR: test_realpath (__main__.MacCommonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-back/Lib/test/test_genericpath.py", line 213, in test_realpath
    self.assertIn("foo", self.pathmodule.realpath("foo"))
  File "/compile/python-back/Lib/macpath.py", line 209, in realpath
    path = Carbon.File.FSResolveAliasFile(path, 1)[0].as_pathname()
Error: (-43, 'File not found')

----------------------------------------------------------------------
Ran 19 tests in 0.087s

FAILED (errors=1, skipped=1)
Traceback (most recent call last):
  File "Lib/test/test_macpath.py", line 57, in <module>
    test_main()
  File "Lib/test/test_macpath.py", line 53, in test_main
    test_support.run_unittest(MacPathTestCase, MacCommonTest)
  File "/compile/python-back/Lib/test/test_support.py", line 1031, in run_unittest
    _run_suite(suite)
  File "/compile/python-back/Lib/test/test_support.py", line 1014, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/compile/python-back/Lib/test/test_genericpath.py", line 213, in test_realpath
    self.assertIn("foo", self.pathmodule.realpath("foo"))
  File "/compile/python-back/Lib/macpath.py", line 209, in realpath
    path = Carbon.File.FSResolveAliasFile(path, 1)[0].as_pathname()
Error: (-43, 'File not found')

----------
assignee: ronaldoussoren
messages: 101360
nosy: michael.foord, ronaldoussoren
severity: normal
stage: needs patch
status: open
title: Test failure in test_macpath.py test_realpath (Mac OS X)
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 20 03:56:03 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 02:56:03 +0000
Subject: [New-bugs-announce] [issue8180] Unicode File Test failures (PEP 277
	on Mac OS X)
In-Reply-To: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>
Message-ID: <1269053763.29.0.578698651935.issue8180@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

I'm *assuming* this is a Mac OS X issue. (10.6.2)

./python.exe Lib/test/test_pep277.py
test_directory (__main__.UnicodeFileTests) ... ok
test_failures (__main__.UnicodeFileTests) ... ok
test_listdir (__main__.UnicodeFileTests) ... FAIL
test_open (__main__.UnicodeFileTests) ... ok
test_rename (__main__.UnicodeFileTests) ... ok

======================================================================
FAIL: test_listdir (__main__.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 92, in test_listdir
    self.assertEqual(sf2, set(self.files))
AssertionError: Items in the first set but not the second:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03b1\u0301-\u03c3\u03b1\u03c2'
u'@test_969_tmp/Gru\u0308\xdf-Gott'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0438\u0306\u0442\u0435'
u'@test_969_tmp/\u306b\u307b\u309a\u3093'
Items in the second set but not the first:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435'
u'@test_969_tmp/Gr\xfc\xdf-Gott'
u'@test_969_tmp/\u306b\u307d\u3093'

----------------------------------------------------------------------
Ran 5 tests in 0.021s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 120, in <module>
    test_main()
  File "Lib/test/test_pep277.py", line 115, in test_main
    test_support.run_unittest(UnicodeFileTests)
  File "/compile/python-back/Lib/test/test_support.py", line 1031, in run_unittest
    _run_suite(suite)
  File "/compile/python-back/Lib/test/test_support.py", line 1014, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_pep277.py", line 92, in test_listdir
    self.assertEqual(sf2, set(self.files))
AssertionError: Items in the first set but not the second:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03b1\u0301-\u03c3\u03b1\u03c2'
u'@test_969_tmp/Gru\u0308\xdf-Gott'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0438\u0306\u0442\u0435'
u'@test_969_tmp/\u306b\u307b\u309a\u3093'
Items in the second set but not the first:
u'@test_969_tmp/\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2'
u'@test_969_tmp/\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435'
u'@test_969_tmp/Gr\xfc\xdf-Gott'
u'@test_969_tmp/\u306b\u307d\u3093'

----------
assignee: ronaldoussoren
messages: 101361
nosy: michael.foord, ronaldoussoren
severity: normal
status: open
title: Unicode File Test failures (PEP 277 on Mac OS X)

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

From report at bugs.python.org  Sat Mar 20 10:18:54 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 09:18:54 +0000
Subject: [New-bugs-announce] [issue8181] Guenstiger kaufen Sie Software
	nicht!
In-Reply-To: <8471975994.84GBKROP240377@kzjfnunsukjauhs.ahext.com>
Message-ID: <8471975994.84GBKROP240377@kzjfnunsukjauhs.ahext.com>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Kaufen Sie nur beste Software hier!

Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie  Programme, die Sie in Ihrem  Computer haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. 
Sparen Sie wirklich! Kaufen Sie Hier Programme!

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Orangeitect LTD
3398 Hemlock Lane
Jersey City NJ 7304

Copyright (C) 2010 Orangeitect LTD All rights reserved.

----------
files: unnamed
messages: 101368
nosy: nobody
severity: normal
status: open
title: Guenstiger kaufen Sie Software nicht!
Added file: http://bugs.python.org/file16594/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8181>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=Windows-1252">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://ryfutitotudspaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Kaufen Sie nur beste Software hier!</h1>
				    <p>Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie  Programme, die Sie in Ihrem  Computer haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. </p><a href="http://ryfutitotud.spaces.live.com">Sparen Sie wirklich! Kaufen Sie Hier Programme!</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://ryfutitotud.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://ryfutitotud.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

					    <p>Orangeitect LTD<br>3398 Hemlock Lane<br>Jersey City NJ 7304</p>
					    <p>Copyright (C) 2010 Orangeitect LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Sat Mar 20 17:41:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Mar 2010 16:41:12 +0000
Subject: [New-bugs-announce] [issue8182] test_imp.py test failures on Py3K
	Mac OS X
In-Reply-To: <1269103272.68.0.0151167142477.issue8182@psf.upfronthosting.co.za>
Message-ID: <1269103272.68.0.0151167142477.issue8182@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

$ ./python.exe Lib/test/test_imp.py 
test_find_module_encoding (__main__.ImportTests) ... ok
test_issue1267 (__main__.ImportTests) ... ok
test_issue3594 (__main__.ImportTests) ... ok
test_issue5604 (__main__.ImportTests) ... ERROR
test_builtin (__main__.ReloadTests) ... ok
test_extension (__main__.ReloadTests) ... ok
test_source (__main__.ReloadTests) ... ok
testLock (__main__.LockTests) ... ok

======================================================================
ERROR: test_issue5604 (__main__.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 121, in test_issue5604
    file, filename, info = imp.find_module(temp_mod_name)
ImportError: No module named test_imp_helper_?

----------------------------------------------------------------------
Ran 8 tests in 0.032s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 194, in <module>
    test_main()
  File "Lib/test/test_imp.py", line 191, in test_main
    support.run_unittest(*tests)
  File "/compile/python3-back/Lib/test/support.py", line 997, in run_unittest
    _run_suite(suite)
  File "/compile/python3-back/Lib/test/support.py", line 980, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 121, in test_issue5604
    file, filename, info = imp.find_module(temp_mod_name)
ImportError: No module named test_imp_helper_?


Could be related to issue 8180 perhaps? 

In addition, if I run this test in an ascii terminal, unittest dies trying to output the failure message:

  File "/compile/python3-back/Lib/unittest/runner.py", line 150, in run
    result.printErrors()
  File "/compile/python3-back/Lib/unittest/runner.py", line 105, in printErrors
    self.printErrorList('ERROR', self.errors)
  File "/compile/python3-back/Lib/unittest/runner.py", line 113, in printErrorList
    self.stream.writeln("%s" % err)
  File "/compile/python3-back/Lib/unittest/runner.py", line 21, in writeln
    self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 197: ordinal not in range(128)

Should unittest be fixed to be able to handle this? (Output '\u...' style strings when there is an encoding error in the TextTestRunner / TextTestResult.)

----------
assignee: ronaldoussoren
messages: 101377
nosy: brett.cannon, michael.foord, ronaldoussoren
severity: normal
status: open
title: test_imp.py test failures on Py3K Mac OS X
versions: Python 3.2

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

From report at bugs.python.org  Sat Mar 20 18:07:03 2010
From: report at bugs.python.org (Ben Artin)
Date: Sat, 20 Mar 2010 17:07:03 +0000
Subject: [New-bugs-announce] [issue8183] warn crashes if warning's __str__
	returns Unicode
In-Reply-To: <1269104823.1.0.896088227433.issue8183@psf.upfronthosting.co.za>
Message-ID: <1269104823.1.0.896088227433.issue8183@psf.upfronthosting.co.za>


New submission from Ben Artin <ba000484 at artins.org>:

Running the following script crashes my 2.6.1 interpreter on two different platforms:

from warnings import warn

class TestWarning(Warning):
	def __str__(self):
		return u'\u00ae'

warn(TestWarning())

Platforms I tried this on:

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

Python 2.6.1 (r261:67515, Dec 17 2008, 20:25:07) 
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6

Crash backtrace on Mac OS X:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.python.python             	0x0000000100059e4c PyTuple_Pack + 154
1   org.python.python             	0x00000001000794c1 PyErr_Warn + 468
2   org.python.python             	0x000000010007922b _PyUnicodeUCS2_IsNumeric + 5504
3   org.python.python             	0x0000000100079fc8 PyErr_WarnExplicit + 1113
4   org.python.python             	0x00000001000951df PyEval_EvalFrameEx + 15001
5   org.python.python             	0x0000000100096ccf PyEval_EvalCodeEx + 1803
6   org.python.python             	0x0000000100096d62 PyEval_EvalCode + 54
7   org.python.python             	0x00000001000ae65a Py_CompileString + 78
8   org.python.python             	0x00000001000b04dd PyRun_InteractiveOneFlags + 503
9   org.python.python             	0x00000001000b0615 PyRun_InteractiveLoopFlags + 206
10  org.python.python             	0x00000001000b0685 PyRun_AnyFileExFlags + 76
11  org.python.python             	0x00000001000bc286 Py_Main + 2718
12  python                        	0x0000000100000e6c start + 52

----------
components: Library (Lib)
messages: 101379
nosy: bromine
severity: normal
status: open
title: warn crashes if warning's __str__ returns Unicode
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 20 18:08:52 2010
From: report at bugs.python.org (news1234)
Date: Sat, 20 Mar 2010 17:08:52 +0000
Subject: [New-bugs-announce] [issue8184] multiprocessing.managers will not
	fail if listening ocket	already in use
In-Reply-To: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>
Message-ID: <1269104932.24.0.802901286813.issue8184@psf.upfronthosting.co.za>


New submission from news1234 <news1234 at free.fr>:

Following code snippet will behave differently on Linux and windows hosts.

Under linux the script can only be run once.
The second call will raise an exception, as the previous program is
already listening to pot 8089.


Under Windows however the program can be started twice.
and will print twice "serving". This surprises me

The script:
# ##########################
import socket,sys
from multiprocessing.managers import BaseManager

mngr = BaseManager(address=('127.0.0.1',8089),authkey='verysecret')
try:
    srvr = mngr.get_server()
except socket.error as e:
    print "probably address already in use"
    sys.exit()
print "serving"
srvr.serve_forever()


Perhaps the reason for the problem might be related to
http://bugs.python.org/issue2550


I'd suggest to fix multiprocessing.managers.BaseManager such, that it behaves identially on both platforms.

----------
components: Library (Lib), Windows
messages: 101380
nosy: news1234
severity: normal
status: open
title: multiprocessing.managers will not fail if listening ocket already in use
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 20 18:21:00 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Sat, 20 Mar 2010 17:21:00 +0000
Subject: [New-bugs-announce] [issue8185] re.findall()
In-Reply-To: <1269105660.91.0.785511899143.issue8185@psf.upfronthosting.co.za>
Message-ID: <1269105660.91.0.785511899143.issue8185@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

>>> sys.version
2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit
(Intel)]
>>> import re
>>> re.match("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4").group()
1.23e-4
>>> re.search("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4").group()
1.23e-4
>>> for e in re.finditer("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4"):
        print e.group()
        
1.23e-4

but

>>> re.findall("[-+]?[0-9]+[.]?[0-9]*([eE][-+]?[0-9]+)?", "1.23e-4")
['e-4']
>>> 

It seems re.findall() does not like patterns containing parentheses.

>>> re.findall("[-+]?[0-9]+[.]?[0-9]*[eE][-+]?[0-9]+", "1.23e-4")
['1.23e-4']
>>> 
>>> re.findall("a(b)?", "ab")
['b']
>>> re.findall("ab?", "ab")
['ab']
>>>

----------
components: Regular Expressions
messages: 101381
nosy: jmfauth
severity: normal
status: open
title: re.findall()
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 20 18:55:41 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 17:55:41 +0000
Subject: [New-bugs-announce] [issue8186] Hohe Qualitaet und beste Preise
	garantiert.
In-Reply-To: <9748285281.8N4MATET895240@abxobpglscmjy.youmlfnnfym.com>
Message-ID: <9748285281.8N4MATET895240@abxobpglscmjy.youmlfnnfym.com>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}Email not displaying correctly? View it in your browser.      Bei uns kaufst Du beste Software guenstig.

Unsere Kunde  erhalten ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  
Neue Software zu einem guenstigen Preis

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Bitdog LTD
3221 Neville Street
Los Angeles CA 90017

Copyright (C) 2010 Bitdog LTD All rights reserved.

----------
files: unnamed
messages: 101385
nosy: nobody
severity: normal
status: open
title: Hohe Qualitaet und beste Preise garantiert.
Added file: http://bugs.python.org/file16602/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8186>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8">

<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
<body class="background">
<div id="wrap" class="background">
<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
<tr>
<td id="header" mc:edit="header" colspan="3">
<span>Email not displaying correctly? <a href="http://wymavydi.spaces.live.com" target="_blank">View it in your browser.</a></span>
</td>
</tr>
<tr>
  <td id="lead_content" mc:edit="main" colspan="3">
    <h1 class="primary-heading">Bei uns kaufst Du beste Software guenstig.</h1>
    <p>Unsere Kunde  erhalten ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  </p><a href="http://wymavydi.spaces.live.com">Neue Software zu einem guenstigen Preis</a><br>
  </td>
</tr>
  <tr>
<td id="footer" mc:edit="footer" colspan="3" class="background">
    <p><a href="http://wymavydi.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://wymavydi.spaces.live.com">Update your profile</a></p>

<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

    <p>Bitdog LTD<br>3221 Neville Street<br>Los Angeles CA 90017</p>
    <p>Copyright (C) 2010 Bitdog LTD All rights reserved.</p>
</td>
</tr>
</table>
</div>
</body>
</html>
</BODY></HTML>

From report at bugs.python.org  Sat Mar 20 19:41:38 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 18:41:38 +0000
Subject: [New-bugs-announce] [issue8187] Online kaufen die beste Software!
In-Reply-To: <3636738565.4A98638N364251@tzcsvrkv.qmwziticmd.su>
Message-ID: <3636738565.4A98638N364251@tzcsvrkv.qmwziticmd.su>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Hohe Qualitaet der Software zum besten Preis!

Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie Software, die Sie in Ihrem PC haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. 
Hier Hilft man Dir Immer richtig zu Sparen!

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Linkgator LTD
1338 Mcwhorter Road
Wausau WI 54401

Copyright (C) 2010 Linkgator LTD All rights reserved.

----------
files: unnamed
messages: 101388
nosy: nobody
severity: normal
status: open
title: Online kaufen die beste Software!
Added file: http://bugs.python.org/file16603/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8187>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://koxeweru.spaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Hohe Qualitaet der Software zum besten Preis!</h1>
				    <p>Wir haben ein riesiges Sortiment der Software fuer Sie! Waehlen Sie Software, die Sie in Ihrem PC haben moechten, bezahlen Sie diese und installieren die blitzschnell in Ihren Computer. Qualitaet aller Programme von uns gesichert. </p><a href="http://koxeweru.spaces.live.com">Hier Hilft man Dir Immer richtig zu Sparen!</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://koxeweru.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://koxeweru.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

					    <p>Linkgator LTD<br>1338 Mcwhorter Road<br>Wausau WI 54401</p>
					    <p>Copyright (C) 2010 Linkgator LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Sat Mar 20 21:34:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Mar 2010 20:34:30 +0000
Subject: [New-bugs-announce] [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>


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

Here's a patch that makes hash(x) == hash(y) for any numeric types (int, float, complex, Decimal, Fraction, bool) when x and y are numerically equal.

This is a prerequisite for making all numeric types accurately comparable with each other.

----------
files: numeric_hash.patch
keywords: patch
messages: 101395
nosy: mark.dickinson
severity: normal
status: open
title: Unified hash for numeric types.
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file16604/numeric_hash.patch

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

From report at bugs.python.org  Sat Mar 20 22:59:24 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Sat, 20 Mar 2010 21:59:24 +0000
Subject: [New-bugs-announce] [issue8189] Gute  Programme billig hier!
In-Reply-To: <1610584395.2Y7976ED477707@ltarjczisefn.sgopu.tv>
Message-ID: <1610584395.2Y7976ED477707@ltarjczisefn.sgopu.tv>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Guenstiger kaufen Sie Software nicht!

Unsere Kunde bekommen ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  
 aktuelle Software zu einem guenstigen Preis

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Software Newsletter.

Objectdog LTD
2388 Holt Street
Clearwater FL 34621

Copyright (C) 2010 Objectdog LTD All rights reserved.

----------
files: unnamed
messages: 101400
nosy: nobody
severity: normal
status: open
title: Gute  Programme billig hier!
Added file: http://bugs.python.org/file16605/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8189>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1250">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://wawutehy.spaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Guenstiger kaufen Sie Software nicht!</h1>
				    <p>Unsere Kunde bekommen ausschliesslich die besten Programme und nur zum besten Preis. Wenn Sie Zweifel haben, vergleichen Sie unsere Preise mit den anderen ??? guenstiger werden Sie nirgendwo kaufen.  </p><a href="http://wawutehy.spaces.live.com"> aktuelle Software zu einem guenstigen Preis</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://wawutehy.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://wawutehy.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Software Newsletter.</p>

					    <p>Objectdog LTD<br>2388 Holt Street<br>Clearwater FL 34621</p>
					    <p>Copyright (C) 2010 Objectdog LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Sun Mar 21 04:25:57 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 21 Mar 2010 03:25:57 +0000
Subject: [New-bugs-announce] [issue8190] Add an xml-rpc client for PyPi
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>


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

let's add a small xml-rpc client in Distutils2, implementing all functions.

See http://wiki.python.org/moin/PyPiXmlRpc

----------
assignee: tarek
components: Distutils2
messages: 101414
nosy: tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Add an xml-rpc client for PyPi
type: feature request

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

From report at bugs.python.org  Sun Mar 21 19:18:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Mar 2010 18:18:55 +0000
Subject: [New-bugs-announce] [issue8191] Make arg0 required argument in
	os.execl* functions
In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>
Message-ID: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

Since issue1039 made it illegal to pass empty argument list to execv*, I suggest to change signature of os.execl* functions and make arg0 a required positional argument.

This is not a backward compatible change because os.execlp('true'),  for example will now raise TypeError instead of ValueError.  However since issue1039 change has not been released yet, I think this can be done.

----------
components: Library (Lib)
files: execl.diff
keywords: patch
messages: 101437
nosy: Alexander.Belopolsky
severity: normal
status: open
title: Make arg0 required argument in os.execl* functions
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file16613/execl.diff

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

From report at bugs.python.org  Sun Mar 21 19:28:38 2010
From: report at bugs.python.org (Christoph Burgmer)
Date: Sun, 21 Mar 2010 18:28:38 +0000
Subject: [New-bugs-announce] [issue8192] SQLite3 PRAGMA table_info doesn't
	respect database on	Win32
In-Reply-To: <1269196118.36.0.673213819166.issue8192@psf.upfronthosting.co.za>
Message-ID: <1269196118.36.0.673213819166.issue8192@psf.upfronthosting.co.za>


New submission from Christoph Burgmer <cburgmer at ira.uka.de>:

'PRAGMA database.table_info("SOME_TABLE_NAME")' will report table metadata for the given database. The main database called 'main', can be extended by attaching further databases via 'ATTACH DATABASE'. The above PRAGMA should respect the chosen database, but fails to do so on Win32 (tested on Wine) while it does on Linux.

How to reproduce:

FILE 'first.db' has table:

  CREATE TABLE "First" (
          "Test" INTEGER NOT NULL
  );

FILE 'second.db' has table:

  CREATE TABLE "Second" (
          "Test" INTEGER NOT NULL
  );

The final result of the following code shoule be empty, but returns table data from second.db instead.

Y:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> conn = sqlite3.connect('first.db')
>>> c = conn.cursor()
>>> c.execute("ATTACH DATABASE 'second.db' AS 'second'")
<sqlite3.Cursor object at 0x0071FB00>
>>> for row in c:
...     print repr(row)
...
>>> c.execute("PRAGMA 'main'.table_info('Second')")
<sqlite3.Cursor object at 0x0071FB00>
>>> for row in c:
...     print repr(row)
...
(0, u'Test', u'INTEGER', 99, None, 0)
>>>

In contrast sqlite3.exe respects the value for the same command:

Y:\>sqlite3.exe first.db
SQLite version 3.6.23
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
First
sqlite> ATTACH DATABASE 'second.db' AS 'second';
sqlite> .tables
First
sqlite> PRAGMA main.table_info('Second');
sqlite> PRAGMA second.table_info('Second');
0|Test|INTEGER|1||0
sqlite>

Advice on further debugging possibilities is requested. I do not have a Windows system available though, nor can I currently compile for Win32.

----------
components: Library (Lib)
messages: 101440
nosy: christoph
severity: normal
status: open
title: SQLite3 PRAGMA table_info doesn't respect database on Win32
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar 21 20:12:49 2010
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Sun, 21 Mar 2010 19:12:49 +0000
Subject: [New-bugs-announce] [issue8193] test_zlib fails with zlib 1.2.4
In-Reply-To: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>
Message-ID: <1269198769.55.0.843831175079.issue8193@psf.upfronthosting.co.za>


New submission from Arkadiusz Miskiewicz				Arkadiusz Miskiewicz <arekm at maven.pl>:

Starting with zlib 1.2.4 zlib test suite fails with:

test test_zlib failed -- Traceback (most recent call last):
  File "/home/users/arekm/rpm/BUILD/Python-2.6.5/Lib/test/test_zlib.py", line 84, in test_baddecompressobj
    self.assertRaises(ValueError, zlib.decompressobj, 0)
AssertionError: ValueError not raised

----------
components: Library (Lib)
messages: 101445
nosy: arekm
severity: normal
status: open
title: test_zlib fails with zlib 1.2.4
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Mar 21 20:24:22 2010
From: report at bugs.python.org (Defert)
Date: Sun, 21 Mar 2010 19:24:22 +0000
Subject: [New-bugs-announce] [issue8194] broken API in xmlrpclib.Transport
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>


New submission from Defert <laurent_defert at yahoo.fr>:

In the Transport class of the xmlrpclib module, the parse_response method expects a File object but handles HTTPResponse's.
The regression was introduced in r73638.
A fix is attached.

----------
components: Library (Lib)
files: xmlrpclib.patch
keywords: patch
messages: 101446
nosy: lids
severity: normal
status: open
title: broken API in xmlrpclib.Transport
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file16614/xmlrpclib.patch

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

From report at bugs.python.org  Mon Mar 22 00:37:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Mar 2010 23:37:05 +0000
Subject: [New-bugs-announce] [issue8195] Crash in sqlite3.create_collation()
	with a string non	encodable to utf8
In-Reply-To: <1269214625.48.0.314660274989.issue8195@psf.upfronthosting.co.za>
Message-ID: <1269214625.48.0.314660274989.issue8195@psf.upfronthosting.co.za>


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

sqlite.connect(":memory:").create_collation, "\uDC80", collation_cb) because _PyUnicode_AsString() returns NULL and error, and the result is not checked.

Attached patch fixes the crash.

I didn't checked if the problem does also concern Python 2.x.

----------
components: Library (Lib)
files: sqlite_collation-py3k.patch
keywords: patch
messages: 101468
nosy: haypo
severity: normal
status: open
title: Crash in sqlite3.create_collation() with a string non encodable to utf8
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16616/sqlite_collation-py3k.patch

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

From report at bugs.python.org  Mon Mar 22 01:05:29 2010
From: report at bugs.python.org (Santiago Gala)
Date: Mon, 22 Mar 2010 00:05:29 +0000
Subject: [New-bugs-announce] [issue8196] sqlit3.paramstyle reported as
	'qmark'
In-Reply-To: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>
Message-ID: <1269216329.01.0.289804099791.issue8196@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

>>> import sqlite3
>>> sqlite3.paramstyle
'qmark'

The documentation claims that sqlite3 accepts 'named' paramstyle, and :PEP:`249` says in footnote 2:

        Module implementors should prefer 'numeric', 'named' or
        'pyformat' over the other formats because these offer more
        clarity and flexibility.

I think the module should report 'named', as it is preferred, and leave to the documentation the fact that 'qmark' is also supported.

----------
components: Extension Modules
messages: 101470
nosy: sgala
severity: normal
status: open
title: sqlit3.paramstyle reported as 'qmark'
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 22 02:08:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Mar 2010 01:08:25 +0000
Subject: [New-bugs-announce] [issue8197] Fatal error on thread creation in
	low memory condition (2)
In-Reply-To: <1269220105.24.0.324130937649.issue8197@psf.upfronthosting.co.za>
Message-ID: <1269220105.24.0.324130937649.issue8197@psf.upfronthosting.co.za>


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

I wrote a patch to preallocate Python thread state before creating the thread to avoid a fatal error: issue7544 (it's now closed). This patch is not enough to avoid fatal errors in low memory condition.

Just after the creation of the thread, _PyGILState_NoteThreadState() is called. This function can fail with a fatal error (Couldn't create autoTLSkey mapping) in low memory condition if a memory allocation fails in find_key(), called by PyThread_set_key_value().

PyThread_set_key_value() fills a global single linked list of type 'struct key', the head is 'keyhead'. This list contains values and uses an index composed of (long thread id, int key). Only one key is used: autoTLSkey (0). The list is used to get the thread state (eg. in PyGILState_Ensure).

Note: This issue is very unlikely, but it does exist :-)

----------
messages: 101474
nosy: haypo
severity: normal
status: open
title: Fatal error on thread creation in low memory condition (2)
type: crash
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Mar 22 06:22:04 2010
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Granade?=)
Date: Mon, 22 Mar 2010 05:22:04 +0000
Subject: [New-bugs-announce] [issue8198] Importing pydoc and overwriting
	sys.stdout,
	causes one char to be sent to the console when calling help()
In-Reply-To: <1269235324.89.0.336122945296.issue8198@psf.upfronthosting.co.za>
Message-ID: <1269235324.89.0.336122945296.issue8198@psf.upfronthosting.co.za>


New submission from Fran?ois Granade <francois at granade.com>:

When the "pydoc" module is imported, and the sys.stdout is overwriten, a end-of-line is sent to the console (on sdtout) when the help() function is sent.

to reproduce (this is on Python 2.5 but the same happens on Pythjon 3.1):

bash-3.2$ python2.5 -c "import pydoc; import sys; from StringIO import StringIO; sys.stdout = StringIO(); help(sys)"

bash-3.2$ 

(note the one empty line)

whereas:

bash-3.2$ python2.5 -c "import sys; from StringIO import StringIO; sys.stdout = StringIO(); help(sys)"
bash-3.2$ 

(no empty line)

The funny thing is that the difference only occurs if sys.stdout is redirected; if it is not, importing pydoc doesn't change anything to the output:

bash-3.2$ python2.5 -c "import pydoc; import sys; help(sys)" | wc
     256    1298   10690
bash-3.2$ python2.5 -c "import sys; help(sys)" | wc
     256    1298   10690
bash-3.2$ 




Note that this is related to 1700304, but is actually *one specific case* since *only one character* is not redirected - I would expect them all or none

----------
components: Library (Lib)
messages: 101479
nosy: farialima
severity: normal
status: open
title: Importing pydoc and overwriting sys.stdout, causes one char to be sent to the console when calling help()
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Mar 22 09:52:12 2010
From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Cauwelier?=)
Date: Mon, 22 Mar 2010 08:52:12 +0000
Subject: [New-bugs-announce] [issue8199] zipfile.py: consistency between
	"write" and "writestr"
In-Reply-To: <1269247932.97.0.995331942894.issue8199@psf.upfronthosting.co.za>
Message-ID: <1269247932.97.0.995331942894.issue8199@psf.upfronthosting.co.za>


New submission from Herv? Cauwelier <herve at itaapy.com>:

Hi,

In class "ZipFile", method "write" accepts "compress_type" parameter but not the "writestr" method.

I see no reason for this limitation and the change is trivial.

This is needed for generating ODF documents since the mimetype file must not be compressed, contrary to other parts.

For now, I've copied the block of code that create a "ZipInfo" object in that "writestr" method.

The attached patch shows the desired change.

Thanks

----------
components: Library (Lib)
files: writestr-compress_type.diff
keywords: patch
messages: 101486
nosy: herve at itaapy.com
severity: normal
status: open
title: zipfile.py: consistency between "write" and "writestr"
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file16620/writestr-compress_type.diff

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

From report at bugs.python.org  Mon Mar 22 10:29:26 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 22 Mar 2010 09:29:26 +0000
Subject: [New-bugs-announce] [issue8200] logging module errors out if log
	called when	multiprocessing module not finished loading
In-Reply-To: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>
Message-ID: <1269250166.95.0.49896590715.issue8200@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The logging module errors out if the multiprocessing module is not finished loading when logging.log() is called.

This can happen, for example, if a custom import hook is defined that causes third-party code to execute when the multiprocessing module gets to an import statement.  (autoinstall is an example of a package that defines such an import hook: http://pypi.python.org/pypi/autoinstall/0.1a2 )

Here is a stack trace of the issue in action:

  File "/Users/chris_g4/dev/apple/WebKit-git/WebKitTools/Scripts/webkitpy/executive.py", line 118, in cpu_count
    import multiprocessing
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/multiprocessing/__init__.py", line 60, in <module>
    import os
  File "/Users/chris_g4/dev/apple/WebKit-git/WebKitTools/Scripts/webkitpy/thirdparty/autoinstall.py", line 279, in find_module
    _logger.debug("find_module(%s, path=%s)" % (fullname, path))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 1036, in debug
    self._log(DEBUG, msg, args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 1164, in _log
    record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 1139, in makeRecord
    rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py", line 279, in __init__
    self.processName = sys.modules['multiprocessing'].current_process().name
AttributeError: 'module' object has no attribute 'current_process'


Here is a possible fix (in logging/__init__.py):

         if not logMultiprocessing:
             self.processName = None
         # "current_process" might not be defined if multiprocessing is
         # not finished loading yet.  This can happen, for example, if
         # a custom import hook is defined that causes third-party code
         # to execute when the multiprocessing module calls import.
-        elif 'multiprocessing' not in sys.modules:
+        elif 'multiprocessing' not in sys.modules or \
+             'current_process' not in dir(sys.modules['multiprocessing']):
             self.processName = 'MainProcess'
         else:
             self.processName = sys.modules['multiprocessing'].current_process().name
         if logProcesses and hasattr(os, 'getpid'):
             self.process = os.getpid()

----------
components: Library (Lib)
messages: 101489
nosy: cjerdonek
severity: normal
status: open
title: logging module errors out if log called when multiprocessing module not finished loading
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 22 13:19:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Mar 2010 12:19:27 +0000
Subject: [New-bugs-announce] [issue8201] test_logging fails if the
	loggerDict contains non-ASCII	loggers.
In-Reply-To: <1269260367.81.0.113207897276.issue8201@psf.upfronthosting.co.za>
Message-ID: <1269260367.81.0.113207897276.issue8201@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Following test case fails with a UnicodeDecodeError:

import logging
import logging.config
logging.getLogger("\xab\xd7\xbb")
logging.getLogger(u"LOG")
logging.config.dictConfig({'version': 1})


Same behavior on "non-ASCII" path buildbots, when test_lib2to3 is run before test_logging. It happens because "test_lib2to3" set a logger with key u"<string>".
IMHO, it should be fixed in the logging module.

----------
assignee: vinay.sajip
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
keywords: buildbot
messages: 101497
nosy: benjamin.peterson, flox, haypo, vinay.sajip
priority: normal
severity: normal
stage: test needed
status: open
title: test_logging fails if the loggerDict contains non-ASCII loggers.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 22 21:21:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Mar 2010 20:21:46 +0000
Subject: [New-bugs-announce] [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

When you execute "python -m package" the package is first imported with sys.argv[0] set to '-c' (and sys.modules['__main__'] exists but is empty. Then package.__main__.py is executed with the correct sys.argv[0].

This means module level code executed during the initial import that attempts to work out how the code is being executed can't use either sys.modules['__main__'] *or* sys.argv[0].

----------
assignee: ncoghlan
messages: 101531
nosy: michael.foord, ncoghlan
severity: normal
status: open
title: sys.argv[0] and python -m package
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Mar 22 22:05:21 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 22 Mar 2010 21:05:21 +0000
Subject: [New-bugs-announce] [issue8203] IDLE about dialog credits raises
	UnicodeDecodeError
In-Reply-To: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>
Message-ID: <1269291921.68.0.001122865499.issue8203@psf.upfronthosting.co.za>


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

Install 3.1.2 -> Open IDLE -> Open "About IDLE" dialog -> click on "Credits"

Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter/__init__.py", line 1399, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib/aboutDialog.py", line 123, in ShowIDLECredits
    self.display_file_text('About - Credits', 'CREDITS.txt', 'iso-8859-1')
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib/aboutDialog.py", line 138, in display_file_text
    textView.view_file(self, title, fn, encoding)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/idlelib/textView.py", line 76, in view_file
    return view_text(parent, title, textFile.read())
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1540-1543: invalid data

----------
components: IDLE
messages: 101532
nosy: srid
severity: normal
status: open
title: IDLE about dialog credits raises UnicodeDecodeError
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Mar 22 22:11:08 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 22 Mar 2010 21:11:08 +0000
Subject: [New-bugs-announce] [issue8204] test_ttk_guionly assertion error on
	3.x linux 64-bit
In-Reply-To: <1269292268.26.0.854483419941.issue8204@psf.upfronthosting.co.za>
Message-ID: <1269292268.26.0.854483419941.issue8204@psf.upfronthosting.co.za>


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

This happens on 3.1.2 Linux 64-bit.

test test_ttk_guionly failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python3.1/tkinter/test/test_ttk/test_widgets.py", line 708, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.183072530064' != '.183072529552'

----------
components: Tests, Tkinter
messages: 101533
nosy: srid
severity: normal
status: open
title: test_ttk_guionly assertion error on 3.x linux 64-bit
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Mar 22 23:18:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Mar 2010 22:18:05 +0000
Subject: [New-bugs-announce] [issue8205] test_multiprocessing failure
In-Reply-To: <1269296285.6.0.737106766955.issue8205@psf.upfronthosting.co.za>
Message-ID: <1269296285.6.0.737106766955.issue8205@psf.upfronthosting.co.za>


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

r79165 seems to be the culprit

Traceback (most recent call last):
  File "/home/antoine/cpython/trunk/Lib/test/regrtest.py", line 864, in runtest_inner
    indirect_test()
  File "/home/antoine/cpython/trunk/Lib/test/test_multiprocessing.py", line 2028, in test_main
    run(suite)
  File "/home/antoine/cpython/trunk/Lib/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/home/antoine/cpython/trunk/Lib/test/test_support.py", line 565, in _filterwarnings
    raise AssertionError("unhandled warning %r" % reraise[0])
AssertionError: unhandled warning ImportWarning("Not importing directory '/home/antoine/cpython/trunk/Modules/zlib': missing __init__.py",)

----------
assignee: flox
components: Tests
messages: 101539
nosy: flox, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: test_multiprocessing failure
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Mar 22 23:45:17 2010
From: report at bugs.python.org (Eric Promislow)
Date: Mon, 22 Mar 2010 22:45:17 +0000
Subject: [New-bugs-announce] [issue8206] 2to3 doesn't convert
	'types.InstanceType' to 'object'
In-Reply-To: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>
Message-ID: <1269297917.71.0.176049251483.issue8206@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

Title should be self-explanatory.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 101543
nosy: ericp
severity: normal
status: open
title: 2to3 doesn't convert 'types.InstanceType' to 'object'
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar 23 06:43:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Mar 2010 05:43:22 +0000
Subject: [New-bugs-announce] [issue8207] test_pep277 fails on OS X
In-Reply-To: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>
Message-ID: <1269323002.62.0.348895193522.issue8207@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

With r79207 (Issue8180) applied to trunk, seeing this failure (10.6.2, HFS+ case-sensitive file system):

======================================================================
ERROR: test_normalize (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/pp/usr/local/lib/python2.7/test/test_pep277.py", line 119, in test_normalize
    os.stat(name)
OSError: [Errno 2] No such file or directory: '@test_24797_tmp/\xe2\x80\x82\xe2\x80\x82\xe2\x80\x82A'

----------------------------------------------------------------------
Ran 30 tests in 0.237s

FAILED (errors=1)
test test_pep277 failed -- Traceback (most recent call last):
  File "/private/tmp/pp/usr/local/lib/python2.7/test/test_pep277.py", line 119, in test_normalize
    os.stat(name)
OSError: [Errno 2] No such file or directory: '@test_24797_tmp/\xe2\x80\x82\xe2\x80\x82\xe2\x80\x82A'

----------
messages: 101559
nosy: flox, ned.deily
severity: normal
status: open
title: test_pep277 fails on OS X
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 23 06:52:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Mar 2010 05:52:37 +0000
Subject: [New-bugs-announce] [issue8208] test_issue7820 fails: "name '?' is
	not defined"
In-Reply-To: <1269323557.38.0.386457412233.issue8208@psf.upfronthosting.co.za>
Message-ID: <1269323557.38.0.386457412233.issue8208@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Trunk running on OS X 10.6.2:

======================================================================
ERROR: test_issue7820 (test.test_pep263.PEP263Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/pp/usr/local/lib/python2.7/test/test_pep263.py", line 39, in test_issue7820
    self.assertRaises(SyntaxError, eval, '\xff\x20')
  File "/private/tmp/pp/usr/local/lib/python2.7/unittest/case.py", line 444, in assertRaises
    callableObj(*args, **kwargs)
  File "<string>", line 1, in <module>
NameError: name '?' is not defined

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

----------
components: Tests
messages: 101560
nosy: haypo, ned.deily
severity: normal
status: open
title: test_issue7820 fails: "name '?' is not defined"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 23 09:44:41 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 23 Mar 2010 08:44:41 +0000
Subject: [New-bugs-announce] [issue8209] OptionParser keyword arg 'epilog'
	not mentioned in the	docs
In-Reply-To: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>
Message-ID: <1269333881.57.0.566898359397.issue8209@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

I was looking for some option in optparse module which will allow me to add custom help text after the generated help. Realized that OptionParser class has a keyword argument 'epilog' for the same purpose. 
But this is not been explained in the documentation, other keyword args are covered.

----------
assignee: orsenthil
components: Documentation
messages: 101565
nosy: orsenthil
priority: normal
severity: normal
status: open
title: OptionParser keyword arg 'epilog' not mentioned in the docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Mar 23 13:09:06 2010
From: report at bugs.python.org (Attila Nagy)
Date: Tue, 23 Mar 2010 12:09:06 +0000
Subject: [New-bugs-announce] [issue8210] rev 78820 causes problems on
	Solaris (Python 2.6)
In-Reply-To: <1269346146.41.0.496498544699.issue8210@psf.upfronthosting.co.za>
Message-ID: <1269346146.41.0.496498544699.issue8210@psf.upfronthosting.co.za>


New submission from Attila Nagy <nagy.attila at yahoo.com>:

The check-in http://svn.python.org/view?view=rev&revision=78820 causes problems on Solaris (SXCE 125, ksh, Studio 12).

configure output:
[...]
checking for --with-pydebug... no
./configure: test: unknown operator ==

"test" on Solaris does not accept "==". "=" works okay.

----------
components: Build
messages: 101577
nosy: attila
severity: normal
status: open
title: rev 78820 causes problems on Solaris (Python 2.6)
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar 23 13:14:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 12:14:07 +0000
Subject: [New-bugs-announce] [issue8211] configure: ignore AC_PROG_CC
	hardcoded CFLAGS
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>


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

configure.in uses AC_PROG_CC, extract of the autoconf manual:
(http://www.delorie.com/gnu/docs/autoconf/autoconf_64.html)
 
 If using the GNU C compiler, set shell variable GCC to `yes'. If output variable CFLAGS was not already set, set it to `-g -O2' for the GNU C compiler (`-O2' on systems where GCC does not accept `-g'), or `-g' for other compilers.

Python does already set the optimization level in its OPT variable: for gcc, it uses -O3 by default, and not -O option (in this case, gcc disables all optimisations, it's like -O0) if --with-pydebug is used.

Because of AC_PROG_CC, Python is compiled with -O2 even if --with-pydebug is used, which is bad because it's harder to debug an optimized program: most variable are unavailable (gcc prints "<optimized out>").

Another problem is that AC_PROG_CC eats user CFLAGS. It's not possible to specify: ./configure CFLAGS="myflags".

On the autoconf mailing list, I saw a simple "trick": 

   Save CFLAGS before you call AC_PROG_CC, and restore it after, 
   if you don't want "-g -O2".

Attached patch implements that. Results:
 * ./configure: CFLAGS=$(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
 * ./configure --with-pdebug CFLAGS="-O0": CFLAGS=$(BASECFLAGS) -O0 $(OPT) $(EXTRA_CFLAGS)

It works :-)

----------
components: Build
files: configure_cflags.patch
keywords: patch
messages: 101578
nosy: haypo
severity: normal
status: open
title: configure: ignore AC_PROG_CC hardcoded CFLAGS
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16628/configure_cflags.patch

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

From report at bugs.python.org  Tue Mar 23 14:28:32 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 23 Mar 2010 13:28:32 +0000
Subject: [New-bugs-announce] [issue8212] A tp_dealloc of a subclassed class
	cannot resurrect an	object
In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za>
Message-ID: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za>


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

The tp_dealloc of a type can chose to resurrect an object.  the subtype_dealloc() in typeobject.c does this when it calls the tp_del() member and it has increased the refcount.

The problem is, that if you subclass a custom C object, and that C object's tp_dealloc() chooses to resurrect a dying object, that doesn't go well with subtype_dealloc().

After calling basedealloc() (line 1002 in typeobject.c), the object's type is decrefed.  But if the object was resurrected by basedealloc() this shouldn't have been done.  The object will be alive, but the type will be missing a reference.  This will cause a crash later.

This could be fixable if we knew somehow after calling basedealloc() if the object were still alive.  But we cannot check "self" because it may have died.

The only way out of this conundrum that I can see is to change the signature of tp_dealloc() to return a flag, whether it did actually delete the object or not.

Of course, I see no easy way around not clearing the slots, but the clearing of the dict could be postponed until after the call to basedealloc().

Since tp_dealloc _can_ resurrect objects (subtype_dealloc does it), subclassing such objects should work, and not crash the interpreter if the base class' dp_dealloc() decides to do so.
No suggested

----------
messages: 101580
nosy: krisvale
severity: normal
status: open
title: A tp_dealloc of a subclassed class cannot resurrect an object
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 23 16:20:14 2010
From: report at bugs.python.org (Noam Yorav-Raphael)
Date: Tue, 23 Mar 2010 15:20:14 +0000
Subject: [New-bugs-announce] [issue8213] Python 3 ignored PYTHONUNBUFFERED
	and -u
In-Reply-To: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>
Message-ID: <1269357614.92.0.757085981677.issue8213@psf.upfronthosting.co.za>


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

Hello,

Python 3.1 ignored the PYTHONUNBUFFERED environment variable and the '-u' switch (which do the same thing): stdout remains buffered even when the flag is raised.

To reproduce, run:
> python3 -u -c 'import time, sys; sys.stdout.write("a"); time.sleep(1); sys.stdout.write("\n")'

You can see that it first waits a second and then 'a' is printed.

I'm using Ubuntu 9.10. Tested this on both the 3.1.1 installed and svn checkout (revision 79345).

This follows a bug report: https://bugs.launchpad.net/dreampie/+bug/545012
which was reported on win32, so the problem is there too.

----------
components: IO
messages: 101584
nosy: noam
severity: normal
status: open
title: Python 3 ignored PYTHONUNBUFFERED and -u
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Mar 23 23:12:13 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Mar 2010 22:12:13 +0000
Subject: [New-bugs-announce] [issue8214] Add exception logging function to
	syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>


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

Sean Reifschneider proposed [1] adding the ability to log an exception using the syslog module.

My proposed implementation is along the lines of:

def logexceptions(chain=True):
    import sys
    import traceback
    import syslog

    # Should we chain to the existing sys.excepthook?
    current_hook = sys.excepthook if chain else None

    def syslog_exception(etype, evalue, etb):
        if current_hook:
            current_hook(etype, evalue, etb)
        # The result of traceback.format_exception might contain
        # embedded newlines, so we have the nested loops.
        for line in traceback.format_exception(etype, evalue, etb):
            for line in line.rstrip().split('\n'):
                syslog.syslog(line)
    sys.excepthook = syslog_exception

Although it would need to be written in C to work in the existing syslog module, and of course it would call syslog.syslog directly.


[1] http://mail.python.org/pipermail/python-ideas/2010-March/006927.html

----------
messages: 101605
nosy: eric.smith, jafo
priority: normal
severity: normal
stage: needs patch
status: open
title: Add exception logging function to syslog module
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Mar 23 23:29:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Mar 2010 22:29:01 +0000
Subject: [New-bugs-announce] [issue8215] getargs.c in Python3 contains some
	TODO and the	documentation is outdated
In-Reply-To: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>
Message-ID: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/c-api/arg.html contains some ambiguous (string or Unicode object) definitions: what is a string? what is an unicode object? Is it a string or not? The problem is that the documentation is for Python2: the code was changed, but not the documentation. I think that it can be replaced by (unicode objet) with lower U to be consistent with (bytes object).

---

There are two functions: getbuffer() and convertbuffer().

getbuffer(): pb=arg->ob_type->tp_as_buffer
 - if pb->bf_getbuffer is not NULL: call PyObject_GetBuffer(arg, view, PyBUF_SIMPLE) and PyBuffer_IsContiguous(view, 'C')
 - if pb->bf_getbuffer is NULL: call convertbuffer()

convertbuffer() calls PyObject_GetBuffer(arg, &view, PyBUF_SIMPLE).

---

"s#", "y", "z" formats use convertbuffer()

"s", "y*", "z*" formats uses getbuffer().

"t" format reimplements convertbuffer().

"w*" format calls PyObject_GetBuffer(arg, (Py_buffer*)p, PyBUF_WRITABLE) and PyBuffer_IsContiguous((Py_buffer*)p, 'C').

"w" and "w#" formats call PyObject_GetBuffer(arg, &view, PyBUF_SIMPLE).

I think that all these cases should be factorized in one unique function.

Is it a bug, or functions using "s#", "y", "z", "t" formats do really support discontinious buffers?

Related PEP: http://www.python.org/dev/peps/pep-3118/

----------
components: Interpreter Core
messages: 101606
nosy: haypo
severity: normal
status: open
title: getargs.c in Python3 contains some TODO and the documentation is outdated
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Mar 23 23:44:04 2010
From: report at bugs.python.org (Nobody/Anonymous)
Date: Tue, 23 Mar 2010 22:44:04 +0000
Subject: [New-bugs-announce] [issue8216] Nur jetzt beste Software zu besten
	Preisen!
In-Reply-To: <9985340552.MB9N7E62837578@sapzsxhlyoyd.kfnuasmdp.com>
Message-ID: <9985340552.MB9N7E62837578@sapzsxhlyoyd.kfnuasmdp.com>


New submission from Nobody/Anonymous:

body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar at section top bar at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar at section top bar links at tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body at section default text at tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body at section appointment detail at tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body at section title style at tip Primary headline at theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body at section subtitle style at tip Secondary headline at theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer at section footer at tip Use the same color as your background to create the page curl at theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer at section link style at tip Specify a color for your footer hyperlinks. at theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links at section link style at tip Specify a color for all the hyperlinks in your email. at theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}																					Email not displaying correctly? View it in your browser.																	  				    Heute nur! Beste Software zum besten Preis!

In unserem  online-Geschaeft finden Sie eine riesige Auswahl, ein grosses Sortiment der besten Software. Qualitaet jedes Programms geprueft! Hier bekommen Sie das Beste nur! 
Jetzt Bekommen Sie Software Einfach Billiger

Unsubscribe report at bugs.python.org | Update your profile

You are receiving this email because you subscribed to Our Newsletter.

Redmiller LTD
4347 Bottom Lane
Southfield MI 48075

Copyright (C) 2010 Redmiller LTD All rights reserved.

----------
files: unnamed
messages: 101608
nosy: nobody
severity: normal
status: open
title: Nur jetzt beste Software zu besten Preisen!
Added file: http://bugs.python.org/file16633/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8216>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE></STYLE>
</HEAD>
<BODY>
<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		
	<style type="text/css">body,#wrap{text-align:center;margin:0px;background-color:#FFFEF8;}/*@tab Top bar
@section top bar
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header{background-color:#FFFEF8;margin:0px;/*@editable*/padding:10px;/*@editable*/color:#666;/*@editable*/font-size:11px;/*@editable*/font-family:Arial;/*@editable*/font-weight:normal;/*@editable*/text-align:center;/*@editable*/text-transform:lowercase;/*@editable*/border:none 0px #FFF;}/*@tab Top bar
@section top bar links
@tip Choose a set of colors that look good with the colors of your logo image or text header.*/#header a,#header a:link,#header a:visited{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Body
@section default text
@tip This is the base font for the content of the email*/#layout{margin:0px auto;/*@editable*/text-align:center;/*@editable*/font-family:Georgia;/*@editable*/color:#404040;/*@editable*/line-height:160%;font-size:16px;}/*@tab Body
@section appointment detail
@tip appointment detail styles*/#appointment{/*@editable*/color:#666;/*@editable*/font-size:18px;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/text-align:center;/*@editable*/padding:0px 0px 40px 0px;}/*@tab Body
@section title style
@tip Primary headline
@theme title*/.primary-heading{/*@editable*/font-size:54px;/*@editable*/color:#000;/*@editable*/font-weight:normal;/*@editable*/font-family:Georgia;/*@editable*/line-height:120%;/*@editable*/margin:10px 0;}/*@tab Body
@section subtitle style
@tip Secondary headline
@theme subtitle*/.secondary-heading{/*@editable*/color:#000;/*@editable*/font-size:24px;/*@editable*/font-weight:normal;/*@editable*/font-style:normal;/*@editable*/font-family:Georgia;/*@editable*/margin:30px 0 10px 0;}/*@tab Footer
@section footer
@tip Use the same color as your background to create the page curl
@theme footer*/#footer{background-color:#FFFEF8;/*@editable*/border-top:1px solid #CCC;/*@editable*/padding:20px;/*@editable*/font-size:10px;/*@editable*/color:#666;/*@editable*/line-height:100%;/*@editable*/font-family:Arial;/*@editable*/text-align:center;}/*@tab Footer
@section link style
@tip Specify a color for your footer hyperlinks.
@theme link_footer*/#footer a{/*@editable*/color:#666;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}/*@tab Links
@section link style
@tip Specify a color for all the hyperlinks in your email.
@theme link*/a,a:link,a:visited{/*@editable*/color:#336699;/*@editable*/text-decoration:underline;/*@editable*/font-weight:normal;}</style></head>
	<body class="background">
		<div id="wrap" class="background">
			<table id="layout" border="0" cellspacing="0" cellpadding="0" width="600" class="layout_background">
				<tr>
					<td id="header" mc:edit="header" colspan="3">
						<span>Email not displaying correctly? <a href="http://ryzywuxym.spaces.live.com" target="_blank">View it in your browser.</a></span>
					</td>
				</tr>
				<tr>
				  <td id="lead_content" mc:edit="main" colspan="3">
				    <h1 class="primary-heading">Heute nur! Beste Software zum besten Preis!</h1>
				    <p>In unserem  online-Geschaeft finden Sie eine riesige Auswahl, ein grosses Sortiment der besten Software. Qualitaet jedes Programms geprueft! Hier bekommen Sie das Beste nur! </p><a href="http://ryzywuxym.spaces.live.com">Jetzt Bekommen Sie Software Einfach Billiger</a><br>
				  </td>
				</tr>
			  <tr>
					<td id="footer" mc:edit="footer" colspan="3" class="background">
					    <p><a href="http://ryzywuxym.spaces.live.com">Unsubscribe</a> report at bugs.python.org | <a href="http://ryzywuxym.spaces.live.com">Update your profile</a></p>

						<p>You are receiving this email because you subscribed to Our Newsletter.</p>

					    <p>Redmiller LTD<br>4347 Bottom Lane<br>Southfield MI 48075</p>
					    <p>Copyright (C) 2010 Redmiller LTD All rights reserved.</p>
					</td>
				</tr>
			</table>
		</div>
	</body>
</html>

</BODY></HTML>

From report at bugs.python.org  Wed Mar 24 00:20:36 2010
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 23 Mar 2010 23:20:36 +0000
Subject: [New-bugs-announce] [issue8217] typo  unterlying
In-Reply-To: <1269386436.19.0.823512367997.issue8217@psf.upfronthosting.co.za>
Message-ID: <1269386436.19.0.823512367997.issue8217@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/howto/webservers.html

The low-level view

When a user enters a web site, his browser makes a connection to the site?s webserver (this is called the request). The server looks up the file in the file system and sends it back to the user?s browser, which displays it (this is the response). This is roughly how the unterlying protocol, HTTP works.

----------
assignee: georg.brandl
components: Documentation
messages: 101610
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: typo  unterlying
versions: Python 3.1

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

From report at bugs.python.org  Wed Mar 24 02:43:11 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 24 Mar 2010 01:43:11 +0000
Subject: [New-bugs-announce] [issue8218] typo currect
In-Reply-To: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>
Message-ID: <1269394991.51.0.861768873468.issue8218@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/howto/webservers.html

The path to the interpreter in the shebang (#!/usr/bin/env python) must be currect.


Sorry man there are a great many distractions here.

----------
assignee: georg.brandl
components: Documentation
messages: 101614
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: typo currect
versions: Python 3.1

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

From report at bugs.python.org  Wed Mar 24 10:24:24 2010
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 24 Mar 2010 09:24:24 +0000
Subject: [New-bugs-announce] [issue8219] Facility and priority
	values/constants not documented for	SysLogHandler
In-Reply-To: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>
Message-ID: <1269422664.92.0.399836778126.issue8219@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

http://docs.python.org/dev/py3k/library/logging.html#logging.handlers.SysLogHandler

What to use as the value for facility for SysLogHandler's constructor is not documented.  There's a reference to LOG_USER, but it's kind of vague because it doesn't specify what LOG_USER it refers to - there's no mention that SysLogHandler itself has these constants.  And the corresponding documented values from the syslog module are not compatible with the ones SysLogHandler works with.

Similarly, the values for facility and priority for SysLogHandler.encodePriority() are not documented, it just talks about integers and strings without saying what they are.

I suggest documenting all the SysLogHandler.LOG_* constants and the priority and facility mapping strings in SysLogHandler's priority_names and facility_names dicts.

----------
assignee: georg.brandl
components: Documentation
messages: 101629
nosy: georg.brandl, scop
severity: normal
status: open
title: Facility and priority values/constants not documented for SysLogHandler
type: feature request

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

From report at bugs.python.org  Wed Mar 24 15:52:37 2010
From: report at bugs.python.org (Ralph Corderoy)
Date: Wed, 24 Mar 2010 14:52:37 +0000
Subject: [New-bugs-announce] [issue8220] site.py's Quitter pollutes builtins
	with exit and quit	for non-interactive use
In-Reply-To: <1269442357.88.0.102314417571.issue8220@psf.upfronthosting.co.za>
Message-ID: <1269442357.88.0.102314417571.issue8220@psf.upfronthosting.co.za>


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

A friend wrote "exit(0)" in a script without an import of sys.  I
pointed out the error and he said "But it works".  He was right.

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 9.10
    Release:        9.10
    Codename:       karmic
    $ python --version
    Python 2.6.4
    $ python -c 'quit("foo")'
    foo
    $ echo $?
    1
    $ python -Sc 'quit("foo")'
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    NameError: name 'quit' is not defined
    $ python -c 'print quit.__class__, exit.__class__'
    <class 'site.Quitter'> <class 'site.Quitter'>
    $

site.py is polluting, to my mind, the builtin namespace with `exit' and 
`quit'.  Surely this should only happen for interactive use of python?

http://docs.python.org/library/constants.html#exit says "They are useful
for the interactive interpreter shell and should not be used in
programs." but it seems to easy for exit, especially, to be used by
mistake.

Could the pollution only happen if the Python interpreter is an
interactive one?  Or, not as good, when called, could they tell this
isn't an interactive session and error?

----------
components: Library (Lib)
messages: 101635
nosy: ralph.corderoy
severity: normal
status: open
title: site.py's Quitter pollutes builtins with exit and quit for non-interactive use
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Mar 24 16:06:20 2010
From: report at bugs.python.org (Robert Kern)
Date: Wed, 24 Mar 2010 15:06:20 +0000
Subject: [New-bugs-announce] [issue8221] 2to3 mishandles StringIO inside a
	package with an io.py	module
In-Reply-To: <1269443180.02.0.978577516398.issue8221@psf.upfronthosting.co.za>
Message-ID: <1269443180.02.0.978577516398.issue8221@psf.upfronthosting.co.za>


New submission from Robert Kern <robert.kern at gmail.com>:

When a module inside a package imports StringIO from cStringIO, it should change that to "from io import StringIO". However, if there is a module inside the package named io.py, 2to3 changes it to "from .io import StringIO".

[bug23]$ tree
.
`-- package
    |-- __init__.py
    |-- helper.py
    `-- io.py

1 directory, 3 files

[bug23]$ cat package/helper.py
from cStringIO import StringIO

[bug23]$ 2to3 package         
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- package/helper.py (original)
+++ package/helper.py (refactored)
@@ -1,1 +1,1 @@
-from cStringIO import StringIO
+from .io import StringIO
RefactoringTool: Files that need to be modified:
RefactoringTool: package/helper.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 101636
nosy: Robert.Kern
severity: normal
status: open
title: 2to3 mishandles StringIO inside a package with an io.py module
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 24 17:33:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Mar 2010 16:33:21 +0000
Subject: [New-bugs-announce] [issue8222] enabling SSL_ERROR_WANT_READ on SSL
	sockets
In-Reply-To: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>
Message-ID: <1269448401.87.0.655952787423.issue8222@psf.upfronthosting.co.za>


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

In light of the recv() and recv_into() implementation change (issue3890), I think we should enable SSL_MODE_AUTO_RETRY for SSL sockets. It prevents blocking read() calls from getting SSL_ERROR_WANT_READ at all.
(previously, we would loop manually in recv() and recv_into(); letting
the C OpenSSL runtime do it for us is certainly more efficient)

See description in
http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html:

? SSL_MODE_AUTO_RETRY

        Never bother the application with retries if the transport is
        blocking. If a renegotiation take place during normal operation,
        a SSL_read(3) or SSL_write(3) would return with -1 and indicate
        the need to retry with SSL_ERROR_WANT_READ. In a non-blocking
        environment applications must be prepared to handle incomplete
        read/write operations. In a blocking environment, applications
        are not always prepared to deal with read/write operations
        returning without success report. The flag SSL_MODE_AUTO_RETRY
        will cause read/write operations to only return after the
        handshake and successful completion. ?

----------
components: Library (Lib)
messages: 101640
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: enabling SSL_ERROR_WANT_READ on SSL sockets
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Mar 24 17:55:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2010 16:55:33 +0000
Subject: [New-bugs-announce] [issue8223] memoryview is not documented in the
	Python library doc
In-Reply-To: <1269449733.3.0.970047691919.issue8223@psf.upfronthosting.co.za>
Message-ID: <1269449733.3.0.970047691919.issue8223@psf.upfronthosting.co.za>


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

memoryview() is not documented in the Python Library documentation, only in the C API ("buffer" chapiter) :-/
http://docs.python.org/c-api/buffer.html

See also #8215.

----------
assignee: georg.brandl
components: Documentation
messages: 101643
nosy: georg.brandl, haypo
severity: normal
status: open
title: memoryview is not documented in the Python library doc
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Mar 24 19:26:00 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 24 Mar 2010 18:26:00 +0000
Subject: [New-bugs-announce] [issue8224] subprocess.Popen raises
	WindowsError if there is a dot in	program name
In-Reply-To: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>
Message-ID: <1269455160.44.0.165523687087.issue8224@psf.upfronthosting.co.za>


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

Assume you have two executables in currect directory:

  baz.exe
  foo.bar.exe

Now "subprocess.Popen(['baz'])" will run successfully. But "subprocess.Popen(['foo.bar'])" will throw the following exception:

Traceback (most recent call last):
  [...]
  File "C:\Python26\lib\subprocess.py", line 483, in check_call
    retcode = call(*popenargs, **kwargs)
  File "C:\Python26\lib\subprocess.py", line 470, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\Python26\lib\subprocess.py", line 621, in __init__
    errread, errwrite)
  File "C:\Python26\lib\subprocess.py", line 830, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified

The workaround is to specify the full name "foo.bar.exe".

----------
components: Library (Lib), Windows
messages: 101646
nosy: srid
severity: normal
status: open
title: subprocess.Popen raises WindowsError if there is a dot in program name
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 25 00:01:58 2010
From: report at bugs.python.org (Mangus Wahberg)
Date: Wed, 24 Mar 2010 23:01:58 +0000
Subject: [New-bugs-announce] [issue8225] Wrong link in xml.etree
	documentation
In-Reply-To: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>
Message-ID: <1269471718.81.0.104288873417.issue8225@psf.upfronthosting.co.za>


New submission from Mangus Wahberg <endast at gmail.com>:

When using the interactive python help and entering xml.etree the help page contains a link faulty link to the online documentation.

The link in the help page is:

 MODULE DOCS
    http://docs.python.org/library/xml.etree

But the correct link is:
http://docs.python.org/library/xml.etree.elementtree

----------
assignee: georg.brandl
components: Documentation
messages: 101655
nosy: georg.brandl, mangus.wahberg
severity: normal
status: open
title: Wrong link in xml.etree documentation
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 25 00:05:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Mar 2010 23:05:54 +0000
Subject: [New-bugs-announce] [issue8226] sys.setfilesystemencoding("xxx");
	open("a") => stack overflow
In-Reply-To: <1269471954.9.0.33641527211.issue8226@psf.upfronthosting.co.za>
Message-ID: <1269471954.9.0.33641527211.issue8226@psf.upfronthosting.co.za>


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

sys.setfilesystemencoding() doesn't check if the argument is a valid encoding name.

If the filesystem encoding is invalid, open("a") goes into an unlimited loop. The default recursion limit is 1000, but the example crash at 930: too bad :-) Each loop allocate ~9000 bytes: Linux creates a 8 MB stack by default, and so ~9000x930 uses all the stack.

Using a lower recursion limit, we can see the loop:
----------
$ ./python -c 'import sys; sys.setrecursionlimit(30); sys.setfilesystemencoding("xxx"); open("x")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 83, in search_function
    norm_encoding = normalize_encoding(encoding)
  File "/home/SHARE/SVN/py3k/Lib/encodings/__init__.py", line 55, in normalize_encoding
    if isinstance(encoding, bytes):
RuntimeError: maximum recursion depth exceeded while calling a Python object
----------

----------
components: Interpreter Core
messages: 101656
nosy: haypo
severity: normal
status: open
title: sys.setfilesystemencoding("xxx"); open("a") => stack overflow
type: crash
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Mar 25 01:09:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Mar 2010 00:09:18 +0000
Subject: [New-bugs-announce] [issue8227] Fix C API documentation: Argument
	parsing
In-Reply-To: <1269475758.09.0.479187943565.issue8227@psf.upfronthosting.co.za>
Message-ID: <1269475758.09.0.479187943565.issue8227@psf.upfronthosting.co.za>


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

Patch fixing Doc/c-api/arg.rst:
 * 'z', 'z#', 'z*' does also accept Unicode
 * unify types name: replace "string or Unicode objet" by "string or Unicode" (it's shorter ;-))

See also #8215 and #2322.

----------
assignee: georg.brandl
components: Documentation
files: c-api_arg.patch
keywords: patch
messages: 101659
nosy: georg.brandl, haypo
severity: normal
status: open
title: Fix C API documentation: Argument parsing
versions: Python 2.7
Added file: http://bugs.python.org/file16636/c-api_arg.patch

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

From report at bugs.python.org  Thu Mar 25 07:16:00 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Thu, 25 Mar 2010 06:16:00 +0000
Subject: [New-bugs-announce] [issue8228] pprint,
	single/multiple items per line parameter
In-Reply-To: <1269497760.71.0.432450737837.issue8228@psf.upfronthosting.co.za>
Message-ID: <1269497760.71.0.432450737837.issue8228@psf.upfronthosting.co.za>


New submission from Dmitry Chichkov <dchichkov at gmail.com>:

I've run into a case where pprint isn't really pretty. 

import pprint
pprint.PrettyPrinter().pprint([1]*100)

Prints a lengthy column of '1'; Not pretty at all. Look:

[1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1,
 1]

----------
components: Library (Lib)
messages: 101672
nosy: Dmitry.Chichkov
severity: normal
status: open
title: pprint, single/multiple items per line parameter
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Mar 25 09:50:58 2010
From: report at bugs.python.org (tb220)
Date: Thu, 25 Mar 2010 08:50:58 +0000
Subject: [New-bugs-announce] [issue8229] Interpreter crash on application
	shutdown
In-Reply-To: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>
Message-ID: <1269507058.23.0.138728346212.issue8229@psf.upfronthosting.co.za>


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

Attached the error report generated by Windows. The problem occurs in 1 out of 10 shutdowns.

----------
components: Interpreter Core, Windows
files: cabb_appcompat.txt
messages: 101679
nosy: tb220
severity: normal
status: open
title: Interpreter crash on application shutdown
versions: Python 2.6
Added file: http://bugs.python.org/file16642/cabb_appcompat.txt

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

From report at bugs.python.org  Thu Mar 25 14:04:27 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Thu, 25 Mar 2010 13:04:27 +0000
Subject: [New-bugs-announce] [issue8230] Lib/test/sortperf.py fails to run
In-Reply-To: <1269522267.95.0.58025957624.issue8230@psf.upfronthosting.co.za>
Message-ID: <1269522267.95.0.58025957624.issue8230@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

There is a test file Lib/test/sortperf.py, which isn't properly updated
to python3, because it considers map and range returning a list instead of an iterator and therefore throwing an exception when run. I have attached a patch to fix it.

----------
components: Tests
files: sortperf.diff
keywords: patch
messages: 101693
nosy: pyfex
severity: normal
status: open
title: Lib/test/sortperf.py fails to run
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16643/sortperf.diff

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

From report at bugs.python.org  Thu Mar 25 16:39:29 2010
From: report at bugs.python.org (cane)
Date: Thu, 25 Mar 2010 15:39:29 +0000
Subject: [New-bugs-announce] [issue8231] Subprocess Startup Error - unable
	to create user config	directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>


New submission from cane <bryan.hoffman at mnsu.edu>:

When trying to run Python 2.6.5 & 3.1 IDLE GUI on Windows 7, I receive the following error that the "IDLE's subprocess didnt make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection."

I've researched this error and tried following the steps to troubleshoot this error without any success.  I do not have any firewall software installed or have the Microsoft firewall enabled.  When following issue 8099 and tring to set the TCL and TK library to the idle.py I get the error that I need to check the path and permissions. (see attached screenshot)

These workstations are setup in active directory enviroment where each username that logs into the workstation is a local administrator and the referenced "M:\" drive is a home directory that is mapped for them.

When the local administrator account logs into the workstation the user can execute the IDLE GUI without any issues.

I found reference in one article that the os.py creates a directory called ".idlerc". 

I'm wondering if there is a way to hardcode a reference path that doesnt point to my "M:\" drive for this directory or is there something else that I can try to fix this issue?

Thanks,
Bryan

----------
components: Windows
files: error.png
messages: 101708
nosy: cane
severity: normal
status: open
title: Subprocess Startup Error - unable to create user config directory
type: crash
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file16649/error.png

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

From report at bugs.python.org  Thu Mar 25 19:32:42 2010
From: report at bugs.python.org (Jonathan Chao)
Date: Thu, 25 Mar 2010 18:32:42 +0000
Subject: [New-bugs-announce] [issue8232] webbrowser open(), open_new(),
	and open_new_tab() Broken Functionality
In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>
Message-ID: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za>


New submission from Jonathan Chao <joncwchao at gmail.com>:

webbrowser.open(), webbrowser.open_new(), and webbrowser.open_new_tab() all do the exact same thing, regardless of the flags that I set. In Firefox, open('www.google.com', new=0), open_new('www.google.com'), and open_new_tab('www.google.com') all open either three new www.google.com tabs (if "Open new windows in a new tab instead" is selected in FF options) or three new www.google.com windows (if "Open new windows in a new tab instead" is not selected in FF options). In Internet Explorer, three new www.google.com tabs are created.

The issue exhibits itself the same way whether or not I have the browser open before running the script.

Environment was a Windows Vista 32-bit machine, running Python 3.1.2.

Example script reads:
import webbrowser
import time
ff = webbrowser.get('firefox')
ff.open('www.google.com', new=0)
time.sleep(3)
ff.open_new('www.google.com')
time.sleep(3)
ff.open_new_tab('www.google.com')

----------
components: Library (Lib)
messages: 101725
nosy: joncwchao
severity: normal
status: open
title: webbrowser open(), open_new(), and open_new_tab() Broken Functionality
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Mar 25 21:30:40 2010
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Thu, 25 Mar 2010 20:30:40 +0000
Subject: [New-bugs-announce] [issue8233] extend py_compile to compile files
	from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>


New submission from Piotr O?arowski <piotr at debian.org>:

Following issue 8140 - attached patches add functionality to take file names to be compiled from standard input in py_compile module (if '-' is the only parameter in args)

----------
components: Library (Lib)
files: py_compile.py.diff
keywords: patch
messages: 101730
nosy: barry, piotr
severity: normal
status: open
title: extend py_compile to compile files from stdin
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16658/py_compile.py.diff

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

From report at bugs.python.org  Thu Mar 25 22:47:45 2010
From: report at bugs.python.org (Yuv Gre)
Date: Thu, 25 Mar 2010 21:47:45 +0000
Subject: [New-bugs-announce] [issue8234] Spelling and text in
	howto/webservers
In-Reply-To: <1269553665.96.0.465279813253.issue8234@psf.upfronthosting.co.za>
Message-ID: <1269553665.96.0.465279813253.issue8234@psf.upfronthosting.co.za>


New submission from Yuv Gre <ubershmekel at gmail.com>:

A spelling mistake ("recommentation") and a bit rephrasing for clarity. I think better can be done, but more text would have to be moved around.

----------
assignee: georg.brandl
components: Documentation
files: webservers_spelling.patch
keywords: patch
messages: 101733
nosy: georg.brandl, ubershmekel
severity: normal
status: open
title: Spelling and text in howto/webservers
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file16660/webservers_spelling.patch

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

From report at bugs.python.org  Fri Mar 26 00:40:01 2010
From: report at bugs.python.org (Kyle VanderBeek)
Date: Thu, 25 Mar 2010 23:40:01 +0000
Subject: [New-bugs-announce] [issue8235] Support FreeBSD's SO_SETFIB in
	socketmodule.c
In-Reply-To: <1269560401.06.0.703544255222.issue8235@psf.upfronthosting.co.za>
Message-ID: <1269560401.06.0.703544255222.issue8235@psf.upfronthosting.co.za>


New submission from Kyle VanderBeek <kylev at kylev.com>:

FreeBSD has a [gs]etsockopt() constant used to cause a given socket to use an alternate routing table (FIB); it appeared in FreeBSD 7.1.  It would be useful to have this exposed as a constant in the socket module to allow special routing rules in complex environments.

----------
components: Extension Modules
files: python-SO_SETFIB.patch
keywords: patch
messages: 101736
nosy: kylev
severity: normal
status: open
title: Support FreeBSD's SO_SETFIB in socketmodule.c
type: feature request
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16662/python-SO_SETFIB.patch

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

From report at bugs.python.org  Fri Mar 26 03:13:41 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 26 Mar 2010 02:13:41 +0000
Subject: [New-bugs-announce] [issue8236] ./configure: ImportError: No module
	named asdl
In-Reply-To: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>
Message-ID: <1269569621.46.0.223841076285.issue8236@psf.upfronthosting.co.za>


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

I'm seeing this error with 2.6 and 3.1 maint branches (not sure about 2.7) on both Linux & Mac 32-bit builds. Does not happen on Linux 64-bit though. Also this is possibly caused by a recent commit, as we never saw this issue before.

[...]
creating Makefile
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "/home/apy/as/pypm-trunk/bin/python", line 49, in <module>
    execfile(__file__)
  File "./Parser/asdl_c.py", line 9, in <module>
    import asdl
ImportError: No module named asdl
make: *** [Include/Python-ast.h] Error 1

----------
components: Build, Interpreter Core
messages: 101738
nosy: srid
severity: normal
status: open
title: ./configure: ImportError: No module named asdl
type: compile error
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Mar 26 04:32:27 2010
From: report at bugs.python.org (Erdem U. Altinyurt)
Date: Fri, 26 Mar 2010 03:32:27 +0000
Subject: [New-bugs-announce] [issue8237] multiprocessing.Queue() blocks
	program
In-Reply-To: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>
Message-ID: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>


New submission from Erdem U. Altinyurt <spamjunkeater at gmail.com>:

multiprocessing.Queue() blocking program on my computer after adding 1400 entry (depending addition size).

Tested with 2.6.2 and 2.6.5(compiled from source with gcc 4.4.1)
Using 64 bit OpenSUSE  11.2.

Output is:
-----------
....
1398  done
1399  done
-----------

and enters deadlock because Q.put() cannot completed.
No problems with basic array with lock().
Here the result after pressing CTRL+C:

-----------------------------------
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in testQ
KeyboardInterrupt
>>> 
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/opt/python/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/opt/python/lib/python2.6/multiprocessing/util.py", line 269, in _exit_function
    p.join()
  File "/opt/python/lib/python2.6/multiprocessing/process.py", line 119, in join
    res = self._popen.wait(timeout)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 117, in wait
    return self.poll(0)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/opt/python/lib/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/opt/python/lib/python2.6/multiprocessing/util.py", line 269, in _exit_function
    p.join()
  File "/opt/python/lib/python2.6/multiprocessing/process.py", line 119, in join
    res = self._popen.wait(timeout)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 117, in wait
    return self.poll(0)
  File "/opt/python/lib/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt

----------
components: Library (Lib)
files: damine6.py
messages: 101740
nosy: eua
severity: normal
status: open
title: multiprocessing.Queue() blocks program
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file16666/damine6.py

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

From report at bugs.python.org  Fri Mar 26 08:33:15 2010
From: report at bugs.python.org (Ciprian Trofin)
Date: Fri, 26 Mar 2010 07:33:15 +0000
Subject: [New-bugs-announce] [issue8238] Proxy handling
In-Reply-To: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za>
Message-ID: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za>


New submission from Ciprian Trofin <ciprian.trofin at ktd.ro>:

After I installed Python 2.6.5, I noticed a drop in performance of web connections via proxy.

This script:
---------------------------------------------------------
import time
import urllib2

timeMark = time.time()
opener = urllib2.build_opener()
textWeb = opener.open("http://www.google.com/").read()
print time.time() - timeMark
---------------------------------------------------------

takes about 60 seconds to complete (consistently)

The same script, run using Python 2.6.2 is completed in less than 1 second  (0.2seconds)

The test system:
- Windows XP SP3
- internet connection via corporate connection, using a proxy (the proxy is set in Control Panel - Internet Options etc)

----------
components: None
messages: 101742
nosy: ciprian.trofin
severity: normal
status: open
title: Proxy handling
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar 26 10:10:55 2010
From: report at bugs.python.org (Peter)
Date: Fri, 26 Mar 2010 09:10:55 +0000
Subject: [New-bugs-announce] [issue8239] Windows 2.6.5 Installer Advanced
	Option Generates Error	Message During Compile Step
In-Reply-To: <1269594655.23.0.434243069051.issue8239@psf.upfronthosting.co.za>
Message-ID: <1269594655.23.0.434243069051.issue8239@psf.upfronthosting.co.za>


New submission from Peter <ps1956 at users.sourceforge.net>:

If the installer is run in Windows XP/SP3 without selecting the Advanced compiling option, it works fine.  If the installer is run in Windows XP/SP3 and the Advanced compiling option is selected, the following error message is generated during the compile step:

"There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support 
personnel or package vendor."

The relevant part of the log when the installer fails using the Advanced compiling option is as follows:

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

MSI (s) (4C:B4) [14:41:27:205]: Doing action: CompilePyc
Action 14:41:27: CompilePyc. 
Action start 14:41:27: CompilePyc.
MSI (s) (4C:B4) [14:45:45:528]: Note: 1: 1722 2: CompilePyc 3: C:\bin
\Python26\python.exe 4: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x 
bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 
MSI (s) (4C:B4) [14:45:45:528]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1722. There is a problem with this Windows Installer package. A 
program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action CompilePyc, location: C:\bin\Python26\python.exe, command: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 
MSI (s) (4C:B4) [14:47:41:133]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (4C:B4) [14:47:41:133]: Product: Python 2.6.5 -- Error 1722. 
There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support 
personnel or package vendor.  Action CompilePyc, location: C:\bin\Python26 \python.exe, command: -Wi "C:\bin\Python26\Lib\compileall.py" -f -x bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib" 

Action ended 14:47:41: CompilePyc. Return value 3.
Action ended 14:47:41: INSTALL. Return value 3.

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

I believe the cause of this installation failure message is due to the 
syntax of the following command:

C:\bin\Python26\python.exe -Wi "C:\bin\Python26\Lib\compileall.py" -f -x bad_coding|badsyntax|site-packages|py3_ "C:\bin\Python26\Lib"

If this command is run in the Windows XP shell, it yields an error.  If the -x option's args are wrapped in double quotes, it runs ok (except for a syntax error when compiling one of the python source files - I don't remember which one):

C:\bin\Python26\python.exe -Wi "C:\bin\Python26\Lib\compileall.py" -f -x "bad_coding|badsyntax|site-packages|py3_" "C:\bin\Python26\Lib"

So it appears that the Windows XP shell is interpreting the "|" 
characters within the -x option's args as pipe characters and tries to 
pipe the "multiple commands" together.

The simple work around is to not use the Advanced compiling option with this release.  If wanted, the compilation step can be performed manually after the installation completes.

----------
components: Installation, Windows
messages: 101746
nosy: ps1956
severity: normal
status: open
title: Windows 2.6.5 Installer Advanced Option Generates Error Message During Compile Step
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Mar 26 16:30:34 2010
From: report at bugs.python.org (Cyril)
Date: Fri, 26 Mar 2010 15:30:34 +0000
Subject: [New-bugs-announce] [issue8240] ssl.SSLSocket.write may fail on
	non-blocking sockets
In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>
Message-ID: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za>


New submission from Cyril <cbay at excellency.fr>:

ssl.SSLSocket.write on non-blocking sockets will fail with:

_ssl.c:1217: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry

on a write retry, if the buffer address has changed between the initial call and the retry (when the initial call returned 0 bytes written, which means you should try again later).

>From OpenSSL docs (http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html):

SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer location (the buffer contents must stay the same). This is not the default to avoid the misconception that non-blocking SSL_write() behaves like non-blocking write().

Attached patch fixes the problem (tested on Python 2.6.5, 2.7 trunk) by calling SSL_CTX_set_mode with SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER. It's a single line patch.

----------
components: Library (Lib)
files: _ssl.c.patch
keywords: patch
messages: 101753
nosy: cbay
severity: normal
status: open
title: ssl.SSLSocket.write may fail on non-blocking sockets
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16668/_ssl.c.patch

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

From report at bugs.python.org  Sat Mar 27 01:49:00 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 27 Mar 2010 00:49:00 +0000
Subject: [New-bugs-announce] [issue8241] py2_test_grammar.py contains
	invalid syntax for 2.6
In-Reply-To: <1269650940.6.0.32953947115.issue8241@psf.upfronthosting.co.za>
Message-ID: <1269650940.6.0.32953947115.issue8241@psf.upfronthosting.co.za>


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

Lib\lib2to3\tests\data\py2_test_grammar.py, in test_with_statement, requires a variant of the with statement (multiple targets) that is not available in Python 2.6.  Compiling py2_test_grammar.py raises a SyntaxError.  This makes the 2.6.5 installer exit with an error message when asked to pre-compile all .pyc files, as reported in issue6716.

The fix is simply to remove the last three 'with' statements in function test_with_statement, around line 923 in Lib\lib2to3\tests\data\py2_test_grammar.py, as this is invalid code for this Python version.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 101779
nosy: gagenellina
severity: normal
status: open
title: py2_test_grammar.py contains invalid syntax for 2.6
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Mar 27 02:12:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Mar 2010 01:12:37 +0000
Subject: [New-bugs-announce] [issue8242] Support surrogates in import ;
	install Python in a non-ASCII directory
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>


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

If the fullpath to the python3 binary contains a non-ASCII character and the file system encoding is ASCII, Python fails with:
---
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8
Abandon
---

The file system encoding is set to ASCII if there is no locale (eg. LANG=C).

The problem is that the command line argument, especially argv[0], is stored to a wchar_t* string using surrogates to store undecodable bytes.

Attached patch fixes calculate_path() and import functions to support surrogates. Details:

 * Initialize Py_FileSystemDefaultEncoding earlier in Py_InitializeEx(), because its value is required to encode unicode using surrogates to bytes
 * Rename char2wchar() to _Py_char2wchar(), the function is not more static ; and create function _Py_wchar2char()
 * Escape surrogates (reimplement surrogateescape decoder) in calculate_path() subfunctions (_wstat, _wgetcwd, _Py_wreadlink)
 * Use surrogateescape error handler in find_module(), NullImporter_init() and zipimporter_init()
 * Write a "fastpath" (I don't know the right term: is it an hack?) for utf-8 encoding with surrogateescape error handler in PyUnicode_AsEncodedObject() and PyUnicode_AsEncodedString(): required because these functions are called by codecs module is initialized

The patch is a work in progress: there are some FIXME (I don't know if the string should be encoded/decoded using surrogates or not).

I only tested ASCII and UTF-8 file system encodings. I don't know if we can support more encodings. Python has few builtin encodings. Other encodings are implemented in Python: we have to import them, but we need the codec to import a module, so...

I don't think that Windows is affected by this issue because it has a better API for unicode filenames and command line arguments, and most patched functions are surrounded by #ifndef WINDOWS ... #endif

----------
components: Unicode
files: surrogates_bootstrap-4.patch
keywords: patch
messages: 101815
nosy: haypo
severity: normal
status: open
title: Support surrogates in import ; install Python in a non-ASCII directory
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16671/surrogates_bootstrap-4.patch

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

From report at bugs.python.org  Sat Mar 27 06:01:07 2010
From: report at bugs.python.org (Daniel Vim)
Date: Sat, 27 Mar 2010 05:01:07 +0000
Subject: [New-bugs-announce] [issue8243] curses writing to window's bottom
	right position raises:	`_curses.error: addstr() returned ERR'
Message-ID: <1269666067.28.0.32380615709.issue8243@psf.upfronthosting.co.za>


Changes by Daniel Vim <333222 at gmail.com>:


----------
files: curses_bug.py
nosy: theosp
severity: normal
status: open
title: curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR'
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16673/curses_bug.py

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

From report at bugs.python.org  Sat Mar 27 15:29:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Mar 2010 14:29:28 +0000
Subject: [New-bugs-announce] [issue8244] Remove obsolete update.sh in PEPs
	repo
In-Reply-To: <1269700168.47.0.104127262998.issue8244@psf.upfronthosting.co.za>
Message-ID: <1269700168.47.0.104127262998.issue8244@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Hello

A script named update.sh was added to the PEPs repository seven years ago to batch convert text PEPs to HTML and push them to a public server (http://svn.python.org/view/peps/trunk/update.sh). I suggest removing it  as it appears to have been unmaintained and superseded by a makefile that is maintained and used (http://svn.python.org/view/peps/trunk/Makefile) together with a post-commit hook.

Regards

----------
assignee: georg.brandl
components: Documentation
messages: 101830
nosy: georg.brandl, merwok
severity: normal
status: open
title: Remove obsolete update.sh in PEPs repo

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

From report at bugs.python.org  Sat Mar 27 19:20:48 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 27 Mar 2010 18:20:48 +0000
Subject: [New-bugs-announce] [issue8245] email examples don't actually work
	(SMTP.connect is not	called)
In-Reply-To: <1269714048.68.0.587279851175.issue8245@psf.upfronthosting.co.za>
Message-ID: <1269714048.68.0.587279851175.issue8245@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Documentation for Python 2.6.5 and 3.1.2 both describe using the smtplib as so:

    s = smtplib.SMTP()
    s.sendmail(me, [you], msg.as_string())
    s.quit()

However, this sample usage is incorrect and doesn't work in practice, because s.connect() is never called. If the reader copies the example code, he will get an error on the call to sendmail:

    smtplib.SMTPServerDisconnected: please run connect() first

The documentation should be updated to reflect the requisite s.connect() call (or to supply sample host/port parameters in the construction).

It appears that in the 2.3.5 docs, the .connect() call was there. I have not yet investigated why it was removed.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 101833
nosy: georg.brandl, jaraco
severity: normal
status: open
title: email examples don't actually work (SMTP.connect is not called)
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Mar 27 19:32:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Mar 2010 18:32:21 +0000
Subject: [New-bugs-announce] [issue8246] test_signal in test_subprocess
	displays traceback
In-Reply-To: <1269714741.15.0.369806249635.issue8246@psf.upfronthosting.co.za>
Message-ID: <1269714741.15.0.369806249635.issue8246@psf.upfronthosting.co.za>


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

test_signal in test_subprocess doesn't mute the subprocess stderr, which gives output such as:

test_subprocess
.
    this bit of output is from a test of stdout in a different process ...
.
    this bit of output is from a test of stdout in a different process ...
.
    this bit of output is from a test of stdout in a different process ...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt

----------
components: Tests
messages: 101836
nosy: flox, gps, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: test_signal in test_subprocess displays traceback
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Mar 28 03:59:29 2010
From: report at bugs.python.org (Matt B)
Date: Sun, 28 Mar 2010 01:59:29 +0000
Subject: [New-bugs-announce] [issue8247] Can't Import Tkinter
In-Reply-To: <1269741569.3.0.106756150038.issue8247@psf.upfronthosting.co.za>
Message-ID: <1269741569.3.0.106756150038.issue8247@psf.upfronthosting.co.za>


New submission from Matt B <mattcbro at earthlink.net>:

>>> import _tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: %1 is not a valid Win32 application.

I 'upgraded' to python 2.6.5 by downloading the windows 64 bit installer.  I'm running windows 7 64 bit.  Everything worked great in 2.6.4 by the way.  I had a similar problem with numpy,  but reinstalling it from this site seemed to fix it:
http://www.lfd.uci.edu/~gohlke/pythonlibs/

I can only speculate what happened.  If I knew what DLL failed to load I could easily check to see if there were dependency issues or 64/32 bit issues.  Perhaps the old dll is still around? If so then there is an issue with the installer I think.

No doubt the issues extends beyond just Tkinter.

----------
components: Tkinter
messages: 101852
nosy: SevenThunders
severity: normal
status: open
title: Can't Import Tkinter
versions: Python 2.6

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

From report at bugs.python.org  Sun Mar 28 05:03:13 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Sun, 28 Mar 2010 03:03:13 +0000
Subject: [New-bugs-announce] [issue8248] Add test cases for bool
In-Reply-To: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>
Message-ID: <1269745393.1.0.997063465461.issue8248@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

These patches add these new test cases to test_bool.py.

Python 2+3:
- Conversion to float
- Conversion to Decimal
- Calling bool() of built-in types

Python 2 only:
- __index__()
- Conversion to long
- sprintf formatting

NOTE: I'm currently helping Dino Viehland port IronPython tests into CPython. This is the first of that series.

----------
components: Tests
files: test_bool.v2.patch
keywords: patch
messages: 101853
nosy: dino.viehland, gnofi
severity: normal
status: open
title: Add test cases for bool
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16677/test_bool.v2.patch

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

From report at bugs.python.org  Sun Mar 28 10:26:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Mar 2010 08:26:46 +0000
Subject: [New-bugs-announce] [issue8249] expat.ParserCreate - SystemError
	bad argument to internal	function
In-Reply-To: <1269764806.84.0.114625164995.issue8249@psf.upfronthosting.co.za>
Message-ID: <1269764806.84.0.114625164995.issue8249@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

First call gave a segfault. Following calls were successful.

Python 2.7a4+ (trunk:79443M, Mar 26 2010, 16:46:11)

~ $ python ../svnmerge.py -F -M merge -r79450,79427,79426,79425,79382,79310,79297
Traceback (most recent call last):
  File "../svnmerge.py", line 2366, in <module>
    main(sys.argv[1:])
  File "../svnmerge.py", line 2361, in main
    cmd(branch_dir, branch_props)
  File "../svnmerge.py", line 1813, in __call__
    return self.func(*args, **kwargs)
  File "../svnmerge.py", line 1483, in action_merge
    should_find_reflected(branch_dir))
  File "../svnmerge.py", line 1263, in analyze_source_revs
    return analyze_revs(branch_pathid, source_url, base, end_rev, **kwargs)
  File "../svnmerge.py", line 1215, in analyze_revs
    logs[url] = RevisionLog(url, begin, end, find_reflected)
  File "../svnmerge.py", line 535, in __init__
    split_lines=False)):
  File "../svnmerge.py", line 1034, in __getitem__
    for event, node in self._events:
  File "/opt/lib/python2.7/xml/dom/pulldom.py", line 232, in next
    rc = self.getEvent()
  File "/opt/lib/python2.7/xml/dom/pulldom.py", line 265, in getEvent
    self.parser.feed(buf)
  File "/opt/lib/python2.7/xml/sax/expatreader.py", line 198, in feed
    self.reset()
  File "/opt/lib/python2.7/xml/sax/expatreader.py", line 247, in reset
    intern=self._interning)
SystemError: Objects/methodobject.c:120: bad argument to internal function
Segmentation fault

----------
components: Extension Modules, XML
messages: 101856
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: expat.ParserCreate - SystemError bad argument to internal function
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar 28 13:16:17 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 11:16:17 +0000
Subject: [New-bugs-announce] [issue8250] Implement pkgutil APIs as described
	in PEP 376
Message-ID: <1269774977.39.0.584076815206.issue8250@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee: tarek
components: Distutils2
nosy: tarek
priority: normal
severity: normal
status: open
title: Implement pkgutil APIs as described in PEP 376
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Mar 28 13:39:05 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Mar 2010 11:39:05 +0000
Subject: [New-bugs-announce] [issue8251] WeakRefSet
In-Reply-To: <1269776345.53.0.282064096076.issue8251@psf.upfronthosting.co.za>
Message-ID: <1269776345.53.0.282064096076.issue8251@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

WeakRefSet would be a useful addition to the weakref module. I needed this for unittest recently but made do with a WeakRefKeyDictionary and setting the values to 1.

----------
components: Library (Lib)
messages: 101859
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: WeakRefSet
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Mar 28 16:28:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:28:36 +0000
Subject: [New-bugs-announce] [issue8252] add a metada section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>


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

let's add a metatadata section in setup.cfg, to express all the metadata fields instead of using setup.py options.

----------
assignee: tarek
components: Distutils2
messages: 101860
nosy: tarek
priority: normal
severity: normal
status: open
title: add a metada section in setup.cfg
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Mar 28 16:34:15 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:34:15 +0000
Subject: [New-bugs-announce] [issue8253] add a resource+files section in
	setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>


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

Implement the [resources] section described in:

http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst

We also need to add a description of packages, scripts and modules.
The result should be that projects will not need a setup.py file anymore

----------
assignee: tarek
components: Distutils2
messages: 101861
nosy: tarek
priority: normal
severity: normal
status: open
title: add a resource+files section in setup.cfg
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Mar 28 16:41:24 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:41:24 +0000
Subject: [New-bugs-announce] [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>


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

This command will contain all options that are used to build extensions (out of the build* and install* commands) and will create a confifuration file.

build* and install* commands will be able to read back the file if present, and use its values, so we don't have to pass the options again.

See 4Suite configure command for an example

----------
assignee: tarek
components: Distutils2
messages: 101864
nosy: tarek
priority: normal
severity: normal
status: open
title: write a configure command
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Mar 28 16:47:17 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 28 Mar 2010 14:47:17 +0000
Subject: [New-bugs-announce] [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>


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

Write a tutorial to describe the cycle of a Python project that is built, released and deployed, using Distutils2. This project will need to be complete enough to cover most use cases.

This tutorial will be part of the Distutils2 documentation and will be also added in the hitchhicker guide.

----------
assignee: tarek
components: Distutils2
messages: 101865
nosy: tarek
priority: normal
severity: normal
status: open
title: step-by-step tutorial
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Mar 28 22:15:16 2010
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sun, 28 Mar 2010 20:15:16 +0000
Subject: [New-bugs-announce] [issue8256] TypeError: bad argument type for
	built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

I'm getting a "TypeError: bad argument type for built-in operation" on a print() with no arguments.  This seems to be a problem in both 3.1 and 3.1.2 (haven't tried 3.1.1).

I've narrowed the problem down in a very small demo program that you can run to reproduce the bug.  Just do "python3.1 bug.py" and hit <ENTER> at the "prompt:".

Removing the doctest call (and calling "foo" directly) doesn't get the error.  Also removing the "input" call (and leaving the doctest call in) doesn't get the error.

The startup banner on my python3.1 is:
Python 3.1.2 (r312:79147, Mar 26 2010, 16:55:44) 
[GCC 4.3.3] on linux2

I compiled python 3.1.2 with ./configure, make, make altinstall without any options.  I'm running ubuntu 9.04 with the 2.6.28-18-generic (32-bit) kernel.

----------
components: IO, Interpreter Core, Library (Lib)
files: bug.py
messages: 101874
nosy: dangyogi
severity: normal
status: open
title: TypeError: bad argument type for built-in operation
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file16681/bug.py

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

From report at bugs.python.org  Mon Mar 29 01:12:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Mar 2010 23:12:21 +0000
Subject: [New-bugs-announce] [issue8257] Decimal constructor to accept float
In-Reply-To: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>
Message-ID: <1269817941.42.0.43725007158.issue8257@psf.upfronthosting.co.za>


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

Per discussion on python-dev, let Decimal(x) accept floats as a possible input, making Decimal.from_float unnecessary.

See attached patch.

----------
assignee: mark.dickinson
files: deci_float_constructor.diff
keywords: easy, patch
messages: 101882
nosy: mark.dickinson, rhettinger
severity: normal
stage: patch review
status: open
title: Decimal constructor to accept float
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16683/deci_float_constructor.diff

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

From report at bugs.python.org  Mon Mar 29 12:08:13 2010
From: report at bugs.python.org (William)
Date: Mon, 29 Mar 2010 10:08:13 +0000
Subject: [New-bugs-announce] [issue8258] Multiple Python Interpreter Memory
	Leak
In-Reply-To: <1269857293.22.0.576084159776.issue8258@psf.upfronthosting.co.za>
Message-ID: <1269857293.22.0.576084159776.issue8258@psf.upfronthosting.co.za>


New submission from William <william.lewis at mastek.com>:

Context:
I am embedding Python into a Windows based C++ application, where a new Python interpreter (using Py_NewInterpreter) is created for each user who connects to the system. When the user logs off, the function "Py_EndInterpreter" is used to free all the associated resources.

Problem:
After starting the application on a server, the memory usage increases rapidly as some users login and log-off from the system.

Some Tests:
I have conducted some tests along with the Python interpreter. I have written a simple C++ program which simply creates 100 Python interpreters and then ends them one by one. If we check the Windows Task Manager, the following are the observations:-

Memory usage before starting to create the Python Interpreters: 4316K
Memory usage after creating 100 Python Interpreters: 61248K
Memory usage after ending the 100 Python Interpreters: 47664K

This shows that there has been a memory leak of approximately 43348K

Please do consider this problem for fixing at the earliest or let me know if I am doing something wrong.

----------
components: Interpreter Core, Windows
files: PythonCall.cpp
messages: 101885
nosy: ewillie007
severity: normal
status: open
title: Multiple Python Interpreter Memory Leak
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file16687/PythonCall.cpp

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

From report at bugs.python.org  Mon Mar 29 14:29:22 2010
From: report at bugs.python.org (owirj)
Date: Mon, 29 Mar 2010 12:29:22 +0000
Subject: [New-bugs-announce] [issue8259] left shift operator doesn't accepts
	long as second	argument
In-Reply-To: <1269865762.04.0.794045726086.issue8259@psf.upfronthosting.co.za>
Message-ID: <1269865762.04.0.794045726086.issue8259@psf.upfronthosting.co.za>


New submission from owirj <cemu at mail.ru>:

python -V:
Python 2.6.5

Executing on 32-bit machine.

>From documentation ( http://docs.python.org/reference/expressions.html ), "5.7. Shifting operations":
"These operators accept plain or long integers as arguments. The arguments are converted to a common type. They shift the first argument to the left or right by the number of bits given by the second argument."

In interpreter:
>>> x = 2677691728509L << 2147483648L
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

hint: 2147483648 = (1 << 31)

First argument is long, second is long too, so expected behavior was normal execution. But as seen from the code above interpreter gives overflow error. Looks like he tries to convert second argument to int type, because this code works gracefully:
>>> x = 2677691728509L << 2147483647L

----------
components: None
messages: 101887
nosy: owirj
severity: normal
status: open
title: left shift operator doesn't accepts long as second argument
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 29 17:09:55 2010
From: report at bugs.python.org (harobed)
Date: Mon, 29 Mar 2010 15:09:55 +0000
Subject: [New-bugs-announce] [issue8260] When I use codecs.open(...) and
	f.readline() follow up by	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

This is an example, last assert return an error :

f = open('data.txt', 'w')
f.write("""line 1
line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
""")
f.close()


f = open('data.txt', 'r')
assert f.readline() == 'line 1\n'

assert f.read() == """line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
"""

f.close()

import codecs

f = codecs.open('data.txt', 'r', 'utf8')

assert f.read() == """line 1
line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
"""

f.close()

f = codecs.open('data.txt', 'r', 'utf8')

assert f.readline() == 'line 1\n'

# this assert return a ERROR
assert f.read() == """line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
"""

f.close()

Regards,
Stephane

----------
components: Library (Lib)
messages: 101892
nosy: harobed
severity: normal
status: open
title: When I use codecs.open(...) and f.readline() follow up by f.read() return bad result
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Mar 29 18:10:38 2010
From: report at bugs.python.org (Jason Mobarak)
Date: Mon, 29 Mar 2010 16:10:38 +0000
Subject: [New-bugs-announce] [issue8261] License link for Python 2.6.5
	release is broken
In-Reply-To: <1269879038.0.0.542921448766.issue8261@psf.upfronthosting.co.za>
Message-ID: <1269879038.0.0.542921448766.issue8261@psf.upfronthosting.co.za>


New submission from Jason Mobarak <jmob at cs.unm.edu>:

The 'Python License' link at

http://www.python.org/download/releases/2.6.5/

results in a 404.

----------
assignee: georg.brandl
components: Documentation
messages: 101894
nosy: georg.brandl, silverjam
severity: normal
status: open
title: License link for Python 2.6.5 release is broken
versions: Python 2.6

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

From report at bugs.python.org  Tue Mar 30 07:09:42 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 30 Mar 2010 05:09:42 +0000
Subject: [New-bugs-announce] [issue8262] bad wording in error message
	attempting to start a Thread	twice
In-Reply-To: <1269925782.78.0.466554273109.issue8262@psf.upfronthosting.co.za>
Message-ID: <1269925782.78.0.466554273109.issue8262@psf.upfronthosting.co.za>


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

Steve Holden, in <http://permalink.gmane.org/gmane.comp.python.general/658347>, about the RuntimeError you get when  a Thread object is started twice:

?"thread already started" implies that the thread is running, but you
actually get the same message if you try to start any terminated thread
(including a canceled one), so "threads cannot be restarted" might be a
better message. Or, better still, "Threads can only be started once".?

This patch fixes the wording as suggested.

----------
components: Library (Lib)
files: threading.diff
keywords: patch
messages: 101918
nosy: gagenellina
severity: normal
status: open
title: bad wording in error message attempting to start a Thread twice
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16695/threading.diff

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

From report at bugs.python.org  Tue Mar 30 12:16:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 10:16:15 +0000
Subject: [New-bugs-announce] [issue8263] regrtest stops prematurately on
	FreeBSD buildbot, with "success" result.
In-Reply-To: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>
Message-ID: <1269944175.56.0.908996591032.issue8263@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The regrtest returns "success", even if the test suite is not run completely.
The last running test is "test_unittest".


http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20trunk/builds/171
...
51 tests OK.
2 tests skipped:
    test_ascii_formatd test_py3kwarn
1 skip unexpected on freebsd6:
    test_ascii_formatd
[294584 refs]
program finished with exit code 0
elapsedTime=1082.949696

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20trunk/builds/168
...
37 tests OK.
5 tests skipped:
    test_bsddb185 test_macostools test_py3kwarn test_startfile
    test_winreg
1 skip unexpected on freebsd6:
    test_bsddb185
[184731 refs]
program finished with exit code 0
elapsedTime=507.756584

----------
components: Tests
keywords: buildbot
messages: 101926
nosy: flox, michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: regrtest stops prematurately on FreeBSD buildbot, with "success" result.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 30 12:52:26 2010
From: report at bugs.python.org (Nick Craig-Wood)
Date: Tue, 30 Mar 2010 10:52:26 +0000
Subject: [New-bugs-announce] [issue8264] hasattr doensn't show private
	(double underscore)	attributes exist
In-Reply-To: <1269946346.53.0.630682854213.issue8264@psf.upfronthosting.co.za>
Message-ID: <1269946346.53.0.630682854213.issue8264@psf.upfronthosting.co.za>


New submission from Nick Craig-Wood <nick at craig-wood.com>:

I just spend a while tracking down a bug in my code which turned out to be an unexpected behaviour of hasattr.

Running this

class Test(object):
    def __init__(self):
        self.__private = "Hello"
    def test(self):
        print(self.__private)
        print(hasattr(self, "__private"))
        print(getattr(self, "__private"))


t = Test()
t.test()

Prints

>>> t.test()
Hello
False
Traceback (most recent call last):
  File "private_test.py", line 10, in <module>
    t.test()
  File "private_test.py", line 7, in test
    print(getattr(self, "__private"))
AttributeError: 'Test' object has no attribute '__private'
>>>

Indicating that even though we just printed self.__private hasattr() can't find it nor getattr().

I think this is probably the intended behaviour, but it does seem inconsistent.

Probably all that is required is a documentation patch...

Maybe something add something like this to the end of

  http://docs.python.org/library/functions.html#hasattr

Note that hasattr won't find private (double underscore) attributes unless the mangled name is used.

----------
components: Interpreter Core
messages: 101928
nosy: ncw
severity: normal
status: open
title: hasattr doensn't show private (double underscore) attributes exist
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Mar 30 12:52:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 30 Mar 2010 10:52:46 +0000
Subject: [New-bugs-announce] [issue8265] test_float fails on ARM Linux EABI
In-Reply-To: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>
Message-ID: <1269946366.65.0.0501186219601.issue8265@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

All the ARM Linux EABI buildbots fail on the same test.

http://www.python.org/dev/buildbot/all/builders/ARM%20Linux%20EABI%202.6/builds/5

test_float
test test_float failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea-armeabi/2.6.klose-linux-armeabi/build/Lib/test/test_float.py", line 665, in test_from_hex
    self.identical(fromHex('0x0.ffffffffffffd6p-1022'), MIN-3*TINY)
  File "/home/pybot/buildarea-armeabi/2.6.klose-linux-armeabi/build/Lib/test/test_float.py", line 375, in identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: 2.2250738585071999e-308 not identical to 2.2250738585071984e-308

----------
components: Interpreter Core
keywords: buildbot
messages: 101929
nosy: flox, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: test_float fails on ARM Linux EABI
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Mar 30 16:34:13 2010
From: report at bugs.python.org (tdjacr)
Date: Tue, 30 Mar 2010 14:34:13 +0000
Subject: [New-bugs-announce] [issue8266] tarfile library should support xz
	compression
Message-ID: <1269959653.86.0.383069027285.issue8266@psf.upfronthosting.co.za>


Changes by tdjacr <tdjacr.foss at gmail.com>:


----------
nosy: thedjatclubrock
severity: normal
status: open
title: tarfile library should support xz compression
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Mar 30 21:18:53 2010
From: report at bugs.python.org (=?utf-8?q?Kent_Engstr=C3=B6m?=)
Date: Tue, 30 Mar 2010 19:18:53 +0000
Subject: [New-bugs-announce] [issue8267] Tutorial secion on dictionary keys
	recommends sort	instead of sorted
In-Reply-To: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>
Message-ID: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>


New submission from Kent Engstr?m <kent at lysator.liu.se>:

The 2.[567] documentation recommends the use of the sort() method
to get a sorted list of dictionary keys. If would be less confusing
to new users if we recommended the sorted() functions instead.

The corresponding piece of Python 3 documentation already uses
the sorted() function.

----------
assignee: georg.brandl
components: Documentation
files: dict.patch
keywords: patch
messages: 101953
nosy: georg.brandl, kent
severity: normal
status: open
title: Tutorial secion on dictionary keys recommends sort instead of sorted
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16699/dict.patch

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

From report at bugs.python.org  Wed Mar 31 00:58:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Mar 2010 22:58:14 +0000
Subject: [New-bugs-announce] [issue8268] Make old-style classes weak
	referenceable
In-Reply-To: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>
Message-ID: <1269989894.58.0.821125509717.issue8268@psf.upfronthosting.co.za>


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

New-style classes are weak referenceable, but old-style classes are not.
For a proper implementation of ABC caches without any memory leaks (see issue2521), this limitation should be raised.

----------
components: Interpreter Core
messages: 101957
nosy: pitrou, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Make old-style classes weak referenceable
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 31 01:26:57 2010
From: report at bugs.python.org (Arnaud Fontaine)
Date: Tue, 30 Mar 2010 23:26:57 +0000
Subject: [New-bugs-announce] [issue8269] Missing return values for PyUnicode
	C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>


New submission from Arnaud Fontaine <arnau at debian.org>:

For example, PyUnicode_FromFormat() does not specify the return value but it does not seem to be only one. I only have a basic knowledge of Python C/API, so I am not sure whether it is meaningful.

----------
assignee: georg.brandl
components: Documentation
messages: 101959
nosy: arnau, georg.brandl
severity: normal
status: open
title: Missing return values for PyUnicode C/API functions
type: feature request
versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Mar 31 02:06:38 2010
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Wed, 31 Mar 2010 00:06:38 +0000
Subject: [New-bugs-announce] [issue8270] Should socket.PF_PACKET be removed,
	in favor of socket.AF_PACKET?
In-Reply-To: <1269993998.45.0.142767118704.issue8270@psf.upfronthosting.co.za>
Message-ID: <1269993998.45.0.142767118704.issue8270@psf.upfronthosting.co.za>


New submission from Denilson Figueiredo de S? <denilsonsa at gmail.com>:

If you look at socket module, there are around 29 AF_* constants (like AF_INET).

On the other hand, there is only one PF_ constant: PF_PACKET. This constant is also defined as AF_PACKET.

Following the "There should be one-- and preferably only one --obvious way to do it." advice, Python 3 removed the <> operator.  I know it's a bit late to change things in Python 3, but should socket.PF_PACKET be removed, in favor of socket.AF_PACKET? (of course, before being removed, it would be left as deprecated for quite some time)

----------
messages: 101966
nosy: denilsonsa
severity: normal
status: open
title: Should socket.PF_PACKET be removed, in favor of socket.AF_PACKET?

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

From report at bugs.python.org  Wed Mar 31 04:28:12 2010
From: report at bugs.python.org (John Machin)
Date: Wed, 31 Mar 2010 02:28:12 +0000
Subject: [New-bugs-announce] [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

Unicode 5.2.0 chapter 3 (Conformance) has a new section (headed "Constraints on Conversion Processes) after requirement D93. Recent Pythons e.g. 3.1.2 don't comply. Using the Unicode example:

 >>> print(ascii(b"\xc2\x41\x42".decode('utf8', 'replace')))
 '\ufffdB'
 # should produce u'\ufffdAB'

Resynchronisation currently starts at a position derived by considering the length implied by the start byte:

 >>> print(ascii(b"\xf1ABCD".decode('utf8', 'replace')))
 '\ufffdD'
 # should produce u'\ufffdABCD'; resync should start from the *failing* byte.

Notes: This applies to the 'ignore' option as well as the 'replace' option. The Unicode discussion mentions "security exploits".

----------
messages: 101972
nosy: sjmachin
severity: normal
status: open
title: str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Mar 31 07:54:32 2010
From: report at bugs.python.org (workshed)
Date: Wed, 31 Mar 2010 05:54:32 +0000
Subject: [New-bugs-announce] [issue8272] Odd exception messages when using
	cStringIO.StringIO	instances as callables.
In-Reply-To: <1270014872.55.0.791249061919.issue8272@psf.upfronthosting.co.za>
Message-ID: <1270014872.55.0.791249061919.issue8272@psf.upfronthosting.co.za>


New submission from workshed <workshed55 at gmail.com>:

Just a minor nit (or I'm missing something), but the results of trying to use a cStringIO.StringIO instance as a callable look wrong to me.  It should of course raise an exception, but shouldn't the 'cStringIO.StringO' and 'cStringIO.StringI' strings reported in the errors below both read 'cStringIO.StringIO'?


winston at eee:~/Python-2.6.5$ ./python
Python 2.6.5 (r265:79063, Mar 30 2010, 22:38:30)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cStringIO
>>> cStringIO.StringIO()()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'cStringIO.StringO' object is not callable
>>> cStringIO.StringIO('')()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'cStringIO.StringI' object is not callable

I get the same results on my Ubuntu 9.10 system with a new build of 2.6.5 and the built in 2.6.4, as well as the 2.5.4 and 2.4.6 versions available in the repos.

Workshed

----------
components: Library (Lib)
messages: 101978
nosy: workshed
severity: normal
status: open
title: Odd exception messages when using cStringIO.StringIO instances as callables.
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 31 13:19:11 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 31 Mar 2010 11:19:11 +0000
Subject: [New-bugs-announce] [issue8273] move test_support into the unittest
	package
In-Reply-To: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>
Message-ID: <1270034351.93.0.515899636762.issue8273@psf.upfronthosting.co.za>


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

Let's move test_support in unittest !

Then maybe, let's expose some of test_support functions into a new class on the top of unittest.TestCase, so they can be used via methods.
 
The purpose is power up people when it comes to write test fixtures or work in a testing environment. These helpers were built to test Python itself, are quite unknown out there. I think it's a shame :)

http://docs.python.org/library/test.html#module-test.test_support

----------
assignee: michael.foord
components: Library (Lib)
messages: 101991
nosy: michael.foord, tarek
severity: normal
status: open
title: move test_support into the unittest package
versions: Python 3.3

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

From report at bugs.python.org  Wed Mar 31 16:11:47 2010
From: report at bugs.python.org (Zubin Mithra)
Date: Wed, 31 Mar 2010 14:11:47 +0000
Subject: [New-bugs-announce] [issue8274] test_run failing
In-Reply-To: <1270044707.08.0.0364512730756.issue8274@psf.upfronthosting.co.za>
Message-ID: <1270044707.08.0.0364512730756.issue8274@psf.upfronthosting.co.za>


New submission from Zubin Mithra <zubin.mithra at gmail.com>:

======================================================================
FAIL: test_run (distutils2.tests.test_build_clib.BuildCLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/test_build_clib.py", line 137, in test_run
    self.assertTrue('libfoo.a' in os.listdir(build_temp))
AssertionError: False is not True

----------------------------------------------------------------------
Ran 135 tests in 1.004s

FAILED (failures=1, skipped=4)
Traceback (most recent call last):
  File "runtests.py", line 18, in <module>
    test_main()
  File "runtests.py", line 12, in test_main
    run_unittest(distutils2.tests.test_suite())
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/__init__.py", line 86, in run_unittest
    _run_suite(suite)
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/__init__.py", line 66, in _run_suite
    raise TestFailed(err)
distutils2.tests.TestFailed: Traceback (most recent call last):
  File "/media/disk/myWorks/working/distutils2/src/distutils2/tests/test_build_clib.py", line 137, in test_run
    self.assertTrue('libfoo.a' in os.listdir(build_temp))
AssertionError: False is not True

----------
assignee: tarek
components: Distutils2
messages: 102011
nosy: tarek, zubin71
severity: normal
status: open
title: test_run failing
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Mar 31 20:53:45 2010
From: report at bugs.python.org (Jasmit)
Date: Wed, 31 Mar 2010 18:53:45 +0000
Subject: [New-bugs-announce] [issue8275] callback function on win64 results
	in bad behavior. mem	leak?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>


New submission from Jasmit <jsingh at roguewave.com>:

I am testing a wrapper on Windows 64 and it seems to result in an null pointer access error ONLY when I insert a print statement in the C code.  I have tested the wrapper with Python 2.6 and Python 2.7a4.  In addition, I have compiled Python 2.6.5 source code and ONLY the release version results in an error.  I think the issue is with memcpy(obj->b_ptr, *pArgs, dict->size) (callbacks.c).  pArgs seem to be  corrupted.  However, I am only looking at the code for the first time and I might be off base.

The following is Python and C code to reproduce the bug.  To resolve, please comment printf statement in jfunc (C function).

Python Code:
from ctypes import *
def fcn(m,n,x,f):
    print "IN Python function fcn ................"
    print f[0]
    
m=3
n=1
pydlltest=cdll.pydlltest
pydlltest.jfunc.restype = POINTER(c_double)
evalstring = 'pydlltest.jfunc('
TMP_FCN=CFUNCTYPE(None,c_int,c_int,POINTER(c_double),POINTER(c_double))
tmp_fcn=TMP_FCN(fcn)
state=[TMP_FCN,tmp_fcn]
evalstring += 'tmp_fcn'
evalstring +=','
evalstring +='c_int(m)'
evalstring +=','
evalstring +='c_int(n)'
evalstring += ')'
print "evalstring=",evalstring
result = eval(evalstring)

C code:
#include <stdio.h>
__declspec(dllexport) double *jfunc(void (*fcn) (int,int,double [],double[]),int m,int n);

double *jfunc(void (*fcn) (int,int,double [],double []),int m,int n)
{
	double *fvec=NULL;
	double *xguess = NULL;
	int i = 0;
	int j = 0;
	/* comment the line below to fix the resulting null pointer access error */
	printf("In j func .................\n");
	fvec = (double *) malloc (m * sizeof (double));
	xguess = (double *) malloc (n * sizeof (double));
	for (i = 0; i < n; i++){
	   xguess[i] = 0.123;
	}
	(*fcn) (m, n, xguess, fvec);
	return fvec;
}

----------
assignee: theller
components: ctypes
files: ctype_win64.txt
messages: 102028
nosy: ocrush, theller
severity: normal
status: open
title: callback function on win64 results in bad behavior. mem leak?
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16708/ctype_win64.txt

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